Automation has always had a button, and someone to press it: a cron, a webhook, a person. The Model Context Protocol (MCP) changes that part. With the MCP nodes in n8n, a workflow stops being something you trigger and becomes a tool that a language model calls on its own, when it judges that necessary. It is a real gain in flexibility and a change in responsibility that deserves to be understood before it is turned on.
A statement before anything else: this post is an analysis of the official documentation and of the specification, not an account of production operation. I do not have an MCP server running; what I follow here is what the primary documents say, with the date on which they were consulted. Where opinion comes in, it is identified as such.
What MCP solves
MCP is an open protocol for connecting language models to tools and data. The idea is to do away with the custom adapter: instead of each assistant speaking in its own way to each system, they all speak the same protocol. Whoever has a tool exposes a server; whoever consumes it uses a client.
n8n is on both sides of that conversation today, with two distinct nodes, both officially documented:
- MCP Server Trigger — makes n8n act as an MCP server, “making n8n tools and workflows available to MCP clients.” In practice: your workflow becomes a tool that an external agent can invoke.
- MCP Client Tool — the reverse path, allowing an agent inside n8n to use tools exposed by a third-party MCP server.
The promise of the first is the most interesting for anyone who already automates: the business logic stays in the workflow, versioned and visible, instead of turning into an instruction inside a prompt.
The inversion nobody mentions
Notice what actually changes. An ordinary webhook is called by a system you integrated, with a contract you defined. An MCP tool is called by a model that decides, on the spot, whether that is the right tool for the request it received.
In other words: the trigger stops being deterministic and becomes a judgment. If the workflow on the other side only reads data, the worst case is an unnecessary query. If it writes, sends, charges, or deletes, the worst case has another name. It is the same boundary that separates an autonomous agent from an assisted agent: reversibility of the error.
The pattern that requires attention
Here is the detail that caught my attention most in the documentation, and that is worth quoting in full. About the MCP Server Trigger, n8n warns:
“By default, the MCP Server Trigger node uses no authentication method, which means that, if your endpoint URL is exposed, unauthorized parties can access your MCP server.”
The node offers Bearer auth and Header auth, and the URL comes with a random path to avoid conflicts. But a path that is hard to guess is obscurity, not access control: the factory default is open, and closing it is a choice made by whoever installs it. On the other side, the MCP Client Tool also accepts connecting without authentication — it is one of the options on the list, alongside Bearer, headers, and OAuth2.
None of this is a flaw in n8n; it is configuration exposed honestly in the documentation. The point is that the path of least effort, here, is the insecure path — and the path of least effort is what most people follow when they are in a hurry to see it working.
The specification has already mapped how this breaks
The MCP’s own security best-practices document is an uncomfortable and useful read. It names the attacks and uses normative language (the spec’s “MUST NOT” is a prohibition, not a suggestion). The ones that matter most to anyone who is going to expose a workflow:
Token passthrough is forbidden. An MCP server cannot accept a token that was not issued for it and pass it along. The spec is literal: MCP servers must not accept tokens that were not explicitly issued for the MCP server. The reason is the usual one — an audit trail and a trust boundary: with someone else’s token in circulation, the final system’s log points to the wrong sender.
A session is not authentication. Another hard rule: MCP servers must not use sessions to authenticate, must verify every incoming request, and must use non-deterministic session identifiers. The attack described is session hijacking, with the attacker guessing or obtaining the identifier and acting as if they were the legitimate client.
The confused deputy. When an MCP server bridges to a third-party API using a fixed client identifier, an attacker can take advantage of the consent cookie the user has already given and skip the approval screen. The required mitigation is per-client consent, validated before forwarding to the external authorizer.
Minimum scope. The spec advises against wildcard scopes (*, full-access) and recommends starting with the minimum, raising it when the privileged operation appears. It is the old principle of least privilege, written for this context: a stolen token with a broad scope is a problem of a different size.
What I will check before turning it on in my pipeline
This part is an architecture decision, not a universal recommendation. This blog’s editorial pipeline is precisely a candidate to become an MCP tool — “generate the draft,” “process the cover,” “open the PR” are operations an assistant could call. Before enabling anything, these are the questions I intend to answer:
- Does the tool write, or only read? Read-only goes in first. Writing waits.
- Is authentication on — Bearer or header, never the open default — and is the endpoint behind the same proxy that already protects the rest?
- Is what the tool can touch the size of the task, or the size of the system?
- Is there a record of which agent called what, in a format that can be read afterward?
- Does the human gate stay where a mistake is expensive? In my case the answer is mandatory: nothing on this blog goes to production without me reading and approving it. An MCP tool can prepare; it cannot publish.
The fifth question is the one that changes weight with MCP. While the trigger was mine, the human gate was almost redundant with the act of triggering itself. With an agent deciding when, the gate stops being redundancy and becomes the only boundary left.
What remains
MCP solves a real problem: stop writing an adapter for every combination of assistant and system, and keep the logic in the workflow instead of burying it in a prompt. n8n’s adoption of both sides of the protocol makes this accessible to anyone who already automates, without writing any server at all.
What changes along with it is who presses the button. An exposed tool is a new surface, the factory default comes without authentication, and the specification already documents in detail how this kind of integration breaks. Turning it on is worth it; turning it on without reading the security page is not.
Sources
- MCP Server Trigger node, what it does, authentication methods (Bearer and Header), and the warning that the default is no authentication — official n8n documentation (primary source), verified on 2026-08-07.
- MCP Client Tool node, connection to an external MCP server, and authentication options, including “none” — official n8n documentation (primary source), verified on 2026-08-07.
- Prohibition of token passthrough, the rule that a session does not authenticate, the confused deputy problem, and scope minimization — Model Context Protocol specification, security best practices (official specification), verified on 2026-08-07.
- Analysis note: no MCP server had been operated by the author as of the publication date; what is described as the author’s own practice is a stated architecture decision, not an account of execution.
