MCP n8n: create and update workflows with Claude, 2026 guide

With the MCP server built into n8n, a compatible client such as Claude Desktop or Claude Code can create or update workflows within its granted permissions. It can also run workflows made available in MCP. Review configurations and results before publishing.

Choose your MCP n8n setup in 30 seconds

The term “mcp n8n” covers several modes. The right choice depends on one question: who is the client, and where is the MCP server located?

This table compares the connection modes. The sections below explain their settings, permissions, and limits.

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.

Two pieces of context before choosing your mode. First, MCP is no longer an Anthropic in-house project: on 9 December 2025 the protocol was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI, with backing from Google, Microsoft, AWS, Cloudflare and Bloomberg. At that date MCP reported more than 97 million monthly SDK downloads and around 10,000 active servers, with first-class client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and VS Code. Second, the specification is a moving target: a revision was published on 28 July 2026. Sources: Anthropic announcement, Linux Foundation press release and the MCP specification.

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 three complementary ways:

1. The instance-level MCP server can search, create, update, validate, and test workflows within granted permissions. It can run workflows made available in MCP.
2. The MCP Server Trigger node exposes tools attached to one workflow. To offer another workflow as a tool, attach it through the Custom n8n Workflow Tool node.
3. n8n can also call external MCP tools from a workflow with MCP Client, or from an agent with MCP Client Tool.

Remember one simple rule: to create or update workflows from Claude, start with the native MCP server. To expose one specific workflow as a custom MCP server, use MCP Server Trigger.

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

A connection to the instance-level MCP server grants the operations allowed for that user and client. Building, editing, and testing tools are distinct from running workflows made available in MCP.

Enable MCP on your n8n instance

In n8n, open Settings > Instance-level MCP and select “Enable MCP access”; this requires the instance owner or admin role. n8n documents workflow creation and editing through MCP from version 2.13.0. Check which tools your instance provides.

Depending on the n8n version, the settings show connection details, workflow access, and connected clients.

• “Connection details” provides client setup and the server URL;
• “Access” shows workflows available in MCP;
• “Connected clients” lets you review or revoke OAuth clients. The detailed layout depends on the n8n version.

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

The instance-level MCP server accepts OAuth or a personal API key sent as a Bearer token. The OAuth client’s granted permissions and the user’s permissions determine what it can do.

With OAuth, review the requested permissions when connecting. n8n then lets you inspect and revoke individual OAuth clients under “Connected clients”.

A personal API key is tied to the account that generates it. Copy it when created, store it securely, and plan rotation: a new token revokes the old one for every client using it.

Limit client permissions and the workflows available in MCP. All clients connected as the same user can access the workflows that user has enabled; you cannot assign different workflows to each client.

Exposing a workflow to MCP: eligibility rules

A client can search previews of workflows its user can see even when “Available in MCP” is off. Full workflow data, edits, and execution require MCP to be enabled for that workflow and the relevant permissions.

To make a workflow available in MCP, publish it and use a supported trigger: Webhook, Schedule, Chat, or Form. Creation and tests can also use a draft; production execution runs the published version.

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

The “execute_workflow” tool starts the workflow and immediately returns an execution ID. Then check its status and, when needed, its data with “get_workflow_execution” or n8n’s Executions tab. Production mode runs the published version; manual mode tests the current version.

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

1. Five minutes is the default timeout for “test_workflow”; versions with a “timeout” parameter can raise it to 60 minutes. “execute_workflow” starts an execution without waiting for its result.
2. If several triggers are eligible, specify one when your version provides “triggerNodeName”. On older versions, check which trigger actually ran.
3. Multi-step forms and human interaction during MCP execution are unsupported. Prepare the input expected by the trigger, such as a JSON object for a Webhook.

Before publishing, test an expected case and an error case using test data. A draft is not a sandbox: a manual execution can affect connected services. Even “test_workflow”, which simulates data for some nodes, can run code or modify files. Check its effects before calling “publish_workflow”, which can publish the current draft.

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

n8n documents a straightforward path in Claude Desktop: Settings > Connectors > Add custom connector. Paste n8n’s “Server URL”, ending in /mcp-server/http, then authorize the OAuth connection. A Claude remote connector must be able to reach this server from Anthropic’s infrastructure.

