Connecting n8n to MCP Servers

n8n mcp integration lets you turn n8n workflows into tools an AI agent can call, and lets an n8n workflow call out to any MCP server as a client. If you already run n8n for automation and you're now building agents with Claude, ChatGPT, or a custom LLM app, MCP is the missing wire between the two worlds. This guide walks through both directions: consuming MCP servers from inside n8n, and exposing n8n itself as an MCP server.

Model Context Protocol (MCP) is an open standard for connecting AI models to tools, data sources, and other services through a single, predictable interface. Instead of writing a custom integration for every tool an agent needs, you point it at an MCP server and it discovers what's available. n8n added native MCP support with two dedicated nodes, so you don't need custom code to bridge the two.

What MCP actually solves for n8n users

Before MCP, if you wanted an LLM to trigger an n8n workflow, you had two options: build a webhook and hand-roll the tool schema for your agent framework, or use a vendor-specific plugin that only worked with one AI provider. Every agent framework (LangChain, the OpenAI Assistants API, custom code) needed its own glue.

MCP standardizes this. A server exposes a list of "tools" (each with a name, description, and JSON schema for its inputs), and any MCP-compatible client, Claude Desktop, Claude Code, Cursor, a custom agent, can call them the same way. n8n ships with:

• MCP Client Tool node: use this inside an AI Agent workflow so your agent can call tools from any external MCP server.
• MCP Server Trigger node: turns an n8n workflow into an MCP server, exposing it (and any tools you attach) to external MCP clients.

That means an n8n workflow can be both a consumer of other people's MCP servers and a provider of its own tools to Claude Desktop or any other MCP client. This is the core of the n8n mcp integration: two nodes, two directions, one protocol.

Part 1: Using the MCP Client Tool node (n8n as an MCP client)

This is the direction most people start with: you have an AI Agent node in n8n and you want it to use tools from an external MCP server (for example, a hosted Notion MCP server, a GitHub MCP server, or a self-hosted server exposing your internal APIs).

Step 1: Build the base agent workflow

Start with a standard n8n AI Agent setup:

1. Add a Chat Trigger node (or any trigger you prefer) as the workflow entry point.
2. Add an AI Agent node and connect it to a chat model (OpenAI, Anthropic, or your provider of choice) via the model sub-node.
3. Give the agent a system prompt describing what it should do and which tools it has access to.

Step 2: Attach the MCP Client Tool node

1. On the AI Agent node, click the tools connector (the small "+" under the agent) and search for MCP Client Tool.
2. Configure the connection type:

- SSE (Server-Sent Events): for MCP servers running over HTTP with a persistent connection. - HTTP Streamable: for MCP servers using the newer streamable HTTP transport.

1. Set the Endpoint URL. For a hosted MCP server this looks like:

https://your-mcp-server.example.com/mcp

1. If the server requires authentication, add credentials. n8n supports:

- Bearer token - Header-based auth (custom header name and value) - No auth, for local/dev servers

1. Under Tools to Include, choose whether the agent sees all tools the server exposes, or only a filtered subset. For production agents, always filter to the tools you actually want; an unfiltered connection hands the LLM every capability the server has, which is both a cost and a security surface you don't need.

Step 3: Test the connection

Run the workflow manually and send a test message that should trigger a tool call. In the execution log, expand the MCP Client Tool node's output. You should see:

• The list of tools it discovered from the server (name, description, schema)
• The specific tool call the agent made
• The raw response returned to the agent

If the node returns an empty tool list, check three things in order: the endpoint URL is reachable from wherever n8n is hosted (not just your laptop), the auth header matches exactly what the server expects, and the transport type (SSE vs HTTP Streamable) matches what the server actually speaks. A mismatched transport is the most common cause of a silent, empty tool list.

A worked example: connecting to a GitHub MCP server

Say you want your n8n agent to open GitHub issues on command.

1. Run or point to a GitHub MCP server (several hosted and self-hosted implementations exist; check current options since these change).
2. In the MCP Client Tool node, set the endpoint to that server's URL and add a bearer token credential using a GitHub personal access token with the right scopes.
3. Restrict Tools to Include to just create_issue and list_issues so the agent can't accidentally use write access it doesn't need (like closing or deleting things).
4. In the agent's system prompt, add a line like: "When the user asks you to file a bug, use the create_issue tool. Always confirm the repository name before calling it."

Now a Slack message like "file a bug: the export button is broken on mobile" can flow into n8n, hit the agent, and the agent calls the MCP tool to open the issue, no custom GitHub node, no webhook you have to maintain.

Part 2: Using the MCP Server Trigger node (n8n as an MCP server)

The reverse direction is just as useful: expose n8n workflows as MCP tools so Claude Desktop, Claude Code, or any other MCP client can call them directly.

Step 1: Create the trigger workflow

