n8n and MCP: Three Surfaces, Not Two (Source-Verified)

Almost every n8n MCP article tells you the same story: n8n can be an MCP server, or an MCP client, two directions, one arrow. That framing is incomplete, and the parameter names those articles print are wrong. n8n ships three structurally different MCP surfaces, and its published docs materially disagree with its own shipped code. Here is what the node source actually says, why your screen does not match the screenshots, and a falsifiable rule for when to walk away.

The four things called n8n MCP

Search n8n mcp server and you get four different answers, three of which are real products and one of which is not n8n's at all. Before any tutorial makes sense, you need to know which one you are looking at.

• The MCP Server Trigger node. Internal name mcpTrigger. The source description is exactly Expose n8n tools as an MCP Server endpoint. It turns one workflow into an MCP server whose tools you author by hand.
• The instance-level MCP server. A separate endpoint at https://<your-n8n-domain>/mcp-server/http. It exposes n8n's own control plane — roughly thirty tools that let an AI client search, build, publish and execute your workflows. n8n authors these tools, not you.
• The MCP Client Tool node. Internal name mcpClientTool, described in source as Connect tools from an MCP Server. This is n8n consuming somebody else's tools inside an AI Agent.
• czlonkowski/n8n-mcp. Not an n8n product. A community repo with over 22,000 stars that bills itself as an MCP for Claude Desktop, Claude Code, Windsurf or Cursor to build n8n workflows for you. Most people typing n8n mcp github want this. There is also an older community node, nerding-io/n8n-nodes-mcp, from before the built-ins existed.

The useful mental model is not a two-way arrow. It is a grid: does n8n expose or consume, and who authors the tools? The first two surfaces are both "n8n as MCP server" and they are nothing alike — one exposes a workflow you built, the other exposes n8n itself. Conflating them is the single most common error in this topic. If you are still deciding whether MCP is the right integration shape at all, our breakdown of MCP versus a plain API is the better starting point.

One framing note before we go further: MCP is an open protocol originally created by Anthropic and donated to the Linux Foundation's Agentic AI Foundation on 9 December 2025. Do not write "Anthropic's MCP". Do not overcorrect either — the donation did not hand over maintainership. The announcement is explicit: The people making decisions about the protocol are still the maintainers who have been stewarding it, guided by community input through our SEP process. The current protocol revision is 2025-11-25, not the 2025-06-18 that most blog posts still cite.

Why the docs do not match your screen

This is the part no competing article will tell you, because they all transcribe the same page. n8n's published MCP docs materially disagree with n8n's shipped code. Verified against the raw node source in packages/@n8n/nodes-langchain/nodes/mcp/ in July 2026:

• The client node docs are wrong about the endpoint field. The published docs page documents exactly one connection field and calls it SSE Endpoint: The SSE endpoint for the MCP server you want to connect to. The source says sseEndpoint is used only at @version: [1]. From @version >= 1.1, the field is Endpoint (endpointUrl) and there is a Server Transport dropdown next to it. The docs mention neither.
• The trigger docs omit an entire auth mode. The docs list only Bearer auth and Header auth. The source has four options: none (the default), bearerAuth, headerAuth, and n8nOAuth2 — labelled n8n User Auth (OAuth2), gated to node version 2 and above, described as Require user to give consent to use their n8n account.

There is a second reason your screen may differ from any screenshot: n8n does not auto-upgrade the typeVersion of nodes already on your canvas. A client node you placed a year ago is pinned at its original version and will keep showing the old UI, while a node you drag in today comes in at 1.4. Both are correct. Any tutorial that prints one universal click-path is wrong for half its readers. Check the node version before you trust a walkthrough — including this one.

Surface 1: MCP Server Trigger

The trigger has two properties that matter more than anything in the tutorials.

It is Tools-only, and it has no outputs. The source declares a single input — an AiTool connection named Tools — and an empty outputs array. The docs put it plainly: the node only connects to and executes tool nodes. Unlike every other trigger in n8n, it does not pass output downstream. To expose a whole workflow you must wrap it in a Custom n8n Workflow Tool node. And because MCP servers can serve Tools, Resources and Prompts, this is a real ceiling: n8n cannot serve Resources or Prompts at all.

