How to Connect Claude to n8n's MCP Server Without Exposing Every Workflow

The n8n MCP server that ships inside n8n lets Claude find, test, run and edit the workflows you enable, and only preview the rest. I budget half an hour for the setup below, written against n8n 2.42.5, the stable release of 8 October 2026. It costs nothing extra if you already run n8n (self hosted Community edition is free; Cloud Starter is €20 a month billed annually) and works on every Claude plan, including Free. It's for people with a few n8n workflows who want Claude to operate them without handing over everything.

Pasting the URL takes two minutes. Four details in n8n's docs decide whether it's safe: every connected client sees the same enabled set, the search tool previews workflows you never enabled, the run tool defaults to your published version, and workflows Claude creates enable themselves for MCP. The steps below are built around them.

Update, 9 October 2026. The stable release moved from 2.40.7 to 2.42.5, and n8n 2.42.0 renamed Workflows exposed to Workflows enabled. Step 9 is new: it probes the instance endpoint and runs the MCP Server Trigger end to end on a local n8n.

What you need first

• n8n 2.33.0 or newer for the Connect a client dialog and callback URL controls (building and editing over MCP needs 2.13.0).
• Owner or admin rights. Only those roles can switch MCP access on.
• A publicly reachable instance for claude.ai and Claude Desktop. Anthropic's help center says Claude connects from Anthropic's cloud even in Claude Desktop. A local install at http://localhost:5678 only works with a client on the same machine, such as Claude Code.
• Any Claude plan. The same article lists custom connectors on Free, Pro, Max, Team and Enterprise, with Free limited to one and Team limited to Owners adding them.
• One low risk workflow with a webhook trigger.

Which of the four routes you need

"Connect Claude to n8n" can mean four different things. The Model Context Protocol is only the transport; the question is which side is the server.

n8n's docs describe the first as one connection per instance with central authentication. The trigger node is closer to the hand built servers in my guide to MCP servers in production.

Step 1: Decide which n8n user Claude acts as

I don't approve the connection as the instance owner. Whatever you connect acts as the n8n user who approved it, and the API key n8n generates is a personal access token tied to that user. The search_workflows tool previews every workflow that user can view, enabled or not, and the enabled set is shared by every client you connect.

You get two levers. The first is the user: a separate member account that can only reach the right workflows becomes the real boundary, the least privilege idea applied to n8n. How you give it workflows depends on your edition:

• Paid plans: share the chosen workflows and credentials with the member account, or put them in a project it belongs to.
• Free Community edition: sharing and projects aren't included, so sign in as the member account, create the workflows there, and add its own copies of only the credentials they use.

The second lever is the grant. n8n's docs say each OAuth client only gets the permissions you granted when it connected, and its OAuth metadata lists 16 scopes, among them workflow:read, workflow:execute and credential:read (I read the list in Step 9). I did not see the consent screen, so I can't say how finely it lets you choose; I'd grant the least that covers a first trial.

Step 2: Enable the n8n MCP server and lock the callback URLs

1. Open Settings. Go to Settings > Instance-level MCP.
2. Turn it on. Select Enable MCP access. The page now shows Connection details, Access and Connected clients.
3. Restrict OAuth redirects. By default n8n accepts any callback URL, which its docs call less secure. In Access, open Allowed callback URLs, choose Only trusted URLs, and list the URLs of the clients you use; a client whose URL isn't listed can't finish sign in. I'd connect your first client before locking this down, so you can see which URL it uses.
4. Leave auto expose off. Auto-expose new workflows (rolling out from n8n 2.36.0) is off by default. Keep it off, or every workflow anyone creates later is reachable by every connected client.

When it worked, Connection details shows the MCP status as enabled and a Connect button. Self hosted, N8N_MCP_MANAGED_BY_ENV=true with N8N_MCP_ACCESS_ENABLED=true (from n8n 2.20.0) sets the switch from the environment, and N8N_DISABLED_MODULES=mcp removes the feature entirely.

Step 3: Expose one workflow and describe it well

Clients can't read details, run or edit a workflow until you enable it. In the workflow editor, open the Workflow menu (...) > Settings and switch on Available in MCP. The Workflows list has Enable MCP access on each card menu, and there's Settings > Instance-level MCP > Workflows enabled > Enable workflows (named Workflows exposed before 2.42.0). From n8n 2.24.0 a project or folder menu can toggle everything inside it, which I'd avoid on a first connection.

Running is separate: in production mode execute_workflow needs a published version with a webhook, chat, form or schedule trigger (manual mode also takes a manual trigger). Check that first if Claude can't run a workflow.

