MCP 2026: The July 28 Spec Update Every Developer Should Know About

The Model Context Protocol has a Release Candidate landing on July 28, 2026, and it changes how MCP servers and clients negotiate capabilities. If you run an MCP server — or build tools that connect to them — there are four changes worth understanding before the cutover.

1. The initialize handshake is gone

Current MCP (2024-11-05) requires every session to begin with an initialize request. The client sends its supported protocol version and capabilities; the server responds with its own; then the real work begins. This is a stateful handshake — the server has to remember something about you before it can serve you.

The 2026 spec removes this requirement. Clients no longer send initialize before making tool calls. The protocol becomes effectively stateless at the transport layer: each request carries enough information to be handled without prior context.

Why does this matter? Stateless servers are much easier to deploy. You can run them on serverless platforms, behind load balancers, in edge workers — anywhere that doesn't support sticky sessions. The old initialize handshake was a subtle scaling problem that the new spec eliminates.

2. server/discover replaces initialize for capability negotiation

The old initialize did two things: it started a session and it negotiated capabilities. The new spec separates these concerns. Capability discovery is now a dedicated method: server/discover.

When a client calls server/discover, the server responds with its protocol version, capabilities, and — critically — its full tool list. In one request, the client knows everything it needs to work with the server. No back-and-forth, no session state required.

The response shape looks like this:

{
  "protocolVersion": "2026-07-28",
  "capabilities": { "tools": {} },
  "serverInfo": { "name": "your-server", "version": "1.0.0" },
  "tools": [
    {
      "name": "your_tool",
      "description": "...",
      "inputSchema": { ... }
    }
  ]
}

This is a strictly better design for discovery. Instead of a client needing to call initialize and then tools/list separately, one call to server/discover returns everything.

3. New required headers: Mcp-Method and Mcp-Name

The 2026 spec adds two HTTP headers that clients must include on tool call requests:

Mcp-Method — the JSON-RPC method being called (e.g. tools/call)

Mcp-Name — the specific tool name being invoked (e.g. ask_site)

These headers exist to enable smarter routing. An MCP gateway or proxy can read the headers and route requests to different backends without parsing the JSON-RPC body. It also makes rate limiting and logging easier — you can identify what a request does from the headers alone.

Servers that don't read these headers won't break — they're meant for infrastructure, not application logic. But if you're building an MCP gateway or a load balancer that handles multiple MCP servers, these headers are what you'd route on.

Your CORS preflight handling also needs to include these new headers in Access-Control-Allow-Headers if you're serving MCP from a browser context:

Access-Control-Allow-Headers: Content-Type, Authorization, Mcp-Method, Mcp-Name

4. The Tasks extension (deferred)

The RC also includes a Tasks extension for long-running operations — a standardized way for a tool call to return a task ID rather than waiting for completion. The client can poll or receive a webhook when the task finishes.

This solves a real problem: tool calls that take longer than an HTTP timeout. Crawling a large site, running an analysis job, or waiting on an external API all fall into this category. The current workaround is various ad-hoc polling schemes or artificially long timeouts.

The catch: Tasks requires background job infrastructure. If your MCP server runs on a serverless platform with a 60-second function timeout, Tasks isn't straightforward to implement — you need a queue, a background worker, and a way to notify the client when the task finishes. For many teams this will be a meaningful deployment change, which is why it's worth understanding the extension exists even if you don't adopt it immediately.

What breaks on July 28

Clients that only send initialize and never server/discover won't stop working — servers are expected to maintain backward compatibility by handling both methods. But clients that require an initializeResult before they'll make any tool calls may break against servers that drop initialize support entirely.

The practical advice: if you maintain an MCP server, add server/discover now and keep initialize as a fallback. If you maintain an MCP client, start sending Mcp-Method and Mcp-Name headers and add support for server/discover responses.

How AgentReady handles the transition

AgentReady's MCP endpoint already supports both the current and upcoming spec. It handles server/discover, reads Mcp-Method and Mcp-Name headers, includes them in CORS preflight responses, and maintains initialize for backward compatibility. Clients on either spec version can connect without configuration changes.

The endpoint runs on Vercel serverless, which means the Tasks extension isn't implemented — long-running operations like site indexing complete synchronously within the 60-second function timeout, or return an error if they can't. If Tasks support becomes important, it would require moving to a queue-backed architecture.

If you're building an MCP server of your own, the cleanest path is to handle both initialize and server/discover in the same switch statement, returning the same capability payload from both. The difference is that server/discover also includes the tool list inline, saving clients a round-trip to tools/list.