MCP C# SDK 2.0 torna HTTP stateless por padrão e adiciona requisições de múltiplas idas e vindas

O SDK que conecta .NET a modelos de IA

O Model Context Protocol (MCP) é o protocolo aberto que padroniza como aplicações entregam contexto e ferramentas para modelos de linguagem↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI →. O SDK C#↳C#68 conteúdosNovidades do C# 8.0: Default Interface MembersDev (Back & Front) · jun 2019C# 8.0 – Conheça suas novas funcionalidadesDev (Back & Front) · mai 2019Novidades do C# 8.0: Switch ExpressionsDev (Back & Front) · mar 2019Ver tudo em Dev (Back & Front) → é mantido em colaboração com a Microsoft e construído sobre o ASP.NET Core, o que o torna a porta de entrada natural para quem integra agentes de IA em back-ends .NET no Brasil.

A Microsoft lançou a versão 2.0 do SDK implementando a revisão 2026-07-28 da especificação MCP. A própria equipe do SDK descreve essa revisão como a maior mudança desde o lançamento do protocolo, porque repensa como o MCP funciona sobre HTTP. Entre agosto e outubro de 2026 vieram ainda três versões menores, de 2.1 a 2.3, todas sobre essa mesma base.

Adeus ao handshake de sessão

A mudança central é que servidores Streamable HTTP agora são stateless por padrão. O handshake initialize e o header Mcp-Session-Id saem de cena: versão do protocolo e capacidades passam a viajar em cada requisição, o que permite que qualquer instância do servidor atenda qualquer chamada, sem roteamento sticky nem armazenamento de sessão compartilhado.

Na prática, HttpServerTransportOptions.Stateless agora é true por padrão. Servidores que ainda precisam de sessão (por exemplo, para manter estado de uma conversa longa) precisam setar essa flag explicitamente como false. Clientes tentam primeiro server/discover e caem para o handshake antigo só quando o servidor é mais velho. Opções exclusivas de modo stateful e os endpoints SSE legados agora disparam os avisos MCP9006 e MCP9004.

Headers que o gateway entende sem abrir o corpo

Uma chamada tools/call passa a carregar os headers Mcp-Method e Mcp-Name, e o atributo [McpHeader] promove um parâmetro de ferramenta a um header Mcp-Param-*. Isso deixa de ser só um detalhe interno: load balancers e API gateways podem rotear tráfego MCP olhando apenas os headers, sem precisar inspecionar o corpo da requisição.

O corpo continua sendo a fonte de verdade: se um header não bater com o que está no payload, o servidor retorna um erro HeaderMismatch. Para quem já lida com Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → API Management, Nginx ou um Application Gateway na frente de serviços .NET, essa padronização reduz a necessidade de parsers customizados só para decidir para onde mandar cada chamada MCP.

MRTR: perguntas no meio da chamada, sem sessão

Tirar o estado do servidor também tira o canal que ele usava para pedir informação ao cliente no meio de uma chamada. O SDK 2.0 resolve isso com Multi Round-Trip Requests (MRTR): uma ferramenta lança InputRequiredException com um ou mais pedidos de entrada, construídos com InputRequest.ForElicitation, ForSampling ou ForRootsList, mais um requestState opaco que carrega o contexto da chamada original.

O cliente coleta as respostas e reemite a chamada com inputResponses. Quando os handlers estão registrados, o McpClient faz isso automaticamente, sem código extra no app consumidor. Em sessões stateful com clientes da revisão 2025-11-25 ou anteriores, o SDK faz a ponte para o antigo modelo de requisições iniciadas pelo servidor; em conexões stateless com clientes antigos, a tentativa de usar esse recurso simplesmente levanta uma McpException.

As APIs de roots, sampling e logging ficam depreciadas sob o aviso MCP9005, seguindo a proposta SEP-2577. Quem usa esses recursos hoje em ferramentas interativas (como um fluxo de aprovação humana antes de uma ação sensível) precisa planejar a migração para o modelo MRTR.

O que quebra e o que não quebra

Segundo o anúncio, as APIs estáveis da série 1.x continuam funcionando. A exceção é Tasks, que migrou para o pacote opcional ModelContextProtocol.Extensions.Tasks e é incompatível com a versão experimental presente nas versões 1.3 e 1.4. Quem dependia de Tasks precisa revisar essa dependência antes de atualizar.

Um pacote experimental, ModelContextProtocol.Extensions.Apps, cobre o recurso de MCP Apps. No fronte de segurança, as notas de release listam regras de OAuth mais rígidas: validação de emissor conforme a RFC 9207, suporte obrigatório e anunciado a PKCE S256, e um tipo de aplicação inferido no registro dinâmico de clientes. Os pacotes seguem mirando .NET 8, 9 e 10, além do .NET Standard 2.0.

Três versões menores em três meses

As atualizações pós-2.0 trouxeram ajustes pontuais, mas relevantes para quem já está em produção:

• 2.1: handler opcional subscriptions/listen para streams de notificação customizados no servidor, e fallback para initialize quando server/discover falha na camada HTTP.
• 2.2: HttpServerSessionMode, que permite a um mesmo endpoint atender clientes das revisões 2025-11-25 e 2026-07-28 ao mesmo tempo; correção de uma exceção em McpHeaderEncoder.DecodeValue.
• 2.3: McpClient.ServerInfo passou a ser anulável, uma mudança source-breaking porque servidores podem omitir metadados de identidade opcionais em server/discover (as notas alertam contra usar identidade autodeclarada para decisões de segurança); respostas Streamable HTTP modernas agora esperam a primeira mensagem de protocolo antes de enviar headers, o que pode exigir saída de progresso ou timeout HTTP maior em handlers silenciosos e de longa duração.

A 2.3 também preserva a ordem de registro ao listar tools, prompts e resources, expõe McpClientOptions.TimeProvider para testes determinísticos de timeout, exclui OAuth do DiscoverProbeTimeout e fecha a entrada de um servidor stdio antes de esperar pela saída graciosa.

O que ainda está em aberto

Um leitor do anúncio perguntou se o protocolo protege o requestState contra adulteração ou reuso entre sessões diferentes; a pergunta ficou sem resposta nos comentários até a publicação da matéria. É um ponto relevante justamente porque o requestState é opaco e viaja fora de qualquer sessão fixa no novo modelo stateless.

A própria equipe do SDK diz que o próximo foco é autenticação e autorização ponta a ponta, área que já recebeu os ajustes de OAuth desta versão mas segue em desenvolvimento.

O que muda para quem constrói com .NET no Brasil

Para times que já rodam APIs .NET atrás de um load balancer ou de um Kubernetes com autoscaling horizontal, o modelo stateless por padrão elimina a necessidade de sticky sessions ou de um Redis compartilhado só para manter estado de sessão MCP. Isso reduz peça de infraestrutura e simplifica o deploy de servidores MCP como mais uma réplica stateless atrás do mesmo Azure Application Gateway ou Nginx já usado para o resto da API.

Quem constrói ferramentas interativas de IA (aprovação humana, formulários dinâmicos, coleta de parâmetros ausentes) precisa migrar explicitamente para o modelo MRTR, já que o canal antigo baseado em sessão para pedir dados ao cliente deixa de existir no modo stateless. E qualquer projeto que dependa do pacote Tasks experimental das versões 1.3/1.4 tem um trabalho de migração concreto pela frente antes de atualizar para 2.0 ou além.

Fonte: InfoQ