MCP n8n: connect Claude to your workflows and go live without surprises

You want Claude (Desktop or another client) to be able to trigger your n8n workflows as tools, with simple configuration, secure access, and reliable execution. MCP n8n is built for that.

Choose your MCP n8n setup in 30 seconds

The term “mcp n8n” actually covers 3 use cases. The right choice depends on one question: who is the client, and where is the MCP server located.

This table saves you 80% of early mistakes. Then, we break down each mode, including config, nodes, JSON, and validation points.

MCP n8n explained: server, client, tools, node, workflow

MCP (Model Context Protocol) is a standard protocol enabling clients (Claude, IDEs, agents, scripts) to call tools exposed by a server.

In practice, MCP n8n works like this:

A client connects to an MCP server. It retrieves the list of tools. It calls a tool with an input, often in JSON. The server executes and returns a response.

n8n integrates with MCP in two complementary ways:

1. n8n can act as an MCP server at the instance level, exposing selected workflows as if each workflow were a tool.
2. n8n can expose an MCP server from a workflow using the MCP Server Trigger node, executing only tool nodes—not a classic flow.
3. n8n can act as an MCP client to consume external tools in your workflows or in an agent, via MCP Client and MCP Client Tool.

Remember one simple rule: if your goal is “Claude uses my n8n workflows,” start with instance-level mode. If your goal is “I’m building a custom MCP server in n8n,” use MCP Server Trigger.

Mode 1: enable n8n’s built-in MCP server (instance-level access)

This is the most straightforward path for “mcp n8n.” You enable MCP access on the instance, then expose a few workflows. Clients connect, list available workflows, and trigger execution.

Enable MCP on your n8n instance

In n8n, go to Settings, then Instance-level MCP, and enable “Enable MCP access.” You must be an owner or admin.

Once enabled, n8n displays a page that centralizes:

• the list of exposed workflows,
• connected OAuth clients,
• a “Connection details” button with the server URL and configuration instructions.

If you’re self-hosted and want to disable the feature at the config level,n8n allows you to remove MCP endpoints via the environment variable N8N_DISABLED_MODULES=mcp.

OAuth2 or token: which auth to choose for your clients

n8n offers two client-side configuration options: OAuth2 or Access Token.

OAuth2 is often the best choice when you have multiple clients, or when you want to be able to revoke a specific client. n8n allows you to revoke a client’s OAuth access from the “Connected clients” tab.

The token is very quick for an initial test. Note: when first generated, n8n prompts you to copy the token immediately. After that, it is hidden. There is a rotation mechanism that revokes the old token and forces all clients to update.

In both cases, think “minimal access”: only expose the necessary workflows, and maintain upstream validation logic.

Exposing a workflow to MCP: the eligibility rules

In instance-level mode, a workflow is not visible to any client until you explicitly enable it.

To be eligible, the workflow must be published and include a supported trigger: Webhook, Schedule, Chat, or Form.

This is an important design consideration: if you want a simple “tool,” a Webhook trigger is often the clearest, as you control the expected JSON input.

Helping Claude “understand” your inputs: the workflow description

When an MCP client selects a workflow to execute, it needs to understand the input format. n8n recommends adding details in the workflow description, especially if you’re using a Webhook trigger.

A good description saves a lot of time. It should remain simple and effective.

Example of useful content in the workflow documentation:

• What the workflow does in one sentence.
• The expected JSON fields (with examples).
• Possible values if you have options.
• The output format.

This creates a readable “contract” for both clients and an agent.

Execution: what really happens when a client runs a workflow

When a client triggers a workflow via MCP, execution proceeds as usual in n8n. You can track it in the Executions list. Once execution completes, the client retrieves the result.

There are three constraints to be aware of from the start, as they affect how you design your MCP workflows:

1. n8n enforces a 5-minute timeout for executions triggered by MCP clients, even if you’ve configured something else in the workflow.
2. If a workflow contains multiple supported triggers, a client may only use one, often the first.
3. Multi-step human interactions are not supported, and binary input is not supported. MCP is limited to text, so primarily JSON.

In short: for MCP n8n, prioritize fast, deterministic, and "fully automatable" workflows.

Connect Claude Desktop to your n8n MCP server (instance-level)

n8n documents a simple path in Claude Desktop: Settings, then Connectors, then “Add custom connector”, then enter the n8n server URL, then authorize.

If you use Claude Code via command line, n8n also provides an example with adding an MCP server over HTTP transport and an Authorization Bearer header with your token.

The key point isn’t the tool. The key point is discipline: a client must have clear access, a controlled token, and well-documented workflows.

