TL;DR: The MCP Client Tool node turns an external MCP server into a bundle of tools your n8n AI Agent can call. You point it at an SSE endpoint, pick an auth method (Bearer, generic header, OAuth2, or None), choose which tools to expose, and wire it into the AI Agent's tool input. This is the opposite of the MCP Server Trigger, which makes n8n itself the server. Use the client when you want one node to hand the agent a whole toolset instead of building and maintaining a dozen separate HTTP Request tool nodes.
What the MCP Client Tool node actually does
The MCP Client Tool node is an MCP client: it consumes the tools an external MCP server exposes and makes them available to your n8n AI Agent. You connect it the same way you connect a Calculator or HTTP Request tool - as a sub-node feeding the AI Agent's tool input. The difference is leverage. One MCP server can publish ten, twenty, or fifty tools, and a single MCP Client Tool node surfaces all of them to the agent at once, with descriptions and schemas the model can reason about.
That is the entire pitch. Instead of manually defining each external capability as its own tool node, you connect to a server that already knows its own tools and let the agent discover them.
If you want the reverse - n8n publishing your workflows as tools that Claude Desktop, Cursor, or another agent can call - that is the MCP Server Trigger, covered in n8n MCP Server: How to Expose Your Workflows to AI Agents. Two nodes, opposite directions. The client calls out; the trigger gets called.
Connection and auth: the fields that matter
The node has three parameters worth understanding before you touch anything else.
SSE Endpoint. This is the URL of the MCP server you are connecting to. The node connects over an HTTP-based transport, so you are giving it the server's endpoint, not a command. (n8n's transport story has been moving toward HTTP Streamable as the modern default, with SSE as the legacy long-lived transport. Confirm which one your target server speaks before you wire it up - mismatched transports are the most common reason a connection silently does nothing.)
Authentication. The node supports Bearer, generic header, and OAuth2, plus None for servers that need no auth. Bearer covers the common case where the server expects an Authorization: Bearer <token> header. Generic header is for servers that key on a custom header name and value. OAuth2 is for servers that run a proper authorization flow. Pick None only for local or fully trusted servers - an open MCP endpoint is an open door to whatever those tools can do.
Tools to Include. This controls how much of the server's catalog the agent sees:
-
All exposes every tool the server publishes. Fine for small, trusted servers.
-
Selected activates a Tools to Include picker so you expose only the specific tools you want. Use this in production.
-
All Except activates a Tools to Exclude picker - the agent gets everything the server offers minus what you blacklist.
The instinct to pick All and move on is the wrong one. A server with fifty tools dumps fifty tool descriptions into your agent's context, which costs tokens and dilutes the model's focus. Select the three or four tools the workflow actually needs and the agent makes better calls.
A concrete setup
Say you want an n8n AI Agent that can search and read your team's documents through an external MCP server, then draft a reply. The wiring:
- Add an AI Agent node and give it a chat model (the n8n MCP server skill files post covers model selection in more depth).
- Add an MCP Client Tool node and connect its output to the AI Agent's tool input.
- In the MCP Client Tool node, set the SSE Endpoint to your document server's URL, choose Bearer auth, and paste the token into the credential.
- Set Tools to Include to Selected and pick only
search_documentsandget_document. - Write the agent's system prompt so it knows those tools exist and when to call them.
The agent now treats search_documents and get_document as native tools. When a user asks "what did we decide about the Q3 pricing change," the agent calls search_documents, gets back document IDs, calls get_document, and answers from the content - no HTTP nodes, no manual JSON parsing, no per-endpoint maintenance on your side.
For an externally hosted MCP server, the credential side looks like this:
{
"sseEndpoint": "https://mcp.yourcompany.com/sse",
"authentication": "headerAuth",
"headerAuth": {
"name": "Authorization",
"value": "Bearer sk_live_your_token_here"
},
"include": "selected",
"includeTools": ["search_documents", "get_document"]
}
Generic header auth is the most flexible option here: it works for Authorization: Bearer ... and for servers that use a custom header like X-API-Key. If your server expects exactly a bearer token and nothing custom, the dedicated Bearer auth method is cleaner. The point is that the node abstracts the transport entirely - you never write the request, you describe the connection and the agent makes the calls.
When this beats hand-built HTTP tool nodes
Reach for the MCP Client Tool node when the external service already speaks MCP and you want more than one or two of its capabilities. Building individual HTTP Request tool nodes means writing the URL, method, headers, body schema, and a hand-authored description for each endpoint, then maintaining all of that when the API changes. An MCP server ships its own tool definitions and schemas. You connect once and inherit the whole catalog, updates included.
The HTTP tool node still wins in two cases. First, when the service has no MCP server - most APIs still do not - an HTTP Request tool is your only option. Second, when you need exactly one endpoint with heavy custom shaping of inputs and outputs, a single purpose-built HTTP node is simpler than standing up or connecting to a server. The decision is not "MCP is better." It is: does an MCP server exist for this service, and do I want enough of its surface to justify the connection? If yes to both, the client node is less code and less maintenance.
There is also a composition angle. Because the agent sees MCP tools as ordinary tools, you can mix them freely - an MCP Client Tool for your document server, a separate one for a calendar server, and a couple of plain HTTP tools for one-off APIs, all feeding the same agent. The agent does not know or care which is which.
How it relates to the MCP Server Trigger
These two nodes are mirror images, and conflating them is the most common confusion in n8n's MCP support.
The MCP Client Tool node makes n8n a consumer. Your agent reaches out to someone else's server and borrows its tools. Data and intent flow outward from n8n.
The MCP Server Trigger node makes n8n a provider. It exposes a URL that external MCP clients - Claude Desktop, Cursor, another n8n instance - connect to in order to run your workflows as tools. It supports SSE and HTTP Streamable transports and the same Bearer, header, and None auth options on the inbound side. Data and intent flow inward to n8n.
You will often run both. n8n acts as a client to pull in a vector-search or calendar MCP server, and simultaneously runs a Server Trigger so that your desktop AI assistant can fire off n8n workflows. For the inbound direction, start with n8n MCP Server: How to Expose Your Workflows to AI Agents. If you specifically want Claude Code driving your instance, Connect Claude Code to n8n via MCP walks through that path.
Common mistakes
Picking All for a large server is the first one, and it quietly degrades agent quality by flooding context with irrelevant tool descriptions. Narrow it with Selected.
Transport mismatch is the second. If the server speaks one transport and you assume another, the connection appears to attach in the editor but the agent never sees any tools. Check the server's documented transport and endpoint path.
Leaving auth on None for a remote server is the third, and it is a security problem, not a convenience. Any MCP server you connect to runs its tools with whatever permissions its token carries. Treat that token like a production API key, store it in an n8n credential rather than inline, and scope it down where the server allows it.
Where to take it next
If you are connecting an n8n agent to an external MCP server for the first time, start narrow: one server, Selected tools, header auth, and a tight system prompt. Get one real task working end to end before you add a second server. The MCP Client Tool node removes the integration grind, but a vague agent prompt will still produce vague tool calls regardless of how clean the connection is.
If you would rather hand the wiring, prompt design, and security scoping to someone who has done it before, that is the kind of build n8n Logic does day to day - reach out when you want a working agent instead of a half-connected one.
FAQ
What is the n8n MCP Client Tool node?
It is a sub-node that acts as an MCP client, connecting your n8n AI Agent to an external MCP server and exposing that server's tools to the agent. You connect it to the AI Agent's tool input the same way you connect any other tool node.
What connection and authentication types does it support?
You configure it with an SSE Endpoint pointing at the MCP server, and the Authentication field supports Bearer, generic header, and OAuth2, plus None for servers that require no auth. Confirm whether your target server uses the SSE or HTTP Streamable transport before connecting.
How is the MCP Client Tool different from the MCP Server Trigger?
They run in opposite directions. The MCP Client Tool node makes n8n a client that calls external MCP servers. The MCP Server Trigger node makes n8n a server that external clients call to run your workflows. Many setups use both at once.
When should I use it instead of an HTTP Request tool node?
Use the MCP Client Tool node when the external service already exposes an MCP server and you want several of its tools, since you inherit all the tool definitions and schemas at once. Use an HTTP Request tool when no MCP server exists for the service or you only need a single heavily customized endpoint.
Can I limit which tools the agent can call?
Yes. Set Tools to Include to Selected to pick a specific allowlist, or All Except to expose everything minus a blacklist. In production, prefer Selected so the agent only sees the few tools it actually needs.
Do I need to self-host n8n to use the MCP Client Tool node?
No. The node is part of n8n's native AI/LangChain nodes and works on both n8n Cloud and self-hosted instances. Your only external requirement is a reachable MCP server endpoint and valid credentials for it.
