Building an AI agent with n8n and MCP
MCP, in plain terms
MCP, short for Model Context Protocol, is a standard protocol that describes how an AI agent discovers tools, calls them, and receives their results. The idea is simple: instead of coding a specific integration between each agent and each service, you expose the tools behind a common interface that any MCP-compatible client knows how to read.
To place MCP correctly, you first need to understand what a tool is for an agent. If the notion of an AI agent and tools is not familiar to you, start with our definition of an AI agent, then with the basics guide building an AI agent with n8n, which covers the AI Agent node, tools, and memory. This guide assumes those foundations are in place and focuses solely on MCP.
Why is MCP useful? Three concrete reasons:
- Reuse: a single MCP server can serve several agents, several projects, even different clients (n8n, a desktop assistant, an IDE).
- Standardization: the agent does not need to know the implementation details of each tool, only the MCP contract.
- Decoupling: the tools can evolve on the server side without breaking the agent on the client side, as long as the contract holds.
MCP does not replace n8n's native tools. It is an additional path for giving or exposing tools, particularly relevant when the same tooling needs to be shared.
n8n's two roles with MCP
n8n can play two distinct roles with respect to MCP. Telling them apart clearly avoids the most common confusion.
n8n as a client: MCP Client Tool
The MCP Client Tool sub-node plugs into an AI Agent node like any other tool. It points to an external MCP server and makes that server's tools available to your agent. Your n8n agent thus becomes a consumer of tools defined elsewhere. Authentication is done via Bearer token, custom header, or OAuth2 depending on what the server expects.
n8n as a server: MCP Server Trigger
The MCP Server Trigger node does the opposite: it turns your n8n workflows into tools exposed through a URL. n8n then becomes an MCP server that other MCP-compatible agents or clients can call. The supported transports are SSE and streamable HTTP (no stdio). This is useful for publishing business capabilities (querying a database, triggering an action) as standardized tools.
| Role | Node | n8n is | Typical use |
|---|---|---|---|
| Client | MCP Client Tool (sub-node) | Consumer | Give external tools to your n8n agent |
| Server | MCP Server Trigger | Provider | Expose your workflows as tools to other agents |
Both can coexist: an n8n workflow can consume an external MCP server while also exposing its own tools to other clients.
Giving MCP tools to your n8n agent, step by step
Here is the procedure on the client side, that is, to plug an external MCP server into an existing n8n agent. It assumes you already have a working agent (Chat Model, at least one tool, optional memory).
- Start from a working n8n agent. Make sure your AI Agent node already responds correctly on simple cases, with its Chat Model configured. That is the baseline described in the basics guide.
- Add the MCP Client Tool sub-node. Connect it to the tool input of your AI Agent node, just as you would for any other tool.
- Provide the MCP server URL and authentication. Enter the external server's endpoint and choose the expected auth mode: Bearer token, custom header, or OAuth2.
- Select and limit the exposed tools. Give the agent only the tools it actually needs. Narrowing the scope reduces errors and the risk surface.
- Test on real cases. Run the agent on representative requests and check that it calls the right MCP tools with the right parameters.
- Put control points before consequential actions. For any tool that writes, deletes, or triggers spending, insert a human validation or an explicit condition before execution.
The agent's memory does not persist between sessions: if your use case requires recovering context from one run to the next, plan for external storage, independent of MCP.
Exposing your n8n workflows via MCP
On the server side, the principle is to publish one or several workflows as tools consumable by third-party agents. The MCP Server Trigger node serves as the entry point.
A few practical points:
- Transports: MCP Server Trigger exposes tools over SSE and streamable HTTP. There is no stdio transport on the n8n side, which means communication goes through a network URL reachable by the client.
- Tool definition: each exposed workflow becomes a tool with its input parameters. Take care with names and descriptions, because that is what the client agent reads to decide when to call the tool.
- Authentication: protect the exposed URL. An open MCP server without auth gives any client the ability to trigger your workflows.
Exposing workflows via MCP is a good way to share business capabilities across several agents without duplicating the logic. To place this building block within a broader automation approach, see our AI automation page.
The guardrails
Plugging tools into an agent, whether they come from MCP or not, increases its capacity to act and therefore its capacity to make mistakes with real consequences. A few robust guardrails:
- Minimal tool scope. Expose only the necessary tools, on the client side as well as the server side. Fewer available tools means fewer possible bad decisions.
- Control points before action. For any consequential action (writing, deleting, sending, spending), insert an explicit validation, human or conditional, before execution. The agent proposes, a control disposes.
- Systematic authentication. On the client side, use Bearer, header, or OAuth2 depending on the server. On the server side, never expose an MCP Server Trigger URL without authentication.
- Traceability. Keep executions and tool calls so you can audit what the agent did, and reconstruct a decision after the fact.
- Tests on real cases before going to production. An agent that responds well on toy examples can drift on real cases. Validate on representative data.
These guardrails are not specific to MCP, but MCP makes them all the more important since it makes it easy to add numerous and heterogeneous tools. In sensitive contexts (for example a workflow operated for an operator under a regulatory license), the routine can be autonomous on the agent side, but consequential actions remain confirmed by the operator.