How to Build Your First MCP-Powered AI Agent in n8n

Your n8n AI agent can hold a conversation, but beyond the nodes you hard-wired it cannot do much, and every new capability means building another custom integration by hand. n8n MCP support changes that: the MCP Client Tool gives your agent a whole server's worth of tools in one node, and the MCP Server Trigger turns your own workflows into tools any MCP-compatible client can call.

Before I built my first MCP agent in n8n, I was solving every capability gap by adding another HTTP Request node or another tool node, wiring credentials again, and hoping nothing broke. The moment I attached an MCP Client Tool to my existing agent and pointed it at a server, the agent could suddenly do things I never explicitly wired. That shift is worth understanding before you touch a single node.

If you have not read the broader context on why MCP matters for solo operators, the MCP servers solopreneur guide covers the background before this hands-on build.

What is MCP and why does it matter for n8n agents?#

MCP (Model Context Protocol) is an open standard that gives AI models one consistent way to discover and call external tools, instead of a custom integration for each one. For n8n agents, a single MCP Client Tool node can replace a pile of hand-built tool nodes, because the agent reads the server's tool list at runtime.

Before MCP, every new capability for an n8n agent was a project. You designed the node, mapped the parameters, managed the credentials, tested the errors. With MCP, you point the agent at a server that already does the work, and the agent stops needing you to predict which tools it will use.

For a solo operator, that is not a small gain. If you are already running an agent for email triage or customer support (see the Claude email triage agent walkthrough), adding a new capability used to mean a new build cycle. With MCP, it means updating or swapping the server.

What are the two MCP nodes in n8n?#

The two n8n MCP nodes are the MCP Client Tool and the MCP Server Trigger. They run the same protocol in opposite directions: the Client Tool is your agent reaching out to use tools, and the Server Trigger is your workflows being reached into by other clients. Know which direction you need before you build.

Here is the full comparison at a glance:

Sources: MCP Client Tool docs, MCP Server Trigger docs

Same protocol, opposite directions: know which node you need before you build.

That table is the thing I wish I had seen before spending 20 minutes searching for a single "MCP node" that handled both directions. There is no single node. There are two, and which one you need depends entirely on which direction data flows.

How do you give your AI agent MCP tools?#

To give your n8n AI agent MCP tools, add an MCP Client Tool sub-node to an existing AI Agent node, set the SSE Endpoint to your external MCP server's URL, and choose an authentication method. The agent discovers the server's tools at runtime and calls them when its reasoning decides they are relevant.

The agent picks the right MCP tool and returns live data, not a guess.

Here is the build, step by step:

Five steps from a bare AI Agent node to a working MCP connection.

Step 1: Add an AI Agent node with a Claude model#

Open your n8n workflow and place an AI Agent node. Attach a Chat Model sub-node and configure it to use a current Claude model. For routine agent work, Claude Sonnet 4.6 handles most tasks well. For harder multi-step reasoning, Claude Opus 4.8 is the right call.

If you are already running an agent on a local model (the connect Ollama to n8n guide covers that setup), you can swap in a Claude model or keep your local model and just add the MCP tool sub-node below it.

Step 2: Attach an MCP Client Tool sub-node#

Inside the AI Agent node's tool panel, add a new MCP Client Tool. This sub-node connects to an external server's SSE endpoint, fetches the server's tool list, and passes available tools to the agent's context. It is what makes your agent an MCP client.

Step 3: Set the SSE Endpoint#

In the MCP Client Tool node, paste your MCP server's SSE endpoint URL into the SSE Endpoint field. This is the specific URL format the server exposes for streaming events. If you are connecting to a public MCP server, its documentation will list this URL. If you are connecting to your own n8n MCP Server Trigger (covered below), copy the URL from that node.

Step 4: Choose authentication#

Select one of: Bearer, generic header, multiple headers, OAuth2, or None. For any server outside your own local environment, use at least Bearer auth. The MCP Client Tool supports all four named auth options natively, so you will not need a separate credential workaround.

