MCP in n8n: Connecting Tools to a Workflow

MCP in n8n solves a narrow problem: giving an agent node tools that no ready node provides. Everything else is better done with ordinary nodes.

Why it belongs in n8n

n8n has a large integration catalogue, which raises the obvious question of why another way to reach external systems is needed. The difference is who decides.

A node is a decision you made at build time. It always runs, in the order you set.

An MCP tool is an option the agent selects from as it goes. It may call it or not, depending on what the previous step revealed.

Hence a simple test: if you know the sequence in advance, you do not need MCP. Use nodes: cheaper, more predictable, visible in the execution history.

The second motive is reuse. A server written for access to your internal system works in n8n, in a terminal agent and in your own code. One integration instead of three.

Connecting

The general shape: the agent node gets a connection to an MCP server, pulls its tool list, and calls those tools like any of its others.

What to account for on a self-hosted install:

A local server launches in the n8n environment, not your shell. Inside a container that means the program must exist in the image. The most common failure is a server that runs on your machine and not in n8n for exactly this reason.

A remote server must be reachable from the n8n container. Network constraints and addressing inside Docker are covered in n8n in Docker.

Secrets go in credentials or environment variables, not in a node field: workflow exports are visible to anyone with interface access.

Server configuration and connection troubleshooting are in MCP setup.

Where it fits

Access to an internal system. An accounting system, a bespoke admin panel, an internal API. No ready node will exist, and the server is written once - see wrapping your own API.

Data on demand. The agent processes a message and looks into the database when it needs to. Done as a node, that query would run every time, including when it is unnecessary.

Shared tooling. One server serves several workflows and several agents, and access logic changes in one place.

What not to do: reach for MCP where an HTTP node suffices. A call known in advance is cheaper made directly.

Limits

Context cost. Every tool description enters every agent request. Several servers noticeably raise per-step cost.

Non-determinism. The agent may skip the tool you needed or call the wrong one. If an action is mandatory, it belongs in a node after the agent rather than as a tool inside it.

Debugging. The n8n execution history shows what entered and left the agent node, but what happens inside the loop is less visible than a plain node chain. That is an argument for keeping the agentic part small.

Permissions. An MCP tool performs a real action. A server with write access will do what the agent decides - see MCP security.

What should stay as nodes: sending messages, writing to systems, known routing, error handling. That boundary is covered in agent recipes.

The protocol overview is in the MCP guide. The n8n overview is in the guide.