# MCP's Second Spec: Reopening the Ledger

> Ten months ago I wrote down what was working in MCP and what wasn't, and named two gaps. The 2026-07-28 spec shipped in July and it is wire-incompatible in both directions. One gap closed by leaving the protocol. The other has not moved. And one thing I said was already false when I published it.

Author: Abdul Hannan Shaikh, senior technical PM at APIMatic.
Published: 16 August 2026  
Topic: Agent-readiness  
Reading time: 12 min read  
Canonical: https://soch.ahshaikh.com/blog/mcp-second-spec-reopening-the-ledger/

---

The 2026-07-28 spec isn't a release candidate any more. It shipped on 28 July, on the date it's named after, ten weeks after the candidate was locked in May. It was filed in my head as still-forthcoming, which tells you something about how closely most of us follow a protocol we depend on.

In October last year I published [an honest ledger of MCP's first year](/blog/one-year-of-mcp-whats-working/): what worked, what didn't, and four things I wanted from year two. This is that ledger reopened. It includes the part where I was wrong about something that had already happened.

Disclosure, same as last time: I'm the PM for an MCP-based product at APIMatic, so weigh what follows against a commercial interest in MCP being good.

## Start with the error, because it's the interesting one

Here's what I wrote in October:

> There's no canonical MCP registry. The closest things are loose lists on GitHub and a few independent directories. I expect a foundation move on this in the next twelve months.

The official MCP Registry launched in preview on 8 September 2025. That's thirty days before I published. The work had been running since February and was signalled publicly in March. So I confidently forecast a thing that had already shipped, and described a landscape that had changed the previous month, and nobody wrote in.

The foundation move also happened, two months after the essay rather than twelve. Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation on 9 December 2025, with AWS, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI as founding platinum members alongside them.

What saves the paragraph, without over-claiming it, is that the sentence underneath the wrong fact still holds. The question underneath was this: when your agent wants to talk to Stripe, which server is the real one, and who says so? The registry answers half of that. It does namespace authentication, so `com.stripe/` is verified against DNS or GitHub and a fork can't squat it, and that's a genuine trust primitive. It declines the other half explicitly. From its own documentation: the metadata is "deliberately unopinionated", downstream aggregators "can provide curation", and the registry "is not intended to be directly consumed by host applications."

It's also, eleven months after launch, still carrying a preview banner warning that breaking changes or data resets may occur. A full pagination of the public API while writing this, on 16 August, returns 22,048 latest-version server records. That's a real index at real scale with a preview label on it and no announced general availability.

So: I was wrong about the fact and right about the thing the fact was standing in for. That's a worse mistake than being wrong outright, because the conclusion was correct and nothing forced me to check.

## The ledger

| What I said in October 2025 | Where it stands | Verdict |
| --- | --- | --- |
| Auth is a mess; enterprise identity is custom work every time | Enterprise-Managed Authorization went stable 18 June 2026. Built on the IETF ID-JAG draft: the client gets an assertion from the identity provider during SSO and exchanges it at the server's authorization server. No per-server consent screen. | Closedby moving out of the core protocol |
| Discovery is unsolved; there's no canonical registry | There was one, a month before I wrote that. 22,048 records today, still in preview, and it deliberately doesn't curate or rank. Server Cards, which would let a crawler read a server's capabilities without connecting, are still on the roadmap. | Partlythe index exists, the judgement doesn't |
| Production-grade context is rarer than it looks | Nothing in this spec touches it. The nearest work is the Skills over MCP working group, which became a working group in April 2026; its extension proposal is in review with no target date. | Openunmoved in ten months |
| Ask: community-shared server-quality evals | A conformance suite shipped, plus an SDK tier system. Both score SDKs against the protocol. Neither asks whether a server helps an agent finish a real task. | Openthe wrong thing got measured |
| The protocol is small enough to implement in a weekend | Java is a Tier 2 SDK with a six-month allowance. Its 2026-07-28 design issue was opened on 13 August 2026, days before this went up, and is at design stage. | No longer true |
| JSON-RPC and STDIO simplicity is the moat | This release moves MCP toward ordinary HTTP: stateless core, cache TTLs modelled on Cache-Control, header-based routing, standard JSON-RPC error codes replacing custom ones. | Conceded |
| Year two is where the gap between "works" and "useful" gets noticed | The 2026 roadmap's own words: "Enterprises are deploying MCP at scale and hitting gaps the protocol does not yet address." | Held |

*Every claim and ask from the October 2025 essay, scored against the 2026-07-28 specification and the state of the ecosystem on 16 August 2026. Two closed, one partly, two open, and two of my own framings that the release has quietly overruled.*

> **Diagram.** The two gaps, redrawn ten months later A diagram in two halves. On the left, October 2025: a single box labelled the MCP protocol contains both gaps, gap one being enterprise auth at the transport edge and gap two being context quality inside the tools, resources and prompts. On the right, August 2026: the same box, with the auth gap now drawn outside it and labelled as solved by an extension built on an IETF identity draft and single sign-on, while the context-quality gap remains exactly where it was, inside the box. The caption notes that one gap was closed by leaving the protocol and the other is still there because nobody has found a way to leave.

*The October essay's own argument was that the two gaps sat at different boundaries, and that this was the point. It still is, but the boundary itself moved. Enterprise auth got solved by an identity standard plus an identity provider, with MCP holding the coat. Context quality has no equivalent layer to hand it to.*

## Auth got fixed by leaving

This is the genuinely interesting part, and it isn't the one the release notes lead with.

The core spec did harden authorization properly. Six separate proposals went in. Clients now validate the issuer parameter, which closes a whole class of mix-up attack. Credentials are bound to the authorization server that issued them. Dynamic Client Registration, which had known problems, is formally deprecated in favour of Client ID Metadata Documents. Servers are now OAuth 2.1 resource servers with discoverable protected-resource metadata, so a client stops guessing where to authenticate.

All useful, and none of it is the answer to the complaint. The complaint was that connecting your MCP server to an enterprise identity system was bespoke work every single time. The answer to that shipped six weeks before the spec did, as an *extension*, and it's mostly not MCP. Enterprise-Managed Authorization leans on an IETF identity draft and on the identity provider already doing single sign-on. Okta's Aaron Parecki described the result as turning "identity into a centralized governance plane", which is an identity-industry sentence and is also exactly right: the protocol stopped trying to own the problem and handed it to the layer that already owns it.

One caution before anybody puts this in a plan. The announcement names Anthropic's Claude surfaces and VS Code as clients and lists Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase as servers. The official client support matrix, which is community-maintained, currently shows exactly one client with the extension implemented. Both of those can be true at once, because the matrix lags and vendor posts run ahead. So if you're choosing between "the spec supports it" and "the client my users actually run supports it", which one has a date on it?

## The gap that hasn't moved at all

Context quality. Ten months, one major release, four SDK generations, and it's exactly where it was.

What October described was that the protocol gives you a connection, not substance, and that plenty of production servers expose tools whose descriptions don't tell an agent when to use them and whose errors don't tell it what to do next. Nothing in 2026-07-28 addresses that, and I don't think it's a criticism of the spec. It isn't a protocol problem. It's a documentation and product problem wearing a protocol costume, which is the same thing I keep arguing about API specs.

What has happened instead is that the complaint has grown a second head, and this one is measurable. Tool metadata across a couple of dozen connected servers eats a serious fraction of the context window before the model has reasoned about anything. Stateless transport does nothing for that. If anything it makes it slightly worse, because the client now re-sends capability information on every request.

The Skills over MCP working group is the place this is being worked on, and it converted from an interest group in April 2026. Its extension proposal is still in review. Ask me again in ten months.

## What actually shipped, and why your server may not survive it

Three changes matter more than the headline features, and the third one is going to hurt people.

**The protocol is stateless now.** The initialize handshake is gone. The session header is gone. Protocol version and client capabilities travel in metadata on every request, and there's a new discovery call servers must implement. Practically, a server can sit behind a plain round-robin load balancer with no sticky routing and no shared session store. Supabase's Inian Parameshwaran made the trade concrete: they run stateless, so features that assumed a session were off the table for them until this landed.

**Server-initiated requests were replaced.** Instead of a server calling back into the client to ask a question, a tool call can now return "input required" along with an opaque state blob, and the client re-issues the original call with the answers. It's a cleaner shape. It also means that blob round-trips through the client, and the security researchers at Equixly have already pointed out the consequence: it's attacker-controlled input by definition and needs integrity protection. Same for the explicit-handle pattern that replaces sessions, where a capability reference now travels through model context and is visible to anything that can influence the model's input.

**It's wire-incompatible in both directions.** A modern client can't talk to a legacy server. A legacy client can't talk to a modern server, and the spec says plainly that legacy clients have no fall-forward mechanism. Supporting both eras is allowed and not required. One aggregator operator, who indexes over sixty thousand open-source servers, put it bluntly on the day: many servers and clients will need refactoring, updating the SDK won't be enough, and it will be messy.

My own closing line in October was that everyone who built on the early shape "gets to rebuild their server next year". I meant it as a warning about auth. It came due for a different reason and on schedule.

The mitigating change is the one nobody will notice until they need it: there's finally a formal deprecation policy. Three states, and a minimum of twelve months between deprecating something and the earliest date it may be removed. Roots, sampling, logging, Dynamic Client Registration and the old SSE transport are all deprecated now, with the earliest removal in July 2027. Nothing has actually been removed under it yet. A protocol that breaks you twice and then writes down how it will warn you next time is a protocol growing up, and it's worth more than any of the new features.

## What I'd do this month if I ran a server

Check whether your SDK speaks 2026-07-28 before you plan anything else. The four Tier 1 SDKs do. If your server is on Java, Ruby, Swift, PHP or Kotlin, your timeline isn't yours, and your roadmap should say that out loud rather than absorbing the slip quietly.

Then decide, deliberately, whether you're dual-era. Supporting both is allowed and not required, which makes it a product decision about how much of your installed base you're willing to drop. Do you know what that number is? If nobody on your team can answer it, the decision still gets made, by default, by whoever ships next.

If you were relying on sessions, budget properly for the migration, because it isn't a config change. You're moving state into arguments the model carries, which is a design problem and a security one at the same time, and the security half is the one your review will skip. Whatever handle your tool mints is now visible to anything that can influence your model's input.

Then ask your team the question the spec can't answer for you: how would you know whether your own server is any good? Nobody can tell you. There are 22,048 of them in the official index, not one of them ranked, and the conformance suite will happily certify a useless server as perfectly conformant. That's the gap I'd like to be wrong about next October.