Step 5: Test with a tool-dependent question#

Send a message the agent cannot answer without calling the MCP tool. Something like "What is the current status of issue #42 in my project?" only makes sense if the agent actually calls the tool. If it answers plausibly from general knowledge, your system prompt or tool description needs tightening, not the wiring.

How do you turn your n8n workflows into an MCP server?#

The MCP Server Trigger turns your n8n workflows into an MCP server, acting as the entry point for any MCP client. Attach Custom n8n Workflow Tool nodes, each pointing at a workflow to expose. The trigger publishes two URLs, test and production, and the production URL goes live when you activate the workflow.

The MCP Server Trigger only connects to and executes tool nodes, not full workflow chains. You are exposing discrete capabilities, not entire pipelines, which gives you precise control over what a client can call.

Authentication on the exposed URL is either Bearer auth or Header auth. Set one of these before you share the URL. An unauthenticated production MCP URL is an open endpoint.

The workflows worth exposing as MCP tools are the ones that do useful, repeatable work with clear inputs and outputs. An email triage workflow, a CRM lookup, a document summarizer are all good candidates. A workflow that sends bulk emails without a confirmation step is not.

How does Claude Desktop connect to your n8n MCP server?#

Claude Desktop talks to MCP servers over stdio transport, but n8n's MCP Server Trigger only speaks SSE and streamable HTTP, so a direct connection silently fails with no error at all. The fix is the mcp-remote bridge, a small npx process that translates between the two transports so Claude can reach n8n.

I ran into this exact wall the first time I pointed Claude Desktop at my n8n MCP server. No error, no connection, just nothing. After checking the n8n docs, the fix was straightforward: add an entry to Claude Desktop's claude_desktop_config.json that runs npx mcp-remote, points at the n8n MCP URL, and passes the bearer token as a header.

Here is the exact config block from n8n's documentation:

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "<MCP_URL>",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<MCP_BEARER_TOKEN>"
      }
    }
  }
}

Replace <MCP_URL> with the test or production MCP URL from your MCP Server Trigger node. Replace <MCP_BEARER_TOKEN> with the bearer token you configured in that node's authentication settings. The env block keeps the token out of the args array so it does not appear in process listings.

Once that config is in place and Claude Desktop restarts, it connects through mcp-remote to your n8n server as if it were a native stdio server.

Source: MCP Server Trigger docs

What should your first MCP agent actually do?#

Your first MCP agent should do exactly one thing: call one MCP server, answer a question that requires that tool, and let you verify in the n8n execution log that the tool was actually called. Start small and confirm the plumbing before adding complexity.

That discipline matters. An agent that gives the right answer by guessing from general knowledge is not a working MCP integration. It is a language model doing what language models do. The execution log is the only verification that counts.

Run through this before calling your first MCP build done.

Once your first build is confirmed, the next natural step is exposing one of your own workflows as a tool other clients can call. The AI automation stack overview for 2026 shows where MCP fits in a full solo operator setup, which helps you decide which workflow to expose first.

How solopreneurs get this wrong#

The most common mistake is treating the MCP Client Tool and the MCP Server Trigger as interchangeable. They are not, and they point in opposite directions. Searching for a single "MCP node" and getting confused when the behavior does not match the docs is a real time sink that catches almost everyone first.

The second mistake is skipping auth on a production MCP Server Trigger URL because "it's just for testing." Once a workflow is activated in n8n, its production URL is live. An unauthenticated MCP endpoint is an open API for anyone who finds the URL.

The third is chaining five MCP servers before verifying the first one works. Every server you add is a new failure point. One confirmed tool call is worth more than five unverified connections.

Where to go from here#

Add the MCP Client Tool to an agent you already have running and point it at one server you care about. Confirm the tool call in the execution log before you build anything else. Then, if you have a workflow worth exposing, drop an MCP Server Trigger on it, set bearer auth, and test the mcp-remote connection from Claude Desktop.

The protocol is the same in both directions. Once you understand that, both nodes make sense immediately.