MCP 2026-07-28 is final. What changes for WordPress and Respira?

The MCP 2026-07-28 specification is now final. It is the largest protocol revision since MCP launched: the core becomes stateless, every request carries its own negotiation context, servers gain a discovery method, authorization gets stricter, and long-running tasks and interactive apps move into extensions.

For somebody using Respira to connect Claude, ChatGPT, Cursor, Codex, or another assistant to WordPress, the immediate instruction is pleasantly short: do not rebuild a working connection. The new specification is versioned. Existing clients and servers can keep negotiating an earlier supported revision while implementations adopt the new wire protocol.

Photo by Growtika on Unsplash.

The short version

• MCP 2026-07-28 is stable. The final tag was published on 28 July 2026.
• It contains breaking wire-protocol changes. A server must not advertise the new revision until it implements those changes.
• Existing Respira connections keep working. MCP server 8.1 uses the official TypeScript SDK 2 packages while preserving the legacy initialize path.
• The SDK 2 migration is shipped and tested. The release suite verifies an exact MCP 2026-07-28 negotiation and a separate legacy-client connection against the same packaged server and tool catalog.
• Webflow MCP 2.0 is a Webflow product version. It is not the name of the MCP 2026-07-28 protocol revision.

1. The protocol is stateless now

Earlier MCP revisions begin with initialize, then may carry an Mcp-Session-Id through later Streamable HTTP requests. In MCP 2026-07-28, the protocol-level session and initialization handshake are gone.

Each request identifies its protocol version and client capabilities in _meta. A client should also identify itself on each request, and a server should identify itself in each result. Applications may still preserve state, but that state must travel through explicit handles such as a task ID, browser ID, or remediation ID instead of an invisible protocol session.

This is especially useful for hosted MCP servers. Requests can reach any healthy instance behind a normal load balancer without sticky routing or a shared session store. Respira’s current public MCP package runs locally over stdio, so this does not change the HTTPS request it makes from the MCP process to the selected WordPress site.

2. Servers must describe themselves before work begins

The new server/discover method tells a client which protocol revisions and capabilities a server supports. A client can call it before any tool operation, select a compatible revision, and fail with a specific unsupported-version error instead of guessing.

Respira 8.1 adopts discovery through the official SDK 2 server packages rather than hand-building a lookalike method on top of SDK 1.x. Protocol support includes the complete request and result contract, not one recognizable RPC name.

3. Results, tool lists, and long-running work are more explicit

Ordinary results now carry resultType: "complete". When a tool needs more information, it can return an input_required result and let the client retry with the requested input. This replaces the old pattern of a server opening a second request back to the client.

Tool, prompt, and resource lists gain explicit cache lifetime and scope fields. Tool ordering should be deterministic so clients can cache the list and reuse model prompt prefixes efficiently. Long-running Tasks, Skills over MCP, and MCP Apps are now independently negotiated extensions instead of reasons to keep expanding the core protocol.

Respira already returned structured tool content and used explicit site and remediation identifiers. Version 8.1 adds the new result envelope, discovery response, cache semantics, server identity metadata, and dual-era release tests required to advertise MCP 2026-07-28.

4. Authorization gets stricter, not more magical

The final revision tightens issuer handling and client registration. Clients must bind stored credentials to the authorization server that issued them, validate an authorization response’s issuer when present, and avoid reusing credentials when the issuer changes. Client ID Metadata Documents become the preferred registration mechanism, while Dynamic Client Registration remains available for compatibility.

Respira’s local stdio server does not expose a public MCP OAuth resource server today. It authenticates the separate WordPress REST request with a scoped site credential. That boundary remains valid. If Respira adds a hosted Streamable HTTP MCP endpoint, it must implement the official protected-resource metadata and bearer-token requirements rather than passing WordPress credentials through the MCP transport.

What Webflow MCP 2.0 gets right

Webflow shipped its own product release called Webflow MCP 2.0 one week before the final protocol revision. The similar names are coincidental: Webflow’s 2.0 is a version of its MCP product, not version 2.0 of the open protocol.

The useful news is not the number. It is what Webflow treats as necessary before an agent works on a visible production website:

• existing workspace roles and permissions apply to agent actions;
• agent changes appear in the site audit log with attribution;
• teams can work on branches before publishing;
• site-specific Agent Instructions carry brand rules and working conventions;
• analytics can move from an observation to an agent workflow.

Webflow’s official launch article frames governance, brand control, and analytics as the difference between an experiment and production infrastructure. That is strong validation for the WordPress agency market too. The buyer is not purchasing an AI connection. The buyer is purchasing controlled execution: who may act, which site they may touch, what the agent changed, how the work is reviewed, and whether it can be verified or reversed.

Respira already has scoped API-key profiles, team and site boundaries, approval gates, duplicate-before-edit behavior, snapshots, audit logs, site-specific skills, accessibility remediation, and security verification receipts. The standard and Webflow’s launch both point toward the same next layer: stronger actor attribution, automatically supplied site rules, branch-like review for large changes, and analytics that can open an approved fixing path.

What Respira 8.1 implements

1. The official SDK 2 packages replace the monolithic SDK 1.x package. Respira uses the new server, client, schema, and stdio entry points.
2. Both protocol eras are served. New clients can negotiate 2026-07-28 through server/discover; existing clients continue through the legacy initialize path.
3. The SDK supplies the complete 2026 result contract. That includes typed results, server identity metadata, structured validation, and supported-version errors.
4. Tool discovery remains deterministic and private. The catalog keeps a stable order and user-specific results are not treated as shared public cache data.
5. Deprecated protocol features are not part of new Respira work. Diagnostics stay on stderr; explicit tool parameters carry site and workflow context.
6. The release test runs the packaged stdio server in both modes. It pins an exact 2026-07-28 connection and separately verifies that a legacy client can initialize and enumerate the same release catalog.

What WordPress users should do now

Keep your current connection and update Respira through the normal release channel. Do not replace connector URLs, regenerate site keys, or edit WordPress settings merely because the protocol has a new date.

The more important test is still concrete: can the assistant identify the selected site, read its current state, respect the credential’s scope, ask before a sensitive change, and return an audit receipt? Protocol conformance makes that connection interoperable. Product governance makes it safe to trust.

Official sources

• MCP 2026-07-28 stable release
• MCP 2026-07-28 specification
• Official key changes from 2025-11-25
• Official TypeScript SDK releases
• Webflow MCP 2.0 technical changelog
• Webflow’s official governance announcement

Check your current connection

Open API keys and MCP, choose an assistant and a site, then follow the setup card. Leave the page open for the first call. It should change from waiting to connected only when the selected WordPress site answers successfully.

mihai