For Claude Code, n8n documents “claude mcp add --transport http n8n <URL>” for OAuth, or the same command with “--header "Authorization: Bearer <TOKEN>"” for an API key. Use the instance MCP URL, not the editor URL.

Choose the permissions needed, check accessible workflows, and verify each tool’s response before allowing a sensitive action.

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

This mode exposes a set of tools defined within one workflow. Use it when you need to choose precisely which tools this endpoint offers.

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.

The local configuration example below bridges to stdio. Compatible remote connectors can also use a reachable HTTP URL directly.

One timing point to factor into your choices right away: revision 2026-07-28 of the MCP specification has officially deprecated the legacy HTTP+SSE transport, with a stated one-year offramp. Streamable HTTP becomes the default path. In practice, if you are standing up a new MCP server in n8n today, favour streamable HTTP and treat SSE as a compatibility mode rather than a target. Source: release note for the 2026-07-28 specification.

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.

Publishing the workflow registers its production URL. Inspect production calls in the Executions tab, subject to your execution retention settings.

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.

For an endpoint reachable outside a trusted network, configure Bearer or Header authentication, protect the credentials, and limit the tools attached to the node. A hard-to-guess URL is not authentication.

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

The n8n documentation gives the local Claude Desktop setup below, using “npx” and “mcp-remote” to bridge this HTTP server to stdio. This example uses a Bearer token; match authentication to your node settings.

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>"

}

}

}

}

Enter the node URL and keep the token out of shared documents. In Claude Desktop, this local server configuration and a remote connector are separate connection methods.

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

When self-hosting, check MCP request routing and proxy settings before opening the production URL.

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.

Behind nginx, the node documentation recommends disabling “proxy buffering” on the MCP endpoint and checking other settings that can interrupt SSE or streamable HTTP.

These constraints concern the MCP Server Trigger node documented by n8n; do not automatically apply them to the instance-level MCP server.

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:

• an SSE endpoint in the documented interface;
• authentication suited to the external server;
• “Tools to Include” to choose which tools the agent sees.

This last point is your best governance lever.

With “All”, the agent sees everything.

With “Selected”, you create a whitelist.

“All Except” excludes a few tools. “Selected” explicitly limits the list; also check the remote account’s permissions and controls inside the workflow.

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,
• the called workflow validates fields and rules before any sensitive write;
• the agent or user checks the result and its effects.

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 drafts a reply. Claude calls a “draft_reply” tool; n8n retrieves context and creates a draft. If human approval is required, handle it in a separate process before sending: the MCP execution itself does not support a multi-step human wait.

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.

Enable “Available in MCP” only for needed workflows and review user permissions. “search_workflows” can still return previews of other workflows a user is allowed to view.

With OAuth, review each client’s permissions and revoke access that is no longer needed. A personal token works differently: rotating it affects every client using it.

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.

Describe expected workflow inputs and outputs. A description guides the client; it does not replace data validation inside n8n.

Add n8n-side validation for sensitive actions. A control node, field checks, rule tests. MCP provides access. Validation builds trust.

For the instance server, distinguish “execute_workflow”, which returns an ID, from “test_workflow”, whose default timeout is five minutes and can be adjusted on supported versions. Multi-step human interactions remain outside the execution flow described here.

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.

For MCP Server Trigger in queue mode with multiple webhook replicas, n8n documents routing all /mcp* requests to one dedicated replica.

The MCP specification dated 28 July 2026 describes a sessionless protocol and routing headers “Mcp-Method” and “Mcp-Name”. This does not establish that the n8n node on your instance already uses that behavior: follow its documentation and test your actual routing.

Behind nginx, check the MCP Server Trigger endpoint proxy for both SSE and streamable HTTP. n8n recommends 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

• Missing workflow: check user permissions and “Available in MCP”. Search can return a preview without execution access. Review a draft before publishing it.
• 401 or 403 error: check the URL, authentication and permissions. Rotating a token requires updating every client that uses it.
• MCP Server Trigger connection interrupted: check the proxy and its response buffering settings.
• MCP Server Trigger with multiple instances: check /mcp* routing to a dedicated instance as documented by n8n.
• Timeout: identify the tool called. “execute_workflow” returns an ID to follow; “test_workflow” waits for a result with a version-dependent configurable timeout. Check execution status before retrying to avoid duplicates.

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.