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 workflowsn8n as tools, with a simple setup, secure access, and reliable execution. MCP n8n is built for this.

Choose your MCP n8n setup in 30 seconds

The term “mcp n8n” actually covers three 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’ll walk through each mode, including the 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 it 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 via the MCP Server Trigger node, executing only tool nodes—not a standard 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 the available workflows, and trigger an execution.

Enable MCP on your n8n instance

In n8n, go to Settings, then Instance-level MCP, and enable “Enable MCP access.” You need to 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 setup instructions.

If you’re self-hosting 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 need the ability to revoke a specific client. n8n lets you revoke a client’s OAuth access from the “Connected clients” tab.

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

In both cases, follow the principle of least privilege: only expose the necessary workflows, and maintain upstream validation logic.

Exposing a workflow to MCP: eligibility rules

In instance-level mode, a workflow is invisible to all clients 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 choice, as you control the expected JSON input.

Helping Claude “understand” your inputs: 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 agents.

Execution: what actually 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 a different setting 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 JSON is preferred.

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

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

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

If you use Claude Code via the command line, n8n also provides an example with an MCP server added via 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 immense flexibility: you create a custom MCP server within a workflow, with your tools, rules, validation, and nodes.

What the MCP Server Trigger node actually does

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

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

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

This explains why some desktop clients require a gateway.

Test URL and Production URL: understanding execution mode

The node displays a test URL and a production URL.

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

In production, the URL becomes stable once 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 mode for fine-tuning inputs, production mode 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 prevent node collisions. 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 is not in stdio mode, 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 documentation, 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 provide them with 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 n8n issues rarely stem from the node itself. They usually 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 documentation 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 must configure the MCP endpoint for SSE, notably by disabling proxy buffering and adjusting options such as gzip, chunked transfer encoding, and the Connection header. n8n provides an example nginx block for /mcp/.

If you take away one thing for Docker: MCP requires a persistent connection. So your network configuration must account for that.

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

Here, the term “mcp n8n” takes on another meaning: you use n8n to call tools exposed by an external server, just like any other 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 to use this mode

This mode is ideal 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.

Configuring the MCP Client node: 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, review, and reuse in a template.

The node also offers a timeout setting 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: connecting 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 hardcoding the tool selection.

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

Minimum configuration

The node requires:

• a SSE endpoint,
• an auth method (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.

With “All”, the agent sees everything.

With “Selected”, you create a whitelist.

With “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 enterprise

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,
• it only sees useful tools,
• a validation node checks the JSON input and limits (e.g., no CRM write if a field is empty),
• then, and only then, you trigger execution.

This combination is what turns MCP into a real work lever—not a gadget.

MCP n8n workflow ideas that quickly deliver value

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

Here are examples that work well with MCP n8n because they have a clear input, fast execution, and a 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 the data, applies a tier 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 measure of quality in MCP n8n

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

A few simple principles to avoid mishaps.

Expose little. At the instance level, no workflow is exposed by default, and you explicitly choose which ones are. Maintain 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. This isn’t cosmetic. It’s part of validation, as it guides the client on the correct inputs.

Add n8n-side validation for sensitive actions. A control node, field checks, rule tests. 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 execution at the instance level. This should shape your design.

Docker and configuration: what to check before opening to clients

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

On the n8n side, note 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 to 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 face dropped connections, incomplete responses, or unresponsive tools. The n8n docs 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 things break: quick diagnosis

Different causes of n8n bugs

The idea is to keep it simple: MCP n8n 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 Scroll’s core 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 AI takeover diagnostic is free and commitment-free.

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

The next step: industrialising 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 templates for clients.

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 industrialisation, 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.

‍