n8n MCP Server Setup: Connect Claude Code to n8n

An n8n MCP server lets an AI client like Claude Code find your n8n workflows and run them as tools. You turn it on under Settings > Instance-level MCP, enable the workflows you want exposed, and add one URL to the client. Setup takes about ten minutes. Most of the real work is deciding what to expose.

Search results for "n8n mcp" mix several different things together, so this post sorts them out first and then walks through the setup we use with Claude Code.

What "n8n MCP" actually refers to

Model Context Protocol (MCP) is the standard that lets an AI client discover and call tools on another system. n8n touches it in four separate places, and the name collision causes most of the confusion.

For most small businesses the first row is the one that matters. It is also the least documented in blog posts, because most older tutorials were written before it existed and describe the trigger node or the community package instead.

How to set up the built-in n8n MCP server

You need instance owner or admin permissions to turn it on. These are the steps from n8n's docs, in the order we do them.

1. Go to Settings > Instance-level MCP and select Enable MCP access.
2. Open Connect a client and copy the Server URL. It ends in /mcp-server/http.
3. Choose how the client authenticates: OAuth, which n8n recommends, or an access token from the API key tab.
4. Enable the specific workflows you want the client to reach. Nothing is exposed by default.
5. Add the server to your client and test it with a harmless read-only workflow first.

Step 4 is the easy one to miss. A client can see previews of workflows through search, but it cannot run or edit one until you enable it. In the workflow editor that is the workflow Settings toggle called Available in MCP. You can also enable a whole project or folder from its options menu.

Connect Claude Code to n8n

Claude Code adds remote servers with claude mcp add --transport http. This is the OAuth version from n8n's own docs. Replace <your-n8n-domain> with your own domain.

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

Then run /mcp inside Claude Code, select n8n and finish the authorization in the browser. If you would rather use the access token from the API key tab, pass it as a header:

claude mcp add --transport http n8n-mcp https://<your-n8n-domain>/mcp-server/http \
  --header "Authorization: Bearer <YOUR_N8N_MCP_TOKEN>"

Claude Code stores a server in local scope by default, which keeps it in your own config. Pass --scope project to write it to a .mcp.json in the repo so a team shares it. If you do that, put the token in an environment variable and reference it as ${VAR} in the header value rather than committing it. Run claude mcp list to see whether the server shows as connected or needs authentication.

The instruction file, skills and hooks that decide how Claude Code uses these tools are a separate job. That is the work on our Claude Code setup page.

The MCP Server Trigger node: when you want your own endpoint

The instance-level server gives a client the whole instance, filtered by what you enabled. The MCP Server Trigger node is narrower. You build a workflow that starts with the trigger, attach tool nodes to it, and n8n exposes just those tools at a URL of its own.

It supports Server-Sent Events and streamable HTTP, not stdio. Authentication is none, bearer or header auth. The test URL works while you listen for a test event, and the production URL registers when you publish the workflow. A random path is generated by default.

We reach for this when a client needs a small, named set of actions, for example "look up a contact" and "create a follow-up task," and should never see anything else. It is also the better fit when another person, not you, will connect their own client and you do not want their access tied to your user account.

Reverse proxies and queue mode

This is where self-hosted setups break, and the symptom is usually a client that connects and then hangs or drops. n8n's docs call out the following.

• Some reverse proxies strip headers. Allow MCP-Protocol-Version, Mcp-Method and Mcp-Name.
• For nginx or similar on the Server Trigger endpoint, turn off proxy buffering, gzip and chunked transfer encoding, and clear the Connection header.
• In queue mode with several webhook replicas, route all /mcp requests to one dedicated replica, or SSE and streamable HTTP connections can break.

If a client connects and then hangs, proxy buffering is the first setting we check.

The community n8n-mcp project

The n8n-mcp repository by czlonkowski is a different tool. It is a community project, MIT licensed, that gives an AI assistant documentation for n8n's nodes plus a library of workflow templates. With n8n API credentials configured it can also create, update and test workflows.

Its README is blunt about the risk: it says never to edit production workflows directly with AI, and to copy a workflow, test in a development environment and keep backups. We agree. When we use Claude Code to draft a workflow, it works on a copy, and a person reviews the node settings before anything goes live.

Facts to re-check, as of October 31, 2026

These details change between n8n releases. Check n8n's MCP server docs before relying on them.

• The Connect a client dialog and per-client steps need n8n 2.33.0 or later. Earlier versions show a simpler page, so you configure the client by hand.
• The builder tools, which create and edit workflows, need 2.13.0 or later.
• An Auto-expose new workflows setting is rolling out from 2.36.0 and is off by default.
• Agents are a separate Preview feature with their own exposure list, from 2.34.0.
• execute_workflow runs the published version of a workflow by default. Its manual mode runs the unpublished version.
• Access is instance-wide per user, not per client.
• The MCP Client Tool node documents an SSE endpoint parameter. Check the node page for newer transport options.

We did not verify plan-level limits on n8n Cloud for MCP access. If you are on Cloud, check your plan against n8n's pricing page. Our n8n pricing breakdown covers how executions are counted.

What we'd do

Start with the instance-level server and OAuth, and expose three or four workflows, all read-only or reversible. A lookup and a draft-creation workflow are enough to learn how the client picks tools. Do not turn on auto-expose for new workflows until you have a naming convention, because the client chooses tools partly from workflow names and descriptions.

Write each exposed workflow as if a stranger will call it with whatever input they guess. Validate inputs in the first node, return a short plain-text result, and put anything that sends an email, charges a card or deletes a record behind a separate approval step. Because access is shared across every client a user connects, one loose workflow is available to all of them.

We run our own agency this way: Claude Code skills handle judgment and scripts handle the exact work. The cold email reply review is a recorded example of that split, and the automations hub has the rest. Connecting n8n gives the agent one more tool to call.

Use the Server Trigger node instead when a client should see only a fixed set of actions. Use the community n8n-mcp project when the job is building workflows rather than running them, and only against a copy. If the whole setup feels like a lot to get right, our n8n workflow service covers building and securing it.