I built a Skill and checker for MCP's breaking change 2026-08-26. Then the checker was wrong about it.

<p>If you are migrating an MCP server right now, here is the thing that will cost you<br> an afternoon, before anything else in this post:</p> <p><strong><code>@modelcontextprotocol/sdk</code> has no 2.x. It never will.</strong></p> <p>It stops at <code>1.30.0</code>. If you go looking for <code>@modelcontextprotocol/sdk@^2</code> you<br> will find nothing and conclude that v2 has not shipped yet. It has — on<br> 2026-07-27, under different names:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>@modelcontextprotocol/server 2.0.0 @modelcontextprotocol/client 2.0.0 @modelcontextprotocol/core 2.0.0 @modelcontextprotocol/node 2.0.0 @modelcontextprotocol/express 2.0.0 ┐ @modelcontextprotocol/fastify 2.0.0 ├ HTTP adapters @modelcontextprotocol/hono 2.0.0 ┘ @modelcontextprotocol/server-legacy 2.0.0 compat shim @modelcontextprotocol/codemod 2.0.0 </code></pre> </div> <p>I know this because my own tool told people the opposite, with total confidence.</p> <h2> What broke </h2> <p>The MCP revision dated <strong>2026-07-28</strong> is the largest change the protocol has had.<br> The short version:</p> <ul> <li>The transport is <strong>stateless</strong>. The <code>initialize</code> / <code>notifications/initialized</code> handshake is gone. Every request now carries its protocol version and client capabilities in <code>_meta</code>.</li> <li> <strong><code>Mcp-Session-Id</code> is gone</strong> from Streamable HTTP. There are no protocol-level sessions any more.</li> <li> <strong><code>server/discover</code> is a MUST.</strong> Servers have to advertise their supported protocol versions and capabilities over it.</li> <li>Server-initiated requests (<code>roots/list</code>, <code>sampling/createMessage</code>, <code>elicitation/create</code>) are replaced by <strong>Multi Round-Trip Requests</strong>: the server returns an <code>InputRequiredResult</code>, the client retries with the answers.</li> <li> <code>logging</code>, <code>sampling</code> and <code>roots</code> are <strong>deprecated, not removed</strong> - twelve-month minimum window.</li> </ul> <p>The second point is the one that hurts. If you keep anything in a <code>Map</code> keyed by<br> session id, it works perfectly on your laptop with one process and fails<br> intermittently the moment two instances sit behind a load balancer. It fails<br> quietly, which is the worst way to fail.</p> <p>So I built a checker: seven rules, a deterministic engine, no model in the loop.<br> Point it at a running endpoint or a repository and it tells you what breaks, with<br> the spec page for each finding so you can prove it wrong. It ships as an agent<br> skill that does the migration too, which I will come back to — because the<br> scanner on its own turned out to be the smaller half.</p> <h2> Then my own rule was wrong </h2> <p>One rule, MCP007, fired when <code>@modelcontextprotocol/sdk</code> resolved below <code>2.0.0</code><br> and said:</p> <blockquote> <p>Upgrade to <code>@modelcontextprotocol/sdk ^2</code>. Run the official v1→v2 codemod for<br> the mechanical renames, then re-check.</p> </blockquote> <p>Both halves of that are wrong, and they are wrong in different ways.</p> <p><code>@modelcontextprotocol/sdk@^2</code> does not resolve. There has never been a 2.x of<br> that package. So the tool was confidently recommending a version that does not<br> exist - to people who would then spend twenty minutes wondering what they were doing wrong.</p> <p>I checked npm, found <code>1.30.0</code> as the latest and no 2.x anywhere in the version<br> list, read the SDK announcement, saw no major version named, and concluded the<br> rule was fabricated wholesale. So I deleted it, wrote a comment explaining that no<br> 2.x line existed and no codemod existed, and - this is the part that stings -<br> propagated that "correction" into the README,