n8n MCP: Built-In Server, Nodes + Setup (2026)

You built an n8n workflow that enriches a new lead, scores it, and drops it into your CRM. It runs 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 one company right now. The workflow lives in n8n, the agent lives in a chat window, and nothing connects the two.

MCP is that connection, and n8n now ships it built in. Recent n8n releases include their own MCP server. You switch it on in Settings, choose which workflows an agent may see, and paste one URL into Claude. No trigger nodes, no bridge script.

That built-in server is one of four things “n8n MCP” can mean, which is why searching for it gets confusing. This guide sorts the four, sets each one up with the steps from n8n’s own docs (read October 14, 2026), and covers the mistakes that stop a connection from working.

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 hundreds of integrations. You wire nodes together on a canvas to move data between apps, run on schedules, respond to webhooks, and run AI agents. The self-hosted Community Edition is free under a Sustainable Use License.

Most MCP tools play one role. Claude Desktop is a client. A Postgres server is a server. n8n plays both. It can publish your automations as tools an agent calls, and it can call tools from other servers inside a running workflow. Zendesk is halfway there, with a client that ships and a server it has only announced, which our Zendesk MCP guide untangles.

The four things “n8n MCP” can mean

Work out which one you want first. It saves an hour of reading the wrong docs.

If you landed here wanting Claude to talk to your n8n, you want the first row. It is the newest of the four and the one most older guides skip.

Setup: n8n’s built-in MCP server (instance-level MCP)

This is n8n’s own MCP server, documented under connect to the n8n MCP server. One connection covers the whole instance. You decide which workflows it can see, and the agent finds and runs them by name.

1. Update n8n: The server is part of recent n8n 2.x releases, and its tools arrive release by release. Building and editing workflows over MCP needs 2.13.0 or later, and the Connect dialog and menu names used below match 2.33.0 and later, so update before you start.
2. Turn it on: An owner or admin opens Settings, then Instance-level MCP, and selects Enable MCP access. To switch it off later, use the MCP status control under Connection details, which disconnects every client at once.
3. Choose the workflows: Nothing is exposed until you say so. Open a workflow, select the ... menu, then Settings, and toggle Available in MCP. To expose a batch, use Manage MCP access on a project or folder. Auto-expose new workflows is off by default and covers only workflows created after you turn it on.
4. Describe each workflow: The agent decides which workflow to run from its name and description. Add one with Edit description in the workflow’s ... menu, and write it like a brief for an assistant: what it does, what input it needs, what it returns.
5. Pick a sign-in method: OAuth is the recommended route. Open Connection details, then Connect, choose your client, and approve access when n8n asks. The API key tab generates a personal access token instead. Copy it before you leave the tab, because n8n hides it afterwards.

Connect Claude, Claude Code, Cursor or Codex

Copy the Server URL from Settings, Instance-level MCP, Connect a client. On n8n Cloud the domain is your-instance.app.n8n.cloud. On a self-hosted instance it is the domain that serves your editor.

Claude Desktop and Claude on the web: Open Settings, then Connectors, and choose Add custom connector. Name it n8n MCP, paste the Server URL, save, and approve access when n8n opens.

Claude Code: Add the server, then run /mcp, pick n8n and finish the OAuth step.

claude mcp add --transport http n8n https://<your-n8n-domain>/mcp-server/http

Cursor: Use the one-click link in n8n’s Connect dialog, or add this to ~/.cursor/mcp.json.

{
  "mcpServers": {
    "n8n": {
      "type": "streamable-http",
      "url": "https://<your-n8n-domain>/mcp-server/http"
    }
  }
}

Codex: Run codex mcp add n8n --url "https://<your-n8n-domain>/mcp-server/http", then codex mcp login n8n.

If you would rather use the API key than OAuth in Claude Desktop, n8n’s docs route it through the supergateway bridge in claude_desktop_config.json.

{
  "mcpServers": {
    "n8n-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "supergateway",
        "--streamableHttp",
        "https://<your-n8n-domain>/mcp-server/http",
        "--header",
        "Authorization:Bearer <YOUR_N8N_MCP_TOKEN>"
      ]
    }
  }
}

The full client list, including VS Code, Windsurf, Gemini CLI and ChatGPT, is in n8n’s client examples. For which other apps can take a server like this, which AI tools support MCP is the current map.

What the agent can do once it is connected

