n8n and MCP: Four Different Things With the Same Name

You search n8n mcp, open the first four results, and they describe four different things. One is a settings toggle that lets Claude build workflows inside your instance. One is a trigger node that turns a single workflow into an MCP endpoint. One is a sub-node that lets an n8n agent call somebody else's MCP server. And one is a community npm package that happens to be called n8n-mcp.

They point in opposite directions. Two of them make n8n the server and one makes it the client, which means picking the wrong one does not give you a worse version of what you wanted — it gives you the reverse of it. The documentation for each is fine in isolation; what is missing is the page that tells you which one you are supposed to be reading.

This is that page.

The Direction Question Comes First

Before anything else, answer one question: is the model inside n8n, or outside it?

If the model is outside — you are in Claude Desktop, Cursor, ChatGPT or a coding agent, and you want it to reach into n8n — then n8n is the server. You want option 1 or option 2 below.

If the model is inside — you have built an AI Agent node on a canvas and you want it to reach out to something else — then n8n is the client. You want option 3.

Almost every hour lost to this is lost by skipping that question. The word "MCP server" appears in the name of all three, because in the first two n8n is the server and in the third you are connecting to a server.

Option 1: The Built-In Instance MCP Server

This is the one most people mean when they say "n8n MCP", and it is the newest. You enable it once in your instance settings, authenticate a client with OAuth or an access token, and an external AI application can then work with your n8n instance directly: find workflows, run the ones you have exposed, and — the recent addition — create and edit workflows and data tables from a prompt.

The details that matter:

• One connection per instance, with centralised authentication. You are not configuring anything per workflow beyond a visibility flag.

• Discovery and access are separate. A client can see previews of workflows the connected user has access to via search_workflows, but it cannot read full workflow data, execute, or modify anything unless you have explicitly enabled MCP access on that workflow. The default is closed, which is the right default — and there is a companion setting that opts new workflows in automatically, which is worth leaving off unless you have decided otherwise on purpose.

• It is in every edition, including the free self-hosted Community Edition, and it is maintained by n8n rather than being a service you run alongside.

• It builds by generating TypeScript, not JSON. n8n's stated reason is that the model has to produce something that type-checks before anything touches your instance, which is a meaningfully better failure mode than a model emitting malformed workflow JSON.

• From n8n 2.33.0 the UI walks you through per-client setup and groups the clients into CLI, Web and IDE. Below that version you configure the client by hand.

Use it when the thing you want is n8n itself under model control. It is a build-and-operate surface, not a data surface.

Option 2: The MCP Server Trigger Node

This one exposes one workflow as its own MCP server. You drop an MCP Server Trigger onto a canvas, attach tool nodes to it, and the node gives you a URL that any MCP client can call.

It behaves unlike every other trigger you have used. A normal trigger fires and passes its output down the chain. This one does not have a chain — it only connects to tool nodes, and the client decides which of them to call. You are not building a workflow that runs; you are building a menu that something else orders from.

What you get to configure:

• Two URLs, test and production. The test URL registers when you click "Listen for Test Event" and shows you the data on the canvas. The production URL registers when you publish, and its executions land in the Executions tab instead.

• A path, randomly generated by default so two trigger nodes cannot collide. You can set it by hand, including route parameters.

• Bearer auth or header auth. Both are ordinary n8n HTTP request credentials.

• SSE and streamable HTTP. Not stdio — so a client that can only launch a local subprocess needs a bridge, which is what mcp-remote is for.

Use it when you want a narrow, deliberate capability exposed to an AI client rather than your whole instance. Three tools you chose, behind a URL you control, with an auth token you can revoke.

This is also the option that lets you turn a third-party integration into an MCP tool without writing an MCP server. Any node that declares itself usable as a tool can be attached here — which includes Evomi's own n8n node, and is the subject of a separate post on exposing a scraping tool through the MCP Server Trigger.

Option 3: The MCP Client Tool Node

The mirror image. This is a sub-node you attach to an AI Agent, and it lets that agent call tools on an external MCP server — Evomi's, GitHub's, your colleague's, anyone's.

Its parameters are short:

• Endpoint and Server Transport — the server you are connecting to, and whether it speaks streamable HTTP or SSE. Older versions of the node had a single field labelled SSE Endpoint, which is worth knowing if you are reading a guide written against one.

• Authentication — none, Bearer, a generic header, multiple headers, or OAuth2. The multiple-headers option exists because plenty of servers want an API key and something else alongside it.

• Tools to Include — All, Selected, or All Except. This one is worth using. A server with forty tools puts forty tool definitions into your agent's context on every call, and most agents get worse as that list grows, not better. Narrowing to the four tools the workflow actually needs is the single cheapest quality improvement available here.