It defaults to no authentication. The source default is none, and n8n's own in-source builder hint is candid about why: Default to 'none'. n8n exposes inbound trigger URLs publicly by design. Only select an authentication method when the user explicitly asks to authenticate inbound traffic. Read that again in context. An MCP Server Trigger left at its default is a publicly callable tool endpoint — an unauthenticated URL that lets anyone who finds it execute your tools. The path parameter defaults to a random string, which is obscurity, not security. If you take one action from this article, set Bearer or Header auth before you go to production.

On version 2 you also get Require Workflow Execute Permission (requireExecuteAccess, default true), which appears only when you pick the OAuth2 mode and gates whether the calling user must also hold execute permission.

Surface 2: the instance-level server

This is the surface almost nobody writes about, and it is the most powerful. Enable it and an MCP client gets tools like search_workflows, get_workflow_details, execute_workflow, publish_workflow, search_nodes, validate_workflow, create_workflow_from_code and a set of data-table operations. In other words, Claude Code can build your n8n workflows for you — the exact job the third-party czlonkowski repo was invented to do, now shipped in the box.

Auth is OAuth2 (recommended for Claude Code) or a personal MCP Access Token that n8n generates on your first visit to the Access Token tab. Enabling it needs instance owner or admin permissions. Version gates, as documented in July 2026: the MCP settings page lands in v2.2.0, workflow building and editing in v2.13, bulk project and folder management in v2.24.0. Expect the tool list to have grown by the time you read this — count the entries in n8n's tools reference rather than trusting any article's number, including ours.

Three documented limitations deserve to be louder than they are:

• Enablement is two-step. Instance level, then each workflow individually. There is no blanket exposure.
• It is not scoped per client. Every client you connect sees every workflow you enabled. You cannot give one agent a subset.
• execute_workflow defaults to production mode and runs the published version. An agent calling it is hitting your live system, not a sandbox. Most other tools operate on unpublished workflows; this one is the exception, and it is the dangerous one.

Surface 3: MCP Client Tool

The client is a sub-node: no inputs, one AiTool output named Tools, hung off an AI Agent. Source-verified specifics, July 2026:

• Versions [1, 1.1, 1.2, 1.3, 1.4], defaultVersion: 1.4. No beta label on the node — though note n8n has not published a formal GA declaration either; that is an inference from the absence of a label.
• Transport dropdown — displayName Server Transport, name serverTransport, description The transport used by your endpoint. The two options are literally HTTP Streamable (httpStreamable) and Server Sent Events (Deprecated) (sse). Default is sse at version 1.1 and httpStreamable at 1.2 and above.
• Auth credentials: httpBearerAuth, httpHeaderAuth, mcpOAuth2Api, httpMultipleHeadersAuth, default none. Note the dedicated MCP-specific OAuth2 credential type — but do not assume it implements the 2025-11-25 auth spec's PKCE and RFC 8707 resource-parameter requirements; n8n does not claim spec compliance and we have not verified it.
• Tools to Include: all (default), selected, or except. Request timeout defaults to 60000 ms.

Now the part where most write-ups would hand you a scary headline and stop. n8n issue #24967 is titled [MCP Client] Transport selection dropdown ignored - causes 95M failed requests retry storm, and the reporter's self-reported impact — one user's number, not n8n telemetry — was roughly 97.6 million failed requests over eight days against their own infrastructure. It is a real, still-open issue. But the title's diagnosis does not survive the thread. The reporter's evidence was GET requests carrying accept: text/event-stream, read as proof the node had silently fallen back to SSE. An n8n maintainer answers directly that this is expected behaviour: The HTTP Streamable transport will still try to open a SSE connection with a GET request to receive messages from the server. That matches the spec — under Streamable HTTP the client MAY issue an HTTP GET to open an SSE stream. So GET plus text/event-stream is not evidence of the wrong transport.

The real defect is stream lifecycle, not transport selection. PR #31087 — fix(MCP Client Tool Node): Tie transport lifecycle to execution cancel signal to prevent GET stream leak, merged June 2026 and released in v2.26.0 — fixed exactly the mechanism that produces a request storm: the MCP SDK's transport auto-reconnects after server timeouts unless an AbortSignal is passed, and n8n was not passing one, so GET streams leaked and accumulated. A separate draft PR, #34397, closes cached client sessions when an execution finishes. If you are on a version before 2.26.0 and seeing runaway requests, upgrade before you touch the dropdown. An earlier, closed report of the same symptom is #18938. Streamable HTTP support arrived in the client via community PR #15454, which is worth knowing — this surface is young and retrofitted, not designed in.

