MCP sem estado facilita o balanceamento, mas exige uma matriz de compatibilidade

O SDK MCP C# 2.0 e suas atualizações até a 2.3 adotam a revisão 2026-07-28 do protocolo e usam Streamable HTTP sem estado por padrão.[8] No fluxo moderno, versão e capacidades acompanham cada requisição, substituindo a dependência do handshake initialize e do identificador de sessão.[8]

O ganho de engenharia está em reduzir acoplamento entre chamada e instância. O risco é tratar a atualização de um pacote como se fosse apenas uma troca de implementação, quando o comportamento observável pelos clientes também mudou.

O que muda para quem desenvolve

A ausência de afinidade de sessão permite distribuir requisições entre instâncias; servidores que precisam de sessões ainda podem ativá-las explicitamente.[8] Cabeçalhos como Mcp-Method e Mcp-Name permitem identificar chamadas sem interpretar o corpo inteiro.[8] Parâmetros selecionados podem aparecer em Mcp-Param-*, mas o corpo continua sendo a referência e divergências geram erro.[8]

Para chamadas que pedem informações adicionais, Multi Round-Trip Requests interrompem o processamento com pedidos de entrada e estado opaco; o cliente coleta respostas e refaz a chamada.[8] Há adaptação para clientes antigos com sessão, mas nem todas as combinações antigas sem estado são compatíveis.[8]

Minha leitura: “suporta MCP” é uma descrição insuficiente para aceitar uma integração. O contrato operacional precisa registrar revisão, transporte, interação e autenticação. Distribuir HTTP com facilidade não prova que o fluxo completo funcionará entre versões diferentes.

Como aplicar

Monte uma matriz com os clientes realmente utilizados e os modos oferecidos pelo servidor. Inclua uma chamada simples, uma operação longa, uma solicitação de entrada adicional, uma interrupção e uma falha de autenticação. Registre comportamento esperado antes de executar cada cenário.

Um experimento útil é colocar duas instâncias de demonstração atrás de um balanceador, sem dados reais. Direcione requisições sucessivas a instâncias diferentes e verifique quais fluxos terminam corretamente. Depois repita com o cliente mais antigo que ainda precisa ser atendido. O objetivo é descobrir dependências concretas de sessão, não assumir que todo estado desapareceu da aplicação.

Inclua revisão de código para ServerInfo ausente: a versão 2.3 passou a aceitar falta desses dados, uma mudança relevante de código-fonte.[8] Não use identidade autodeclarada como autorização para executar ferramentas.

Cuidados e limites

Tasks migrou para um pacote opcional incompatível com a implementação experimental anterior.[8] A linha também endurece OAuth, incluindo validação do emissor e anúncio obrigatório de PKCE S256.[8] Não misture compatibilidade de API com compatibilidade de comportamento de segurança.

As respostas HTTP modernas aguardam a primeira mensagem do protocolo, exigindo atenção a progresso e timeout em tarefas longas.[8] A reportagem ainda registra uma pergunta sem resposta sobre proteção do estado MRTR contra adulteração ou reutilização.[8] Isso é uma lacuna de informação, não prova de vulnerabilidade nem garantia de proteção.

Fonte

[8] Fonte: InfoQ