An AI agent that has to click through your admin panel is slow, brittle, and breaks the moment you move a button. An agent that can call get_order_status(order_id) and get structured JSON back does not. The Model Context Protocol, or MCP, is the open standard that describes those callable tools, and n8n can now act as an MCP server: any workflow you build becomes a tool an agent can invoke over the network.
This is part three of the n8n Automation Stack series. Part one covered the core concepts, part two covered installing n8n properly. That second one matters here more than usual, because the MCP transport is the one thing a default reverse proxy configuration will silently break.
What You Get
- One n8n workflow exposed as an MCP tool with a typed input schema.
- Bearer-authenticated access from Claude Desktop, Cursor, or any MCP client.
- The four self-hosting failures that stop it working, and the fix for each.
- A tested look at the second, instance-level MCP server: what it exposes, what it costs to run, and the security boundary you are trusting.
Two Directions, Do Not Mix Them Up
n8n sits on both sides of MCP, and the node names are easy to confuse.
| Node | Direction | Use it when |
|---|
| MCP Server Trigger | n8n exposes tools | An external agent should call your workflow |
| MCP Client Tool | n8n consumes tools | Your n8n AI Agent needs a third-party MCP server |
This article builds the first one. The second gets a paragraph at the end.
Prerequisites
A self-hosted n8n instance you can reach over HTTPS, an MCP client, and a workflow worth exposing. Pick something with a clear input and a clear output. A lookup against a database, a status check against an internal API, or a search over your own content all work well. Anything that takes ten parameters and returns prose does not.
Step 1: Add the MCP Server Trigger
Create a new workflow and add the MCP Server Trigger node. It replaces the usual trigger, so this workflow will not have a Schedule or Webhook node.
The node gives you a path, which becomes part of the URL agents connect to, and an authentication choice. Two options are available, both configured through HTTP request credentials:
- Bearer auth: a token in the
Authorization header. Use this unless you have a reason not to.
- Header auth: a custom header name and value, for fitting an existing scheme.
Set a path you will recognise later. The node then shows you two URLs, and the difference between them is the same test versus production split from part one.
The trigger on its own exposes nothing. Tools attach to it as sub-nodes, and two kinds can connect:
- Custom n8n Workflow Tool, which exposes another of your workflows as a callable tool.
- MCP Client Tool, which re-exposes tools from another MCP server.
Use the first. Attach a Custom n8n Workflow Tool, point it at the workflow doing the actual work, and then spend your time on the two fields that decide whether an agent uses your tool correctly: the name and the description.
The description is not documentation. It is the prompt the model reads when deciding whether to call your tool. Write it for the model:
{
"name": "get_order_status",
"description": "Look up the current status of a customer order by its ID. Returns status, carrier and tracking number. Use when the user asks where an order is.",
"parameters": {
"order_id": "The order ID, format ORD-12345"
}
}
Vague descriptions produce agents that either never call the tool or call it constantly with nonsense arguments. Say what it returns and when to use it.
Step 3: Test Before You Publish
Click Listen for Test Event and the node hands you a test URL. Point your MCP client at it and call the tool once.
The test URL displays live data in the editor, which is the whole reason to use it. You can see the arguments the model sent and the data each node returned. Note that it listens for a single event, so if a second call appears to hang, that is why.
Step 4: Publish and Connect for Real
Publishing the workflow activates the production URL. Production executions do not display in the editor at all. To inspect them you open the Executions tab, which is where all your debugging happens from this point on.
Point your MCP client at the production URL with the same credentials. In Claude Desktop that is an entry in the MCP servers section of the config; in Cursor and other clients it is equivalent. The tool should appear in the client's tool list with the name and description you set in step 2.
Step 5: The Self-Hosting Reality Check
This is the part that is not in most walkthroughs, and it is where a self-hosted instance behind a proxy stops working.
There is no stdio transport
Many MCP servers run as a local subprocess and speak over standard input and output. The n8n MCP Server Trigger does not support stdio. It is SSE and HTTP only, meaning your n8n instance has to be reachable over the network from wherever the client runs. If your client only supports stdio, you need a bridge process, not this node.
Proxy buffering breaks it
Server-Sent Events depend on the server pushing bytes as they happen. A reverse proxy that buffers responses will hold those bytes until the buffer fills or the connection times out, and the symptom is a connection that appears to open and then never delivers anything. The n8n documentation is explicit that a reverse proxy in front of the MCP endpoint must have buffering disabled and compression settings adjusted.
In nginx that is proxy_buffering off; on the location handling the MCP path. In Apache, SetEnv proxy-sendchunked 1 and no output filters on that path. This is the same setting part two flagged, and it is the first thing to check when a connection opens but no tools appear.
Multiple replicas break it differently
If you run n8n with more than one webhook replica behind a load balancer, SSE connections fail when a follow-up request lands on a different replica than the one holding the stream. The fix is routing: send every request matching /mcp* to one dedicated replica. Single-container deployments are unaffected, which is most self-hosted setups.
We connected a real MCP client to a self-hosted instance and the first thing that broke was concurrency. Sending several tool calls in one parallel batch returned transport errors, some coming back as a bare "not connected" even though the server was up. Running the same calls one after another worked every time.
This is the SSE transport doing exactly what the buffering and replica warnings above predict: a single streamed connection does not want several requests racing through it at once. If your client or your agent framework likes to fan out tool calls in parallel, throttle it to one in flight. A call that fails this way is worth a single sequential retry before you assume anything is actually wrong with the server.
The Other Direction: Consuming MCP Servers
The MCP Client Tool node is the mirror image. Attach it to an n8n AI Agent and the agent gains the tools of an external MCP server. It connects over an SSE endpoint, and it supports bearer, single or multiple custom headers, OAuth2, or no authentication at all.
The useful detail is tool filtering. You can expose All tools from the server, a Selected subset, or All Except a blocklist. Handing a model 40 tools when it needs 3 measurably degrades tool choice, so select deliberately.
A Third Thing, Which Is Not This
n8n also has an instance-level MCP server, a different feature with a confusingly similar name. It lets an MCP client connect to n8n itself at /mcp-server/http and build, search, test, and publish workflows by prompting. Authentication is OAuth2 or a personal access token. We wired one into a client and used it, so the rest of this section is from that rather than from the docs.
This is a development tool, not a runtime one. It is how you build workflows by talking to a model, not how an agent calls your workflow in production.
What it actually exposes
Connecting turns n8n into a toolbox with four kinds of tool, and the difference between them is entirely about blast radius:
| Family | Does | Cost of a mistake |
|---|
| Read | List and inspect workflows, executions, credentials, tags | None |
| Build | SDK reference, node search, config validation | None, it only reads and checks |
| Write | Create, update, publish, archive, restore versions | Mutates your instance |
| Execute | Run and test workflows | Runs real workflows with real credentials |
That last row is the one to respect. An execute call is not a dry run. If the workflow it triggers calls a paid model API, hits a database, or posts to a webhook, it does all of that for real. Point an agent at this server and "test my workflow" can mean spending money and sending outbound requests.
Two things it does right
Listing credentials returns names and types only, never secret values. You can let a model see that an OpenAI credential and a Postgres credential exist, and reference them by ID when building, without ever exposing the keys. That is the correct design and it held up in practice.
It also refuses to let you guess. The server makes you pull the SDK reference and the best-practices guidance for a technique before it will accept workflow code, so a model cannot hallucinate node parameters straight into your instance. Building is slower as a result, and correct more often.
The opt-in is real, and stricter than you expect
Workflows are exposed individually. On the instance we connected to, a small minority of the total were flagged available over MCP; the rest were invisible to the connected client even though the same token could list them through the management tools. The exposure is also not client-scoped: every client using that token sees the same enabled set. Treat "enabled for MCP" as a deliberate per-workflow decision, not a default.
The token is the whole security boundary
A personal access token here is a long-lived bearer credential. The one we generated was a JWT with no expiry claim, so it does not time out on its own, and it grants read, build, write, and execute across everything the issuing user can reach. It sits in your client's config file in plain text.
Which means: store it like a password, do not commit the config that holds it, and rotate it in n8n's settings if it ever leaks. Anyone who reads that file can drive your instance.
One more caveat. Several third-party guides cite an enablement environment variable and a minimum version that do not match the official documentation, which describes the module as enabled by default and disabled with N8N_DISABLED_MODULES=mcp. Check your own instance before copying either claim.
What This Is Actually Good For
Two directions, two audiences.
The Server Trigger from steps one through five is for exposing what you already built. If you run n8n and have workflows an agent should be able to trigger, an internal lookup, a status check, a search over your own content, wrapping them as tools is a thin layer over work that already exists.
The instance-level server is the inversion: it is for building and auditing n8n from a chat window. Asking a model which workflows are active, which have not run since last quarter, or which are exposed over MCP is a fast way to take stock of an instance that has grown past what you remember. Building a new workflow through it means the model discovers nodes and validates them against your real credentials before anything is saved. It is the most useful when your instance is large enough that clicking through the editor has become the slow path.
Limitations and Gotchas
- No stdio transport. The instance must be network-reachable from the client.
- SSE needs an unbuffered path end to end, including any CDN in front.
- Concurrent tool calls over the SSE transport fail. Send one at a time.
- Production executions are invisible in the editor. Use the Executions tab.
- The tool description is prompt text and drives model behaviour. Treat it as code.
- An execute call on the instance-level server runs the real workflow with real credentials. It is not a dry run.
- The bearer token is the whole security boundary, is long-lived, and sits in a config file in plain text. Anyone who reads it can drive your instance.
When Not To Bother
Skip the Server Trigger if you only need an agent to call one HTTP endpoint. An MCP server wrapping a single API call adds a hop and a service to maintain. Point the agent at the API.
Skip the instance-level server on a small instance you already know by heart. Its payoff scales with how many workflows you have forgotten about, and on a handful of workflows the editor is faster than a chat window.
Sources and Further Reading
Ten minute version: add an MCP Server Trigger to any existing workflow, set bearer auth, attach a Custom n8n Workflow Tool, and call the test URL from your client. If nothing arrives, check proxy_buffering first.