If you are shopping for what to plug in on the other end, see our roundup of the best MCP servers, and the Google Ads MCP server for a concrete worked case.

The SSE deprecation half-truth

n8n's dropdown says Server Sent Events (Deprecated), and readers reasonably conclude that MCP dropped SSE. It did not.

The spec defines exactly two standard transports: stdio, communication over standard in and standard out and Streamable HTTP, and says clients SHOULD support stdio whenever possible. Streamable HTTP replaces the HTTP+SSE transport from protocol version 2024-11-05, and that old transport is the thing marked deprecated. But Streamable HTTP itself still uses SSE: the spec says the server can optionally make use of Server-Sent Events (SSE) to stream multiple server messages. The difference is architectural — the old transport used two endpoints, Streamable HTTP uses a single MCP endpoint handling both POST and GET.

So: pick HTTP Streamable, because the two-endpoint transport is on the way out. But do not say "SSE is dead" in your postmortem, and do not be surprised when your Streamable HTTP connection carries text/event-stream. This is not academic — it is precisely the misreading that produced the headline on #24967 above. Before you blame the dropdown, check your n8n version and check whether the traffic you are staring at is just the listener stream doing its job.

When not to use n8n for MCP

Most articles' downsides section says something like "less flexible than code." Here are three constraints you can actually check, each from a primary source.

1. Do not use n8n as your MCP server if you need to scale horizontally. The docs state the trigger relies on Server-Sent Events (SSE) or streamable HTTP, which require the same server instance to handle persistent connections. Queue mode with a single webhook replica is fine. But if you run multiple webhook replicas, you need to route all /mcp* requests to a single, dedicated webhook replica — otherwise connections frequently break or fail to deliver events reliably. Your MCP server becomes a deliberate single point of failure. Related: behind nginx you must disable proxy buffering for the endpoint, and may need to disable gzip and chunked transfer encoding and clear the Connection header. A default nginx config silently breaks the stream.

2. Do not use n8n as an MCP server for Claude if n8n is private. This is the one that kills projects on day one. Anthropic's documentation states that Claude connects to your remote MCP server from Anthropic's cloud infrastructure, rather than from your local device, and that this holds for every Claude client, including claude.ai, Claude Desktop, Cowork, and the mobile apps. Consequently: Servers hosted on a private corporate network, behind a VPN, or blocked by a firewall won't connect, even if you can reach them from your own machine. You must expose the endpoint publicly and allowlist Anthropic's IP ranges (check their docs for current ranges — do not hard-code them). No node setting fixes this. There is one documented escape hatch worth knowing about: Anthropic's MCP tunnels carry traffic to private-network MCP servers over an outbound-only connection, with no inbound ports and no origin IP allowlist. It does not rescue this path today — tunnels are a research preview, and Anthropic's docs state that tunnels created through the Console are not available as connectors in claude.ai, so they serve Managed Agents and the Messages API rather than the consumer clients. Note also that this whole constraint is the custom-connector path specifically; a locally launched stdio server is a different mechanism.

3. Do not use n8n as your MCP server if the tool is hot. Every tool call is a full workflow execution — latency, plus execution billing on n8n Cloud. And since the trigger only connects to tool nodes, you get no post-trigger orchestration to amortise it.

The rule, stated so you can falsify it:

Use n8n as the MCP server when the tool is cold, human-shaped, and already glued to n8n's integrations. Write your own server the moment it is hot, needs to scale past one replica, or needs Resources or Prompts — because n8n-as-server is Tools-only.

If you land on the write-your-own side, we walk through it in how to build an MCP server. If you land on n8n, the model driving the agent matters as much as the plumbing — see the best LLMs for AI agents in 2026, and what an LLM gateway does if you want to swap models without touching the workflow.

One last piece of context for why any of this is worth the trouble. Anthropic's December 2025 donation post reports There are now more than 10,000 active public MCP servers, covering everything from developer tools to Fortune 500 deployments, with 97M+ monthly SDK downloads across Python and TypeScript. Treat those as a dated floor, not a current count. The Agentic AI Foundation was co-founded by Anthropic, Block and OpenAI with support from Google, Microsoft, AWS, Cloudflare and Bloomberg — which is the real argument for building on MCP rather than a vendor's bespoke plugin format. Official SDKs are tiered across ten languages, not two: TypeScript, Python, C# and Go at tier 1, Java and Rust at tier 2, Swift, Ruby, PHP and Kotlin at tier 3.

FAQ