MCP just got simpler. Here is what changed, and what it means if you own a WordPress site.

MCP's 28 July 2026 specification removes some ceremony from connecting an AI assistant to a server. A server can work without maintaining a session, a client can ask what it supports before doing anything else, and a client can identify itself with a URL instead of registering a new opaque ID first. Respira supports the new path while keeping existing connections working.

The short version

Nothing you already connected needs to be rebuilt. Older MCP clients still get the session-based transport they expect. Clients speaking the 2026-07-28 protocol can use the stateless path, discover the server's capabilities, and complete OAuth with client metadata published at their own URL.

If those terms mean nothing to you, that is fine. The practical change is that the setup page can do more of the choosing. Pick your assistant, pick your site, and Respira shows the right route. If you do not know which assistant or route applies, the new “not sure yet” option starts with the simplest checks.

1. Sessions are optional

The previous HTTP flow normally started with initialize, then carried an Mcp-Session-Id through later requests. That remains useful for servers with state to preserve. It is no longer required for a server that can answer each request independently.

Respira's WordPress endpoint can now answer a 2026-07-28 request without issuing a session ID. Each request still passes through the same authentication, capability checks and audit trail. This changes transport bookkeeping, not the safety model around the site.

2. Clients can discover a server before initializing it

The new server/discover method gives a client a small, predictable description of the server: its identity, supported protocol versions and capabilities. It is the protocol equivalent of reading the label before opening the box.

Respira reports both the new stateless version and the established 2025-11-25 version. A modern client can choose the newer route. An existing client can continue with the route it already understands.

3. OAuth clients can identify themselves with a document URL

MCP OAuth previously leaned on dynamic client registration for clients that did not have a pre-arranged ID. The new Client ID Metadata Document path lets a client use an HTTPS URL as its ID. The document at that exact URL declares its name, redirect addresses and supported OAuth behavior.

Respira's authorization server now accepts that URL form after validating the document and its redirect addresses. Registered opaque client IDs still work, and dynamic registration remains available for backwards compatibility. Supporting a new standard should not turn yesterday's working setup into today's repair job.

Two deeper changes for client and server authors

Server-to-client requests are now expressed as multi-round-trip results. Instead of opening a second request channel for sampling, elicitation or roots, the server returns the input it needs and the client retries the original operation with that input. The protocol calls this MRTR. It keeps the exchange attached to the operation that asked for it.

The old standalone HTTP GET event stream is removed from this revision, and the earlier HTTP+SSE transport is formally deprecated. Streamable HTTP remains the current HTTP transport. A server that needs an ongoing notification stream asks for one through subscriptions/listen, while ordinary calls stay self-contained POST requests.

What this means when you connect WordPress

The setup experience now waits for real proof. Respira checks that the WordPress REST endpoint is healthy before revealing a connector URL, then watches for the first successful tool call. “Connected” means a tool actually reached the selected site, not merely that a configuration string was copied.

This also makes support less ambiguous. The connection event records whether setup came from a dashboard command, a Cursor install link, a manual config, native OAuth or a native API key. It records the route, not prompts or WordPress content.

The compatibility promise

Protocol changes arrive unevenly. Desktop apps, coding agents, hosted assistants and WordPress plugins do not all update on the same morning. Respira therefore negotiates the path instead of forcing one:

• 2026-07-28 clients get stateless requests and server/discover.
• 2025-11-25 clients keep the established session-based transport.
• URL client metadata and registered client IDs are both accepted.
• Existing connector URLs and scoped keys keep working.

The specification details live in the official MCP 2026-07-28 specification, with the stateless design in SEP-2575. The useful outcome is smaller: fewer connection rituals, clearer capability negotiation, and no migration chore for people who were already connected.

Try the connection check

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 will change from waiting to connected when the site answers successfully.

mihai