22 September 20263 min read

MCP quietly became the standard — and n8n speaks it in both directions

Two years ago it was an Anthropic protocol. Now it sits under the Linux Foundation, OpenAI and Google ship it, and your n8n instance can be both ends of it.

The short version

MCP — the Model Context Protocol — is a plug. One side is an AI model, the other side is a tool: your calendar, your database, a workflow. Before it, every model vendor had its own way of describing tools, and every integration was written twice.

Anthropic published it in November 2024. In December 2025 it was donated to the Agentic AI Foundation under the Linux Foundation, with OpenAI and Block as co-founders and AWS, Google, Microsoft, Cloudflare and Bloomberg joining as platinum members. That is the part that matters for anyone deciding where to spend a weekend: it is not one vendor's protocol any more.

What changed this summer

The 2026-07-28 specification is the biggest revision so far, and it is mostly about making MCP boring enough for production:

  • Stateless core. The initialize/initialized handshake and session IDs are gone. A call is a request and a response, which means it survives load balancers, serverless functions and restarts without special handling.
  • Header-based routing. Method and tool names travel in Mcp-Method and Mcp-Name HTTP headers, so a gateway can route and authorise without parsing the body.
  • Multi round-trip requests. A server can answer resultType: "input_required" and ask for something mid-call — an approval, a missing field — without holding a stream open.
  • Cacheable listings. Tool and resource lists carry ttlMs and cacheScope, so a client stops re-asking what your server offers on every single turn.
  • Auth hardening. Issuer validation per RFC 9207, and Dynamic Client Registration formally deprecated in favour of Client ID Metadata Documents.

Deprecated with a twelve-month support window: roots, sampling and logging, plus the legacy HTTP+SSE transport. If something you run uses HTTP+SSE, that is now a dated item on a list, not a preference.

Where n8n fits

n8n speaks MCP in both directions, and the two directions solve different problems.

As a client, n8n consumes someone else's MCP server as a tool inside an AI Agent node. No custom node, no REST wrapper — if a vendor ships an MCP server, your agent can use it.

As a server, the MCP Server Trigger turns your own workflows into tools that any MCP client can call — including the assistant you already have open. A September 2026 update added an Instructions field whose text is handed to connecting clients, which is the difference between an agent that guesses what your tool does and one that is told.

That second direction is the interesting one for a small business, and it is easy to miss. The workflow you built to look up a client's order history stops being something you trigger and becomes something you can ask for.

When not to use it

MCP is for cases where a model decides what to call. That is the entire value, and also the entire cost: a model deciding means a model can decide wrong.

If the job is "when a form is submitted, write a row and send a confirmation", that is a webhook and a workflow. It runs the same way a thousand times, it costs nothing per run, and no prompt can talk it into doing something else. Putting a model in the middle of a deterministic path buys unpredictability at a premium.

The rule that has held up: MCP for questions, webhooks for events. Anything that starts with a human asking something open-ended is a good tool call. Anything that starts with a system emitting a known event should stay a plain path — and if it ends in a message to a real person, it should end in a draft.

Sources

← All posts Every claim here links to its source.
Pre-launch

Hourbench builds the workflows these posts talk about.

The Automation Vault is 20 ready-to-run n8n workflows plus a bonus one. It is built and installable, and in final testing against real accounts before it goes on sale.

See what's coming →