NodeRecipe.

n8n MCP: The Three Different Things That Name Means (2026)

n8n MCP means three different features: instance-level MCP access, the MCP Server Trigger node, and the MCP Client Tool node. Which one you need, how to set it up, and what breaks.

By Ali Ilyas · · Updated September 15, 2026

"n8n MCP" is three separate features that share a name, and most of the confusion around them is people following instructions for one while trying to build another.

They point in different directions. One turns your whole n8n instance into a server that Claude Code or Cursor can drive. One turns a single workflow into a server. One does the reverse and lets a workflow call somebody else's server. Picking the wrong one costs you an afternoon, because each has its own setup path and none of the steps transfer.

This page sorts out which is which, then covers the parts that actually break: queue mode, reverse proxies, and what you exposed without meaning to.

What's on this page

Which one do you want?

You want to…UseWhere it lives
Let Claude Code, Cursor or ChatGPT read, build and run workflows in your instanceInstance-level MCP accessSettings → Instance-level MCP
Hand an AI client a small, hand-built set of tools from one workflowMCP Server Trigger nodeA node on the canvas
Let an n8n AI agent call an outside service's MCP serverMCP Client Tool nodeA sub-node under an AI Agent

The first two are both "n8n as a server" and they are easy to mix up. The distinction is scope: instance-level access is one connection for the whole instance with central authentication and a per-workflow allow-list, while the Server Trigger node exposes only the tools you wire into that one workflow. If you want an AI assistant that can generally operate n8n, you want the first. If you want to publish a deliberately narrow tool — "check stock levels", nothing else — you want the second.

The third is the odd one out. It is not about exposing n8n at all; it is about consuming someone else's MCP server from inside a workflow, and it only makes sense attached to an n8n AI agent.

1. Instance-level MCP access

This is the newest of the three and the one most people mean in 2026. It lets a supported client connect to your instance and search workflows, run the ones you have exposed, and — from n8n 2.13.0 — create and edit workflows and data tables.

Turning it on:

  1. Settings → Instance-level MCP, then Enable MCP access. You need instance owner or admin permissions.
  2. In Connection details, select Connect, pick your client, and follow the steps shown.
  3. Copy the Server URL. It ends in /mcp-server/http.

Authentication is either OAuth (n8n's recommendation) or an API key. The API key path has one detail worth catching before you close the tab: n8n shows the generated token once. Leave the tab and you get a redacted value, and the only way back is to rotate it — which revokes the old token and means updating every client already using it.

On self-hosted instances you can drive the same switch from the environment instead:

N8N_MCP_ACCESS_ENABLED=true      # turn instance-level MCP on
N8N_MCP_MANAGED_BY_ENV=true      # apply MCP settings at every startup, lock the UI controls
N8N_DISABLED_MODULES=mcp         # remove the feature entirely: endpoints and UI

N8N_MCP_MANAGED_BY_ENV is the one to reach for if you run more than one instance and want them to stop drifting apart. It locks the matching controls in the UI, so nobody fixes staging by clicking something that gets wiped on the next deploy. If you are not running n8n yourself yet, the self-hosted n8n setup covers where these variables go.

Exposing workflows, and the one exception

Enabling MCP on the instance exposes nothing by itself. Each workflow has to be enabled individually — from the Workflows exposed page, the workflow's own Settings → Available in MCP toggle, or the workflow card menu. From n8n 2.24.0 you can toggle a whole project or folder at once, and from 2.36.0 there is an Auto-expose new workflows setting that applies to workflows created afterward.

Not every workflow is eligible. A workflow can only be exposed if it is published and contains a webhook, form, schedule, or chat trigger.

The exception to the allow-list is search_workflows. It reaches every workflow the connecting user has permission to view, exposed or not. It returns previews only — names, descriptions, timestamps, tag and trigger counts — not the workflow body. That is still a real disclosure: workflow names in most instances are descriptive, and a preview list is a map of what the business automates.

What the client can actually do

The tools reference lists 47 entries across six categories — workflow management, execution management, credential management, the workflow builder, agent management, and data tables. Forty-six are tools; one is a reference resource.

Two of them deserve reading before you connect anything:

  • execute_workflow defaults to production mode, meaning it runs the published version, not whatever is open on your canvas. It accepts a manual mode for the current unpublished version. The default is the safe one for your editor and the dangerous one for your data.
  • list_credentials exists. It does not hand over secrets, but it confirms which services the instance holds credentials for.

n8n also publishes n8n Skills — a set of capability modules in the n8n-io/skills repository, 13 capability skills plus a meta-skill that routes between them, with 50+ reference documents. They exist because a coding agent connected to the MCP server can build workflows but does not know n8n's conventions for expressions, error handling or sub-workflows. They are plain Markdown, so you can read them before installing them, which is the right order.

2. The MCP Server Trigger node

This node turns one workflow into its own MCP server, exposing only the tools you attach to it.

It behaves unlike every other trigger in n8n, and this is the part that confuses people on first use: it only connects to tool nodes. A normal trigger fires and passes its output down the chain. The MCP Server Trigger does not have a chain. Clients list the tools hanging off it and call them individually. To expose an existing workflow as one of those tools, attach it with the Custom n8n Workflow Tool node.

The node gives you two URLs, test and production, on the same split as the n8n Webhook node: the test URL registers when you click Listen for Test Event and shows data on the canvas; the production URL registers when you publish and shows nothing, with the run visible under Executions instead.

Authentication is None, Bearer, or Header. The path is randomly generated by default to avoid collisions with other Server Trigger nodes, and you can override it if you need stable endpoints.

Transport: why Claude Desktop needs a shim

The node supports Server-Sent Events (SSE) and streamable HTTP. It does not support stdio.

That matters because several desktop clients speak stdio. n8n's documented workaround is to run a gateway that proxies between them:

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "<MCP_URL>",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<MCP_BEARER_TOKEN>"
      }
    }
  }
}

