MCP in n8n: connecting an AI Agent to external tools with the Model Context Protocol

Until now, giving an n8n AI Agent a tool meant building it yourself: an HTTP Request Tool pointed at a specific API, a Code Tool for custom logic, or a Workflow Tool to reuse an existing workflow — the trio covered in our custom tools for AI Agent guide. The Model Context Protocol (MCP) changes that in both directions: it lets an n8n agent consume tools already exposed by a third-party MCP server without recoding them, and it lets n8n itself become that server, publishing your workflows as tools that Claude Desktop, Cursor, or any other MCP client can call directly.

n8n ships two native nodes for these two use cases: MCP Client Tool (consume) and MCP Server Trigger (expose). This guide covers both, with their actual parameters and the pitfalls to avoid.

MCP in one minute

The Model Context Protocol standardizes how a language model discovers and calls external tools. Before MCP, every tool integration was coded case by case — a GitHub connector different from a Notion connector, different again from an internal one. An MCP server exposes a list of tools with standardized input/output schemas; any MCP client (an n8n agent, Claude Desktop, an IDE like Cursor) can then discover and call those tools without knowing the implementation details of each.

For an n8n AI Agent, that means something concrete: instead of building one HTTP Request Tool per endpoint of a third-party API that exposes twenty of them, you wire up a single MCP Client Tool pointed at that API's MCP server, and the agent discovers the available tools itself.

MCP Client Tool: consuming an external MCP server

The MCP Client Tool node plugs into the ai_tool connection of an AI Agent, exactly like a toolHttpRequest or toolCode. Its configuration comes down to three pieces:

The endpoint and transport

The node connects to an MCP server through an endpoint URL. The MCP protocol has evolved: the older SSE (Server-Sent Events) transport is now deprecated in favor of the newer HTTP Streamable transport. SSE is still accepted for compatibility with older servers, but any new integration should target HTTP Streamable when the target MCP server supports it.

Authentication

The MCP Client Tool supports several authentication methods toward the remote server:

• None — no authentication, for an internal or test MCP server;
• Bearer — a single token sent as a header;
• Header Auth or Multiple Headers — one or several name/value pairs, useful when the server requires, say, an API key and a client identifier;
• OAuth2 — for MCP servers that expose a full authorization flow.

These credentials are stored in a dedicated n8n credential, with the same isolation as any other node's credentials.

Tools to Include: scoping what the agent can see

This is the parameter that matters most for production reliability. An MCP server can expose dozens of tools; Tools to Include offers three modes:

• All — every tool on the server is visible to the agent;
• Selected — you explicitly check which tools are allowed;
• All Except — every tool except the ones you exclude.

The same principle that applies to a well-written HTTP Request Tool description applies here: the wider and more ambiguous the list of tools visible to the agent, the higher the risk of a wrong selection. For a support agent connected to a GitHub MCP server, for example, restricting the list to read-only tools (issue search, PR reading) prevents it from accidentally triggering a create or close action — the same caution recommended in our custom tools guide for write-capable HTTP calls.

MCP Server Trigger: exposing an n8n workflow as an MCP tool

In the other direction, the MCP Server Trigger node turns an n8n workflow into an MCP server that an external client can query. It works like any other n8n trigger, with two specifics:

• A test URL and a production URL — the same logic as a regular n8n webhook: the test URL is active while you build the workflow in the editor, the production URL activates once the workflow is published.
• A randomly generated URL path by default, to avoid collisions between multiple MCP Server Triggers on the same instance — though you can set it manually if you need a stable URL, for instance to document it in a shared team configuration.

Once the workflow is published, a compatible MCP client — Claude Desktop, Cursor, or a third-party agent — can point to that production URL to discover and call the tools the workflow exposes.

Securing an MCP Server Trigger

A published MCP Server Trigger is, by nature, a publicly exposed entry point — the same risk category as a regular n8n webhook. The same precautions detailed in our securing an n8n webhook guide apply here: enable authentication (a Bearer token at minimum) rather than leaving the endpoint open, never paste the production URL into an unencrypted channel or a public repository, and scope down what the workflow actually does behind the trigger — an MCP Server Trigger that writes to a database needs to validate its inputs with the same rigor as any public API, since any misconfigured (or malicious) MCP client can technically call it.

A concrete case: a support agent connected to a CRM via MCP, itself exposed over MCP

Take a full scenario to see both nodes together:

1. A lead qualification agent (like the one described in our qualifying inbound leads with AI guide) needs to check a contact's history in a CRM. Instead of building one HTTP Request Tool per CRM endpoint, an MCP Client Tool points at the MCP server that CRM exposes natively, with Tools to Include scoped to read-only tools (contact search, interaction history).
2. That same workflow, once hardened, can in turn be exposed as a tool through an MCP Server Trigger — so a Claude Desktop agent used internally by the sales team can trigger a lead qualification directly from its conversation, without opening n8n.

The result: n8n becomes both a consumer and a provider of MCP tools, with no code beyond configuring these two nodes.

MCP, HTTP Request Tool, or Workflow Tool: which one to use?

MCP doesn't replace the existing tools, it adds a third option:

Situation	Recommended tool
A third-party API you call yourself, with no MCP server available	HTTP Request Tool
Business logic specific to your own operation (a calculation, a validation, a transformation)	Code Tool
Reusing an existing n8n workflow, including a specialized sub-agent	Workflow Tool
A third-party service that already exposes an official MCP server	MCP Client Tool
Making an n8n workflow callable from Claude Desktop, Cursor, or an external agent	MCP Server Trigger

Good practice is to check first whether the service you want to integrate already exposes an official MCP server, before rebuilding a homegrown HTTP Request Tool endpoint by endpoint: the MCP Client Tool avoids maintaining an integration that drifts out of sync the moment the provider changes something on their side.

Going further

If you're still new to n8n's cluster node architecture before tackling MCP, start with our Getting started with n8n's AI nodes guide, which covers the AI Agent node, chains, and memory basics. The Inbox AI Pack (€79) and the Compliance & Audit Pack (€149) both rely on the ai_tool connection to act, not just answer — exactly the pattern the MCP Client Tool extends to already-standardized third-party tools. If your AI stack spans several of these use cases (email triage, document RAG, compliance), the Complete FlowKit Bundle (€269) brings all three packs together on that same tool-equipped agent foundation.