n8n MCP Server: How to Connect n8n to Claude and Your AI Agents (2026)

automation
The n8n and Claude logos connected through the Model Context Protocol, representing an n8n MCP server setup
Three ways to connect n8n and MCP — as a server, as a client, and as a thing Claude manages for you.

If you've searched "n8n MCP server" and come away confused, it's not you. There are three different ways n8n and the Model Context Protocol fit together, and they point in different directions. Get them straight and the whole thing clicks. Here's the short version before we go deep:

  • n8n as an MCP server — your workflows become tools an AI client (Claude, Cursor, ChatGPT) can call. You use the MCP Server Trigger node.
  • n8n as an MCP client — an AI Agent node inside n8n reaches out and uses tools from someone else's MCP server. You use the MCP Client Tool node.
  • n8n managed by an AI — Claude Code or Cursor builds and edits your workflows for you, through the community @n8n/mcp-server package.

Most tutorials pick one, never name the other two, and leave you thinking you set it up wrong. We build these for clients weekly, so let me walk all three — with the setup, the auth, and the part where it bites you.


What is an n8n MCP server, exactly?

An n8n MCP server exposes one or more of your workflows as tools an external AI model can call over MCP. You add an MCP Server Trigger node to a workflow, n8n hands you an endpoint, and from then on any MCP-aware client — Claude Desktop, Cursor, a custom agent — can invoke that workflow as if it were a native function.

Think about what that unlocks. Every integration n8n already has — 500-plus apps, your CRM, Slack, Google Sheets, a Postgres database, a Retell voice call — becomes a tool your agent can reach without you writing a single custom function. The Model Context Protocol is just the open standard, maintained here, that lets the model discover and call those tools in a consistent way. n8n stops being "the thing that runs on a schedule" and becomes the hands your AI agent uses to touch the real world.

The one-line answer: an n8n MCP server turns your existing automations into callable tools for any AI agent, using workflows you may already have built.


The three ways to connect n8n and MCP

Here's the table we wish existed when we started. Print it, honestly.

| What you want | Node / tool | Direction | Use it when | |---|---|---|---| | Let Claude/Cursor call your workflows | MCP Server Trigger | n8n serves tools | You want an AI agent to run your automations on demand | | Let an n8n agent use outside tools | MCP Client Tool | n8n consumes tools | Your AI Agent node needs a database, browser, or SaaS the model can drive | | Let an AI build your workflows | @n8n/mcp-server (npm) | AI manages n8n | You want to describe an automation and have Claude assemble it |

Ninety percent of the "it doesn't work" messages we see come from someone using the wrong row for the job. If you want Claude to fire your lead-routing flow, you need the Server Trigger — not the client node, not the npm package.


Setting up n8n as an MCP server (the Server Trigger)

This is the one people mean when they say "I want an n8n MCP server." The goal: your workflow becomes a tool Claude can call.

  1. Add the MCP Server Trigger node as the workflow's entry point. It replaces the webhook or manual trigger and marks the workflow as an MCP endpoint.
  2. Define your tools. Wire the operations you want to expose and give each a plain, specific description. The model reads those descriptions to decide when to call the tool, so write "Create a lead in the CRM from a name, email, and phone" — not "CRM node." Bad descriptions are the number one reason an agent picks the wrong tool.
  3. Turn on auth. Set bearer token or header authentication on the trigger. Generate a secret, store it in a manager, and never — ever — publish an unauthenticated MCP endpoint. It's a remote-code-for-your-business button.
  4. Copy the endpoint URL once the workflow is active. If you self-host, the instance has to be reachable over HTTPS on a real domain; a localhost port won't work for a cloud AI client.
  5. Connect the client. Drop the URL and token into Claude Desktop's or Cursor's MCP config. The client auto-discovers the tools.
  6. Test with a real prompt and watch the execution fire in n8n. Check the logs before you point a paying client at it.

