n8n MCP Features Explained: Five Things, One Confusing Name

n8n now has five separate features with "MCP" in the name. Two of them are nodes whose names differ by one word. One of them is a catalog that did not exist when we last wrote about this. If you have been confused about which one you are supposed to use, that is not your fault.

This is part nine of our n8n series. Part three covered the MCP Server Trigger in depth and still stands. This piece is the map: what the five things are, which one fits your problem, and what has changed underneath since July.

MCP, the Model Context Protocol, is an open standard for handing tools to a language model. A server exposes tools, a client consumes them. Every feature below is n8n sitting on one side of that line or the other.

The five n8n MCP features, and the names that collide

We pulled this list from a live self-hosted instance rather than the docs, because the docs scatter these across four pages.

Numbers 3 and 5 are the ones most coverage misses. We will spend most of our time there.

Server Trigger vs Client Tool vs the standalone Client

The first three are all nodes, and the difference is direction plus granularity.

The Server Trigger (1) points outward. You built a workflow, you want Claude or ChatGPT or your own agent to be able to call it. Part three walks through this end to end, including the three self-hosting failures that stop it working, so we will not repeat it.

The Client Tool (2) points inward, at an AI Agent. You attach it, and the agent gains every tool the remote server offers, subject to a filter. The model decides which to call and when.

The standalone Client (3) is the one nobody talks about, and it is genuinely different. It is a normal workflow node. You pick one specific tool from the remote server using a dropdown, you map its parameters like any other node, and it runs. No model decides anything.

That last distinction matters more than it sounds. If you know exactly which remote tool you need and exactly what to pass it, routing that through an agent means paying for tokens so a model can rediscover a decision you already made. The standalone client is the deterministic path.

Its parameters, read from the live node definition:

Two tuning knobs for nodes 1 and 2

These live in the source and not in the environment variable docs, and both matter if you run MCP under load.

For the Client Tool, N8N_MCP_CLIENT_CACHE_TTL_MS defaults to 5 minutes. n8n's own comment explains why it exists: keeping the client open "lets all tool calls within a single workflow execution share one MCP session (required for stateful MCP servers)". Drop it too low and stateful servers break mid-execution. N8N_MCP_CLIENT_CACHE_MAX_SIZE defaults to 500 cached clients.

For the Server Trigger, N8N_MCP_SERVER_SESSION_IDLE_TTL_MS defaults to 15 minutes and N8N_MCP_SERVER_SESSION_SWEEP_INTERVAL_MS to 5 minutes. The first exists because "streamable HTTP clients that disconnect without sending an explicit DELETE rely on this to avoid leaking sessions". If you are hosting an MCP server for clients you do not control, that is your leak protection.

The instance-level server, and how much it grew

Number 4 is the one that lets an MCP client drive n8n itself. Part three covered its blast radius (read, build, write, execute) and its token model, and both still apply. What changed is the surface area.

Connecting to a 2.41 instance today exposes 50 tools. The notable addition is a 15-tool agents family that did not exist in July: search_agents, create_agent, mutate_agent, validate_agent, call_agent, publish_agent, delete_agent, verify_agent_mcp_server and friends. There is also a data-table family and list_n8n_gateway_services.

In other words, the Agents feature we covered in part eight is fully drivable over MCP. You can build, validate and publish an agent from a chat window without opening the editor.

One sharp edge carried over from part three, now with more reach: an execute call is not a dry run, and the agent tools include publish_agent. Treat the token as what it is.

The registry: one-click OAuth, and the one server you cannot have

Number 5 is the genuinely new one. Open the node panel, pick a service, sign in, and n8n creates the OAuth credential for you and attaches the server to your agent. No URL, no manual credential, no reading someone's setup guide.

The question we actually wanted answered: does it work the same when you self-host? Mostly yes, with exactly one exception, and here is how to check it yourself.

The registry is served from a public, unauthenticated API. You can audit the whole catalog without an n8n instance at all:

curl -s "https://api.n8n.io/api/mcp-servers?version=4&pagination%5BpageSize%5D=100" \
  | jq -r '.meta.pagination.total'