1. Start a new workflow and add an MCP Server Trigger node as the entry point.
2. n8n generates an MCP endpoint URL for this workflow (visible in the node's settings panel). This is the URL external MCP clients will connect to.
3. Set authentication on the trigger. For anything beyond local testing, require a bearer token or header credential, this endpoint is effectively a remote-code-execution surface if left open.

Step 2: Define the tool(s) the workflow exposes

Each MCP Server Trigger workflow can expose one or more callable tools. Attach nodes downstream of the trigger the same way you'd build any n8n workflow: HTTP Request nodes, database queries, other API calls. The trigger node's parameters let you define:

• Tool name: what the MCP client will call it.
• Description: this is what the LLM reads to decide when to use the tool, write it the way you'd write a docstring for another engineer's benefit, since a vague description leads to the agent misusing or ignoring the tool.
• Input schema: the parameters the tool accepts, defined as JSON schema fields (name, type, required/optional, description).

For example, a workflow that looks up order status in your internal system might define:

tool name: get_order_status
description: Look up the current status of a customer order by order ID. Returns status, tracking number if shipped, and estimated delivery date.
parameters:
  order_id (string, required): the order ID, format ORD-XXXXXX

Step 3: Wire the logic

Downstream of the trigger, add whatever nodes actually fetch the data: an HTTP Request node hitting your internal order API, a Postgres node querying your orders table, or a chain of nodes doing something more complex. End the workflow with a Respond to Webhook-style final node (or let the MCP Server Trigger's own response handling capture the last node's output) so the MCP client gets a clean JSON result back.

Step 4: Point an MCP client at it

In Claude Desktop or Claude Code, add the workflow's MCP endpoint URL to your MCP server configuration, matching whatever auth you set on the trigger. Once connected, the client will list get_order_status (or whatever tools you defined) as available, and the LLM can call it in conversation, no separate app, no custom plugin.

Running MCP servers alongside self-hosted n8n

If you're self-hosting n8n (Docker, a VPS, or Kubernetes), a few practical notes:

• Networking: the MCP Server Trigger's endpoint needs to be reachable by whatever client is calling it. If your n8n instance sits behind a reverse proxy (nginx, Caddy, Traefik), make sure the MCP path is proxied with support for the transport type you're using (SSE needs long-lived connections; don't let a proxy timeout kill it prematurely).
• Environment variables: nothing MCP-specific is required beyond what a normal n8n install needs, but if you're calling external MCP servers that need API keys, store those as n8n credentials rather than hardcoding them into HTTP Request nodes or node parameters.
• Scaling: if you expect many concurrent MCP tool calls, run n8n in queue mode with separate worker processes so a slow downstream API call in one tool doesn't block other workflow executions.
• Versioning: MCP is still evolving as a spec (transports and auth patterns have changed over time). Keep n8n updated and check release notes when the MCP nodes change behavior.

Debugging common issues

Agent doesn't call the tool at all. Check the tool's description first. LLMs decide whether to invoke a tool almost entirely based on the description and the user's phrasing. If the description is generic ("does order stuff"), rewrite it to be specific about when and why to use it.

Tool call succeeds but returns malformed data. The MCP protocol expects structured responses. If your downstream workflow returns raw HTML or an unstructured string, wrap the final node's output in a clean JSON object with named fields rather than a blob of text.

Connection refused or timeout from the MCP Client Tool node. Confirm the target server is actually running and that the URL includes the correct path (many MCP servers use /mcp or /sse as a path segment, not just the bare domain). If it's a local server and n8n runs in Docker, localhost inside the container is not the same as localhost on your host, use the host's Docker network address or a service name instead.

Auth errors that look like connection errors. Some MCP servers return a generic connection failure instead of a clear 401 when a token is missing or malformed. Double check the header name matches exactly (case matters for some servers) before assuming the server itself is down.

Putting it together: a two-way workflow

A realistic setup often uses both nodes in the same n8n instance, just in different workflows. One workflow exposes internal tools (order lookups, CRM updates, internal search) via MCP Server Trigger for Claude Desktop or Claude Code to use during support and ops work. A separate agent workflow uses MCP Client Tool to pull in external capabilities, like a hosted web search MCP server or a documentation MCP server, so the n8n agent itself can answer richer questions without you building a custom node for every external service.

This is the practical value of n8n mcp integration: you stop building bespoke integrations per AI tool and start building once, against a protocol that both n8n and your AI clients already speak.

FAQ

Does n8n need a paid plan to use MCP nodes? The MCP Client Tool and MCP Server Trigger nodes are part of n8n's core node set, available on self-hosted instances. Check current licensing terms for n8n Cloud plans, since feature availability by tier can change.

Can I use MCP Client Tool outside of an AI Agent node? It's designed to attach to an AI Agent node as a tool source. For calling an MCP server outside of an agent context, you'd typically use an HTTP Request node against the server's endpoint directly, though you lose the automatic tool-discovery and schema handling the dedicated node provides.

What's the difference between SSE and HTTP Streamable transport? Both are ways to carry MCP protocol messages over HTTP. SSE keeps a persistent server-sent-events stream open; HTTP Streamable is a newer transport pattern some servers use instead. Match whichever transport the specific MCP server you're connecting to actually implements, they are not interchangeable.

Is it safe to expose an n8n workflow as an MCP server publicly? Only with authentication enabled and careful scoping of what the workflow can do. Treat an MCP Server Trigger endpoint the same way you'd treat any authenticated API: require a token, restrict what downstream nodes can access (don't give it write access to production systems unless the tool explicitly needs it), and log calls so you can audit what the agent actually did.

Can one n8n workflow expose multiple MCP tools? Yes. A single MCP Server Trigger workflow can define multiple tools, each with its own name, description, and schema, routed to different downstream logic within the same workflow using switch or routing nodes.

How do I know which MCP servers are worth connecting to? Look for servers maintained by the vendor of the service you need (official GitHub, Slack, or database MCP servers tend to be more stable than community ones) and check that the tool list matches what you actually need before wiring it into a production agent.