MCP n8n: connect Claude to your workflows, and go into production without surprises

You want Claude (Desktop or other client) to be able to launch your n8n workflows like tools, with simple configuration, secure access, and reliable execution. MCP n8n is made for that.

Choose your MCP n8n setup in 30 seconds

The keyword “mcp n8n” actually covers 3 uses. The right choice depends on a single question: who is the client, and where is the MCP server located.

This chart saves you 80% of initial mistakes. Then, we roll out each mode, with the config, the nodes, the json, and the validation points.

MCP n8n in plain language: server, client, client, tools, node, workflow

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

In practice, MCP n8n reads 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 then returns a response.

n8n integrates with MCP in two complementary ways:

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

Remember a simple rule: if your objective 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: activate n8n's integrated MCP server (instance-level access)

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

Activate MCP on your n8n instance

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

Once activated, n8n displays a page that centralizes:

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

If you are self-hosted and want to deactivate the feature at the configuration 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 customers

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

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

The token is very fast for a first test. Attention: during the first generation, n8n asks you to copy the token right away. Then it is masked. There is a rotation mechanism that revokes the old token and requires all clients to be updated.

In both cases, think of “minimal access”: expose only useful workflows, and keep an upstream validation logic.

Exposing a workflow to MCP: eligibility rules

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

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

This is an important point for design: if you want a simple “tool”, a Webhook trigger is often the clearest, because you know the expected json input.

Helping Claude to “understand” your inputs: the workflow description

When an MCP client chooses a workflow to run, they need to understand the input format. n8n recommends adding details in the workflow description, especially if you're using a trigger webhook.

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

Example of useful content in workflow documentation:

• What workflow does in one sentence.
• Expected fields in json (examples included).
• Possible values if you have options.
• The output format.

In this way, you create a “contract” that can be read by customers and by an agent.

Execution: what really happens when a customer starts a workflow

When a customer initiates a workflow via MCP, the execution happens as usual in n8n. You can follow her in the Executions list. When the execution finishes, the client gets the result.

There are three constraints to be aware of from the start because they change the way you design your MCP workflows:

1. n8n imposes a 5-minute timeout for executions triggered by MCP clients, even if you have set up something else in the workflow.
2. If a workflow contains several supported triggers, a client can use only one, often the first one.
3. Multi-stage human interactions are not supported, and binary input is not supported. MCP is limited to text, so JSON instead.

In short: for MCP n8n, favor 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 URL of the n8n server, then authorize.

If you use Claude Code on the command line, n8n also provides an example with the addition of an MCP server in HTTP transport and an Authorization Bearer header with your token.

The important point is not the tool. The important point is discipline: a customer must have clear access, a controlled token, and well-described workflows.

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

This mode is very sought after because it gives enormous freedom: you create a “tailor-made” MCP server in a workflow, with your tools, your rules, your validation, and your nodes.

What does the MCP Server Trigger node really do

The MCP Server Trigger node exposes a URL that MCP clients can call. Then, customers list the available tools and call a tool to do a job.

Key difference: this node does not behave like a typical trigger that sends data to the next node. It only connects and runs tool nodes.

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

This explains why some desktop clients need a gateway.

URL testing and URL production: understanding the execution mode

The node shows a test URL and a production URL.

In testing, 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 don't see the data in the editor, but you can see it in the Executions tab.

It is a good design for daily work: test to adjust inputs, production for operation.

Auth and path: secure your MCP endpoint

The node allows you to force an auth on the client side. 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

As the MCP Server Trigger node is not in studio, n8n offers a Claude Desktop configuration that uses a gateway via npx and mcp-remote, with an Authorization Bearer header.

Here is the structure as set out in the doc, with your values:

{

“mcpServers”: {

“n8n”: {

“command”: “npx”,

“args”: [

“mcp-remote”,

<MCP_URL>“,

“--header”,

“Authorization: Bearer $ {AUTH_TOKEN}”

],

“env”: {

<MCP_BEARER_TOKEN>“AUTH_TOKEN”: "”

}

}

}

}

‍

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

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

On a self-hosted docker setup, MCP n8n problems rarely come from the node. They come from the network and from the mode of execution.

