Most guides to this were written before the feature they describe existed in its current form, and it shows: they walk you through a dialog your n8n version does not have, or they wire up a community tool and call it “connecting n8n to Claude,” which is a different thing that does something else.

This is the current wiring, checked against n8n’s docs on 2 September 2026, with the version gates called out because that is where people get stuck.

How do I connect n8n to Claude?

Enable instance-level MCP in n8n under Settings > Instance-level MCP, expose the workflows you want reachable, then point Claude at https://your-n8n-domain/mcp-server/http. In Claude Code that is one command:

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

Then run /mcp and select n8n to finish the OAuth sign-in.

That is the whole thing when it works. The rest of this post is the four places it does not.

Check your version first

Before anything else:

n8n --version

If that says 2.33.0 or higher, you get the Connect a client dialog: pick your client from a dropdown, get tailored setup steps, one-click install for web clients. Follow n8n’s own screens, they are good.

If it says less than 2.33.0, instance-level MCP still works. You just do not get the dialog, and the page is a simpler layout. You build the config by hand, which is what the rest of this post covers anyway.

This matters more than it sounds like it should, because a lot of self-hosted n8n is a good way behind, and the gap is usually the host’s image rather than anything you did. We can put numbers on that from our own fleet, because we measured it on 2 September 2026 across 191 running n8n pods: 127 of them, two thirds, were still on the version our image shipped at the time (2.21.4), while the owners who had run the update were spread across 2.33.7, 2.34.5, 2.34.6, 2.35.7, 2.36.7, 2.36.8 and 2.36.9. Fifteen minor versions of spread on one platform, and the single biggest predictor of which side a pod landed on was whether anyone had pressed update.

We rebuilt that image the same day, so a pod deployed on InstaPods now boots 2.37.7 and the dialog is there from the start. The point generalises past us: whatever host you are on, the version you get on day one is whatever they baked, and it can be a year old. Check the number rather than the tutorial.

Step 1: enable MCP on the instance

Settings > Instance-level MCP > Enable MCP access. Instance owner or admin only. Off by default.

Self-hosted, you can do it with environment variables instead:

N8N_MCP_ACCESS_ENABLED=true    # default false
N8N_MCP_MANAGED_BY_ENV=true    # apply on every boot and lock the UI controls

N8N_MCP_MANAGED_BY_ENV is the one to use if you are managing config as code, because it stops someone changing it in the UI and having it silently revert on the next restart.

If you want the feature gone entirely rather than just off, N8N_DISABLED_MODULES=mcp removes the endpoints and hides the UI.

Step 2: expose the workflows

Enabling MCP exposes nothing on its own. This is a good design and a common source of “it connected but Claude sees nothing.”

Three ways to expose one workflow:

From n8n 2.24.0 you can toggle a whole project or folder at once via the Options menu > Manage MCP access. From 2.36.0, rolling out gradually, there is an Auto-expose new workflows setting, off by default, that covers workflows you create afterwards.

The eligibility rule that catches everyone, verbatim from n8n’s docs:

You can only enable MCP access for published workflows that contain a webhook, form, schedule, or chat trigger node.

So: it has to be published, and it has to have a real trigger. A draft will not appear. Neither will a workflow whose only entry point is the manual “Test workflow” button. If a workflow you expect is missing, check those two things before you touch anything to do with MCP.

One exception worth knowing: search_workflows can see every workflow the current user has permission to view, whether or not you exposed it. It returns previews only, not full workflow data, but it is not nothing. If workflow names are sensitive, that is the tool to think about.

Step 3: connect Claude

Pick OAuth or an API key. They are not equivalent, and the difference is about revocation.

Claude Code, OAuth

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

Then /mcp in Claude Code, select n8n, approve in the browser.

Or as config in claude.json:

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

Claude Code, API key

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

Get the token from Settings > Instance-level MCP > Connect > API key. n8n generates a personal access token tied to your user the first time you open that tab, and shows it once. Leave the tab and you get a redacted value, and your only option is to rotate, which revokes the old one and means updating every client using it.

Claude Desktop and Claude.ai

Both take the server URL directly in their connector settings. On n8n 2.33.0+, the Connect a client dialog offers a one-click setup for web clients. Otherwise paste https://your-n8n-domain/mcp-server/http into Claude’s own connector settings and complete the sign-in when the browser opens.

Which auth to pick

