Configurar o servidor MCP sem herdar um prazo de validade

Em algum momento desta semana você vai copiar um bloco de configuração de servidor MCP (o padrão que liga o assistente às ferramentas, como uma tomada universal). De um post, da documentação de um projeto, da resposta de um agente. Esse bloco é curto, parece inofensivo e você vai colar sem ler linha por linha.

Ele decide duas coisas que não se anunciam: se o servidor que dirige o seu navegador escuta apenas você ou escuta qualquer página aberta em outra aba, e por quanto tempo essa configuração continua funcionando.

Engenharia de protocolo fica de fora; o módulo fixa o mínimo que evita duas dores caras: um servidor local alcançável de fora, e uma configuração que funciona hoje e para sozinha daqui a algumas semanas porque uma revisão nova entrou em vigor.

A 2026-07-28 foi anunciada como candidata em 21 de maio de 2026 e publicada como vigente em 28 de julho de 2026, ao fim de uma janela de validação de dez semanas. No mesmo dia saíram a versão 2.0 do SDK de Python e a do SDK de TypeScript.

A virada importa porque a revisão reescreveu a camada base. Configuração antiga não quebra de um dia para o outro, porque os SDKs 2.x atendem clientes da era 2025 no mesmo servidor. O risco está na dependência sem limite superior, que sobe sozinha para a 2.x e leva junto a mudança de import.

Dois transportes, não três.

A especificação define exatamente dois transportes: stdio e Streamable HTTP. Clientes devem preferir stdio quando for possível, e é por stdio que a maioria dos servidores locais de controle de navegador roda.

O transporte antigo, com um endpoint de GET para o stream e outro de POST para as mensagens, pertence à revisão 2024-11-05 e está deprecado desde a revisão 2025-03-26. Boa parte dos tutoriais de 2024 e do começo de 2025 ensina justamente esse par de endpoints, o que os torna material vencido sem aviso na página.

Esse bloco é a configuração de referência publicada pelo próprio time do Chrome, e ele usa stdio: o cliente sobe o servidor como processo filho e conversa por entrada e saída padrão. Não existe porta aberta, não existe header de origem, e por isso não existe a superfície de ataque que vem a seguir.

A conversa muda quando o servidor é HTTP e roda na sua máquina. Aí entram as duas regras de higiene que a própria especificação exige.

Primeira regra: o servidor deve validar o header Origin e responder 403 Forbidden quando ele estiver presente e for inválido. A segunda: rodando localmente, o servidor deveria se ligar apenas a 127.0.0.1, e não a todas as interfaces.

Por trás das duas está o mesmo mecanismo. Uma página qualquer que você abriu no navegador consegue fazer requisições para endereços locais. Com um nome de domínio que troca de resolução no meio do caminho, ela alcança o servidor que roda na sua máquina como se fosse um serviço remoto comum. Isso se chama DNS rebinding, é conhecido há anos, e não depende de você clicar em nada.

O que a 2026-07-28 mudou debaixo dos seus pés.

A 2026-07-28 tornou o protocolo stateless. O handshake de inicialização saiu, e junto com ele saíram notifications/initialized e o header Mcp-Session-Id. A versão do protocolo e as capacidades do cliente passaram a viajar em _meta a cada requisição, e um método novo, server/discover, assumiu o papel de anunciar versões e capacidades. Servidores que precisam de estado entre chamadas passaram a usar handles explícitos, cunhados pelo servidor e passados como argumento comum de ferramenta.

Tarefa deste módulo. Rode a auditoria e responda por escrito, em um arquivo, quatro perguntas: qual transporte cada servidor seu usa; se algum servidor local está ligado em algo diferente de 127.0.0.1; se alguma dependência de SDK está sem limite superior de versão; e se algum servidor foi aprovado uma vez e nunca mais revisado.

Depois corrija o item mais barato hoje mesmo. Na maioria das configurações o mais barato é o limite superior na dependência, que leva dois minutos e evita a quebra silenciosa quando a dependência subir para a 2.x sem ninguém pedir.