n8n MCP Server vs MCP Server Trigger: Which One You Actually Need

I lost an afternoon to this naming collision, so let me save you the same one. Search “n8n MCP server” and you get two sets of results that look like they're describing the same feature with slightly different screenshots. They're not the same feature. They point in opposite directions.

The MCP Server Trigger node is a node you drop on a canvas. It makes that one workflow available to the outside world as an MCP server, and the only tools it offers are the ones you wire into it. Everything else in your instance stays invisible.

The built-in n8n MCP server isn't a node at all. It's a server that ships inside n8n, and an external client connects to it once to talk to your whole instancethrough centralized auth. n8n's own docs open the page with a disambiguation note because enough people conflated them.

This is the part most write-ups are stale on. When the built-in server launched, all it could do was run existing workflows. That made it a remote control — useful, unexciting.

On April 29, 2026 that changed. It can now build new workflows from scratch and update existing ones directly in your instance. The tool surface covers workflow management, workflow building, agent management and data tables, including validating workflows, running test executions and generating test data.

Read that list again, because it reframes the whole feature. A model that can author a workflow, validate it, run a test execution against generated data and read the result has a feedback loop. It isn't guessing at JSON and handing you something to paste in. It can check its own work. That's the difference between a code generator and something that actually converges.

The catch is version gating, and it bites quietly. The capabilities landed in stages:

• n8n 2.13.0 — workflow building and editing over MCP
• n8n 2.24.0 — project and folder level MCP access
• n8n 2.33.0 — current settings layout and allowed callback URLs
• n8n 2.34.0 — the Agents feature

If your self-hosted box is behind, the connection still succeeds. You just get a smaller toolbox than the docs describe and no error explaining why. Check /rest/settingsor the footer version before you spend an hour wondering why your client can't create anything.

No edition gate. Cloud, Enterprise and the free self-hosted Community Edition all have it. That surprised me — this is the kind of feature that usually lands behind a plan.

The Trigger node is the boring one, and boring is the point. You build a workflow, attach tools to the trigger via the Custom n8n Workflow Tool node, and clients can list those tools and call them. That's the whole model.

What makes it valuable is what it doesn't do. A client connected to a Trigger node cannot enumerate your other workflows, cannot read your credentials list, cannot create anything. It sees three tools because you attached three tools.

This is how you ship an internal capability to someone else's agent. A lookup against your CRM, a quote calculator, a “check inventory” call — build it once with the connectors you already have, expose it, done. It's the same reasoning I walked through in tool node vs sub-workflow, one layer further out: the sub-workflow question is about structure inside your instance, this one is about what leaves it.

Two transport details worth knowing up front. It supports SSE and streamable HTTP, and it does not support stdio — so a local-only client that speaks stdio needs a bridge. And the URL path is randomly generated by default, deliberately, so two Trigger nodes don't collide. You can override it. Resist the urge to set it to /mcp on every workflow.

Nothing stops you running both. On my own instance the built-in server is connected to a client I drive personally, and the workflows I hand to other people's agents each sit behind their own Trigger node. Different doors, different keys.

The built-in server takes OAuth or an API key. The API key path is a personal access token in a plain Authorization: Bearer header, which is fine for a script and wrong for anything with a human attached — that token carries everything your user account can do.

OAuth is the one to use. The client redirects to n8n, the user signs in, and the connection gets permission-scoped access: the docs give the example of a client that can read workflows without being able to create or run them. Combine that with project and folder level scoping from 2.24.0 and you can hand a client one project instead of the estate.

Do that. A read-only MCP connection over a single project is a genuinely safe thing to leave connected. A full-permission personal access token pointed at your production instance is a credential sitting in a config file on whatever machine your client runs on. Same protocol, wildly different failure modes — the general shape of this problem is the one I covered in remote MCP server authentication.

Here's the one that will eat your evening if you run n8n seriously.

MCP over SSE is a long-lived connection. Your load balancer doesn't know that. If you're in queue mode with more than one webhook replica — which is exactly what you do when you scale n8n properly — round-robin routing sends the client's follow-up requests to a replica that has no idea the session exists. The documented requirement is blunt: route all /mcp*requests to a single dedicated webhook replica. Skip it and connections “frequently break or fail to reliably deliver events.”

The symptom is nasty because it isn't a clean failure. Tool listing works. The first call works. Then things drop intermittently and you go looking for a bug in your workflow that was never there.

Second half of the same problem: your reverse proxy. nginx buffers responses by default, which is correct for normal HTTP and fatal for SSE — events pile up in the buffer instead of reaching the client. Disable proxy buffering on that endpoint, and check gzip and chunked transfer encoding while you're in there. If you're running multiple webhook replicas at all, the sizing and routing tradeoffs are the same ones from scaling n8n with queue mode.

A one-line connection that gives a model your entire automation estate is a great developer experience and a bad security boundary. Both statements are true at once, and which one matters depends entirely on where the model's input comes from.

For me driving a client I control, the built-in server is excellent. It reads an existing workflow, patches the node I described, runs a test execution and tells me what came back — without me clicking through the canvas. That's real time saved.

For an agent processing inbound customer messages, it's the wrong tool by a mile. Two reasons:

• Blast radius. Every workflow in the instance is reachable. A prompt injection that talks the agent into calling the wrong workflow now has your whole estate to aim at, not one endpoint.
• Context cost. Instance-wide tool surfaces are large, and every schema is re-sent on every turn. You pay for the tools the agent never calls, on every single request.

Both are things I've written about separately — what MCP servers actually cost in tokens and tool poisoning in MCP servers — and the n8n built-in server is where both land in the same decision at the same time.

The Trigger node solves both by construction. Three tools attached means three schemas in context and three things reachable. Constraint as a feature.

• Built-in MCP server = whole instance, one connection, set up in settings. MCP Server Trigger = one workflow, only the tools you attach.
• Since April 29, 2026 the built-in server can build and update workflows, not just run them — plus validate, test-execute and generate test data.
• Version gates are silent: 2.13.0 for building, 2.24.0 for project/folder scope, 2.33.0 for the current settings layout, 2.34.0 for Agents.
• No edition gate. Cloud, Enterprise and free self-hosted Community all have it.
• Use OAuth, not a personal access token, so the connection is permission-scoped — and scope it to a project where you can.
• Queue mode with multiple webhook replicas: pin all /mcp* traffic to one replica and disable proxy buffering, or SSE will drop intermittently.
• Never point a customer-facing agent at the instance server. Give it a Trigger node with the two or three tools it actually needs.

Both sets of docs are worth reading directly before you wire anything up: connecting to the n8n MCP server and n8n's own announcement of the workflow-building update.