On 28 July 2026 the Model Context Protocol publishes its 2026-07-28 revision. The maintainers call it the largest revision of the protocol since launch, and that is not marketing: it removes the initialize handshake, removes protocol-level sessions, deprecates three features that have been there since the beginning, and changes how a server asks a client for anything.
The release candidate was locked on 21 May, so what ships is known. What almost nobody has written is what it means if the thing on the other end of that protocol is a WordPress site. That’s this brief.
The one number that matters
The official WordPress MCP Adapter — the core AI team’s plugin, the path WordPress is steering self-hosted sites toward — states that its HTTP transport implements MCP 2025-11-25. That is the revision 2026-07-28 supersedes.
This is not a criticism of the adapter. The release candidate locked in May, the adapter is a 0.x project with a documented breaking change in its own last two releases, and shipping against a spec that isn’t final yet would be the wrong call. But it does mean the honest answer to “is WordPress ready for the new MCP spec?” on 28 July is: the official adapter targets the previous revision, and there is migration work between here and there.
It’s also the only WordPress MCP server that publicly states a target revision at all. We checked all four in our registry; the other three don’t document one. That’s worth knowing before you build anything load-bearing on top of them.
What actually changes
The protocol becomes stateless. The initialize / notifications/initialized handshake is gone. So is the Mcp-Session-Id header and protocol-level sessions entirely. Every request now carries its own protocol version and client capabilities in _meta. A new server/discover RPC — which servers must implement — advertises supported versions and capabilities up front.
For WordPress this is mostly good news, and it’s worth being specific about why. A stateless protocol over ordinary HTTP POSTs is a far better fit for how WordPress is actually hosted than a session-bound one. No session affinity means no sticky-session requirement, which means a WordPress site behind a load balancer, or on shared hosting where consecutive requests may not hit the same PHP worker, stops being a special case. Servers that genuinely need cross-call state are expected to mint their own handles and pass them as ordinary tool arguments.
Server-initiated requests are replaced by MRTR. Previously a server could call back to the client — roots/list, sampling/createMessage, elicitation/create. Under Multi Round-Trip Requests, the server instead returns an InputRequiredResult (resultType: "input_required") listing what it needs, and the client retries the original request with inputResponses attached. Every result now carries a required resultType field; results from older servers that omit it must be treated as "complete".
Three features are deprecated: Roots, Sampling and Logging. They keep working — the new deprecation policy guarantees a minimum twelve-month window — but new implementations shouldn’t adopt them. The suggested migrations are to pass files via tool parameters or resource URIs instead of Roots, integrate with a provider API directly instead of Sampling, and log to stderr or OpenTelemetry instead of Logging.
HTTP+SSE is now formally Deprecated. It has been soft-deprecated since 2025-03-26; this revision reclassifies it under the new lifecycle policy. Anything still on the old SSE transport should move to Streamable HTTP. Separately, SSE stream resumability and message redelivery are removed from Streamable HTTP too — no more Last-Event-ID, and a broken stream means the in-flight request is lost and must be re-issued with a new request ID.
Authorization gets stricter, and this is the part that will bite quietly. OAuth 2.0 Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents. Authorization servers should include the iss parameter in responses per RFC 9207, and clients must validate it before redeeming an authorization code. Client credentials are now explicitly bound to the issuer that minted them: clients must key them by issuer, must not reuse them against a different authorization server, and must re-register when it changes.
Error codes were renumbered. The spec now partitions the JSON-RPC server-error range, reserving -32020 to -32099 for MCP itself. Codes introduced in this draft moved: HeaderMismatch -32001 → -32020, MissingRequiredClientCapability -32003 → -32021, UnsupportedProtocolVersion -32004 → -32022. Resource-not-found also moves from -32002 to -32602 to line up with JSON-RPC’s Invalid Params. If you have error handling keyed to the old numbers, it is now wrong.
What this means per server
| Server | Targets | Auth | Exposure |
|---|---|---|---|
| WordPress MCP Adapter | 2025-11-25 | Application Passwords | Handshake and session removal; needs a server/discover implementation |
| WordPress.com MCP | Undocumented | OAuth 2.1 + PKCE | The authorization hardening — DCR deprecation, iss validation, issuer binding |
| AI Engine MCP | Undocumented | OAuth 2.1 / Bearer | Both the transport changes and the OAuth changes |
| WordPress.org Plugin Directory MCP | Undocumented | Application Password | Built on the Abilities API and MCP Adapter, so it inherits the adapter’s position |
The hosted servers — WordPress.com’s and WordPress.org’s — will be migrated by their operators, and you will not have to do anything. The self-hosted path is where the work lands: if you run the MCP Adapter on your own site, you own the upgrade.
What the coverage elsewhere is getting wrong
Two things worth correcting, because both are circulating.
MCP Apps is not part of the core protocol. It ships alongside the 2026-07-28 revision as an official extension, and the release-candidate announcement is explicit that extensions sit beyond the core. The core changelog for this revision doesn’t mention MCP Apps at all — what it does mention is a new extensions field on client and server capabilities, and the Tasks feature being moved out of core into an extension of its own. If you read “MCP Apps ships in the new spec” and concluded your server has to implement it, it doesn’t.
The spec is not out yet. As of this writing it is a release candidate, locked since 21 May, publishing on 28 July. Several write-ups describe it in the past tense. The distinction matters if you’re deciding whether to build against it today.
What to actually do
If you run WordPress and you’re using MCP:
- Nothing urgent, if you’re on a hosted server. WordPress.com and WordPress.org operate their own; migration is theirs.
- If you self-host the MCP Adapter, watch its releases rather than the spec. The adapter is pre-1.0 and has already shipped breaking changes in v0.3.0 and v0.5.0, each with a migration guide. That’s the channel that will tell you when to move.
- Audit your error handling now. The renumbering is the cheapest thing to get wrong and the easiest to fix ahead of time.
- If you built anything on Roots, Sampling or Logging, start planning. Twelve months is generous, and it is still a clock.
- If you wrote your own OAuth client against a WordPress MCP endpoint, read the authorization section properly. Issuer binding and
issvalidation are security requirements, not style preferences.
The larger point
WordPress spent 2026 positioning itself as, in Automattic’s words, the operating system of the agentic web. The Abilities API and the MCP Adapter are real infrastructure toward that, and the WordPress.org Plugin Directory shipping its own MCP server in March was a genuine signal of intent.
A stateless protocol is a better foundation for that ambition than the one it replaces — it fits WordPress’s hosting reality far better. But the gap between “the spec ships on 28 July” and “the official WordPress adapter targets the previous revision” is the actual state of play today, and it’s more useful to say so than to describe the ecosystem as further along than it is.
We track every WordPress MCP server we can verify, including which spec revision each one documents, in the MCP server registry.