n8n and MCP: connecting your workflows to an LLM local

#n8n and MCP: two nodes, two directions

The Model Context Protocol (MCP) is an open protocol that describes how an AI application discovers and calls tools provided by a server. If the concept is new to you, the guide “MCP: c'est quoi?” covers the basics; here, we assume you already know the terms client, server, and tool.

In n8n, MCP shows up as two nodes in the AI family (n8n-nodes-langchain package). They serve two opposite needs, and tutorials make it easy to mix them up.

MCP Server Trigger: n8n becomes a server

The node publishes an MCP URL. Every tool you attach to it (a sub-workflow, an HTTP request, a built-in tool) becomes an MCP tool that an external client can list and call. Typical use: giving your local assistant access to “create a ticket,” “search the CRM,” or “send a summary” without handing it your credentials.

MCP Client Tool: n8n becomes a client

The node plugs in as a tool under an AI Agent node. It connects to an existing MCP server, retrieves its list of tools and makes them available to the agent. Typical use: a scheduled workflow whose agent reads files, queries a database or searches documentation through an MCP server that's already in place.

What MCP doesn't change

Your choice of model is a separate decision. The n8n agent can run on Ollama, and the client calling your MCP Server Trigger can use a local model too. MCP only carries the tool descriptions and tool calls, not the model.

Both nodes can coexist in the same instance: a "server" workflow that exposes a few business actions, and an "agent" workflow that consumes one or more MCP servers. Nothing even stops an n8n agent from calling the MCP Server Trigger of another workflow in the same instance, which amounts to splitting a large agent into reusable building blocks.

#Prerequisites

A recent n8n instance

Self-hosted, preferably with Docker. The MCP nodes appeared in 2025 and have changed since then (transports, authentication options): update n8n and rely on what your editor shows. The installation itself is covered in detail in the n8n with Docker guide.

Ollama reachable from n8n

By default, Ollama listens on http://localhost:11434. If n8n runs in a container, localhost refers to the container, not your machine: you'll need a different address (see step 1).

A model that supports tool calling

An agent is only useful if the model can produce structured tool calls. Pick a model whose Ollama listing shows the tools capability, for example from the Qwen3 family. At Q4_K_M, an 8B fits in about 5 GB of VRAM and a 14B in about 9 GB, which is comfortable on a 12 GB RTX 3060 or a 12 GB RTX 4070.

For step 2

An MCP server reachable over HTTP. Servers launched only locally via stdio (an npx or uvx command) can't be reached by n8n as is: you need a server that listens on a URL.

For step 4

An MCP client that can talk to a remote server: LM Studio, Open WebUI, Claude Desktop through a gateway, or the protocol's official inspector for testing.

#Step 1: An n8n agent connected to a local model

Both MCP directions go through an agent, either on the n8n side or on the client side. So start by making sure n8n can talk to your local model. The basic connection is covered in detail in the n8n + Ollama guide; here's the bare minimum.

# Télécharger un modèle compatible avec l'appel d'outils
ollama pull qwen3:8b

# Vérifier qu'Ollama répond et liste le modèle
curl http://localhost:11434/api/tags

If n8n runs in Docker and Ollama runs directly on the host, add an entry to the n8n service that points host.docker.internal to the host machine. On Docker Desktop (macOS, Windows), this name already exists; on Linux, you have to declare it.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    extra_hosts:
      - "host.docker.internal:host-gateway"

On Linux, Ollama listens only on 127.0.0.1 by default: a container won't reach it via host-gateway until you set OLLAMA_HOST=0.0.0.0 in the Ollama service. If both run in the same Compose file, use the service name instead, for example http://ollama:11434.

1. 01
   Create the agent

   In a new workflow, add a Chat Trigger (handy for testing), then an AI Agent node.
2. 02
   Connect the model

   On the agent's Chat Model input, add Ollama Chat Model. Create the Ollama credential with the base URL http://host.docker.internal:11434 (or http://localhost:11434 if n8n isn't running in a container), then select qwen3:8b.