# which entries are gated to a capability your instance may not have
curl -s "https://api.n8n.io/api/mcp-servers?version=4&pagination%5BpageSize%5D=100" \
  | jq -r '.data[].attributes | select(.requiredCapabilities != null)
           | "\(.slug)  \(.requiredCapabilities)"'

On 2026-10-01 that returns 77 servers, all marked active and official. Of those, 74 authenticate with OAuth2, two extend an existing credential, and one uses stored credentials. And exactly one declares a required capability:

{
  "slug": "eleven-labs",
  "title": "ElevenLabs",
  "requiredCapabilities": ["n8n-cloud"]
}

That capability is granted only to Cloud deployments. The check lives in packages/cli/src/modules/mcp-registry/registry/mcp-registry-capabilities.ts, and the logic is short enough to read in full: the base capability set is empty, n8n-cloud is added only when the deployment type is cloud, and a server survives the filter when your instance supports every capability it asks for. Servers that declare none pass everywhere.

So on self-hosted n8n the registry shows 76 of 77 servers. We confirmed it on a live self-hosted instance through n8n's own agent asset discovery: querying for "tavily" returns the server with its URL and OAuth credential type, while querying for "eleven" returns an empty array. Twenty-two other obscure servers we spot-checked (Axiom, Honeycomb, Railway, Sanity, Postman, Mux, Lusha and more) were all present.

Nothing warns you. The server is simply not in the list. If you want ElevenLabs on a self-hosted box, there is a separate non-registry node for it, so you are not locked out of the service, only out of the one-click path.

Do not trust the published server count

You will see "about 70 servers" quoted widely. That comes from an August 2026 announcement, and the catalog has moved since. PandaDoc was named in that announcement and is not in the registry today.

n8n's own documentation refuses to commit to a number, and is right to: "The list of registry servers changes often. Browse the current list in the node panel instead of relying on a static list here." The curl above is how you get today's answer instead of last quarter's.

The trap: neither check catches a broken MCP server

This is the part to take away even if you skip everything else.

When you attach an MCP server to an agent, there are two things that look like safety nets. Neither one is.

The first is validate_agent. n8n documents the limitation plainly: "validate_agent never performs this handshake, so an unverified entry can pass validation and still fail at runtime." We tested it. We built a throwaway agent whose only MCP server pointed at https://example.com/definitely-not-an-mcp-server, then validated it:

{"ok": true, "valid": true, "errors": [], "missing": []}

Clean bill of health for a server that does not exist.

The second is verify_agent_mcp_server, the tool whose entire job is to open a live connection and confirm the server works. Pointed at that same nonsense URL, it returns:

{"ok": true, "tools": []}

It says ok. For a URL that is not an MCP server. We got the identical response pointing it at two real registry servers without credentials.

The lesson: ignore ok and read the tools array. An empty tool list is the only failure signal you get, and it means either "wrong URL" or "not authenticated", with no way to tell which apart. n8n's own guidance points the right way without saying why: "Confirm the returned tools cover the requested capability and use the list to populate toolFilter instead of guessing tool names."

We did not get a positive case, a non-empty tool list, because that needs a completed OAuth sign-in and we kept this test credential-free. So treat the above as proof that failure is silent, not as a measurement of what success looks like.

The discovery path that works, and one that does not

If you are wiring an agent, use discover_agent_assets with kind: "mcpServers". It returns each server's slug, URL, transport and OAuth credential type.

Do not reach for a node search. Registry servers are excluded from search_nodes when you set usage: "agentTool", even though being agent tools is the whole point of them. We reproduced this with a control: searching "tavily", "railway" and "mapbox" with the filter returns "No nodes found", while the same three queries without it return @n8n/mcp-registry.tavily, .railway and .mapbox. Two separate discovery systems, and the obvious one is the wrong one.

Some limits worth knowing before you design around them. An agent accepts at most 20 MCP servers. Each entry takes a toolFilter with allow or exclude mode, an approval block set to global or a named list of tools requiring human sign-off, and a connectionTimeoutMs capped at 120000.

