If you searched “n8n MCP server” you probably have a specific thing in mind, and there is a good chance the page you landed on before this one was about a different thing with the same name. Five separate pieces of software get called some version of “the n8n MCP server,” they point in opposite directions, and picking the wrong one costs you an afternoon.

Here is the disambiguation first, then how to actually run the one you want.

What is the n8n MCP server?

There are two n8n features with that name. The instance-level MCP server is built into n8n and exposes your whole instance at https://your-n8n-domain/mcp-server/http, so a client like Claude can search, run and build workflows. The MCP Server Trigger node is a node you place inside one workflow, and it exposes tools from that workflow only. Instance-level is one connection per n8n install; the trigger node is one connection per workflow.

The five things called “n8n MCP”

WhatDirectionWhere it runsUse it when
Instance-level MCP servern8n is the serverYour n8n instance, /mcp-server/httpYou want Claude to see and run your workflows
MCP Server Trigger noden8n is the serverInside one workflowYou want one workflow to behave as a purpose-built MCP server
MCP Client Tool noden8n is the clientSub-node on an AI AgentYour n8n agent needs to call someone else’s MCP server
MCP Client noden8n is the clientAny workflow stepYou want to call an MCP server without an AI Agent
n8n-mcp (community)Neither, sort ofYour laptopYou want Claude to write n8n workflows for you

The direction column is the one that matters. Half the confusion in this space is people reading a guide about n8n calling out to an MCP server when what they wanted was an MCP client calling in to n8n.

And a sixth thing that is not n8n’s at all: hosting platforms including us ship MCP connectors for managing servers. Ours deploys and manages pods. It has nothing to do with your workflows. More on why that distinction matters at the end.

Instance-level MCP: the one most people want

This is the feature that grew fastest and the one the search term is mostly chasing now. It arrived as a beta in n8n 1.121.0 and lost its preview label around 2.33.

One connection covers your whole instance. n8n’s docs put the difference plainly:

Instance-level MCP access lets you create one connection per n8n instance, use centralized authentication, and choose which workflows to enable for access. […] In comparison, you configure an MCP Server Trigger node inside a single workflow. This node exposes tools only from that workflow.

Turning it on: Settings > Instance-level MCP > Enable MCP access. You need instance owner or admin permissions, and it is off by default. On self-hosted n8n there are two environment variables worth knowing:

N8N_MCP_ACCESS_ENABLED=true   # default false - turn the feature on
N8N_MCP_MANAGED_BY_ENV=true   # apply MCP settings from env on every boot, lock the UI
N8N_DISABLED_MODULES=mcp      # remove the endpoints and hide the UI entirely

That last one is the kill switch. If you run n8n for other people and do not want an MCP surface at all, it removes the endpoints rather than just hiding the toggle.

What clients get. A lot, and it is worth knowing before you enable it. The tool surface covers workflow management (search_workflows, get_workflow_details, execute_workflow, test_workflow, publish_workflow), executions, credentials, a workflow builder (create_workflow_from_code, update_workflow, validate_workflow), agent management and data tables.

Exposure is opt-in per workflow, with one exception. Enabling MCP on the instance exposes nothing on its own. You then enable individual workflows, or a whole project or folder from n8n 2.24.0. The exception is search_workflows, which can see every workflow the current user can view, though it returns previews rather than full workflow data.

There is one eligibility rule that catches people, straight from the docs: “You can only enable MCP access for published workflows that contain a webhook, form, schedule, or chat trigger node.” A draft, or a workflow whose only entry point is a manual trigger, will not appear no matter how many toggles you flip.

One more thing to understand before you connect a second client: access is not scoped per client. Every client you connect sees every workflow you exposed. You cannot give Claude one set and ChatGPT another. Visibility is still scoped per user, but not per client.

MCP Server Trigger: one workflow, on purpose

The node arrived in n8n 1.88.0, released 2025-04-10, alongside the MCP Client Tool. The changelog line was short: “We are adding two new nodes: a MCP Server Trigger for any workflow / a MCP Client Tool for the AI Agent.”

It gives you two URLs, production and test:

https://your-webhook-base-url/mcp/<your-path>        # production
https://your-webhook-base-url/mcp-test/<your-path>   # test

The path defaults to a random string specifically so two trigger nodes do not collide, and you can edit it.

Transport: both SSE and Streamable HTTP. Not stdio. Node versions below 2 use the older split /sse and /messages sub-paths; version 2 and up use a single path. Worth noting that the MCP specification itself lists HTTP+SSE as deprecated in favour of Streamable HTTP as of spec revision 2025-03-26, though it has not been removed. n8n has not deprecated anything on its side.

Authentication defaults to none, and that is deliberate. The node’s own builder guidance says: “Default to ‘none’. n8n exposes inbound trigger URLs publicly by design. Only select an authentication method when the user explicitly asks to authenticate inbound traffic.” The options are None, n8n User Auth via OAuth2 on version 2 and up, Bearer Auth, and Header Auth. If the workflow behind that trigger does anything you would not want a stranger doing, set one.

The community n8n-mcp project is a different animal

czlonkowski/n8n-mcp has 22,821 GitHub stars as of 2 September 2026, MIT licensed, latest release v2.77.0 on 31 August. A good share of the “n8n mcp” search volume is looking for this rather than for anything inside n8n.

