MCP 2026-07-28: The Protocol Goes Stateless

If you have ever operated a remote MCP server, you know which part hurts: sessions.

A client connects, sends initialize, and receives an Mcp-Session-Id. Every request after that has to carry it. Behind a load balancer, that means sticky routing. It means server memory tied to a connection that can disappear without warning. It means tools/list may answer differently depending on who is asking and when, so almost nothing the server returns is safely cacheable.

The Model Context Protocol revision published on July 28, 2026 removes that model. Search1API's Hosted MCP speaks it today.

What actually changed

This is not a maintenance release. The 2026-07-28 revision reshapes the base protocol:

• Sessions are gone. Protocol-level sessions and the Mcp-Session-Id header are removed from the Streamable HTTP transport. A server that genuinely needs cross-call state now mints an explicit handle and passes it as an ordinary tool argument, where it is visible instead of hidden in transport metadata.
• The handshake is gone. There is no more initialize and notifications/initialized. Every request carries its own protocol version and client capabilities in _meta, under io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities. Servers identify themselves back in each result's _meta.
• `server/discover` is new and mandatory. Servers must implement it so a client can ask, before anything else, which protocol versions and capabilities are on offer.
• Subscriptions replace the GET endpoint. A single long-lived subscriptions/listen POST stream replaces the HTTP GET channel and resources/subscribe. Clients opt in to specific notification types.
• Server-initiated requests are replaced by MRTR. Instead of the server calling back into the client with sampling/createMessage or elicitation/create, a result can come back with resultType: "input_required" and a list of what it still needs. The client retries the original request with the answers attached.
• Several methods are retired. ping, logging/setLevel, and notifications/roots/list_changed are gone. Log level is now set per request in _meta. Tasks moved out of the core protocol into an official extension.

Taken together, the shape of an MCP server changes. List endpoints no longer vary per connection. Any node can answer any request. The protocol looks much more like ordinary HTTP and much less like a stateful RPC session.

What this means if you run a hosted MCP server

The stateless model is a real simplification, but it moves work rather than deleting it.

You no longer need sticky routing, session tables, or reconnection logic that rebuilds context. You do need to validate a _meta envelope on every single request, because the version negotiation that used to happen once at initialize now happens continuously. A request that omits io.modelcontextprotocol/clientCapabilities is not a slightly incomplete request; it is invalid, and the server has to say so precisely enough that the client can fix it.

That is the part worth budgeting for. The removal of sessions is the headline, but per-request envelope validation is the work.

Talking to Search1API's Hosted MCP

Search1API runs a hosted MCP server at https://mcp.search1api.com/mcp. It reports 2026-07-28 support through server/discover, and you can check that yourself:

curl -sS -X POST https://mcp.search1api.com/mcp \
  -H "Authorization: Bearer $SEARCH1API_KEY" \
  -H "Mcp-Method: server/discover" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "server/discover",
    "params": {
      "_meta": {
        "io.modelcontextprotocol/protocolVersion": "2026-07-28",
        "io.modelcontextprotocol/clientInfo": { "name": "my-client", "version": "1.0.0" },
        "io.modelcontextprotocol/clientCapabilities": {}
      }
    }
  }'

The response reports the supported versions, the server capabilities, and the server identity in _meta:

{
  "result": {
    "supportedVersions": ["2026-07-28"],
    "capabilities": { "tools": { "listChanged": true }, "resources": { "listChanged": true } },
    "resultType": "complete",
    "_meta": {
      "io.modelcontextprotocol/serverInfo": { "name": "search1api-server", "version": "0.5.1" }
    }
  }
}

Swap the Mcp-Method header and the method field for tools/list and the same envelope returns the live tools: search, news, crawl, sitemap, and trending. No handshake, no session id, no connection to keep alive.

Authorization is unchanged. OAuth-aware clients follow protected-resource discovery from the WWW-Authenticate challenge, and API keys still work as bearer tokens. If you want the background on that, see Connect AI Agents to Search1API with OAuth 2.1 .

Older clients keep working

Almost no MCP client speaks 2026-07-28 yet, and that is the honest state of the ecosystem right now. As of July 29, 2026, the latest published @modelcontextprotocol/sdk on npm is 1.30.0, and its LATEST_PROTOCOL_VERSION is still 2025-11-25.

So the compatibility path matters more than the new one for the moment. A client that sends initialize with 2025-06-18 still gets a normal response from Search1API's Hosted MCP, over both HTTP and stdio. Nothing you have configured today stops working because the server learned a newer revision.

That is the point of supporting a revision early rather than late: the clients that arrive later find a server already waiting for them, and the clients that are here now do not have to move.

If you are migrating

Three things are worth doing before the ecosystem catches up:

1. Call `server/discover` first. It is the cheapest way to find out what a server supports without guessing, and it is the only method designed for that job.
2. Treat `_meta` as required, not decorative. Build the envelope once in your client and attach it to every request.
3. Stop assuming a connection carries meaning. If your integration relied on state established at initialize, that state now needs an explicit home.

The protocol got smaller and more boring, which is usually the sign of a good revision.

---

Point any MCP client at Search1API's hosted server and give your agent live web search, news, page content, sitemaps, and trending topics: read the MCP documentation .