# Disabling tools that can work as read/write operations (n8n_executions, n8n_workflow_versions)

[mahmoudnaif]

Read-Only Usage Concerns with Certain MCP Tools

Hello everyone 👋

We’re planning to use this excellent MCP in read-only mode, and overall, it fits our needs really well. There is already an environment variable that allows disabling tools globally, which is great.

However, we ran into an issue with tools that support both read and write operations within the same tool.

---

Example: n8n_workflow_versions

The n8n_workflow_versions tool is a good example.
As shown in the image below, the tool can operate in both read and write modes, depending on the selected attributes:

Read operations

• List workflow versions
• Get workflow version details

These would be extremely valuable for our users in a read-only setup.

Write / destructive operations

• Delete versions
• Roll back to a previous version
• Truncate versions

Because these actions are exposed through the same tool, simply enabling or disabling the tool as a whole doesn’t give us the level of control we need.

---

Missing Read-Only Control

Unfortunately, I couldn’t find:

• An out-of-the-box read_only_mode for such tools, or
• A way to restrict the tool to GET / LIST operations only, while disabling mutating actions

(Please correct me if I’m missing something here.)

---

Another Example

The same concern applies to the n8n_executions tool, which also mixes read-only and write/destructive capabilities.

---

Any guidance, best practices, or planned support for per-operation read-only control would be greatly appreciated.

Thanks! 🙏

[christiansousadev]

Hi @mahmoudnaif,

You've raised a vital point regarding IT Governance and Operational Risk. In enterprise environments, granting an LLM "Write/Delete" access to workflow versions is often a deal-breaker for security teams.

Since the current MCP implementation bundles these actions within the same tool, here are three strategies to enforce a read-only state from an architectural perspective:

1. The "API Key Scoping" Strategy (Infrastructure Level)
   The most robust way to ensure read-only behavior is at the Source of Truth (the n8n API).

Create a specific API Key in n8n for the MCP.

If your n8n version supports granular RBAC (Role-Based Access Control) for API keys, restrict this key to View-only permissions.

Result: Even if the LLM tries to call a Delete operation, the n8n API will return a 403 Forbidden, maintaining the integrity of your workflows.

2. The "Schema Filtering" Workaround (Middleware Level)
   If you are running the MCP via Docker, you can intercept the tool definitions before they reach the LLM.
   A common pattern in Governance-driven architectures is to use a small wrapper or a modified tools configuration that prunes the "mutating" methods (Delete, Rollback, Truncate) from the JSON schema exposed by the MCP.

3. Proposed Feature: "Allowed Methods" Filter
   A great addition to this project would be an environment variable like DISABLED_TOOL_METHODS.

Example: DISABLED_TOOL_METHODS=delete,truncate,rollback

The server would then filter out any operation containing these keywords from the list_tools output.

Why this matters for Governance:
Without this separation, you risk "Agentic Hallucinations" where the AI might accidentally trigger a rollback during a troubleshooting session. Implementing a Read-Only Proxy ensures that the AI remains an "Observer" and not an "Operator" with destructive power.

I strongly support the need for a granular read_only flag per tool. Until then, Scoping the API Key is your safest bet for production environments.

[czlonkowski]

Hey @mahmoudnaif — you are not missing anything, and @christiansousadev is right on all three points. Let me give you the honest state of the world.

What exists today. There is a DISABLED_TOOLS env var that filters at the tool level — set DISABLED_TOOLS=n8n_workflow_versions,n8n_executions,... and those tools do not show up in list_tools at all. The catch is exactly what you described: it is all-or-nothing, so you lose list/get along with the destructive actions.

I confirmed the shape of both tools you flagged by reading the handlers:

• n8n_workflow_versions actions: list, get (read) / rollback, delete, prune, truncate (write)
• n8n_executions actions: list, get (read) / delete (write)

So yes, bundled. There is no per-operation gate anywhere in the code today — the tools carry destructiveHint: true metadata but nothing enforces it at runtime.

What I would actually do in production right now. Christians point #1 is the strongest answer for enterprise-grade read-only: create a read-only API key in n8n (newer versions support scoped keys) and let the n8n API return 403 on anything destructive. That is a hard boundary the LLM cannot cross and it is orthogonal to what we ship here. Belt-and-braces: combine it with DISABLED_TOOLS=n8n_delete_workflow,n8n_update_full_workflow,n8n_update_partial_workflow,n8n_manage_datatable,n8n_manage_credentials to prune the obviously-write tools, and keep n8n_workflow_versions/n8n_executions enabled — the API key scoping will block the destructive branches inside them.

On the feature request. Christians option #3 is the right shape — an env var that filters operations at dispatch time before the handler runs, so you keep list/get and lose the rest. I like it, it is on my radar, and it is cheap to implement. No ETA yet, but it is a good candidate. Open to a PR if you or anyone here wants to take a swing — happy to review.

Thanks for the detailed writeup, and Christian, thanks for the thoughtful breakdown. Exactly the kind of governance framing that makes this project better.

[czlonkowski]

Tracked as #714 — feel free to chime in over there with any constraints I missed.