Mode 2: MCP Server Trigger in n8n (a workflow becomes an MCP server)

This mode is highly sought after because it offers enormous flexibility: you create a custom MCP server within a workflow, with your tools, your rules, your validation, and your nodes.

What the MCP Server Trigger node really does

The MCP Server Trigger node exposes a URL that MCP clients can call. Then, clients list the available tools and invoke a tool to perform a task.

Key difference: this node doesn’t behave like a classic trigger that sends data to the next node. It connects and executes only tool nodes.

Another useful point: the node supports SSE and streamable HTTP but does not support stdio.

This explains why some desktop clients need a gateway.

Test URL and Production URL: understanding the execution mode

The node displays a test URL and a production URL.

In test mode, n8n “listens” and displays the data in the editor when you run the workflow in test mode.

In production, the URL becomes stable when you publish the workflow. You won’t see the data in the editor, but you can view it in the Executions tab.

This is a solid design for daily work: test for fine-tuning inputs, production for deployment.

Auth and path: securing your MCP endpoint

The node allows you to enforce client-side authentication. You can choose Bearer auth or Header auth.

Use a token from the start. In production, avoid open MCP endpoints, even for a POC.

The “Path” parameter is also important. By default, n8n generates a random path to avoid collisions between nodes. You can set a clean path if you need stable URLs, for example for a template or shared documentation.

Claude Desktop configuration: JSON example with gateway

Since the MCP Server Trigger node isn’t stdio-based, n8n provides a Claude Desktop configuration that uses a gateway via npx and mcp-remote, with an Authorization Bearer header.

Here’s the structure as exposed in the docs, with your values:

{

"mcpServers": {

"n8n": {

"command": "npx",

"args": [

"mcp-remote",

"<MCP_URL>",

"--header",

"Authorization: Bearer ${AUTH_TOKEN}"

],

"env": {

"AUTH_TOKEN": "<MCP_BEARER_TOKEN>"

}

}

}

}

‍

This format is very practical for your internal clients: you give them a config template, a token, and a URL. Then, Claude can use your tools as actions.

Docker, queue mode, and reverse proxy: the two pitfalls that break MCP

On a self-hosted Docker setup, MCP issues with n8n rarely come from the node. They come from the network and execution mode.

First point: in queue mode, if you have multiple webhook replicas, SSE and streamable HTTP can break if requests don’t return to the same instance. The n8n docs recommend routing all /mcp* requests to a single dedicated instance, or having a separate replica set with a single webhook container for MCP.

Second point: behind a reverse proxy like nginx, you must configure the MCP endpoint for SSE, notably by disabling proxy buffering and adjusting options like gzip, chunked transfer encoding, and the Connection header. n8n provides an example nginx block for /mcp/.

If you remember one thing for Docker: MCP requires a persistent connection. So your network config must account for that.

Mode 3: n8n as an MCP client (MCP Client node) to consume external tools

Here, the keyword “mcp n8n” takes on the other meaning: you use n8n to call tools exposed by an external server, like a normal step in a workflow.

The MCP Client node is designed for this. It allows you to connect to an MCP endpoint, select a tool, and provide the parameters.

When this mode is the right choice

This mode is perfect if:

• you already have an external MCP server (Notion, internal, custom tool),
• you want to use it in existing workflows,
• you don’t want to expose your n8n instance to external clients.

You keep n8n as the orchestrator. You consume MCP as a building block.

MCP Client node configuration: transport, auth, JSON

The node requires:

• Server Transport and MCP Endpoint URL,
• Authentication (Bearer, header, OAuth2, or none),
• Tool (the list is automatically fetched from the server),
• Input Mode: Manual or JSON.

The “Input Mode” choice is more important than it seems.

Manual is fine if the tool has 2 or 3 simple parameters.

JSON is preferable if you have nested parameters. It’s also easier to version and review in a template.

The node also offers a timeout and a “Convert to Binary” option depending on the return type (images, audio).

In a production workflow, I recommend keeping explicit JSON. This makes validation, review, and debugging easier.

Mode 4: connect an n8n agent to external MCP tools (MCP Client Tool node)

This mode is very “agent-centric.” You want the agent to be able to select and call external tools without you coding the tool selection.

The MCP Client Tool node is designed precisely for this. It connects an agent to an MCP server and exposes its tools to the agent.

The minimal configuration

The node requires:

• an SSE Endpoint,
• an auth (Bearer, header, OAuth2, or none),
• a “Tools to Include” setting to decide which tools are visible to the agent.

This last point is your best governance lever.

In “All”, the agent sees everything.

In “Selected”, you create a whitelist.

