Insight ·

MCP just became boring, and that is the whole point

The 2026-07-28 specification is the largest revision since launch: a stateless core, server rendered interfaces and long running tasks. A protocol becoming unremarkable is what makes it safe to build on.

MCP just became boring, and that is the whole point

From experiment to plumbing

Anthropic released the Model Context Protocol in November 2024 as an open experiment in connecting models to tools. In December 2025 it was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI. Ownership moved from one company's roadmap to a community process.

The 2026-07-28 specification is the first large release under that arrangement, and the biggest revision since launch.

What changed

Three parts matter for anyone running systems rather than writing them.

  • A stateless core. The protocol no longer assumes a long lived session. Servers scale on ordinary HTTP infrastructure, which means the load balancer, the cache and the autoscaler you already operate are the ones you use.
  • MCP Apps. Servers can return rendered interfaces, not only text and data, so a tool can hand back a form or a table instead of asking a model to describe one.
  • A Tasks extension. Long running work gets a first class representation, so a job that takes four minutes stops pretending to be a request that takes four seconds.

Authorization also moved closer to how organisations already work, aligning with OAuth and OpenID Connect rather than inventing a parallel scheme.

Why boring is the compliment

Version negotiation lets old and new implementations interoperate rather than fork, and date based versioning marks this as the last backwards incompatible change. Both are signals of a protocol that has stopped optimising for novelty and started optimising for the people who keep it running.

That shift is what makes an integration a reasonable thing to own. The question stops being whether the standard survives the year and becomes whether your server is well built.

What it means for your own systems

If your CRM, your order system or your internal knowledge base is reachable through a documented MCP server, any assistant your team is permitted to use can reach it under your rules, and changing model vendors stops being a rewrite. If it is not, every new assistant becomes a fresh integration project.

The order of work has not changed:

  1. Decide which systems an agent may read and which it may write.
  2. Put authentication and audit in front of both, not behind them.
  3. Expose the read paths first, and only then the actions that move money or send messages.

The part nobody puts in the announcement

A protocol does not give you permissions, logging or a rollback story. Teams adopting MCP report the same recurring problems: audit trails, single sign on, gateway behaviour and configuration portability. Those remain yours to solve however good the specification is.

That is the honest reading of a maturing standard. It removes the integration argument and leaves the operational one, which was always the harder half.