n8n and MCP: Using the Model Context Protocol in n8n
If you build automations in n8n and you have started wiring large language models into them, you have probably run into the Model Context Protocol. MCP is the connective tissue that lets an AI model reach tools and data living outside its own runtime. n8n supports it directly, and the support runs in both directions: an n8n workflow can act as an MCP client that calls external tools, and an n8n instance can act as an MCP server that exposes its own logic to other AI clients.
This breakdown stays close to what n8n actually ships. We cover what MCP is in plain terms, the four ways n8n speaks the protocol, how each MCP node behaves, and where MCP fits inside an AI Agent workflow. The goal is a working mental model you can act on, not a tour of the spec.
What Is MCP?
The Model Context Protocol is an open standard for connecting an AI model to external tools and data sources. Think of it as a common plug. Instead of every model integrating with every tool through a bespoke connector, a tool publishes itself once over MCP, and any model that speaks the protocol can use it. The model is the client; the system that exposes the tools is the server.
That client and server split matters for n8n, because n8n can sit on either side of it. In one workflow, n8n plays the client and reaches out to an external MCP server to borrow its tools. In another, n8n plays the server and offers up its own workflows as tools that an outside AI client can call. Holding both roles in your head is the key to understanding everything that follows.
Practitioner note: MCP does not replace your HTTP requests or API credentials. It standardizes how a model discovers and invokes capabilities. You still authenticate to the underlying service. What changes is that the model gets a consistent, self-describing list of what it is allowed to call, rather than a hand-wired integration per tool.
How n8n Supports MCP
n8n exposes MCP through four distinct capabilities. Two are core nodes you drop into a workflow, one is a tool sub-node you attach to an AI Agent, and one is an instance-level feature that turns the whole n8n install into an MCP server. They are easy to conflate, so it helps to see them laid out side by side before going deeper on each.
The split that trips people up is between the two server-side options. The MCP Server Trigger turns a single workflow into an MCP endpoint, while the instance-level MCP server is a property of the whole n8n install. We will return to that distinction in its own section.
The MCP Nodes Up Close
MCP Client node
The MCP Client node is a core node that connects an n8n workflow to an external MCP server and calls the tools that server exposes. You point it at the server you want to consume, and the node can invoke that server's tools as a step in your workflow. This is how a plain, deterministic n8n workflow borrows capabilities published over MCP without you hand-coding a connector for each one.
MCP Server Trigger node
The MCP Server Trigger node is the mirror image. It is a core trigger node that exposes the workflow it sits in as an MCP endpoint. Once the trigger is active, an external MCP client can invoke that workflow as if it were a tool. This is the node you reach for when you want one specific n8n automation to be callable by an outside AI system over the protocol.
MCP Client Tool
The MCP Client Tool is not a standalone workflow node. It is a tool sub-node you attach inside an AI Agent, alongside the agent's other tools. With it wired in, the agent can call tools served over MCP as part of its own reasoning loop. The practical difference from the MCP Client node is who decides when to call: the MCP Client node fires as a fixed workflow step, while the MCP Client Tool is one option the agent may choose during execution.
n8n as an MCP Server
Beyond the per-workflow MCP Server Trigger, n8n can act as an MCP server at the instance level. Here the n8n install itself becomes the server that external AI clients connect to. The n8n docs cover this under headings such as setting up and using the n8n MCP server and an MCP server tools reference, which is the signal that this is a first-class capability of the platform rather than a single node.
The distinction is worth pinning down because both options put n8n in the server role. The MCP Server Trigger publishes one workflow as one endpoint. The instance-level MCP server is a property of the running n8n install as a whole. If you are deciding between them, ask whether you want to expose a single automation or stand up n8n as a broader tool provider for your AI clients.
Practitioner note: MCP is a fast-moving specification, and the exact transport, authentication, and tool-exposure details for the n8n MCP server are documented and evolve. Before you build against it, confirm the current behavior in the n8n docs rather than assuming the shape from an older tutorial. The capability is stable; the surface details are not frozen.
MCP in AI Agent Workflows
n8n is AI-native and built on LangChain, which is what lets it support retrieval-augmented generation and multi-agent setups. The centerpiece is the AI Agent node. Unlike a plain LLM step that just generates text, the AI Agent node performs goal-oriented task completion: it selects and executes actions across multiple steps to reach an objective.
An agent is only as capable as the tools it can reach. n8n supplies a roster of tool sub-nodes for exactly this, including Calculator, Custom Code, Wikipedia, SerpApi, Wolfram Alpha, Call n8n Workflow, and the MCP Client Tool. The first six give the agent a fixed set of built-in abilities. The MCP Client Tool is the one that opens the door to everything else.
That is the role MCP plays inside an agent workflow. By attaching the MCP Client Tool, you let the agent reach any capability an external MCP server publishes, without adding a dedicated node for each one. If your agent needs to query a system you run behind an MCP server, the agent discovers and calls those tools through the protocol. This is also where n8n's broader connectivity story matters: the same workflows often route their model calls through gateways like OpenRouter, so an agent's model layer and its tool layer can both be swappable.
When you give an agent the MCP Client Tool, you are letting it call whatever the connected server exposes. Treat that server as part of your trust boundary. Vet which MCP servers an agent can reach and scope their tools to what the task needs.
Use the MCP Client node when a deterministic workflow step should call a remote tool. Use the MCP Client Tool when you want the agent to decide whether and when to call it. Picking the wrong one leads to either an agent that cannot reach a tool or a workflow that hands control to the model when it should not.
Frequently Asked Questions
Does n8n support the Model Context Protocol?
Yes. n8n supports MCP through four capabilities: the MCP Client node, the MCP Server Trigger node, the MCP Client Tool used inside AI Agents, and an instance-level MCP server that lets n8n itself act as an MCP server. These are documented in the n8n docs and the Build an AI workflow tutorial.
What is the difference between the MCP Client node and the MCP Client Tool?
The MCP Client node is a core node that connects a workflow to an external MCP server so the workflow can call that server's tools as a fixed step. The MCP Client Tool is a tool sub-node used inside an AI Agent, so the agent itself can choose to call tools served over MCP during its reasoning loop.
Can n8n act as an MCP server?
Yes, in two ways. The MCP Server Trigger node exposes a single workflow as an MCP endpoint that external clients can invoke. Separately, the n8n instance itself can be an MCP server, documented under setting up and using the n8n MCP server and the MCP server tools reference.
How does MCP fit into an AI Agent workflow?
The AI Agent node selects and executes actions across multiple steps and draws on tool sub-nodes such as Calculator, Custom Code, Wikipedia, SerpApi, Wolfram Alpha, Call n8n Workflow, and the MCP Client Tool. Adding the MCP Client Tool lets the agent reach any capability an external MCP server publishes, which is how MCP extends an agent's reach to outside systems.