If a client connects to instance-level MCP without any of this, that is expected — the instance server speaks HTTP directly. The shim is a Server-Trigger-node problem, not a general n8n MCP problem, and this is exactly the kind of instruction that gets copied from the wrong section.

3. The MCP Client Tool node

The other direction. This is a sub-node you attach to an AI Agent, and it lets the agent call tools on an external MCP server.

Before adding it manually, check the node panel: n8n keeps a registry of MCP servers, and if the service you want is in it, you connect from the panel and sign in, and n8n creates the credential for you. The MCP Client Tool node is for servers that are not in the registry yet. The registry's contents change often enough that no written list is worth trusting — look in the panel.

Configured manually, the node takes an SSE Endpoint and an authentication method: Bearer, a generic header, multiple headers, or OAuth2. Multiple Headers Auth covers servers wanting both an API key and a username.

The parameter to think about is Tools to Include:

  • All — the agent sees every tool the server exposes.
  • Selected — only the ones you list.
  • All Except — everything but the ones you exclude.

All is the default shape of least effort and the wrong one for most builds. Every exposed tool costs context on every call, and the agent's decision space grows with each one. n8n's own docs frame the trade directly: a built-in node gives you tighter control because you fix the operation and pin the parameters, leaving the model only the fields you choose; an MCP server gives the agent range at the cost of control and context. If you know the agent needs to post to one Slack channel, the Slack node is the better tool, not an MCP server that can also delete things.

The five things that break it

1. Queue mode with multiple webhook replicas. SSE and streamable HTTP need the same server instance to hold a persistent connection. One webhook replica is fine. With several, you must route all /mcp* requests to a single dedicated webhook replica — a separate replica set with one webhook container, and ingress or load balancer rules sending /mcp* there. Skip this and connections break intermittently or silently fail to deliver events, which is the worst failure shape to debug because it looks like the model being flaky.

2. Reverse proxy buffering. Behind nginx, the MCP endpoint needs buffering off. n8n's documented location block:

location /mcp/ {
    proxy_http_version          1.1;
    proxy_buffering             off;
    gzip                        off;
    chunked_transfer_encoding   off;

    proxy_set_header            Connection '';

    # The rest of your proxy headers and settings
}

Setting these explicitly on the MCP location matters even if you think they are already off — the point is to stop them being inherited from elsewhere in the config. A proxy, load balancer or WAF that strips MCP request headers will also break the connection; n8n allows the routing headers in its CORS policy from 2.36.0.

3. "You do not have sufficient permissions to authorize this request." This message is misleading. For the instance MCP server it means MCP access is not enabled on the instance — not that your user lacks a role. While the server is running, any signed-in user can approve a client; while it is off, n8n refuses everyone. Ask an owner or admin to turn it on.

4. claude.ai asks you to sign in even when Authentication is None. Known behaviour, and claude.ai is the only client documented as doing it. It assumes every MCP endpoint on a domain uses the same user authentication the instance offers elsewhere. Not a misconfiguration on your side.

5. Cloud clients cannot reach a private instance. Obvious written down, less obvious at 1am: a browser-based client needs your instance publicly reachable. If you are testing against localhost, only a local client will connect. Same class of problem as a webhook URL that still says localhost.

What MCP does not give you: the retry problem

