n8n MCP Server: Instance Access, Trigger and Client Tool

"n8n MCP server" can mean three different features, and picking the right one is most of the work. n8n supports MCP in both directions: AI tools can reach into n8n, and n8n workflows can call outside MCP servers.

Here's the short version, based on n8n's own docs as of October 2026:

• Instance-level MCP access is n8n's built-in MCP server. Turn it on once, and clients like Claude, ChatGPT, Cursor or Claude Code can search, run, build and edit the workflows you allow.
• The MCP Server Trigger node turns one workflow into its own custom MCP server, exposing only the tools you attach to it.
• The MCP Client Tool node goes the other way. It lets an n8n AI Agent call tools from any external MCP server.

Below: what each one does, how to set it up, the limits n8n documents, and which one fits your situation.

What "n8n MCP server" actually means

MCP (Model Context Protocol) is the open standard that lets AI assistants call outside tools. If you're new to it, read our plain-English MCP explainer first, or skim the official Model Context Protocol site.

MCP has two roles. A server exposes tools. A client (Claude Desktop, Claude Code, Codex, a custom agent) connects to the server and calls those tools for you. n8n can play both roles, which is why searches for "n8n mcp" turn up guides that seem to describe different products.

There are also community projects that use the same name. We'll cover those near the end.

Instance-level MCP access: let Claude or ChatGPT work in n8n

This is what most people mean by "the n8n MCP server." n8n's MCP server setup guide says the built-in server lets connected clients:

• Search for your workflows
• Interact with workflows marked as available in MCP
• Trigger and test exposed workflows
• Create and edit workflows and data tables

The building part is newer. n8n's docs say building and editing workflows over MCP is "available from n8n 2.13.0", so older self-hosted instances can only run existing workflows.

The full MCP server tools reference groups the tools into workflow management (search_workflows, execute_workflow, test_workflow, publish_workflow), execution management, instance context, a workflow builder (search_nodes, validate_workflow, create_workflow_from_code, update_workflow), data tables, and agent management. n8n labels its agents feature as Preview and advises against relying on it in production.

How to turn it on

On both Cloud and self-hosted instances, the steps are the same:

1. Go to Settings > Instance-level MCP.
2. Select Enable MCP access. This needs instance owner or admin permissions.
3. Open Connect a client, pick OAuth (n8n's recommended option) or an API key, and copy the Server URL. It ends in /mcp-server/http.
4. Enable MCP access for each workflow you want clients to use. You can do this from the workflow's settings (Available in MCP), from the workflows list, or in bulk for a project or folder.

The Connect a client dialog with per-client setup steps arrived in n8n 2.33.0. On older versions you configure clients by hand.

If you self-host and don't want the feature at all, n8n documents N8N_DISABLED_MODULES=mcp to remove the endpoints and hide the UI.

Connect Claude Code to the n8n MCP server

This is the OAuth command from n8n's client connection examples:

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

Then run /mcp in Claude Code and select n8n to finish signing in. Replace <your-n8n-domain> with your instance's domain. n8n warns that the Server URL "isn't the address of your n8n editor," so copy it from the Connect dialog rather than your browser's address bar.

The same page has setup steps for Claude Desktop, Codex, Gemini CLI, Cursor, VS Code, Windsurf, Lovable and Google ADK agents. For more on how Claude Code stores MCP servers, see our Claude Code MCP configuration guide.

Limits to know before you switch it on

n8n's docs are clear about a few things guides often skip:

• Access isn't per client. Every client you connect can see every workflow you've enabled for MCP. You can't give Claude one set and Cursor another. Visibility is still per user, so people only see enabled workflows they already have access to.
• Search sees more than you enabled. search_workflows can preview every workflow the current user can view. Full data, running and editing still need MCP access turned on for that workflow.
• execute_workflow runs the published version by default. It also has a manual mode for the current, unpublished version.
• Not every trigger works. Production runs support Webhook, Chat Trigger, Form Trigger and Schedule Trigger nodes. Multi-step forms and human-in-the-loop steps aren't supported.
• Cloud AI clients need a reachable instance. The troubleshooting section says to make sure your instance is publicly accessible if you use cloud-based MCP clients.

If you connect a coding agent to build workflows, n8n also publishes n8n Skills, a set of Markdown skills that teach the agent n8n's conventions for expressions, error handling and more. Install steps live in that repo's README.

MCP Server Trigger node: one workflow as a custom MCP server

The instance-level server exposes workflows. The MCP Server Trigger node does something narrower: it makes a single workflow act as its own MCP server.

It works differently from n8n's other triggers. Instead of passing output to the next node, it "only connects to and executes tool nodes." You attach tool nodes to it, and MCP clients can list and call them. To expose a whole sub-workflow as one tool, attach it with the Custom n8n Workflow Tool node.

What the docs say about setup:

• Two URLs. There's a test URL for building and a production URL that n8n registers when you publish the workflow.
• Transports. It supports Server-Sent Events (SSE) and streamable HTTP. It doesn't support stdio.
• Authentication. None, Bearer auth, or Header auth.
• Path. It defaults to a random path. You can set your own if you need stable endpoint URLs.

For Claude Desktop, n8n's example config runs a gateway (mcp-remote) that bridges the remote URL to a local process. n8n's instance-level examples use a different gateway (supergateway) for Claude Desktop with an API key. Both are official n8n examples, so follow the page for the feature you're using.

Two limits are worth knowing. If you run n8n in queue mode with multiple webhook replicas, you need to send all /mcp* traffic to one dedicated replica, or connections "will frequently break." And claude.ai custom connectors ask you to sign in to n8n even when authentication is set to None. n8n says claude.ai is the only client known to do this.

When to pick this over instance access: when you want to hand an AI client a small, deliberate toolset, such as "look up an order" and "create a support ticket," and nothing else. n8n's own comparison says the trigger node is useful "when you want to craft a specific MCP server behavior within one workflow."

MCP Client Tool: use external MCP servers in n8n AI Agents

Now the other direction. The MCP Client Tool node connects an n8n AI Agent to tools exposed by an outside MCP server.

You give it the server's SSE endpoint and credentials, then choose which tools the agent can use: all of them, a selected list, or all except a list. It supports Bearer, header, multiple-header and OAuth2 authentication.

Before you add one by hand, check n8n's built-in MCP servers registry. From an AI Agent's tools panel, you can search for a service like Notion or Linear, sign in, and n8n creates the credential for you. n8n says the registry list "changes often," so browse it in the node panel. Use the MCP Client Tool for servers that aren't listed yet.

If you're looking for servers worth connecting, our roundup of the best MCP servers is a good starting list.

MCP server vs a built-in n8n node as an agent tool

n8n's docs make a useful distinction here:

In short, a built-in node gives you tighter control. An MCP server gives the agent more freedom, at the cost of control and more context per call.

There's also a plain MCP Client node. It calls one MCP tool as a regular workflow step, without an agent. Use it when the step is always the same.

Community "n8n MCP" servers

Plenty of third-party projects use the n8n MCP name. The best known is czlonkowski/n8n-mcp, an MIT-licensed server maintained by an independent developer, not by n8n. Its README describes it as giving AI assistants structured access to n8n node documentation, properties, operations and workflow templates.

Its documentation and template tools work without an n8n instance. A separate set of management tools (creating, updating and deleting workflows, among others) only turns on when you supply N8N_API_URL and N8N_API_KEY. You can self-host it with npx or Docker, or use the maintainer's hosted version.

Its README carries a warning worth repeating: never edit production workflows directly with AI. Copy the workflow and test in a development environment first.

With n8n's own server now able to build and edit workflows, start there. Reach for a community server only when it offers something specific you need, and review its repo before you hand it an API key for your instance.

Which n8n MCP option should you use?

Key points:

• n8n works with MCP in both directions. Decide whether the AI is calling n8n or n8n is calling the AI's tools.
• Instance-level access is one connection for the whole instance, but you enable each workflow yourself, and every connected client sees the same set.
• The MCP Server Trigger node is for a hand-picked toolset inside one workflow.
• The MCP Client Tool brings outside MCP servers into n8n agents, with tool-level allow and exclude lists.

If you're still deciding whether n8n is the right automation platform at all, our n8n alternatives guide compares the main options.

n8n MCP is a strong fit when your work already lives in trigger-based workflows. If what you actually want is to run AI apps and workflows someone else already built, without wiring up servers, credentials and webhook replicas, Taku is an AI-native desktop workspace for exactly that: mirror a working setup, run it, and keep it. Taku is in Beta, and the Mac app is available now.

FAQ

Does n8n have an official MCP server?

Yes. n8n has a built-in, instance-level MCP server. You enable it under Settings > Instance-level MCP, and clients connect to a URL ending in /mcp-server/http. Separately, the MCP Server Trigger node lets one workflow act as its own MCP server.

What's the difference between n8n MCP and the MCP Server Trigger node?

Instance-level MCP gives you one connection per instance, central authentication, and access to every workflow you enable. The MCP Server Trigger node lives inside a single workflow and exposes only the tools attached to it.

Can Claude build n8n workflows through MCP?

Yes, on n8n 2.13.0 and later. The instance-level server includes workflow builder tools such as search_nodes, validate_workflow, create_workflow_from_code and update_workflow. n8n suggests coding agents like Claude Code over chat clients for this, since they're better at generating and validating code.

How do I use an MCP server inside an n8n workflow?

Add the MCP Client Tool node to an AI Agent, enter the server's endpoint and credentials, and choose which tools to include. If the server is in n8n's MCP registry, you can connect it from the agent's tools panel instead. For a single fixed tool call without an agent, use the MCP Client node.

Does the n8n MCP server work with self-hosted n8n?

Yes. The setup steps cover both Cloud and self-hosted instances. Self-hosted users can also manage MCP settings with environment variables, or remove the feature with N8N_DISABLED_MODULES=mcp. If you use a cloud-based AI client, your instance needs to be publicly reachable.

Can I limit which workflows each AI client sees?

Not per client. n8n's docs say every connected client sees all workflows you've enabled for MCP. You control the overall set by enabling or disabling MCP access per workflow, project or folder, and you can review or revoke individual OAuth clients under Connected clients.