Then choose Edit description from the same menu and write it like a function docstring. "Creates a HubSpot contact from name, email and company. Input: webhook POST body with those three fields. Side effect: writes to the live CRM." tells Claude far more than "HubSpot sync". Name any side effect you can't undo.

Step 4: Copy the right server URL

In Connection details, select Connect. The Connect a client dialog opens on the OAuth (recommended) tab. Pick your client: Claude Code sits under CLI, Claude.ai under Web, where the dialog offers One-click setup. Copy the Server URL, which ends in /mcp-server/http:

# not run: placeholder domain
https://your-instance.app.n8n.cloud/mcp-server/http

n8n's client examples warn that this isn't your editor's address, so don't copy your browser's address bar.

Step 5: Connect Claude

Claude.ai and Claude Desktop

I did not click through this flow: it needs a Claude account and a public n8n URL. The steps follow Anthropic's help center article as I read it on 9 October 2026.

1. Open connectors. Go to Customize > Connectors, click + Add, then Add custom connector. On Team and Enterprise an owner uses Organization settings > Connectors.
2. Name it and paste the Server URL from Step 4, then click Continue.
3. Review the authentication settings Claude detected, changing them only if your server needs something different. Click Continue, then Add.
4. Approve in n8n. Claude sends you to n8n. Sign in as the member account from Step 1 and approve (use a private window, or a browser already signed in as the owner will approve as the owner). On Team and Enterprise, each member then clicks Connect on the connector.

Claude Code

One command, from n8n's client examples. Claude Code's docs recommend HTTP for remote servers and mark SSE deprecated:

# not run: placeholder 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 OAuth sign in in your browser. I couldn't do that last part, but Step 9 shows Claude Code 2.1.220 reaching a local n8n and reporting that it needs authentication. n8n's official skills plugin bundles this connection (not run).

If you must use an API key

Some headless setups can't do an OAuth redirect. Switch the dialog to the API key tab, copy the token (n8n shows it once), and pass it as a header:

# not run: placeholder domain and token
claude mcp add --transport http n8n-mcp https://your-n8n-domain/mcp-server/http \
  --header "Authorization: Bearer YOUR_N8N_MCP_TOKEN"

I prefer OAuth because its clients show up in Connected clients with a Revoke access button. API key clients don't, and rotating the key cuts off every client using it. My notes on what stolen AI API keys get used for explain why that matters.

What you should see: Connected clients in n8n counts one client, and the n8n tools appear under the connector in Claude.

Step 6: Run a staged first session

Run it in this order, so nothing live happens until you've seen the test pass.

1. Search. Ask: "List the n8n workflows you can see and tell me which ones you can run." Claude calls search_workflows. Workflows you didn't enable may appear as previews, which is the behavior from Step 1.
2. Read details. Ask it to open your enabled workflow and describe its trigger and nodes (get_workflow_details).
3. Pinned test. Ask: "Prepare pin data for this workflow, fill it with realistic sample values, then test it." Claude calls prepare_workflow_pin_data, then test_workflow, which pins trigger nodes, nodes with credentials and HTTP Request nodes to that sample data while Set, If and Code nodes run for real. It times out after 300 seconds unless Claude passes a larger timeout, up to 3,600.
4. Manual run. Ask for manual mode with a body such as {"name": "Ada Test", "email": "ada@example.com"}. That runs the current, unpublished version against real services. Webhook, form and chat triggers need input, so execute_workflow also needs the trigger's name (n8n 2.36.0 and later); have Claude read it from the details first.
5. Production run. Only now ask for production mode, which runs the published version.

execute_workflow returns an execution ID immediately, so have Claude check get_workflow_execution before it reports success.

Step 7: Let Claude build and edit workflows

From n8n 2.13.0 the same connection can create and edit workflows. I ask Claude to follow the build pipeline in order:

1. Look up nodes with search_nodes and get_node_types instead of guessing parameter names.
2. Validate first. n8n's reference says validate_workflow must be called before creating or updating.
3. Create with create_workflow_from_code, edit with update_workflow (1 to 100 operations, saved atomically apart from node group operations).
4. Review with get_workflow_versions_diff (n8n 2.36.0 and later) before you publish anything.

Create n8n Workflows With Agents | Official MCP

n8n's docs suggest a coding agent such as Claude Code over a chat client for building. Its list_credentials tool never returns secret values, so Claude can reference your Slack or HubSpot credential by ID without seeing it.

Publishing stays a human decision in my setups. A publish_workflow tool exists, but a person should read the canvas first, the same human in the loop rule I use for agentic email that never sends on its own.

Step 8: Review access every month