MCP is a transport and a tool-description format. It is not a transaction system, and nothing about connecting a model to your workflows makes those workflows safe to call twice.

This is worth spelling out because the failure is invisible in testing and expensive in production. Of the 46 tools the n8n MCP server exposes, exactly one — archive_workflow — is documented as idempotent. Nothing in the MCP documentation describes deduplication, an idempotency key, or a replay guard for execute_workflow.

So, the four questions worth answering before you expose a workflow that does anything irreversible:

What happens on a retry? The action happens again. If an agent calls a tool, gets a timeout, and calls it again — which is ordinary agent behaviour, not a bug — the workflow runs a second time. If it sends, charges, posts or creates, it does that twice. n8n tracks nothing about which steps already succeeded.

What happens under concurrent execution? Nothing serialises MCP calls. Two clients are connected to the same instance and both can call execute_workflow on the same workflow at once. Any guard built as "look up a key, then write if absent" is not atomic and will let both runs through when they interleave.

What happens on partial failure? An agent that calls three tools and fails on the third leaves the first two done. There is no rollback and no compensating action unless you wrote one.

What happens out of order? The model decides the order. That is the entire point of an agent, and it means any sequencing assumption you would get for free in a fixed workflow is gone. A tool that is only correct when it runs after another tool needs to enforce that itself.

The practical answer is the same one that applies to any n8n AI agent: make the write idempotent at the destination, check a key before the irreversible step while accepting that the check is not atomic, and expose read-only tools freely while treating write tools as things you allow-list one at a time. Our free n8n workflow templates include an error handler and a heartbeat monitor, which is the floor for anything running unattended — and 84.8% of published n8n workflows have no error handling at all, so the floor is not where most people start.

What you actually exposed

Three properties of instance-level MCP that are easy to miss, and all three are disclosure questions rather than convenience questions:

Access is not scoped per client. Every client you connect sees every workflow you have enabled. Connect Claude Desktop and ChatGPT and both see the same set; you cannot give one client a subset. Visibility stays user-scoped — a user only sees MCP-enabled workflows they already have access to — but that is a different axis from client scoping.

search_workflows sees past the allow-list. Previews only, as above, and previews of everything the user can view.

OAuth callback URLs are unrestricted by default. n8n allows any callback URL unless you change it. Settings → Instance-level MCP → Access → Allowed callback URLs, switch to Only trusted URLs, and list the ones you expect. n8n's own documentation calls the default less secure, and this is a two-minute change.

If you enabled MCP to try it and moved on, the honest cleanup is to revoke the clients: Connected clients → View all → Revoke access. Note that API-key clients do not appear in that list, because they authenticate with a bearer token rather than an OAuth connection — for those, rotate the token.

Frequently asked questions

Is n8n an MCP server or an MCP client? Both, through different features. Instance-level MCP access and the MCP Server Trigger node make n8n a server. The MCP Client Tool node makes a workflow a client of someone else's server.

Do I need the MCP Server Trigger node to connect Claude Code to n8n? No. That is instance-level MCP access — Settings → Instance-level MCP — and it needs no node on any canvas. The Server Trigger node is for publishing a narrow, hand-built tool set from one workflow.

Why does my MCP connection keep dropping? The two usual causes are queue mode with more than one webhook replica, and a reverse proxy buffering the response. Both break the persistent connection SSE and streamable HTTP depend on.

Does the MCP Server Trigger support stdio? No — SSE and streamable HTTP only. Clients that speak stdio need a gateway such as mcp-remote in between.

Which workflows can I expose to MCP clients? Published workflows containing a webhook, form, schedule, or chat trigger. Others are not eligible, regardless of the instance setting.

Can I stop MCP being available at all on a self-hosted instance? Yes. N8N_DISABLED_MODULES=mcp removes the endpoints and hides the related UI.

Does exposing a workflow to MCP let a client see my credentials? The list_credentials tool reports which credentials exist, not their secret values. Treat the names themselves as information you are disclosing.

Will an MCP client run my unpublished workflow? execute_workflow defaults to production mode and runs the published version. It supports a manual mode for the current unpublished one, so the answer depends on what the client asks for.

Primary references: n8n's Connect to n8n MCP server guide, the MCP server tools reference, the MCP Server Trigger node docs, and the MCP Client Tool node reference.

Version notes above reflect n8n's documentation as of 2026-09-15; MCP is moving quickly and feature availability is version-gated, so check your instance's version before assuming a setting exists. If MCP is the reason you are setting n8n up in the first place, start with n8n in Docker and then what n8n is and how it works — MCP is a good deal easier to reason about once workflows and items are familiar.