3. 03
   Test without tools

   Open the workflow chat and ask a simple question. A reply confirms that n8n is connected to Ollama; the rest of the guide adds tools on top.

#Step 2: Consume an MCP server from an n8n agent

The MCP Client Tool node attaches to the AI Agent's Tool input, just like any other tool. At runtime, it queries the MCP server, retrieves the list of tools with their descriptions and parameter schemas, and presents them to the model. The model decides which tool to call with which arguments; n8n relays the call and returns the result.

1. 01
   Add the node

   Under the agent created in step 1, click the + on the Tool input and choose MCP Client Tool.
2. 02
   Enter the endpoint

   Paste the MCP server URL and choose the transport that server offers. The n8n documentation lists HTTP streaming (streamable HTTP), the protocol's current transport, and Server-Sent Events (SSE), which is older but still served by some servers. If the server documents a URL ending in /sse, it's usually SSE; otherwise, try HTTP.
3. 03
   Choosing authentication

   None, Bearer (a token sent in the Authorization header), or a custom header, depending on what the server requires. The exact options depend on your n8n version; the token is stored as an n8n credential, not in plain text in the workflow.
4. 04
   Filter tools

   The Tools to Include parameter offers All, Selected, or All Except. Choose Selected: a local 8B model picks better among three well-described tools than among thirty, and you limit what the agent can trigger.
5. 05
   Test

   In the chat, ask for an action that requires the tool. In the agent's execution log, you can see the tool that was called, the arguments generated by the model, and the server's response.

Practical reminder: n8n must be able to reach the MCP server. A server running on your machine at localhost:3000 is not visible from the n8n container; the same host.docker.internal or Docker service name rule applies.

#Step 3: Expose your workflows with the MCP Server Trigger

This is the direction most people are after when they search for "n8n mcp": turning existing automations into tools an assistant can call. The MCP Server Trigger differs from regular triggers: it doesn't start a chain of nodes; it only connects to tool nodes and publishes them.

1. 01
   Create the server workflow

   Create a new workflow and add the MCP Server Trigger node. It displays a test URL and a production URL, plus a Path field that sets the end of the URL. You can replace the random identifier with a readable path if you like, but keep it hard to guess.
2. 02
   Attaching tools

   Click the trigger's Tool input and add tools. The most useful one is the tool that calls another n8n workflow (Call n8n Workflow Tool): your existing automation becomes an MCP tool. You can also attach HTTP Request Tool or integration tools provided by n8n.
3. 03
   Write a clear name and description

   The client sees only the tool's name, its description and its parameter schema. That text is what the model reads to decide whether to make a call. Write an explicit description in one or two sentences: what the tool does, which parameters it expects and what it returns.
4. 04
   Define the sub-workflow parameters

   In the called workflow, declare the expected input fields (for example, a ticket's title and priority). The MCP client will receive this schema, and the model will fill in the values.
5. 05
   Test, then activate

   The test URL responds only while the editor is listening for a test event, and executions then appear on the canvas. The production URL works only after the workflow is activated. Use the test URL while you fine-tune the workflow, and give the production URL to your clients.

Test        : https://n8n.mondomaine.lan/mcp-test/<chemin>
Production  : https://n8n.mondomaine.lan/mcp/<chemin>

The base address is the same one n8n uses for its webhooks. If n8n shows localhost:5678 but you access it under a different name, fix the instance's WEBHOOK_URL variable: it determines the URL shown in the node.

#Step 4: connect a local MCP client to n8n

What's left is to have these tools called by an assistant that also runs on a local model. Before using any "smart" client, check the server with the protocol's official inspector: it lists the exposed tools and lets you call them manually, with no model in the loop.

# Lance l'inspecteur MCP dans le navigateur (nécessite Node.js)
npx @modelcontextprotocol/inspector

In the interface, choose the matching transport, paste the production URL, add the Authorization header if you enabled authentication, then list the tools. If your n8n tools show up with their descriptions, the server is ready.

#LM Studio and clients that accept a URL

Recent clients accept a remote MCP server defined by a URL directly. LM Studio, for example, reads an mcp.json file in mcpServers format; a remote entry looks like the one below. Check your client's documentation for the exact field names, which may vary from one tool to another.

{
  "mcpServers": {
    "n8n": {
      "url": "https://n8n.mondomaine.lan/mcp/<chemin>",
      "headers": {
        "Authorization": "Bearer <votre-jeton>"
      }
    }
  }
}

#Clients limited to stdio: use a gateway

Some clients can only launch local stdio servers. For this case, the n8n documentation describes using the mcp-remote gateway, which runs as a stdio server and relays calls to the n8n URL. The token is passed through an environment variable rather than hard-coded in the arguments.

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://n8n.mondomaine.lan/mcp/<chemin>",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<votre-jeton>"
      }
    }
  }
}