First point: in queue mode, if you have multiple webhook replicas, SSE and streamable HTTP can break if requests don't come back to the same instance. The n8n doc recommends 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 need to configure the MCP endpoint for SSE, including disabling proxy buffering, and adjusting options like gzip, chunked transfer encoding, and the Connection header. n8n provides an example of an nginx block for /mcp/.

If you only remember one thing for Docker: MCP requires a persistent connection. So your network configuration must be designed for that.

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

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

The MCP Client node is made for that. It allows you to connect to an MCP endpoint, choose a tool, and then provide the parameters.

When this mode is the right choice

This mode is perfect if:

• you already have an external MCP server (Notion, internal, homemade 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're consuming MCP like a brick.

MCP Client node configuration: transport, auth, json

The node asks for:

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

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

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

JSON is best 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 type of return (images, audio).

In a workflow, I recommend keeping the JSON explicit. This makes it easy to validate, review, and debug.

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

This mode is very “agent”. You want the agent to be able to choose and call external tools, without requiring you to code the tool selection.

The MCP Client Tool node is used for exactly that. It connects an agent to an MCP server and exposes its tools to the agent.

The minimum configuration

The node asks for:

• 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 tool.

In “All”, the agent sees everything.

By “Selected”, you create a whitelist.

In “All Except”, you block some sensitive tools. In a customer context, I prefer “Selected”. This reduces the risk and improves the quality of the agent. Fewer tools, better selected, better documented.

The “agent” pattern that works in business

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

A simple pattern:

• the agent receives the request,
• he only sees useful tools,
• a validation node checks the json input and the limits (ex: no CRM writing if field is empty),
• then only do you start the execution.

It is this combination that turns MCP into a real work tool, and not into a gimmick.

MCP n8n workflow ideas that quickly add value

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

Here are examples that lend themselves well to MCP n8n because they have clear input, fast execution, and useful output.

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

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

A support flow that offers an answer. Claude uses a “draft_reply” tool. The workflow searches for the right documentation, retrieves the ticket context, produces a response, and then triggers human validation before sending.

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

These examples have one thing in common: you're not trying to get MCP to talk. You make n8n work. MCP is becoming the standard access to trigger the right workflow at the right time.

Security, access, validation: the real level of quality on MCP n8n

On “mcp n8n”, safety is rarely a topic at the beginning. Then it becomes central as soon as several customers appear.

A few simple principles to avoid accidents.

Expose little. At instance-level, no workflows are exposed by default, and you explicitly choose which ones are exposed. Maintain that discipline.

Prefer OAuth2 when you have multiple clients. You can dismiss a customer without breaking the others.

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

Write workflow descriptions. It's not cosmetic. It is part of the validation, because it guides the customer on the right inputs.

Add validation on the n8n side when the action is sensitive. A control node, a field check, a rule test. MCP provides access. Validation gives confidence.

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

Docker and configuration: what to check before opening to customers

If you are using Docker, you have two levels of configuration. That of n8n and that of your network.

On the n8n side, know that you can completely disable MCP 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, set up the MCP endpoint for SSE. Otherwise you'll have broken connections, incomplete answers, or unresponsive tools. In particular, the n8n doc recommends disabling proxy buffering for /mcp/.

It is not a detail. If you want reliable service for your customers, that's the base.

When it crashes: quick diagnosis

The idea is to keep it simple: MCP n8n does not often fail “randomly”. It almost always fails because of access, network mode, or a poorly adapted workflow.

The next step: industrialize MCP n8n in your stack

When MCP n8n is well established, you get a very concrete effect: your customers can trigger reliable workflows, your agents can use controlled tools, and your instance keeps track of each execution.

This is also where projects are played out: choice of mode (instance-level or MCP Server Trigger), workflow design, validation, docker configuration, token governance, token governance, documentation and templates, documentation and templates for customers.

At Scroll, we precisely help teams to go from “it works on my desktop” to a clean, secure and maintainable setup: MCP architecture, agent design, flow redesign, n8n industrialization, and production implementation with a level of validation adapted to your context. If you want to save time and avoid classic pitfalls, we can frame your “mcp n8n” use case together and deliver a configuration that lasts over time.

‍