On this page
MCP confuses people in n8n because n8n can sit on either side of the protocol, and the two sides do opposite things. Get them straight and the architecture becomes obvious: as an MCP server, n8n exposes your workflows as tools for an external AI to call; as an MCP client, an AI agent inside n8n calls tools that live on someone else’s server. This post draws the line clearly, with a decision table you can actually use.
New to connecting the two worlds? The n8n MCP server setup guide covers wiring Claude to n8n; this post is about the architecture underneath.
The one distinction that clears everything up
In MCP, a server exposes tools and a client consumes them. That is the whole protocol in a sentence. Everything else is detail. So the only question that matters for n8n is: in this design, is n8n offering capabilities, or using them?
- Offering capabilities to an AI, n8n is the server.
- Using capabilities from elsewhere, n8n is the client.
Hold onto that and the two n8n features below stop blurring together.
n8n as an MCP server
Here n8n exposes selected workflows as tools that an external AI client, Claude Desktop, Claude Code, or any MCP-capable assistant, can discover and call. You build a workflow behind an MCP Server Trigger, and from the AI’s point of view your automation is just another tool it can invoke.
What this is good for:
- Letting an assistant trigger real business actions: “create the onboarding tasks for this new client,” “kick off the weekly report,” “enrich this company.”
- Turning automations you already trust into a safe, curated toolbox for an AI, you decide exactly which workflows are exposed.
- Giving an external agent capabilities without handing it raw access to your systems; it only sees the tools you publish.
The mindset: you are publishing an API for an AI, expressed as workflows. Curate it. Expose the handful of workflows you want callable, not everything.
n8n as an MCP client
Here the direction reverses. An AI Agent node inside n8n uses the MCP client tool to call tools hosted on external MCP servers. Your workflow is the consumer; the capability lives somewhere else.
What this is good for:
- Giving an n8n agent access to tools that already exist as MCP servers, internal company tools, a vendor’s official MCP server, or a specialized service.
- Composing capabilities you do not want to rebuild in n8n: if a robust MCP server already does the job, your agent just calls it.
- Keeping your workflow logic in n8n while borrowing skills from the wider MCP ecosystem.
The mindset: your n8n agent is the brain, and external MCP servers are hands it can borrow.
Decision table
| You want to… | n8n’s role | Feature to reach for |
|---|---|---|
| Let Claude trigger your automations as tools | Server | MCP Server Trigger |
| Expose a curated toolbox to an external AI | Server | MCP Server Trigger |
| Let your n8n agent use an external tool | Client | MCP Client tool (in an AI Agent) |
| Compose third-party or internal MCP tools into a workflow | Client | MCP Client tool |
| Have an assistant build workflows in your instance | Neither, use the API | See the setup guide |
That last row matters: connecting Claude so it can build workflows for you (via the n8n API and a server like n8n-MCP) is a different thing from either MCP role above. It is worth not conflating “AI that builds n8n workflows” with “n8n speaking MCP at runtime.”
Doing both
The two features are independent, so a real system often uses both at once. One workflow consumes external tools as a client to get its job done; another exposes its own capabilities as a server so an assistant can trigger it. There is no conflict, they just share a protocol name. If you find yourself asking “server or client,” the honest answer is frequently “both, in different workflows.”
Where to go next
If your goal is to have Claude design and build workflows for you, read the n8n MCP and Claude Code guide and the setup walkthrough. If your goal is exposing n8n’s own workflows as tools, MCP servers in n8n goes deeper on the server side.
Key takeaways
Server exposes tools, client consumes them, that single rule tells you which n8n feature you need. Use the MCP Server Trigger when you want an external AI to call your automations; use the MCP Client tool when you want your n8n agent to call tools hosted elsewhere. Mature setups do both, and neither is the same as connecting Claude to build workflows through the API.
Want help designing the right MCP architecture? Let’s talk about your automation roadmap.
Frequently asked questions
What is the difference between an MCP server and an MCP client in n8n?
An MCP server exposes tools for something else to use; an MCP client consumes tools from a server. In n8n, the MCP Server Trigger turns your workflows into callable tools for an external AI, while the MCP Client tool lets an AI Agent node inside n8n call tools hosted elsewhere.
When should n8n be the MCP server?
When you want an external AI assistant, like Claude, to be able to trigger your automations as tools. You curate which workflows are exposed, and the AI calls them the way it would call any other tool.
When should n8n be the MCP client?
When you are building an AI agent inside n8n and want it to use capabilities that live on other MCP servers, for example a company's internal tools or a third-party service that ships an MCP server. Your n8n agent becomes the consumer.
Can n8n be both at once?
Yes, and often it should. A workflow can consume external tools as a client while another workflow exposes its own capabilities as a server. They are independent features that happen to share a protocol.
Related reading
Want this built for you?
We design and ship production n8n automation for agencies, and train your team to own it.
Book a build →