The server gives the agent a set of tools, listed in n8n’s tools reference. In practice they fall into five jobs.

• Find workflows: search_workflows returns previews of every workflow you can view, and get_workflow_details reads one that is enabled for MCP in full.
• Run them: execute_workflow runs the published version of a workflow that starts with a Webhook, Chat Trigger, Form Trigger or Schedule Trigger. Its manual mode runs the current draft instead and also accepts a Manual Trigger. Multi-step forms and human-in-the-loop steps are not supported. test_workflow runs a workflow with sample data in place of credentialed services and HTTP requests, so your apps are not called while you check it. Nodes that need no credential, such as file reads and writes, still run for real.
• Check what ran: search_workflow_executions and get_workflow_execution read the execution history of workflows enabled for MCP, so you can ask why last night’s run failed.
• Build and edit: search_nodes and get_node_types read real node definitions, and the builder tools create and update workflows, then publish_workflow makes one live. This needs 2.13.0 or later.
• See credentials, never secrets: list_credentials returns each credential’s name, ID and type. Secret values are never sent to the agent.

Two things to know before you switch it on. Every client you connect sees every workflow you enable, and n8n cannot limit a workflow to one client. And n8n’s own agents, which you can also expose here, are still in preview.

Built-in server or Server Trigger?

n8n’s docs draw the line clearly. Instance-level MCP is one connection for the whole instance, with central sign-in, and the workflows you enable are easy to find and run with no setup per workflow. The MCP Server Trigger lives inside one workflow and exposes only that workflow’s tools, which suits a server you want to shape by hand.

Use the built-in server when you want an agent to work across your automations, or to build them. Use the Server Trigger when you want a narrow, purpose-built tool set, such as three tools with their own token that you hand to a client without opening up the rest of the instance.

Setup: one workflow as an MCP server (the Server Trigger)

This is the “turn this workflow into a tool” path, and it works on any n8n version that has the MCP nodes.

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 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. Keep the token in a credential, never in the workflow body.

Activate the workflow and copy the production URL the trigger exposes. Claude’s custom connectors have no place to enter a Bearer token, so a Bearer-protected trigger does not work there. Claude Desktop reaches it through the mcp-remote bridge, which n8n’s docs show like this, with your trigger’s URL and token in place of the placeholders.

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "<MCP_URL>",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<MCP_BEARER_TOKEN>"
      }
    }
  }
}

Add that to claude_desktop_config.json and restart Claude Desktop. Clients that let you set a request header can take the URL and token directly instead.

Setup: n8n calling other MCP servers

Flip the direction. Now you are building inside n8n, and you want a workflow to reach a tool that lives somewhere else. n8n has two built-in nodes for it.

The MCP Client Tool node is for agents. 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 calls the remote server’s tools the same way it calls any other n8n tool. The reference lives in the MCP Client Tool docs.

The MCP Client node is for plain workflows. It runs one tool from an external server as an ordinary step, with no agent deciding anything, which is the better fit for a scheduled job that always makes the same call. It supports Bearer, header, multiple-header and OAuth2 auth. Its reference is under the MCP Client node docs.

Before these shipped, the community n8n-nodes-mcp package was the usual way in, and older tutorials still install it. The built-in nodes cover the same ground without a community install.

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 agent can reach any MCP server on the internet or your own network, not just n8n’s built-in integrations.

The mental model that keeps this straight. The built-in server and the Server Trigger publish n8n outward. The Client nodes pull the outside world in.

Setup: the community server that teaches Claude n8n

This one has no canvas. It is an MCP server you connect to Claude, and its whole job is teaching the model n8n.

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. The community czlonkowski/n8n-mcp server fixes that by exposing structured documentation for n8n’s nodes as MCP tools. Its README counts 2,951 nodes, 838 core and 2,113 community. The agent looks up the real node instead of inventing one.

There are two ways to run it. The hosted version at dashboard.n8n-mcp.com has a free tier of 100 tool calls a day. Or run it locally in Claude Desktop with npx.

{
  "mcpServers": {
    "n8n-mcp": {
      "command": "npx",
      "args": ["n8n-mcp"],
      "env": {
        "MCP_MODE": "stdio",
        "LOG_LEVEL": "error",
        "DISABLE_CONSOLE_OUTPUT": "true"
      }
    }
  }
}

