MCP 2026-07-28 drops the old handshake

An MCP server you depend on can start refusing your client's first request after a protocol upgrade. If the server speaks only MCP 2026-07-28, clients that still open with initialize can't connect. The tools can stay the same while the way clients reach them changes.

The 2026-07-28 changelog removes the initialize and notifications/initialized handshake. Servers now answer a server/discover request with their versions, capabilities, and identity.

Over Streamable HTTP, an older client's initialize request lacks the required headers. A server that supports only 2026-07-28 answers 400 Bad Request with a HeaderMismatch error. The spec's compatibility matrix says these clients have "no fall-forward mechanism".

How we check both versions

Our MCP check now reads both protocol versions so it can keep checking tools through this upgrade.

The check opens with initialize. If the server refuses it, we send server/discover as a 2026-07-28 client and read its tools, resources, and prompts.

Pins on Tool wording unchanged and No new tools keep holding through the upgrade if the tools stay the same (why those pins matter). We alert only when an assertion you've ticked breaks or recovers.

What the check misses

We connect over Streamable HTTP from outside, so servers that run over stdio or on a private network are out of reach. If your server answers both protocol versions, we read it through the handshake only. That check doesn't see how the server answers a 2026-07-28 client.