Once a month, open Settings > Instance-level MCP and check Connected clients (revoke any OAuth client nobody uses; it disconnects at once), Workflows enabled (remove anything that shouldn't be callable, including workflows Claude created), and whether an API key is still in use. If not, rotate it so the old value dies.

Step 9: Check it locally and add a narrow MCP Server Trigger endpoint

This step is optional; stop at Step 8 if the instance route is all you need. You need Docker and Python. The instance server gives Claude the whole enabled set, and for a smaller one you use the MCP Server Trigger node. I probed the instance endpoint and ran the trigger end to end on a throwaway n8n 2.42.5 in Docker, bound to 127.0.0.1, with no owner account and no sign in. I did not call any instance tool, because that needs a signed in client. This starts it with MCP access on:

docker run -d --name n8n-mcp-demo -p 127.0.0.1:15678:5678 \
  -v n8n-mcp-demo-data:/home/node/.n8n \
  -e N8N_MCP_MANAGED_BY_ENV=true -e N8N_MCP_ACCESS_ENABLED=true \
  -e N8N_EDITOR_BASE_URL=http://127.0.0.1:15678 -e WEBHOOK_URL=http://127.0.0.1:15678/ \
  -e N8N_DIAGNOSTICS_ENABLED=false -e N8N_VERSION_NOTIFICATIONS_ENABLED=false \
  docker.n8n.io/n8nio/n8n:2.42.5 > /dev/null

Wait for it:

until [ "$(curl -s -o /dev/null -w '%{http_code}' -X POST http://127.0.0.1:15678/mcp-server/http)" = "401" ]; do sleep 2; done
curl -s http://127.0.0.1:15678/healthz

{"status":"ok"}

With access on, the instance endpoint answers a tokenless request with a 401 and points to its OAuth metadata, which lists the scopes a grant can carry:

curl -s -i -X POST http://127.0.0.1:15678/mcp-server/http \
  -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}' \
  | tr -d '\r' | grep -E '^(HTTP/|WWW-Authenticate)'

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="n8n MCP Server", resource_metadata="http://127.0.0.1:15678/.well-known/oauth-protected-resource/mcp-server/http"

curl -s http://127.0.0.1:15678/.well-known/oauth-protected-resource/mcp-server/http \
  | python -c "import json,sys; d=json.load(sys.stdin)['scopes_supported']; print(len(d), d[:3], 'credential:read' in d)"

16 ['workflow:read', 'workflow:write', 'workflow:execute'] True

With access off, I got a 404 and {"message":"MCP access is disabled"} after restarting with N8N_MCP_ACCESS_ENABLED=false. Now the trigger route. This workflow has one MCP Server Trigger with Bearer auth and two Code Tool nodes. Node version 2.1 serves streamable HTTP at the path you set, here /mcp/demo-tools, and sends the instructions field to clients:

{
  "id": "mcpdemo0000000001",
  "name": "MCP trigger demo",
  "nodes": [
    {
      "id": "11111111-1111-4111-8111-111111111111",
      "name": "MCP Server Trigger",
      "type": "@n8n/n8n-nodes-langchain.mcpTrigger",
      "typeVersion": 2.1,
      "position": [0, 0],
      "webhookId": "aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa",
      "parameters": {
        "authentication": "bearerAuth",
        "path": "demo-tools",
        "instructions": "Two small demo tools. Call add_numbers for arithmetic and shout for upper casing."
      },
      "credentials": { "httpBearerAuth": { "id": "bearercred0000001", "name": "Demo bearer" } }
    },
    {
      "id": "22222222-2222-4222-8222-222222222222",
      "name": "add_numbers",
      "type": "@n8n/n8n-nodes-langchain.toolCode",
      "typeVersion": 1.3,
      "position": [-200, 220],
      "parameters": {
        "name": "add_numbers",
        "description": "Add two numbers a and b and return the sum.",
        "language": "javaScript",
        "jsCode": "const a = Number(query.a); const b = Number(query.b); return String(a + b);",
        "specifyInputSchema": true,
        "schemaType": "manual",
        "inputSchema": "{\"type\":\"object\",\"properties\":{\"a\":{\"type\":\"number\"},\"b\":{\"type\":\"number\"}},\"required\":[\"a\",\"b\"]}"
      }
    },
    {
      "id": "33333333-3333-4333-8333-333333333333",
      "name": "shout",
      "type": "@n8n/n8n-nodes-langchain.toolCode",
      "typeVersion": 1.3,
      "position": [200, 220],
      "parameters": {
        "name": "shout",
        "description": "Return the input text in upper case.",
        "language": "javaScript",
        "jsCode": "return String(query).toUpperCase();"
      }
    }
  ],
  "connections": {
    "add_numbers": { "ai_tool": [[{ "node": "MCP Server Trigger", "type": "ai_tool", "index": 0 }]] },
    "shout": { "ai_tool": [[{ "node": "MCP Server Trigger", "type": "ai_tool", "index": 0 }]] }
  },
  "settings": {},
  "active": false
}

