Two earlier posts on this site covered MCP one workflow at a time. The MCP Server Trigger exposes a single workflow as a tool, and the MCP Client Tool lets an n8n Agent call an external server. Both work fine, but they share the same limit: every new workflow you want an AI assistant to reach means wiring up another trigger, another credential, and another URL to hand out. n8n's instance-level MCP skips all of that. Connect once, with OAuth, and Claude gets a single door into your whole n8n instance instead of a separate one per workflow.
That's a bigger grant than a single-workflow tool, so this post covers both how to turn it on and how to keep it scoped to what you actually want an assistant touching.
Before you start
You'll need an n8n instance on a version that supports instance-level MCP. It's been available since 2.18.4 on self-hosted Community Edition (and on Cloud and Enterprise from around the same time), with OAuth added as the recommended connection method in 2.31.0. If you're on an older self-hosted version, update first. If you don't have an instance at all yet, a free n8n Cloud trial gets you one on a current release, instance-level MCP included. You'll also need instance owner or admin permissions (a regular member can't enable this) and Claude Desktop installed on your machine.
Disclosure: the n8n Cloud link above is an affiliate link — if you sign up through it, we may earn a commission at no extra cost to you. See our affiliate disclosure for details.
Step 1: Turn on instance-level MCP
Go to Settings > Instance-level MCP and select Enable MCP access. On a self-hosted instance you can do the same thing at deploy time instead, by setting the environment variable N8N_MCP_ACCESS_ENABLED=true (available from 2.20.0). That's the better option if you provision instances by config rather than clicking through the UI after every deploy.
Nothing is exposed yet at this point. Enabling the feature just makes the MCP server exist, it doesn't hand any workflow to it.
Step 2: Decide which workflows Claude can see
Open any workflow, click its main ... menu in the top-right corner, choose Settings, and flip on Available in MCP. That single workflow now shows up as something an MCP client can find and act on. You can do the same from the workflows list: open a workflow card's menu and pick Enable MCP access, or select several workflows at once and use the Enable workflows button in the table header to expose a whole project or folder at once.
Blip: There's also an "Auto-expose new workflows" toggle back in Settings, which quietly hands Claude every workflow you build from now on. Convenient. Also exactly the kind of setting worth remembering you turned on.
If you'd rather opt in per workflow than trust your future self to remember an auto-expose toggle, leave that setting off and come back to Step 2 each time you build something you want the assistant to reach.
Step 3: Generate the connection details
Back in Settings > Instance-level MCP, open Connection details and select Connect. This opens the Connect a client dialog. Confirm you're on the OAuth (recommended) tab. The alternative Access Token tab issues one long-lived bearer token instead, which works but can't be revoked per client the way an OAuth connection can, so a leaked token means rotating access for everyone who uses it, not just the one client that leaked it.
In the Your client dropdown, choose Claude Desktop. n8n shows you a Server URL value tailored to that client. This is the address Claude Desktop authenticates against, not something you construct by hand.
Step 4: Add n8n as a custom connector in Claude Desktop
In Claude Desktop, open Settings > Connectors and select Add custom connector. Give it a name ("n8n MCP" is fine) and paste the Server URL from Step 3 in as the Remote MCP Server URL. Save it, and Claude Desktop prompts you to authorize access to your n8n instance. Approve it, and the OAuth handshake completes without you ever touching a token or a config file by hand.
This is where instance-level MCP earns its keep over the single-workflow trigger from the earlier post. There, you were editing claude_desktop_config.json directly and copying a bearer token into an environment variable. Here, the whole connection is a name, a URL, and one authorization click.
Tip: if Claude Desktop connects but can't see any workflows, the fix is almost always Step 2, not the connection itself. Instance-level MCP access and per-workflow "Available in MCP" are two separate switches, and it's easy to flip the first without the second.
Step 5: Try it from a plain-English prompt
Open a new chat in Claude Desktop and ask for something that maps to a workflow you exposed in Step 2. "What workflows do I have that touch Stripe" is a reasonable first test, since it only needs read access. If the connection is set up right, Claude lists and inspects your workflows without you naming a specific tool.
From n8n 2.13.0 onward, MCP clients can also build and edit workflows, not just run existing ones, so a prompt like "create a workflow that watches a folder and archives new files" can result in Claude actually assembling nodes in your instance. Check what it produces before you activate it, the same way you'd review a pull request from a new teammate rather than merging it on trust.
Step 6: Review and scope what you granted
Each client that connects only gets the permissions it asked for and you approved during that OAuth handshake. Reading workflows without being able to create or run them is a valid, narrower grant than full read, build, and execute access, and it's worth choosing deliberately rather than accepting whatever the default happens to be.
To see what's actually connected, go back to Settings > Instance-level MCP, open Connected clients, and select View all. You get a table of every OAuth client, its access level, and when it connected, plus a revoke action for anything that shouldn't have access anymore. Get in the habit of checking this table the way you'd check any other service with standing access to your systems, not just once at setup, the same instinct worth applying to auditing an instance for leaked API tokens: a one-time check is worth less than a habit.
If you're running self-hosted behind a dedicated hostname (say, n8n-mcp.example.com in front of the same instance, rather than your normal editor URL), set N8N_MCP_BASE_URL to that address (available from 2.31.0). n8n advertises that URL during OAuth instead of the instance's default base URL, so clients authenticate against the address you actually intend them to hit.
Before you hand over the keys
Instance-level MCP is the right tool when you want an assistant working across your automations generally: "find the workflow that does X" or "build me something new," rather than being scoped to one job. That's also exactly why it deserves more caution than the single-workflow MCP Server Trigger from the earlier post. A client with build and edit access here can, in principle, touch anything you exposed to it, not just answer questions about it, and a workflow it builds for you is one you're choosing to trust before you activate.
Start narrow. Expose the handful of workflows you actually want an assistant reasoning about, leave "Auto-expose new workflows" off until you trust the habit of reviewing what gets shared, and check the Connected clients table every so often. Once that scope feels right, instance-level MCP is the version of "ask n8n to do something in plain English" that scales past a single workflow, which is the whole point of connecting it this way in the first place.
Top comments (0)