In “All Except”, you block a few sensitive tools. In a client context, I prefer “Selected”. It reduces risk and improves agent quality. Fewer tools, better chosen, better documented.

The “agent” pattern that works in business

An agent without guardrails is often too free. MCP n8n becomes powerful when you structure the flow.

A simple pattern:

• the agent receives the request,
• it only sees useful tools,
• a validation node checks the JSON input and limits (e.g., no CRM write if field is empty),
• then and only then you trigger execution.

It’s this combination that turns MCP into a real work lever, not a gadget.

MCP n8n workflow ideas that quickly deliver value

We talk a lot about protocol. In reality, what matters is the result in your flows.

Here are examples that work well with MCP n8n, as they have a clear input, fast execution, and useful output.

An “ops” assistant that prepares a report. The client (Claude Desktop) calls a “resume” tool with a JSON containing notes, date, and participants. n8n transforms, formats, then pushes to Notion or Google Docs. The workflow does the heavy lifting, the client guides.

A sales agent that qualifies a lead. The client sends a JSON (source, company, size, need). The workflow enriches, applies a level rule, then returns a recommendation. If the score exceeds a threshold, a second workflow creates a task. Everything is traceable in the execution.

A support flow that suggests a reply. Claude uses a “draft_reply” tool. The workflow finds the right documentation, retrieves the ticket context, produces a response, then triggers human validation before sending.

A simple finance setup. A tool triggers an export, calculates KPIs, then returns a summary table. The client receives a structured output. The workflow keeps the history.

These examples share a common thread: you’re not trying to make MCP talk. You’re making n8n work. MCP becomes the standard access point to trigger the right workflow at the right time.

Security, access, validation: the true quality level for MCP n8n

With “mcp n8n”, security is rarely a concern at first. Then it becomes central as soon as multiple clients appear.

A few simple principles to avoid accidents.

Expose little. At the instance level, no workflow is exposed by default, and you explicitly choose which ones are. Keep this discipline.

Prefer OAuth2 when you have multiple clients. You can revoke one client without breaking the others.

If you use a token, organize rotation. n8n revokes the old token when you generate a new one. Prepare a process to update your clients.

Write workflow descriptions. It’s not cosmetic. It’s part of validation, as it guides the client on the correct inputs.

Add n8n-side validation when the action is sensitive. A control node, a field check, a rule test. MCP provides access. Validation builds trust.

Finally, respect MCP mode limits. No binary input, no human-in-the-loop, and a maximum of 5 minutes of execution at the instance level. This should influence your design.

Docker and configuration: what to check before opening to clients

If you're using Docker, you have two levels of configuration: n8n’s and your network’s.

On the n8n side, know that you can disable MCP entirely via N8N_DISABLED_MODULES=mcp if you need a kill switch.

On the network side, remember two rules.

SSE and streamable HTTP require a stable connection on the same instance. In queue mode with multiple webhook replicas, route /mcp* to a dedicated instance.

Behind nginx, configure the MCP endpoint for SSE. Otherwise, you’ll have connections dropping, incomplete responses, or tools not responding. The n8n docs notably recommend disabling proxy buffering for /mcp/.

This isn’t a minor detail. If you want a reliable service for your clients, this is the foundation.

When it breaks: quick diagnosis

Different causes of n8n bugs

The idea is to keep it simple: n8n MCP rarely fails “at random.” It almost always fails due to access issues, network mode, or a poorly adapted workflow.

Industrializing your AI workflows in production

Connecting Claude to n8n via MCP in a demo is one thing. Keeping it in production—reliability, security, controlled costs, scalability—is another. This is the core of Scroll’s expertise: developing AI-assisted applications and automations, designed for production from the start.

If you have a serious AI integration project, see our AI code development approach or integrating Claude in enterprise. For an AI project already launched but struggling, the Dr Lovable diagnosis is free and commitment-free.

For an overview of the protocol and essential MCP servers, see our complete MCP 2026 guide.

The next step: industrialize MCP n8n in your stack

When MCP n8n is properly set up, you get a very tangible effect: your clients can trigger reliable workflows, your agents can use controlled tools, and your instance keeps track of every execution.

This is also where projects are won or lost: choosing the mode (instance-level or MCP Server Trigger), workflow design, validation, Docker config, token governance, documentation, and client templates.

At Scroll, we help teams move from “it works on my desktop” to a clean, secure, and maintainable setup: MCP architecture, agent design, workflow overhaul, n8n industrialization, and production deployment with a validation level tailored to your context. If you want to save time and avoid common pitfalls, we can frame your “mcp n8n” use case together and deliver a configuration built to last.

‍