You build a slick n8n workflow that enriches a new lead, scores it, and drops it into your CRM. It runs like clockwork on a schedule, and you stop thinking about it. Then one afternoon you are in Claude, mid-task, and you want to run that exact enrichment on a single company right now. You cannot. The workflow lives in n8n, the agent lives in a chat window, and there is no wire between the two.
MCP is that wire. n8n has some of the most complete Model Context Protocol support of any automation tool, and it runs in both directions. Your workflows can become tools an AI agent calls. Your workflows can also call tools from other AI systems while they run.
That two-way support is exactly why “n8n MCP” confuses people. Searching it turns up three different things, and half the setup guides online quietly answer a different question than the one you asked. This guide sorts out what n8n MCP actually means, how to set up each version, the use cases that earn a slot, and the mistakes that trip people up before they ship a single tool.
- n8n MCP runs both ways. n8n can be an MCP server that exposes your workflows to AI agents, or an MCP client that calls other servers mid-workflow.
- Server direction: the
MCP Server Triggernode turns workflows into tools Claude or Cursor can call. There is also a native instance-level server in preview. - Client direction: the
MCP Client Toolnode lets an n8n AI Agent use tools from any external MCP server. - The third meaning: the community
czlonkowski/n8n-mcpserver teaches Claude n8n itself, so the agent can build real workflows for you. - Pair it with a bookmarks MCP. n8n runs the automation. The gotchas and templates you saved on X and Reddit live elsewhere. ContextBolt brings both into one prompt.
What n8n MCP actually does
The Model Context Protocol is an open standard Anthropic released in late 2024. It defines how an AI client talks to an external tool. A server exposes a set of tools, the client calls them mid-task, and the results flow straight back into the model’s reasoning. No copy-paste, no tab-switching.
n8n is a fair-code workflow automation tool with over 500 integrations. You wire nodes together on a canvas to move data between apps, run on schedules, respond to webhooks, and increasingly, to run AI agents. It is one of the most popular self-hosted automation platforms, and the self-hosted Community Edition is free with unlimited executions under a Sustainable Use License.
Here is the thing worth understanding before you touch a node. Most MCP tools are one role or the other. Claude Desktop is a client. A Postgres server is a server. n8n is both at once. It can publish your automations as callable tools, and it can consume tools from other servers inside a running workflow. That symmetry is powerful, and it is the exact reason the search term is a mess.
”n8n MCP” means three things
Sort out which one you want first. It saves you an hour of reading the wrong docs.
One. n8n as an MCP server. You expose your n8n workflows as tools, and an outside AI client (Claude, Cursor, ChatGPT) calls them. This is the MCP Server Trigger node, plus a newer native instance-level server. Use this when you already have workflows worth calling from a chat.
Two. n8n as an MCP client. An n8n AI Agent workflow calls tools that live on an external MCP server. This is the MCP Client Tool node. Use this when you are building an agent inside n8n and want it to reach a database, a search tool, or your bookmarks.
Three. A community server that makes Claude an n8n expert. The czlonkowski/n8n-mcp server has nothing to do with running your workflows. It feeds Claude structured knowledge of n8n’s roughly 2,000 nodes so the agent can design and validate workflows for you. Use this when you want help building n8n itself.
Most people typing “n8n mcp” want the third one and do not know it exists, then land in the Server Trigger docs and get confused. Keep the three straight and the rest is easy.
| What you want | What you use | Direction |
|---|---|---|
| Call your workflows from Claude | MCP Server Trigger node | n8n is the server |
| Let an n8n agent use outside tools | MCP Client Tool node | n8n is the client |
| Have Claude build n8n workflows | czlonkowski/n8n-mcp server | Claude learns n8n |
Setup: n8n as an MCP server
This is the “call my workflows from an agent” path. You are turning an n8n workflow into a tool that shows up in Claude or Cursor.
Drop an MCP Server Trigger node onto the canvas. You will find it in the AI section, alongside the other LangChain nodes. Unlike a normal trigger that fires on an event and passes output down the chain, this trigger only connects to tool nodes. It does nothing on its own. It waits for an MCP client to call one of the tools hanging off it.
Connect at least one tool to it. The most common choice is the Custom n8n Workflow Tool node, which wraps another workflow and hands it to the agent as a callable tool with a name and a description. The description matters more than people expect. That text is how the model decides when to call your tool, so write it like you are briefing an assistant, not naming a variable. The full reference is in n8n’s MCP Server Trigger docs.
Turn on authentication. The trigger supports Bearer auth, where the client sends a token in an Authorization header, and header auth, where you pick a custom header name and value. Do not skip this. An unauthenticated MCP endpoint on a public n8n instance is an open door to your automations. Set a token, keep it in a credential, never paste it into the workflow body.
Activate the workflow and copy the production URL the trigger exposes. That URL plus the token is what you paste into a client. In Claude Desktop it goes under Custom Connectors, in Cursor it goes in the MCP config, and the same endpoint works in every client that speaks remote MCP. If you are unsure which clients qualify, which AI tools support MCP is the current map.
There is also a newer option worth knowing about. n8n now ships a native, instance-level MCP server, in public preview since 2026, documented under accessing the n8n MCP server. Instead of wiring a trigger per workflow, it exposes your whole instance to an agent so it can build, test, and publish workflows directly. It is a heavier grant of power. Read the next two sections before you turn it loose.
Setup: n8n as an MCP client
Flip the direction. Now you are building an agent inside n8n, and you want it to reach a tool that lives somewhere else.
This is the MCP Client Tool node. You connect it to an AI Agent node as one of its tools, point it at an external MCP server’s URL, and add whatever auth that server needs. When the agent runs, it can call the remote server’s tools the same way it calls any other n8n tool. The reference lives in the MCP Client Tool docs.
A concrete shape. You build a support-triage agent in n8n. It reads an incoming ticket, and you want it to check your live docs and your saved research before it drafts a reply. You add one MCP Client Tool node pointed at a docs server and another pointed at a bookmarks server. Now the n8n agent has reach beyond the 500 built-in integrations, into any MCP server on the internet or your own network.
The mental model that keeps this straight. Server Trigger publishes n8n outward. Client Tool pulls the outside world in. If you find yourself adding a Client Tool node to expose a workflow, you have grabbed the wrong one.
Setup: the server that makes Claude an n8n expert
This one has no canvas. It is an MCP server you connect to Claude, and its whole job is teaching the model n8n.
The problem it solves is real. Ask a stock Claude to build an n8n workflow and it guesses at node names, invents parameters that do not exist, and hands you JSON that fails to import. It has read about n8n but does not know the exact shape of the 2,000-odd nodes. The community czlonkowski/n8n-mcp server fixes that by exposing structured documentation for those nodes, their properties, and their operations as MCP tools. The agent looks up the real node instead of hallucinating it.
Install it the same way you add any local server. In Claude Desktop, add it to your config with npx.
{
"mcpServers": {
"n8n-mcp": {
"command": "npx",
"args": ["n8n-mcp"]
}
}
}
It works in Claude Desktop, Claude Code, Cursor, and Windsurf. Once connected, you describe the automation you want in plain language and Claude builds a validated workflow you can paste into n8n. Wire in your n8n API credentials and it can push the workflow to your instance and even trigger a test run. It is the closest thing to a co-pilot for n8n, and it is free and open source.
This is a different job from the two built-in nodes. The nodes connect a running n8n to the wider MCP world. This server connects the act of building n8n to Claude. You will likely end up using more than one of the three.
Use cases that earn the slot
A protocol feels abstract until you have used it for a week. Here is the short list people actually reach for.
Run a workflow on demand from a chat. You keep a lead-enrichment or report-building workflow in n8n. With the Server Trigger, you ask Claude to run it for one record, right now, without opening n8n. The automation you built for batches becomes a single-shot tool.
Give an n8n agent live reach. A support or research agent built in n8n uses the Client Tool node to query your database, search the web, or pull your saved threads mid-run. It stops being limited to the apps n8n integrates and starts using anything with an MCP server.
Let Claude write the automation. The community server means you describe the flow and Claude drafts the nodes, validated against real schemas. You review, tweak, and ship in a fraction of the time. Read the generated workflow before you activate it. It is a strong first draft, not a finished product.
Chain n8n to a bigger agent stack. Expose a handful of your best workflows as tools, then let an agent orchestrate them alongside a coding tool, a docs server, and a bookmarks server. n8n becomes one specialized hand in a larger system.
Where n8n MCP still needs a human
Honest limits, because a workflow tool with agent access can do real damage if you trust it blindly.
An exposed instance is an attack surface. The Server Trigger and the instance-level server both hand an outside agent the ability to run your automations. Those workflows touch your CRM, your email, your database. Lock every endpoint with a token, scope what you expose, and never publish a workflow that can send money or delete records without a human in the loop. The is MCP safe breakdown covers what to check.
The instance-level server is a big grant. Letting an agent build and publish workflows directly in your instance is convenient and it is preview software with broad power. Start it on a throwaway instance, not the one running your production automations.
A generated workflow is a draft. The community server makes Claude far better at n8n, not perfect. It can still pick a suboptimal node, miss an edge case, or over-scope a credential. Read it like a junior’s pull request before you activate it.
It answers, it does not watch. MCP is request and response. An agent calls your workflow when you ask. It does not sit in the background and ping you when a competitor changes their pricing or a metric moves. That is a monitoring job, and it belongs to a different kind of tool.
The mistakes that break n8n MCP setups
The same handful of issues come up over and over.
Grabbing the wrong node. Server Trigger and Client Tool sound interchangeable and do opposite things. Setting out to call your workflows and reaching for the Client Tool node is the single most common n8n MCP mistake. Server publishes, client consumes.
Forgetting the trigger needs a tool. The MCP Server Trigger does nothing until you connect at least one tool node to it. A trigger sitting alone exposes an endpoint with no tools, and the client sees an empty toolbox.
Skipping auth on a public instance. An unauthenticated trigger URL on a reachable n8n instance is an open door. Set a Bearer or header token before you activate, every time.
Weak tool descriptions. The model decides whether to call your tool based on its name and description. Vague text means the agent ignores a perfectly good workflow or calls it at the wrong moment. Describe it like you are briefing a new hire.
Confusing the community server with the nodes. People install czlonkowski/n8n-mcp expecting it to run their workflows, or add the built-in nodes expecting Claude to suddenly know n8n. Different jobs. The server teaches Claude n8n. The nodes connect a live n8n to MCP.
Why your saved research belongs next to your automations
Here is the gap nobody setting up n8n MCP talks about. Your workflows are only half of what you know about your own systems.
The other half is everything you saved and never filed. The X thread with the exact webhook pattern you keep meaning to copy. The Reddit post where someone solved the rate-limit error you are hitting. The n8n template a creator posted on LinkedIn that does most of what you need. That context shapes how you build, and none of it is in your n8n instance. It is trapped across three bookmarks tabs on three platforms.
n8n gives an agent your workflows and your integrations. It does not give the agent the scattered fixes and templates you collected along the way. So you get an assistant that can run your automation but has never seen the thread that showed you how to build it.
This is where a bookmarks MCP earns a slot next to your n8n server. ContextBolt is a Chrome extension that captures what you save on X, Reddit, and LinkedIn, tags each save by topic automatically, and exposes the whole collection through a personal MCP endpoint. The free Basic tier covers 150 bookmarks. Pro at $6 a month adds unlimited saves, encrypted cloud sync, and the MCP endpoint any client can call. You can even wire it straight into an n8n agent with the Client Tool node.
Now the agent reads both halves in one prompt. “Build me an n8n flow that posts new signups to Slack, and pull anything I saved about n8n webhook auth” returns the workflow and the three threads you bookmarked about that exact problem. Your instance says what runs. Your bookmarks say how you figured it out. For the bigger picture of feeding an agent your own context, see the personal AI context stack, and for other servers worth the slot, the best MCP servers for knowledge workers.
The one opinion worth holding
The flashy version of n8n MCP is the instance-level server letting Claude build and publish workflows on its own. It is genuinely impressive. Betting your setup on it is still a mistake.
The quiet version is the one that pays off. Keep n8n doing what it is best at, running reliable automations you understand, and use MCP to connect it to the rest of your stack. Expose your best workflows as tools with the Server Trigger. Give your n8n agents reach with the Client Tool node. Let Claude help you build with the community server. Three deliberate connections beat one agent with the keys to your whole instance.
The other thing worth saying plainly. The server you connect matters more than the client you connect it to. n8n, Claude, and Cursor all speak the same protocol, so wiring one workflow up pays off across every tool you touch. The same is true for the second half of your context. Connect your automations, connect your bookmarks, and the agent finally knows both what runs and how you learned to build it. That is the setup. Everything else is detail.