Save the two blocks as workflow.json and credential.json. The credential holds a fake token:

[
  {
    "id": "bearercred0000001",
    "name": "Demo bearer",
    "type": "httpBearerAuth",
    "data": { "token": "demo-local-token-not-a-secret" }
  }
]

Import both, publish, and restart so the production webhook registers (the CLI's update:workflow is deprecated for publish:workflow):

docker cp workflow.json n8n-mcp-demo:/tmp/workflow.json
docker cp credential.json n8n-mcp-demo:/tmp/credential.json
docker exec n8n-mcp-demo n8n import:credentials --input=/tmp/credential.json
docker exec n8n-mcp-demo n8n import:workflow --input=/tmp/workflow.json
docker exec n8n-mcp-demo n8n publish:workflow --id=mcpdemo0000000001
docker restart n8n-mcp-demo > /dev/null
until [ "$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:15678/mcp/demo-tools)" = "403" ]; do sleep 2; done

Successfully imported 1 credential.
Importing 1 workflows...
Successfully imported 1 workflow.
Publishing workflow with ID: mcpdemo0000000001 (current version)
Note: Changes will not take effect if n8n is running.
Please restart n8n for changes to take effect if n8n is currently running.

A client on the official Python SDK (2.3.0, installed with uv pip install mcp in a virtual environment, which also provides the python command used below) sends a request with no token, then connects with it, lists the tools and calls both:

# trigger_client.py
import asyncio

import httpx2
from mcp import Client
from mcp.client.streamable_http import streamable_http_client

URL = "http://127.0.0.1:15678/mcp/demo-tools"
TOKEN = "demo-local-token-not-a-secret"


async def main():
    # 1. No credentials: the Bearer auth on the trigger node should refuse us.
    async with httpx2.AsyncClient() as bare:
        r = await bare.post(URL, json={"jsonrpc": "2.0", "id": 1, "method": "ping"})
        print("no token ->", r.status_code, r.text)

    # 2. With the Bearer token: initialize, list the tools, call both.
    http = httpx2.AsyncClient(headers={"Authorization": f"Bearer {TOKEN}"})
    async with Client(streamable_http_client(URL, http_client=http)) as client:
        print("server:", client.server_info.name, "| protocol:", client.protocol_version)
        print("instructions:", client.instructions)
        tools = await client.list_tools()
        for t in sorted(tools.tools, key=lambda t: t.name):
            print("tool:", t.name, "|", t.description)
        r = await client.call_tool("add_numbers", {"a": 2, "b": 3})
        print("add_numbers(2, 3) ->", r.content[0].text)
        r = await client.call_tool("shout", {"input": "hello from claude"})
        print("shout ->", r.content[0].text)


asyncio.run(main())

python trigger_client.py 2>/dev/null

no token -> 403 Authorization data is wrong!
server: MCP_Server_Trigger | protocol: 2025-11-25
instructions: Two small demo tools. Call add_numbers for arithmetic and shout for upper casing.
tool: add_numbers | Add two numbers a and b and return the sum.
tool: shout | Return the input text in upper case.
add_numbers(2, 3) -> 5
shout -> HELLO FROM CLAUDE

The SDK also prints an Unknown SSE event: endpoint warning on stderr, which I hid. A node set to version 1 serves SSE at /mcp/<path>/sse instead, and an SSE client listed and called its tool too. n8n's docs say the node supports both and not stdio. The next script counts executions around one session: initialize and the tool listing created no webhook mode executions, and each tool call created one:

# count_executions.py
import subprocess
import sys

# Read only count of webhook mode executions in the demo container's SQLite file.
JS = """
const {DatabaseSync} = require("node:sqlite");
const db = new DatabaseSync("/home/node/.n8n/database.sqlite", {readOnly: true});
console.log(db.prepare("select count(*) as n from execution_entity where mode = 'webhook'").get().n);
"""


def count():
    out = subprocess.run(["docker", "exec", "n8n-mcp-demo", "node", "-e", JS],
                         capture_output=True, text=True).stdout
    return int(out.strip().splitlines()[-1])


before = count()
# One session: initialize, tools/list, then two tool calls.
subprocess.run([sys.executable, "trigger_client.py"], capture_output=True, text=True)
print("executions created by one session:", count() - before)

python count_executions.py

executions created by one session: 2

Claude Code reaches both endpoints with the Step 5 command. I pointed it at a throwaway config folder to keep my real settings untouched. The instance endpoint wants a sign in I did not complete; the trigger endpoint accepts the Bearer header:

export CLAUDE_CONFIG_DIR="$(mktemp -d)"
claude mcp add --transport http n8n http://127.0.0.1:15678/mcp-server/http > /dev/null
claude mcp add --transport http n8n-tools http://127.0.0.1:15678/mcp/demo-tools \
  --header "Authorization: Bearer demo-local-token-not-a-secret" > /dev/null
claude mcp list | grep '^n8n'
rm -rf "$CLAUDE_CONFIG_DIR"

n8n: http://127.0.0.1:15678/mcp-server/http (HTTP) - ! Needs authentication
n8n-tools: http://127.0.0.1:15678/mcp/demo-tools (HTTP) - ✔ Connected

Two more notes from n8n's docs and the node's source in the 2.42.5 image. The docs list None, Bearer and Header auth, but node version 2 and later also offers n8n User Auth (OAuth2), which I read in the code and did not test. n8n's docs also say claude.ai asks for an n8n sign in even when authentication is None. I'd expect Bearer auth, with the token in the connector's Request headers field, to work around it, but I didn't test that. When you're done, remove the sandbox:

docker rm -f n8n-mcp-demo > /dev/null
docker volume rm n8n-mcp-demo-data > /dev/null
docker rmi docker.n8n.io/n8nio/n8n:2.42.5 > /dev/null

Troubleshooting

"You do not have sufficient permissions to authorize this request"

This OAuth approval page means MCP access is off for the instance. The wording doesn't say so, but n8n's docs state there's no other cause. Enable it in Step 2, then reconnect.

Claude Code lists the server as failed though n8n is running

This only affects remapped ports and proxies. In Docker, claude mcp list showed a refused connection because n8n built its OAuth discovery URLs from localhost:5678 while I had published port 15678, so the client followed a URL that went nowhere. Setting N8N_EDITOR_BASE_URL and WEBHOOK_URL to the address clients really use fixed it (I set both together).

Connection fails behind a proxy

If a reverse proxy or web application firewall allowlists headers, add MCP-Protocol-Version, Mcp-Method and Mcp-Name, or clients may fail to connect or drop to an older protocol. For the trigger node, also turn off proxy buffering in nginx, and with several webhook replicas route every /mcp* request to one.

Costs, scale, and when to skip this

Cost at scale. The MCP server has no separate price; you pay for executions. On n8n's pricing page as I read it on 9 October 2026, Starter is €20 a month billed annually for 2,500 executions and Pro is €50 for 10,000. n8n's docs say only production executions count towards the quota, so Claude's pinned tests and manual runs shouldn't. Each tool call on the trigger route ran in webhook mode, and the docs say each webhook request counts one execution, so I'd assume trigger traffic counts. They don't say whether a production run started through execute_workflow counts, so I'd watch the Insights dashboard for a month.

When not to use this. Claude only acts while you're in a conversation with it. It won't react to a new lead at 3 a.m.; your n8n triggers do that. Keep scheduled or event driven work in n8n, including any AI agent workflows running inside n8n. And if different clients need different workflows, the instance server can't do it, so use separate MCP Server Trigger workflows as in Step 9.

I build and monitor setups like this for clients; see how I work.

Frequently asked questions

Does the n8n MCP server work with the free Claude plan?

Yes. Anthropic lists custom connectors on the Free plan, but Free accounts can add only one custom connector. If n8n is the only remote MCP server you use, that's enough. If you already use another custom connector, you'll need to remove it or move to a paid plan such as Pro before adding n8n.

Is the n8n MCP server available on self hosted n8n?

Yes. Instance level MCP works on n8n Cloud and on self hosted instances, where owners can also manage it through environment variables or remove it with N8N_DISABLED_MODULES=mcp. For cloud based clients such as claude.ai, the instance must be reachable from the public internet.

Can Claude see all my n8n workflows?

It can see previews of every workflow the approving user can view through the search tool, but it can only read details, run or edit workflows you've enabled for MCP. Enabling isn't per client, so every connected client sees the same set. Approving as a limited member account, and limiting what each OAuth client was granted, are the two ways to shrink that.

What is the difference between the n8n MCP server and the MCP Server Trigger node?

The instance MCP server is one endpoint for the whole instance that exposes the workflows you enable and adds building tools. The MCP Server Trigger node lives inside one workflow and exposes only the tools you attach to it, over SSE or streamable HTTP, with Bearer or header authentication. Use the trigger node for a narrow, hand designed tool set.