OAuth, if you can. Each connected client holds only the permissions granted at connect time, and Settings > Instance-level MCP > Connected clients > View all shows every client, its access level and when it connected, with per-row revoke.

API-key clients do not appear in that list at all, because they authenticate with a bearer token rather than an OAuth connection. You get one token per user, and revoking means rotating and re-pasting everywhere. Fine for a machine you control; poor for anything you might want to cut off individually.

Step 4: the things that break it

Proxy buffering

The most common self-hosted failure, and it presents as MCP being flaky rather than as a proxy problem. n8n’s own nginx configuration:

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

MCP over Streamable HTTP holds a long-lived connection. A buffering proxy sits on the events until the buffer fills, which looks exactly like a server that has stopped responding.

Stripped headers

Clients send MCP-Protocol-Version, Mcp-Method and Mcp-Name. A proxy or WAF forwarding only an allowlist has to allow all three. n8n’s own words on what happens otherwise: “clients may fail to connect or fall back to an older protocol version.” The fallback is the mean one, because a half-working connection sends you debugging the wrong layer. n8n allows these in its CORS policy from 2.36.0.

The webhook base URL, and the rename

n8n has to know its own public URL:

N8N_WEBHOOK_URL=https://n8n.example.com
N8N_PROXY_HOPS=1

WEBHOOK_URL is deprecated from n8n 2.35.0 in favour of N8N_WEBHOOK_URL. The old name still works and logs a warning. Nearly every n8n guide predating mid-2026 uses the deprecated spelling, so if you copied a docker-compose.yml from a blog post, that is probably what you have.

For Claude.ai and Claude Desktop your instance must be publicly reachable. Claude Code on the same machine can talk to a local n8n; hosted Claude cannot reach localhost. If n8n is currently reporting localhost as its own address, fix that first: n8n HTTPS and webhook URL walks through N8N_WEBHOOK_URL, N8N_PROXY_HOPS and N8N_PROTOCOL together.

Queue mode with multiple webhook replicas

If you run n8n in queue mode with more than one webhook replica, route all /mcp* requests to a single dedicated replica. Otherwise, per the docs, “your SSE and streamable HTTP connections will frequently break or fail to reliably deliver events.” Long-lived connections and round-robin do not mix.

What Claude can do once it is connected

Worth reading before you approve the consent screen, because “connect n8n to Claude” is a bigger grant than it sounds. The tools cover:

execute_workflow defaults to production mode and runs the published version. It also takes a manual mode to run the current unpublished draft, which is the one you want while iterating.

Two limits to hold in mind: access is not scoped per client, so Claude and ChatGPT both see everything you exposed and you cannot split them; and execute_workflow runs real workflows against real credentials. If a workflow sends email or moves money, an assistant can now trigger it. Expose deliberately.

The scoping limit is n8n’s, not MCP’s, and it is one of the places the MCP-native n8n alternatives genuinely behave differently: Activepieces runs one built-in MCP server per instance too, but its tool categories (discovery, flow building, tables and so on) are switched on and off per project, so what a client can reach is decided per project rather than per instance.

Where hosting comes into it, honestly

The only part of this that is a hosting problem is the public URL. Instance-level MCP needs your n8n reachable over HTTPS at a stable address before a cloud client can talk to it at all, and on a DIY VPS that is a certificate, a proxy config with the buffering settings above, and a DNS record you maintain.

On InstaPods, n8n is $7/mo flat on the Build plan (2 vCPU, 2 GB RAM, 25 GB SSD) with HTTPS and the public webhook URL configured at deploy, so the reachability half is done. The proxy in front of your pod is ours and already passes long-lived connections.

On versions: we pin what we bake rather than tracking latest, so what you get depends on when we last rebuilt. As of 2 September 2026 that pin is 2.37.7, which is npm’s current release, so a fresh pod today sits above the 2.33.0 line and gets the Connect a client dialog. That will drift again as n8n ships - it releases several times a week - so check your own n8n --version rather than trusting this sentence. If it reads below 2.33.0, you want the manual config above. Updating is one click with an automatic snapshot and rollback.

And to head off a genuine confusion: InstaPods’ own MCP connector is not this. We ship a connector at https://app.instapods.com/api/mcp that manages pods - create, deploy, set environment variables, read logs, change plan. It knows nothing about your workflows. Connecting it does not connect n8n. You would connect both, for different reasons: ours to run the server, n8n’s to reach what runs on it.