Model context protocol news: what's actually changed, and what hasn't

Most Model Context Protocol (MCP) news is noise. New servers, new clients, new gateways, new acronyms — and the same agent projects still stalling for the same reason. Our view: the protocol layer is maturing fast, but the part of the stack that actually decides whether your agent works in production isn't moving at the same pace. If you're tracking MCP updates 2026 to time an investment, here's what we think is worth your attention and what isn't.

The protocol is settling. That's good and boring

The Model Context Protocol, introduced by Anthropic in late 2024, has done what an open protocol should do in its second year: it's stopped being interesting. The transport story is clearer. Authentication has a sensible shape. Tool definitions, resources, and prompts have stabilised enough that SDKs don't churn weekly. OpenAI supporting MCP through the Responses API removed the last serious doubt about reach.

This is the most important item on any model context protocol roadmap, and it's also the least exciting. A protocol that gets boring is a protocol you can build on. We treat MCP that way — as plumbing, not a product strategy.

The gateway gold rush is hiding the real problem

The loudest segment of mcp ecosystem changes is the gateway layer. Portkey, Lunar.dev, MintMCP, Speakeasy's MCP Platform — every month brings another vendor offering to govern, route, observe, or secure MCP traffic. The pitches rhyme: registries, policy, auth, observability, multi-tenant fan-out.

We're not against any of this. Governance matters once you have something to govern. The problem is the framing. Gateways assume the tools already exist. They sit in front of MCP servers and broker access to them. For an established SaaS company with multiple products and an underpowered API layer, the gateway is solving the wrong end of the problem. You don't have an MCP traffic problem. You have a there is no MCP server worth fronting problem, because the underlying APIs don't expose what the agent needs to do.

A gateway in front of an empty room is still an empty room.

MCP servers are easy. Useful MCP servers are not

The second pattern dominating the news cycle: every SaaS vendor announcing an MCP server. Treat these announcements with the same scepticism you'd apply to any v1 API. A press release saying "we now support MCP" usually means a thin wrapper over the public REST API — which means the agent can reach exactly what the API already exposed, and nothing more.

That ceiling is the real story. Your APIs already expose a small fraction of what your product can do. Wrapping them in MCP doesn't change the ceiling — it changes the protocol. The agent still can't reach the 90%+ of product capability that only the UI knows how to drive.

If you're evaluating a vendor's MCP server, the only question that matters is: what fraction of the product's actual capability is reachable through it? Most answers, honestly given, are uncomfortable.

What we're watching that isn't getting headlines

Three shifts matter more than the gateway and server announcements, and none of them are trending:

• Auth lifecycle in MCP runtimes. Tool calls executing as the authenticated user, not a shared service account, is the difference between a demo and something you can put in front of a customer. Most of the ecosystem still hand-waves this.
• Tool maintenance at SaaS release cadence. A server published once and forgotten silently drifts as the product changes. The interesting work is in keeping tools current as part of the SDLC.
• Generation, not curation. Hand-curated tool catalogues don't scale across a multi-product portfolio. The teams getting somewhere are generating tools from the codebases they already own, not from OpenAPI specs they wish they had.

These are the items that decide whether an agent project ships. They're also the ones least likely to appear in a vendor announcement, because they're harder to build than a wrapper.

How Pontil fits

We build at the layer underneath the protocol conversation. Pontil is a Tools-as-a-Service platform — we generate, run, and maintain the tools agents invoke against your own products. MCP is one of the protocols we speak. It isn't the point.

The point is that the tools layer has to do four things the gateway and server announcements mostly skip: reach the capability your existing APIs don't expose, execute as the authenticated user with the right permissions, stay current as your products change, and compound across a portfolio rather than per-product. Get those right and the protocol choice becomes a trivial configuration. Get them wrong and no amount of MCP news fixes the stall. If you want to see what that looks like against your own stack, book a working session.

What to do with this

Stop tracking MCP news as a signal of progress on your agent project. The protocol is fine. The ecosystem around it is doing what ecosystems do — fragmenting, consolidating, and producing more vendors than the problem strictly requires. None of that movement will unstick a project that's blocked on capability access.

If your agent work has stalled, the question to answer this quarter isn't which MCP gateway do we pick. It's what fraction of our product's real capability can an agent actually reach today, and what's the credible path to closing that gap before the rewrite finishes in three years. Answer that honestly and most of the news cycle stops mattering.