O que mudou na versão de julho

A especificação do Model Context Protocol (MCP) publicada como versão 2026-07-28 removeu as sessões do protocolo e o cabeçalho Mcp-Session-Id do transporte Streamable HTTP. O MCP passou a ser stateless. Servidores que precisam guardar estado entre chamadas agora criam um identificador próprio, como o ID de um carrinho ou de um fluxo, e recebem esse identificador de volta como argumento comum de ferramenta. O guia de segurança da especificação trata o risco que nasce daí como state handle hijacking: alguém obtém ou adivinha o identificador e passa a ler ou alterar o estado de outro usuário.

Para quem vai ligar um agente de IA ao CRM, ao ERP ou ao banco de dados da empresa por MCP, reunimos abaixo oito testes tirados da especificação e da documentação do Claude Code. Cada um traz o comando, o endereço ou a configuração exata para rodar hoje.

Antes dos testes: o inventário

No Claude Code, o comando claude mcp list lista todos os servidores MCP configurados com o status de cada um, e claude mcp get nome-do-servidor mostra os detalhes de um servidor específico. Anote a URL de cada servidor remoto e o comando de inicialização de cada servidor local. Os testes abaixo usam essa lista.

Os oito testes

  1. O servidor responde 401 sem token e indica onde estão os metadados. Faça uma requisição sem credencial com curl -si -X POST SEU_SERVIDOR/mcp, trocando SEU_SERVIDOR pelo endereço https do servidor. A especificação exige que o servidor publique a localização do servidor de autorização de uma de duas formas: no cabeçalho WWW-Authenticate, com o parâmetro resource_metadata, junto da resposta 401, ou no endereço /.well-known/oauth-protected-resource. Se nenhuma das duas existir, o servidor está fora da especificação.
  2. Os escopos anunciados são mínimos. Rode curl -s SEU_SERVIDOR/.well-known/oauth-protected-resource e leia o campo scopes_supported. A especificação lista como erro comum publicar todos os escopos possíveis nesse campo e usar escopos coringa ou genéricos, como o asterisco, all e full-access. No Claude Code, a forma suportada de restringir um servidor a um subconjunto aprovado pela segurança é fixar os escopos no .mcp.json com o campo oauth.scopes, numa string separada por espaços (por exemplo "channels:read chat:write search:read" num servidor do Slack).
  3. O servidor de autorização suporta PKCE com S256. Rode curl -s SEU_SERVIDOR_DE_AUTORIZACAO/.well-known/oauth-authorization-server, com o endereço https do servidor de autorização, e procure o campo code_challenge_methods_supported. Se ele não existir, a especificação manda o cliente MCP recusar a autorização. Quando tecnicamente possível, o método exigido é S256.
  4. Token emitido para outro serviço é recusado. Envie ao servidor MCP um token válido de outra API da empresa, no cabeçalho Authorization: Bearer. A resposta precisa ser 401. A especificação obriga o servidor a validar que o token foi emitido para ele como público-alvo (audience) e proíbe aceitar ou repassar qualquer outro token. O guia de segurança chama o repasse de token passthrough e explica o risco: com um token roubado, o servidor vira uma ponte para extrair dados, e os logs passam a mostrar a identidade errada. Confira também que nenhum token aparece na URL, porque a especificação proíbe token na query string.
  5. O identificador de estado está preso ao usuário. Pegue um identificador de estado devolvido ao usuário A e chame a mesma ferramenta com o token do usuário B. O servidor precisa recusar. Pela especificação, possuir o identificador não pode valer como autenticação. A recomendação é gerar identificadores aleatórios com gerador seguro, evitar IDs sequenciais e guardar o estado no servidor com chave no formato user_id:handle, com o user_id tirado do token verificado e nunca enviado pelo cliente.
  6. Servidor local mostra o comando inteiro antes de rodar. Na configuração em um clique de um servidor local, o cliente MCP precisa mostrar o comando exato, com todos os argumentos e sem cortes, e pedir aprovação explícita. Os exemplos de ataque da especificação são comandos de inicialização como um npx de pacote malicioso seguido de um curl que envia a chave SSH privada do usuário (~/.ssh/id_rsa) para fora. Revise no inventário cada comando local procurando os padrões que a especificação manda destacar: sudo, rm -rf, operações de rede e acesso a pastas fora do esperado. Para servidores que só rodam na máquina, a especificação recomenda o transporte stdio, que limita o acesso ao próprio cliente.
  7. O cliente MCP que roda em servidor bloqueia a rede interna. Um servidor MCP malicioso pode preencher os endereços de descoberta do OAuth com destinos internos e fazer o cliente buscá-los. As faixas que a especificação manda bloquear são 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 (onde ficam os endpoints de metadados de nuvem, como 169.254.169.254), fc00::/7 e fe80::/10. A especificação também pede HTTPS em todas as URLs de OAuth em produção, validação de cada redirecionamento e um proxy de saída como o Smokescreen. Ela desaconselha escrever a validação de IP à mão, porque atacantes usam codificações em octal, hexadecimal e IPv4 mapeado em IPv6 que parsers caseiros deixam passar.
  8. Ferramentas que concedem acesso exigem aprovação humana em toda chamada. Se o servidor MCP é da sua empresa, marque a ferramenta com _meta["anthropic/requiresUserInteraction"] igual a true na resposta de tools/list. O Claude Code passa a pedir permissão em toda chamada dessa ferramenta, inclusive nos modos acceptEdits, auto e bypassPermissions, e não oferece a opção de não perguntar de novo. No modo dontAsk, que nunca pergunta, a chamada é negada. As outras ferramentas do mesmo servidor mantêm o comportamento normal.

O que esses testes definem

Esses testes definem, para cada agente, o que ele pode ler, o que pode alterar e em que ponto uma pessoa precisa aprovar. É esse desenho de limites e de revisão humana que a LC Labs faz com o time antes de conectar um agente a sistemas de produção.

Fontes