The three env lines are needed in Claude Desktop. Without MCP_MODE set to stdio, the server’s log text lands in the channel Claude Desktop reads and you get JSON parsing errors in the UI. To let it push workflows to your instance, also add N8N_API_URL and N8N_API_KEY to that env block, then restart Claude Desktop. It works in Claude Code, Cursor, VS Code and other MCP clients too.

Does the built-in server make it redundant? Not quite. The built-in server knows your instance: your workflows, your runs, your credentials by name. The community server knows n8n in depth, including community nodes you have not installed yet. Plenty of builders run both, the community server for drafting and the built-in one for testing and publishing.

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: Your lead-enrichment or report workflow is enabled for MCP. 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.

Ask why a run failed: With the built-in server connected and the workflow enabled for MCP, “why did the CRM sync fail last night” becomes a question Claude can answer from the execution history rather than one you dig into by hand.

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. One common version is SEO inside n8n, a scheduled agent that researches a batch of keywords and writes them to a sheet before you wake up.

Let Claude write the automation: You describe the flow and Claude drafts the nodes, validated against real definitions, then tests it with sample data before anything goes live. Read the result before you publish 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, then let an agent use 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 built-in server and the Server Trigger both hand an outside agent the ability to run your automations. Those workflows touch your CRM, your email, your database. Enable only the workflows an agent needs, lock every endpoint, and never expose a workflow that can send money or delete records without a human in the loop. The is MCP safe breakdown covers what to check.

Building rights are a big grant: Letting an agent create, edit and publish workflows in your instance is convenient, and it carries broad power. Try it on a test instance before you point it at the one running your production automations.

A generated workflow is a draft: Both servers make Claude far better at n8n, not perfect. It can still pick a weak node, miss an edge case, or over-scope a credential. Read it like a junior’s pull request before you publish 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.

Someone still has to own the instance: Every setup above assumes a person who can read a workflow, spot a bad node, and fix it on the morning it breaks. Solo builders have that person by default. Plenty of small teams do not, and an instance nobody owns rots quietly until someone notices the leads stopped syncing three weeks ago. That gap is why n8n implementation exists as a service at all, from freelancers through to specialist shops like Oakflow AI, who build and hand over n8n workflows for small businesses in France. Worth knowing the option is there before you wire an agent into something you cannot maintain.

Why n8n MCP is not working

The same handful of issues come up over and over.

The client connects but sees no workflows: Nothing is marked Available in MCP yet. Enabling MCP on the instance exposes nothing by itself.

Claude on the web cannot reach your n8n: n8n’s troubleshooting notes say the instance must be publicly accessible for cloud-based clients. An n8n that only runs on localhost works with Claude Code or Cursor on the same machine, not with a web connector.

The agent runs an old version: execute_workflow runs the published version by default. Publish your changes, or ask the agent to use manual mode for the draft.

The run fails and lists trigger names: The workflow has more than one eligible trigger, or the trigger needs input. The agent has to name the trigger it wants, so tell it which one.

A proxy breaks the connection: n8n’s docs say a reverse proxy may need to pass the MCP-Protocol-Version, Mcp-Method and Mcp-Name headers through.

Grabbing the wrong node: Server Trigger and Client Tool sound interchangeable and do opposite things. The server publishes, the client consumes.

The Server Trigger has no tools: It does nothing until you connect at least one tool node to it. A trigger sitting alone gives the client 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 descriptions: The model chooses a workflow or tool by its name and description. Vague text means the agent ignores a good workflow or calls it at the wrong moment.

Expecting the community server to run your workflows: It teaches Claude n8n. Running and publishing your workflows is the built-in server’s job.

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 saves any web page with its text and captures what you save on X, Reddit and LinkedIn, tags each save by topic automatically, and on Pro exposes the whole library through a personal MCP endpoint. Basic is free with no account. Pro at $6 a month removes the cap and adds cloud sync and the MCP endpoint any client can call, so you can 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 an agent building and publishing 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. Turn on the built-in server, enable your five best workflows, and give each one a description a stranger could act on. Use the Server Trigger when one client needs a narrow tool set. Use the Client nodes when your n8n agents need reach. Let Claude draft with the community server, and read what it writes. A few deliberate connections beat one agent with the keys to your whole instance.

The server you connect matters more than the client you connect it to. n8n, Claude, Cursor and Codex 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 knows both what runs and how you learned to build it. The bookmarks half starts free and takes one install.