That's the whole loop. The trap is step 2: teams expose ten tools with vague names, the model gets confused, and they blame MCP. We've had better results scoping one MCP server to one workflow with one clear job than cramming a Swiss Army knife into a single endpoint. It also matches how we think about AI Agent node vs sub-workflow structure — small, named, testable units beat one giant flow every time.


Using n8n as an MCP client (the other direction)

Flip it around. Sometimes you want the AI Agent living inside n8n to use tools from somewhere else — a headless browser, a vector database, a third-party MCP server a vendor published. That's the MCP Client Tool node.

You attach it to an AI Agent node, point it at the external MCP server's URL and credentials, and the agent can now call those tools mid-workflow. Practical example we've shipped: an n8n agent that qualifies inbound leads pulls live account data from an internal MCP server, then decides whether to book a call. The reasoning happens in n8n; the data and actions come from MCP tools on both sides.

Server Trigger and Client Tool aren't either/or. A mature build often serves a few tools to Claude and consumes a few from elsewhere. Naming them right in your own head is what keeps you sane.


Letting Claude build your n8n workflows

The third path is the one that surprises people, and it's the community @n8n/mcp-server package — completely separate from the built-in nodes. Here you're not exposing workflows to end users; you're letting a coding agent like Claude Code or Cursor author them for you through the n8n API.

Setup is a standard MCP config in your coding tool:

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": ["@n8n/mcp-server"],
      "env": {
        "N8N_API_URL": "https://your-n8n-instance.com/api/v1",
        "N8N_API_KEY": "your-api-key"
      }
    }
  }
}

Generate the API key in your n8n settings, drop it in, and now you can tell Claude "build me a workflow that watches a Gmail label, extracts the invoice total, and appends it to a Sheet" — and it assembles the nodes for you. It's genuinely fast for prototyping. It is not for production hand-off to a client, and it needs an API key that can rewrite your instance, so keep it on a dev environment. Treat it like giving an intern admin access: great for speed, gated for a reason.


Why this matters for agencies right now

Every one of our clients already has automations. The MCP shift means those automations stop being back-office plumbing and become the action layer for AI agents — the difference between a chatbot that talks and an agent that actually books the appointment, updates the CRM, and fires the follow-up. If you've already moved your stack off Zapier and Make onto self-hosted n8n, you're one node away from every one of those flows being agent-callable.

We've watched clients try to rebuild all of this as custom API code and burn weeks on auth and error handling that n8n already solved. The MCP Server Trigger collapses that into an afternoon. Pair it with the voice agents we deploy on Retell and you get a phone agent whose "tools" are real business workflows, not brittle one-off webhooks. And if you're still deciding which automations even deserve this treatment, our list of n8n workflows every agency needs is a decent starting map.


The gotchas we've actually hit

  • Descriptions are the product. The model only calls tools as well as you describe them. Spend your time here, not on the plumbing.
  • HTTPS is non-negotiable. Self-hosted instances need a real domain and cert. Localhost endpoints won't reach a cloud client, and this eats an hour if you don't know it going in.
  • Auth on every endpoint, one credential per client. An open MCP server is a liability. Scope tools narrowly and log every call.
  • Don't confuse the three modes. Ninety percent of "broken" setups are the wrong node for the goal. Re-read the table.
  • Version drift is real. MCP support in n8n is moving fast in 2026 — check your instance version against the official n8n docs before assuming a node behaves the way a six-month-old tutorial says.

MCP is the first standard that makes "AI agent that does real work" a configuration job instead of a coding project, and n8n is the fastest place we've found to stand it up. The teams winning with it aren't the ones with the fanciest model — they're the ones whose tools are clearly named, tightly scoped, and actually wired to the systems that run the business.

Want your existing automations turned into agent-callable tools — without the trial-and-error? Get a free automation audit and we'll map which of your workflows are one node away from being MCP tools, and which ones you should build first.