Resources · n8n integration

n8n MCP Client nodeConfigure MCP Client in n8n.

The n8n MCP Client node calls a tool hosted on an MCP server and drops the result back into the workflow. Six parameters drive it: the transport, the endpoint URL, the authentication mode, the tool itself, how its input is built, and a short options list. Built for teams wiring AI tooling into real automations.

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the n8n MCP Client node actually do?

MCP servers expose tools over a network endpoint. The MCP Client node is the standalone way to reach one of those tools from a regular n8n workflow: point it at an endpoint URL, pick a tool, describe the input, and the node runs the call and returns what the server sends back. It sits in the AI package of n8n as a root node, so it takes its items from the main input wire like any other step.

The first scenario is the one most people land here for: a document arrives in a workflow and a hosted tool has to process it. The node takes the item, fills the tool input through Input Mode, and the parsed result continues down the branch toward Google Sheets or a notification in Slack. Nothing about the call is hidden in an agent loop, which is the point.

Second scenario: an internal MCP server that already wraps company logic. Instead of rebuilding that logic with HTTP calls, the workflow authenticates once through the Authentication selector and calls the tool by name. The credential is created once in the n8n Credentials menu and reused across every workflow that needs the same server.

Third scenario: a scheduled enrichment job. The workflow loops over rows, calls the same tool for each one, and writes the answers to a report that lands in Gmail. Because tool calls can run long, Timeout in the options collection is what keeps an execution from hanging.

When should you reach for something else? If the tools should be picked by a model rather than by you, the call belongs to AI Agent with its own tool ports, and the model behind it comes from a provider node such as OpenAI or Anthropic. The MCP Client node is the deterministic option: you name the tool, it runs that tool, every time.

Known limits are worth stating up front. The node speaks two transports, and one of them, Server Sent Events, is marked deprecated in the catalog. There is no event listener here: the node does not wake up on its own, so something upstream has to start the workflow. And the node describes version 1 of itself, so an older workflow can show fewer options than the ones on this page.

Connect

How do you authenticate against an MCP server?

  1. 01

    Pick the transport your server speaks

    Open the node and start with Server Transport, the transport used by your endpoint. Two choices exist: httpStreamable (HTTP Streamable) and sse (Server Sent Events (Deprecated)). The server documentation says which one it exposes, and picking the wrong one fails the connection before authentication is even tried. On a server that offers both, HTTP Streamable is the one that is not flagged as deprecated in the catalog.

  2. 02

    Paste the endpoint URL

    MCP Endpoint URL is required: it is the URL of the MCP server to connect to, in the shape shown by the field placeholder, e.g. https://my-mcp-server.ai/mcp. Full path, not just the host. If the URL comes from a previous step, an expression works here too: n8n reads a field of the incoming item with {{ $json.field }}, and an empty required field stops the node before any call goes out.

  3. 03

    Choose the authentication mode

    Authentication is the way to authenticate with your endpoint, and the selector carries five values: bearerAuth (Bearer Auth), headerAuth (Header Auth), mcpOAuth2Api (MCP OAuth2), multipleHeadersAuth (Multiple Headers Auth) and none (None). Each one points at a credential you create once in the Credentials menu of n8n, which any other workflow can then reuse. A public demo server usually accepts none.

Parameters

What does each parameter of the MCP Client node control?

The MCP Client node has 6 parameters. For each one: the node as you configure it in n8n, what the parameter changes, and our field notes.

01

Server Transport

serverTransport

What you see in n8n

Notes & use cases

Sets the transport used by your endpoint, so the node knows how to talk to the server before anything else happens.

Key parameters

  • Server Transport: httpStreamable (HTTP Streamable) is the current option; sse (Server Sent Events (Deprecated)) stays available for servers that have not moved yet.
Use cases
a self-hosted MCP server that was set up a while back often still exposes Server Sent Events, and the workflow keeps running on that value until the server is upgraded.
02

MCP Endpoint URL

endpointUrl

What you see in n8n

Notes & use cases

Holds the URL of the MCP server to connect to. Required, and the only parameter that decides which server answers.

Key parameters

  • MCP Endpoint URL: a string, shaped like the placeholder e.g. https://my-mcp-server.ai/mcp, or an expression such as {{ $json.endpoint }} when the address changes per item.
Use cases
staging and production usually run the same tools behind two addresses, and an expression fed by the previous step swaps between them without duplicating the workflow.
03