Recent versions also ship a pre-configured client per popular service — Notion, Stripe, Linear, GitLab and around seventy others — each appearing in the nodes panel under its own name rather than as "MCP". They are the same node underneath with the endpoint filled in, so everything above still applies; the only thing to know is that finding "Linear" in the panel does not mean you have avoided MCP, and the Tools to Include advice matters most exactly there, where the server was not built with your workflow in mind.

Use it when the decision-making lives in your n8n canvas and the capability lives somewhere else.

Option 4: The Community Package Called n8n-mcp

There is a separate, community-maintained npm package named n8n-mcp. It predates the built-in server and does an overlapping job — giving an AI client tools for working with n8n — and it is a common search result for the same query.

It is not the same thing as option 1, it is not maintained by n8n, and it is a service you run yourself. It may still be the right answer if you need coverage the built-in server does not have. But if you arrived at it by searching n8n mcp and assumed it was the official path, check option 1 first: it now covers most of what people originally installed the package for, and it is one toggle instead of one more process.

Which One, In One Table

Where Scraping and Proxies Fit

All four of these move instructions around. None of them fetches a web page, and this is where the topic tends to blur, because "give my agent web access over MCP" is one of the most common reasons people go looking for MCP in the first place.

There are three honest ways to get live web data into an n8n agent, and the right one depends on which direction you picked above:

The agent is in n8n and you want it to fetch pages. Attach a scraping node to the AI Agent as a tool. No MCP involved at all — the MCP Client Tool node is for reaching an external MCP server, and if the capability you want is already a node, wrapping it in a protocol buys you nothing. Evomi's n8n node declares itself usable as a tool for exactly this case, and returns markdown, which is the format a model actually wants.

The agent is outside n8n and you want it to fetch pages through your workflow. MCP Server Trigger, with the scraping node attached as a tool. Your client gets a URL, your n8n instance does the fetching, and your API key never leaves the instance.

You want the model to control the connection as well as the request. That is neither of the above: it is a scraping provider's own MCP server, connected either directly to your desktop client or through the MCP Client Tool node. It is the only one of the three where a model can pick an exit country, hold a session or check what it has spent, because those are not things an n8n scraping node exposes. Evomi's is documented in the MCP server integration docs.

None of these three is more correct than the others. They are three different places to put the decision.

The Part Everyone Underestimates: Deployment

Two operational details will cost you an afternoon each if you meet them by surprise, and both belong to option 2.

Reverse proxies buffer, and SSE cannot be buffered. Running n8n behind nginx without turning buffering off for the MCP path produces a connection that appears to work and then silently fails to deliver events. n8n's documented minimum:

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
}

Queue mode with multiple webhook replicas breaks it. SSE and streamable HTTP need the same server instance to hold the connection. One webhook replica is fine. More than one, and you have to route every /mcp* request to a single dedicated replica at the ingress or load balancer. Skip that and connections drop intermittently, which is the worst possible failure shape because it looks like a client bug.

If you are running n8n yourself, both of these land on you, and neither is mentioned by any of the tutorials. Self-hosting has a few more of these edges around outbound traffic too.

What People Get Wrong

• Assuming "MCP server" means one thing in n8n. It means three, and one of them is a client. Ask which direction the model is sitting in before reading any tutorial.

• Reaching for MCP when a node already exists. If the capability ships as an n8n node, attaching it to your agent as a tool is fewer moving parts, fewer credentials and one less network hop than routing it through a protocol.

• Exposing the whole instance when you meant to expose one thing. The built-in server plus a permissive workflow flag is a much larger surface than an MCP Server Trigger with three tools on it. Both are legitimate; only one of them is what most people describe wanting.

• Leaving Tools to Include on All. Forty tool definitions in the context window on every turn is a measurable quality cost, not just a token cost.

• Testing with the test URL and shipping the test URL. The test URL only registers while you are listening. It works beautifully right up until you close the tab.

• Expecting stdio. The Server Trigger does not speak it. Desktop clients that only launch subprocesses need mcp-remote in between, with the bearer token passed as a header argument.

Wrapping Up

The confusion here is a naming accident rather than a design flaw. n8n shipped a way to be an MCP server, a way to be a single-workflow MCP server, and a way to be an MCP client, and all three ended up with "MCP" in the label. Once you have decided whether the model is inside your canvas or outside it, the choice collapses to one option and the documentation for that option is good.

The thing worth taking away is that none of them are web access. MCP moves tool calls; it does not fetch pages, and it has no opinion about which IP address your request leaves from. That is a separate decision, it is the one that determines whether the fetch succeeds, and it is worth making deliberately rather than discovering when a workflow that worked on your laptop returns 403 from a datacenter.