Construí uma Skill e verificador para a mudança drástica do MCP

Se você está migrando um servidor MCP agora, aqui está a coisa que vai custar uma tarde, antes de qualquer outra coisa neste post:

@modelcontextprotocol/sdk não tem 2.x. Nunca terá.

Ele para em 1.30.0. Se você procurar por @modelcontextprotocol/sdk@^2, você
não encontrará nada e concluirá que a v2 ainda não foi lançada. Ela foi — em
2026-07-27, sob nomes diferentes:

@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   ├ Adaptadores HTTP
@modelcontextprotocol/hono           2.0.0   ┘
@modelcontextprotocol/server-legacy  2.0.0   compat shim
@modelcontextprotocol/codemod        2.0.0

Eu sei disso porque minha própria ferramenta disse às pessoas o oposto, com total confiança.

O que quebrou

A revisão do MCP datada de 2026-07-28 é a maior mudança que o protocolo já teve.
A versão curta:

• O transporte é sem estado. O handshake initialize / notifications/initialized foi embora. Cada solicitação agora carrega sua versão de protocolo e capacidades do cliente em _meta.
• Mcp-Session-Id foi embora do HTTP Streamable. Não há mais sessões a nível de protocolo.
• server/discover é um MUST. Os servidores têm que anunciar suas versões de protocolo e capacidades suportadas através dele.
• Solicitações iniciadas pelo servidor (roots/list, sampling/createMessage,elicitation/create) foram substituídas por Multi Round-Trip Requests: o servidor retorna um InputRequiredResult, o cliente tenta novamente com as respostas.
• logging, sampling e roots estão obsoletos, não removidos - janela mínima de doze meses.

O segundo ponto é o que dói. Se você mantiver algo em um Map indexado por
id de sessão, funciona perfeitamente no seu laptop com um processo e falha
internamente no momento em que duas instâncias estão atrás de um balanceador de carga. Ele falha
silenciosamente, que é a pior maneira de falhar.

Então eu construí um verificador: sete regras, um motor determinístico, sem modelo no loop.
Aponte para um endpoint em execução ou um repositório e ele lhe diz o que quebra, com
a página da especificação para cada descoberta, para que você possa provar que está errado. Ele é enviado como uma habilidade de agente que também faz a migração, sobre a qual voltarei — porque o scanner por si só acabou sendo a metade menor.

Então minha própria regra estava errada

Uma regra, MCP007, disparou quando @modelcontextprotocol/sdk foi resolvido abaixo de 2.0.0
e disse:

Atualize para @modelcontextprotocol/sdk ^2. Execute o codemod oficial v1→v2 para
os renomes mecânicos, depois verifique novamente.

Ambas as partes estão erradas, e elas estão erradas de maneiras diferentes.

@modelcontextprotocol/sdk@^2 não é resolvido. Nunca houve um 2.x de
esse pacote. Então a ferramenta estava recomendando com confiança uma versão que não
existe - para pessoas que então passariam vinte minutos se perguntando o que estavam fazendo de errado.

Eu verifiquei o npm, encontrei 1.30.0 como a mais recente e nenhuma 2.x em lugar nenhum na lista de versões, li o anúncio do SDK, não vi nenhuma versão principal nomeada, e concluí que a
regra foi fabricada por completo. Então eu a deletei, escrevi um comentário explicando que nenhuma
linha 2.x existia e nenhum codemod existia, e - esta é a parte que dói -
propaguei essa "correção" para o README, a habilidade e o guia de remediação.

Eu havia substituído uma declaração errada por uma declaração errada de forma diferente.

Por que o segundo erro foi tão fácil

Olhe para o que eu realmente verifiquei. Eu verifiquei o pacote que a regra nomeou. Ele termina
em 1.30.0. De dentro desse único pacote, essas duas situações são indistinguíveis:

não há v2 ainda
v2 existe sob um nome diferente

Uma renomeação produz exatamente a evidência que você esperaria da ausência. Verificar
mais arduamente no mesmo lugar não ajuda — a resposta não está lá. Eu só a encontrei quando fui procurar pelo codemod, que acabou existindo como seu próprio
pacote, e cuja descrição dizia "Codemod para migrar o código do SDK TypeScript do MCP da v1 para a v2". Um codemod para uma v2 que não existe seria uma coisa estranha de publicar.

A regra agora se baseia na presença do pacote v1 em vez de um limite de versão, porque o nome do pacote é o sinal real:

// O nome do pacote É a linha v1. Ele para em 1.30.0 e fala o
// protocolo pré-2026-07-28. a v2 foi enviada sob nomes diferentes completamente,
// então uma comparação de versão aqui é sem sentido.
if (!ctx.source?.sdkVersion) return null;

E um teste agora fixa o primeiro erro permanentemente:

test("MCP007 nomeia os pacotes de substituição reais e o codemod real", () => {
  const f = evaluate({ source: withSdk("^1.17.0") })
    .find((x) => x.ruleId === "MCP007");

  assert.ok(f.fix.includes("@modelcontextprotocol/server"));
  assert.ok(f.fix.includes("@modelcontextprotocol/client"));
  assert.ok(f.fix.