On the model side, the same rules as in step 2 apply: load a model that supports tool calling in your client, keep only a few tools visible, and test first with an unambiguous request. The MCP and local LLM guide details client-side configuration for Ollama and its interfaces.

#Securing n8n's MCP endpoints

An MCP Server Trigger URL is an entry point that triggers your workflows using the credentials stored in n8n. Without authentication, anyone who knows it can create your tickets or read your CRM. Treat it like an API key.

Enable authentication

The node supports Bearer token or header authentication. Always enable it, even on a local network. Generate a long random token, for example with the openssl command below, and use a different token for each client so you can revoke just one.

Don't expose n8n to the internet without a reason

For personal or small-team use, keep n8n on the local network or behind a VPN (WireGuard, Tailscale). If exposure is necessary, go through an HTTPS reverse proxy, with IP filtering if possible.

Limit what each tool can do

An MCP tool should do one specific thing with bounded parameters. Avoid exposing a generic “run an SQL query” or “call any URL” tool: a model that makes a mistake, or malicious content read by the agent, can hijack it.

Watch out for prompt injection

If the agent reads external content (emails, web pages, documents) and has tools that take actions, a booby-trapped text can instruct it to call a tool. Separate read tools from action tools, and add human approval (a wait or approval node) before any irreversible action.

Audit on the third-party MCP server side

On the client side, only add MCP servers to an agent if you know their publisher and code. The tool descriptions provided by the server go straight into the model's context.

Monitor executions

Every tool call produces an execution in n8n. Check the server workflow's history regularly: it's your audit log.

# Générer un jeton aléatoire de 64 caractères hexadécimaux
openssl rand -hex 32

If a reverse proxy sits in front of n8n, it must let streaming responses through. The n8n documentation provides an nginx example that disables buffering for MCP paths; the snippet below reuses those directives. Adapt it to your configuration and add the /mcp-test/ path if you test through the proxy.

location /mcp/ {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding off;
    gzip off;
}

#n8n MCP troubleshooting: common issues

The client sees no tools

Check that tools are actually attached to the MCP Server Trigger's Tool input, and that you're using the production URL with an activated workflow, or the test URL while the editor is listening.

401 or 403 error

The token doesn't match, or the client isn't sending the header. Test with the MCP inspector, which shows exactly which headers are sent. Watch out for the space after "Bearer".

Connection drops or hangs

Almost always a proxy that buffers the stream, or the wrong transport selected on the client side (SSE vs. HTTP). Test directly on port 5678 to rule out the proxy.

The displayed URL contains localhost

n8n's WEBHOOK_URL variable is not set, so the URL won't be reachable from another machine. Set it to the instance's public or network address, then restart n8n.

ECONNREFUSED to Ollama

Containerized n8n looks for Ollama inside the container. Use host.docker.internal or the Docker service name, and make sure Ollama is listening on a reachable interface.

The model never calls the tool

The model doesn't support tools, the tool description is too vague, or too many tools are exposed. Switch to a model tagged tools, rewrite the description, and narrow the selection.

The model makes up parameters

The sub-workflow schema is too loose. Declare typed fields and describe the expected values; validate inputs in the workflow before taking any action.

#Go further

This guide covers MCP in n8n. For protocol basics, configuring MCP clients on the Ollama side, or connecting n8n to a local model, these guides pick up from here.