Use the approval block. It is the documented human-in-the-loop control for MCP tools, and an MCP server is third-party code calling your systems.

What your instance sends home

The registry catalog is not bundled. Your instance fetches it from https://api.n8n.io/api/mcp-servers and refreshes on a schedule. From the task definition: every 8 hours, cluster-scoped and durable, so it runs once per cluster rather than once per worker.

That is a modest, infrequent call carrying no workflow data, but it is an outbound call to a vendor endpoint on a schedule, which some people need to know about and air-gapped deployments need to handle.

On switching it off, be careful which feature you are switching off, because the names collide here too. The instance-level MCP server (number 4) has a documented control: Settings, then Instance-level MCP, then Enable MCP access, which needs owner or admin rights, and N8N_DISABLED_MODULES=mcp removes its endpoints and UI entirely. Disabling it disconnects every connected client and revokes access.

The registry is a different backend module, registered internally as mcp-registry. We did not verify that any documented setting stops its refresh specifically, and we are not going to guess at an environment variable and have you paste it into production. Part three already caught third-party guides citing n8n MCP environment variables that do not match the docs. If you need the registry off, confirm the module name against your own version first.

Why any of this exists: custom tools cannot reach the network

n8n Agents let you write a custom tool in TypeScript, which looks like it should make most of the above unnecessary. It does not, and the reason is worth knowing before you design around it.

We gave a test agent a custom tool whose only job was to fetch the registry catalog over HTTPS. The agent called it correctly and got back:

{"error": "fetch is not available in the sandbox."}

Custom tools run sandboxed, with only the @n8n/agents and zod imports available and no outbound network. They are for computation, not for talking to the outside world.

Swapping that custom tool for an HTTP Request node tool, pointed at the same URL, worked first time and returned the full catalog. That is the division of labour: custom tools compute, node and workflow tools and MCP servers reach outward. If your agent needs a remote service, one of the five features in this article is how it gets there.

Which one do you actually want

Is it open source

n8n is source-available under the Sustainable Use Licence, which we covered in part one. That piece teaches a check: code in .ee paths sits outside that licence and needs a commercial key.

Both MCP modules pass. packages/cli/src/modules/mcp-registry/ and packages/cli/src/modules/mcp/ carry no .ee suffix, while siblings ldap.ee, external-secrets.ee, log-streaming.ee, source-control.ee and provisioning.ee all do. Every MCP feature here is Sustainable Use code, available on self-hosted Community.

Which version you need

The capability filter shipped in 2.41.0 (2026-09-22). npm's latest and stable both resolve to 2.41.5. The 2.42.x line is published as beta, so if you read elsewhere that 2.42 is the current release, check the tag before you pin it.

Dates worth having: instance-level MCP went generally available in 2.33.0, registry search reached the Assistant in 2.35.0, the Server Trigger gained an Instructions field in 2.36.0, registry remotes gained custom headers in 2.40.0, and 2.42.0 removed the MCP Registry feature flag from the Assistant.

Sources and further reading

• n8n docs: MCP servers and the registry
• n8n docs: connect to the n8n MCP server
• The mcp-registry module source
• n8n release notes
• Model Context Protocol specification

Ten minutes: run the two curl commands above against the registry API. You will know today's real server count, whether anything new has been gated to Cloud since we published, and whether the service you were hoping for is in the catalog at all. None of it needs an n8n instance running.

Tested on: a self-hosted n8n instance running the instance-level MCP server v1.2.0, protocol 2025-06-18, with the Agents module enabled. Exact n8n version not pinned; the ElevenLabs capability filter was active, which requires 2.41.0 or newer. Registry counts were taken from the public api.n8n.io catalog API and then independently reproduced by a live n8n Agent running Claude Sonnet 5 on that instance, which returned the same 77 servers, the same 74 oauth2 / 2 extendsCredential / 1 usesCredentials split, and ElevenLabs as the only capability-gated entry. Source claims were read from the public master tree. The agent used to test validation against a non-existent MCP server was deleted afterwards.
Date tested: 2026-10-01