Authentication

authentication

What you see in n8n

Notes & use cases

Defines the way to authenticate with your endpoint, and switches which credential type the node asks for.

Key parameters

  • Authentication: bearerAuth (Bearer Auth), headerAuth (Header Auth), mcpOAuth2Api (MCP OAuth2), multipleHeadersAuth (Multiple Headers Auth), none (None).
Use cases
a server that wants a project header next to the token is the case for Multiple Headers Auth, while a single static token fits Bearer Auth and takes seconds to set up.
04

Tool

tool

What you see in n8n

Notes & use cases

Names the tool to use on the server. Required, and it is what the execution actually runs.

Key parameters

  • Tool: a resource locator, so the tool can be picked from the list the server returns or typed in by its identifier when the list cannot load.
Use cases
a server that publishes one tool per document type lets a Switch upstream route each file to the right tool, with one MCP Client node per branch and no shared configuration to keep in sync.
05

Input Mode

inputMode

What you see in n8n

Notes & use cases

Decides how the tool input is built, field by field or as one object.

Key parameters

  • Input Mode: manual (Manual) to manually specify the input data for each tool parameter, json (JSON) to specify the input data as a JSON object.
  • Parameters: required in Manual, it maps each tool parameter to a value or an expression.
  • JSON: the object sent in JSON mode.
Use cases
Manual keeps a short tool readable for whoever inherits the workflow; JSON wins when an upstream step already produced the whole payload.
06

Options

options

What you see in n8n

Notes & use cases

Groups the additional options to add, both of which change what comes back and how long the node waits.

Key parameters

  • Convert to Binary: whether to convert images and audio to binary data; left off, images and audio are returned as base64 encoded strings.
  • Timeout: time in ms to wait for tool calls to finish.
Use cases
a tool that renders an image needs Convert to Binary before the file can be attached downstream, and a slow generation tool needs Timeout raised or the execution stops mid call.
Need help

Need help automating MCP Client with n8n?

A person reads every message.

FAQ

MCP Client and n8n, the questions that come up next

01Is the n8n MCP Client node free to use?
Yes. It ships in the AI package of n8n, @n8n/n8n-nodes-langchain, which comes with the product. There is nothing to install and no extra cost on the n8n side, on n8n Cloud as well as on a self-hosted instance running the Community Edition under the Sustainable Use license. A workflow built on one runs the same way on the other. What can cost money is what sits behind the endpoint: the MCP server you call, and any model provider involved further along the workflow, bills its own API calls under its own terms. n8n adds nothing to that.
02What do you need for the node to run?
Three things, and the node will not execute without them. An MCP Endpoint URL, since the field is required and an empty required field blocks the node. A transport that matches the server, chosen in Server Transport between HTTP Streamable and the deprecated Server Sent Events. And a tool, picked in the Tool resource locator. Authentication is a fourth decision rather than a fourth requirement: the selector accepts None for a server that does not ask for anything, and otherwise points to a credential created once in the Credentials menu and reused everywhere.
03What are the limits of this node?
It calls one tool per node, on one endpoint, with the input you describe. It does not listen for anything, so a Schedule or a Webhook step upstream is what starts the workflow. Its two transports are HTTP Streamable and Server Sent Events, and the second is marked deprecated in the catalog. The options collection is short: Convert to Binary and Timeout, nothing else. The page describes version 1 of the node, so an older workflow may display fewer options. And the tool list depends on the server answering, which is why a wrong transport looks like an empty catalog.
04What should you plug in to get started?
Start with a public MCP server, Authentication set to None, and Input Mode on Manual. That combination removes credentials from the equation and shows the tool parameters as plain fields, which is the fastest way to see what the server expects. Once the call returns, switch the values to expressions such as {{ $json.field }} so the node reads the incoming item. Move to JSON mode only when an upstream step already builds the whole object. If a model should be choosing the tool instead of you, that job belongs to the AI Agent node and its tool port, not here.
05n8n or Make for calling an MCP server?
It depends on where the data has to live. n8n can be self-hosted with Docker or npm, or used on n8n Cloud, and the workflow is identical either way, which matters when an MCP server sits on an internal network. Make is hosted only, with no self-hosting option, and is billed per operation, so a workflow that calls a tool for every row in a batch has a cost that follows volume. On visual logic both are comfortable. Pick on hosting, data control and the cost model, in that order.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.