It solves the opposite problem. n8n’s own MCP server lets an assistant use your workflows. n8n-mcp gives an assistant a map of n8n itself so it can build workflows: 2,616 nodes indexed, 832 core plus 1,784 community, 99% property coverage, and a library of 2,352 workflow templates.

Point it at Claude Code:

claude mcp add n8n-mcp \
  -e MCP_MODE=stdio \
  -e LOG_LEVEL=error \
  -e DISABLE_CONSOLE_OUTPUT=true \
  -e N8N_API_URL=https://your-n8n-instance.com \
  -e N8N_API_KEY=your-api-key \
  -- npx n8n-mcp

Without N8N_API_URL and N8N_API_KEY you get documentation tools only, which is genuinely useful on its own. With them, it can read and write against the live instance. The README carries a warning in bold that deserves repeating: never edit your production workflows directly with AI.

Most people who are serious about this end up running both. n8n-mcp to author the workflow, n8n’s own MCP server to let an assistant run it afterwards.

Running it self-hosted: three things that actually break

1. The webhook base URL, and its recent rename. The MCP Server Trigger is a webhook, so it inherits whatever n8n thinks its public URL is. Set it explicitly:

N8N_WEBHOOK_URL=https://n8n.example.com

Note the name. WEBHOOK_URL is deprecated from n8n 2.35.0 and replaced by N8N_WEBHOOK_URL. The old name still works and n8n logs a warning, but essentially every guide written before mid-2026 uses the deprecated one, including guides that are otherwise fine. Behind a proxy you also want N8N_PROXY_HOPS=1 and the X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto headers forwarded.

For cloud-based MCP clients your instance has to be publicly reachable. Claude.ai cannot connect to localhost. If yours is currently showing localhost as its webhook URL, that is a proxy configuration problem rather than an MCP one, and we wrote up the fix separately in n8n HTTPS and webhook URL.

2. Proxy buffering will silently break it. This is the single most common self-hosted failure and it does not look like a proxy problem, it looks like MCP being flaky. n8n’s own nginx snippet:

location /mcp/ {
    proxy_http_version          1.1;
    proxy_buffering             off;
    gzip                        off;
    chunked_transfer_encoding   off;
    proxy_set_header            Connection '';
}

Separately, clients send MCP-Protocol-Version, Mcp-Method and Mcp-Name. A proxy or WAF that forwards only an allowlist has to allow all three, or, in n8n’s words, “clients may fail to connect or fall back to an older protocol version.” The quiet fallback is the nasty half: it half-works, and you debug the wrong layer.

3. Queue mode needs one dedicated webhook replica. If you scaled n8n into queue mode, MCP has a constraint most scaling guides do not mention. A single webhook replica is fine. Multiple replicas require routing all /mcp* requests to one dedicated replica, or, per the docs, “your SSE and streamable HTTP connections will frequently break or fail to reliably deliver events.” Long-lived connections and round-robin load balancing do not mix.

The version table, because half of this is version-gated

CapabilityNeeds
MCP Server Trigger, MCP Client Tool nodesn8n 1.88.0
Instance-level MCP (beta)n8n 1.121.0
Standalone MCP Client noden8n 1.122.0
Workflow-building tools over MCPn8n 2.13.0
Project and folder-level MCP togglesn8n 2.24.0
”Connect a client” dialog, per-client setup stepsn8n 2.33.0
Auto-expose new workflowsn8n 2.36.0 (rolling out)

That 2.33.0 row is the one to check before you follow any tutorial. Below it, instance-level MCP works, but the settings page is a simpler layout with no per-client setup steps, and you configure the client by hand. Plenty of guides show screenshots of a dialog your version does not have.

Where we fit, and one thing we are not

We are a hosting platform, so the useful thing we can tell you is what it costs to have somewhere reliable to run this. n8n on InstaPods is $7/mo flat on the Build plan: 2 vCPU, 2 GB RAM, 25 GB SSD, HTTPS and a public URL configured at deploy, which is the part instance-level MCP needs in order to talk to a cloud client at all. No per-execution billing.

Two honest caveats, because this post is useless if it is a pitch.

We pin the n8n version we bake rather than tracking latest, so what a fresh pod boots depends on when we last rebuilt the image. As of 2 September 2026 that pin is 2.37.7, npm’s current release, so a new pod lands above the 2.33.0 line in the table and has the Connect a client dialog from the start.

Worth knowing that this is a real variable and not a detail, whoever you host with. We measured our own fleet that morning: of 191 running n8n pods, 127 were still on the version the previous image shipped, because a pod keeps whatever it booted with until somebody updates it. Rebuilding the image fixes the starting point for new pods; it does not touch existing ones. So if you have had an n8n instance for a while, anywhere, check n8n --version before you follow a guide - ours updates in one click with an automatic snapshot and rollback, and most hosts have some equivalent.

Our MCP connector is not an n8n MCP server. InstaPods ships its own connector at https://app.instapods.com/api/mcp, and it is easy to assume from the name that it does something for your workflows. It does not. It manages pods: create one, deploy code, set environment variables, read logs, run a command, change plan. Twenty-one tools, all about hosting. If you connect it to Claude expecting to see your n8n workflows, you will see your servers instead. The two are complementary and completely separate: ours gets n8n running, n8n’s exposes what n8n does. Anyone telling you a hosting provider’s MCP server gives an assistant access to your automations is describing something that does not exist.

Which one should you actually use?