HTTP transmissível, Três Eras e o Contrato de Rede Atual

O transporte HTTP remoto do MCP passou por três designs distintos em cerca de dois anos. O transporte HTTP+SSE de 05/11/2024 usava dois endpoints e um fluxo de longa duração; ele foi descontinuado em 26/03/2025 e está sujeito a remoção futura. O Streamable HTTP o substituiu em 26/03/2025 com um único endpoint — mas aquela primeira versão ainda carregava sessões em nível de protocolo, um fluxo GET independente, solicitações iniciadas pelo servidor via SSE e fluxos retomáveis. A revisão de 28/07/2026 removeu esses mecanismos. O que resta é excepcionalmente limpo: cada mensagem JSON-RPC do cliente é enviada como seu próprio POST, as respostas às solicitações são um objeto JSON ou um fluxo SSE vinculado a essa solicitação, e metadados selecionados da solicitação são espelhados nos cabeçalhos para que intermediários possam rotear e inspecionar o tráfego sem analisar o corpo da mensagem. Essa última decisão de design é a que merece uma leitura atenta.

Um balanceador de carga roteia com base em um cabeçalho enquanto o servidor executa com base no corpo, e os dois divergem. Isso não é uma hipótese nesta especificação — é o motivo declarado para a existência de uma regra de validação completa. O transporte de 28/07/2026 acomoda explicitamente intermediários entre cliente e servidor, e grande parte do novo contrato de cabeçalhos só faz sentido quando lido dessa forma.

1. Três Eras

05/11/2024 — HTTP+SSE. Dois endpoints. O cliente emitia um GET que abria um fluxo SSE, cujo primeiro evento era um endpoint evento informando ao cliente para onde enviar o POST. Tudo o que era iniciado pelo servidor chegava no fluxo de longa duração. Descontinuado desde 26/03/2025 sob a política de ciclo de vida de recursos, sendo desaconselhada a adoção por novas implementações.

26/03/2025 a 25/11/2025 — Streamable HTTP, primeira versão. Um único endpoint MCP, o que representou uma simplificação significativa. Mas quatro mecanismos o mantinham com estado: os servidores podiam atribuir uma sessão via cabeçalho Mcp-Session-Id , encerrada com um HTTP DELETE; os clientes podiam abrir um fluxo SSE independente com GET para receber mensagens iniciadas pelo servidor; os servidores podiam enviar solicitações JSON-RPC em fluxos SSE; e os fluxos eram retomáveis via Last-Event-ID.

28/07/2026 — a versão atual. Nenhum desses quatro permanece. As notas de revisão listam as remoções claramente: o endpoint de fluxo GET e as sessões em nível de protocolo desapareceram, e as seções abaixo acrescentam que os fluxos não são retomáveis e que os servidores não devem enviar solicitações independentes em um fluxo.

Um servidor que implementa apenas a revisão atual lida com tráfego mais antigo com comportamento especificado: GET ou DELETE para o endpoint MCP recebe 405 Método não permitido; um Mcp-Session-Id cabeçalho é ignorado e nenhum identificador de sessão é criado ou ecoado; um Last-Event-ID cabeçalho é ignorado.

2. O Protocolo de Comunicação

O servidor expõe um caminho de endpoint HTTP — o endpoint MCP — que suporta POST. A base de segurança do transporte é importante antes de qualquer otimização de comunicação: os servidores devem validar o Origin cabeçalho em conexões de entrada e retornar 403 para uma origem presente, porém inválida; servidores executados localmente devem se vincular ao localhost em vez de a todas as interfaces; e os servidores devem autenticar as conexões. Esses requisitos existem para reduzir o risco de DNS-rebinding e acesso não autorizado.

Envio. Cada mensagem JSON-RPC do cliente é seu próprio POST. O cliente deve incluir um Accept cabeçalho listando tanto application/jsonetext/event-stream, e o corpo deve ser uma única solicitação ou notificação JSON-RPC. Os clientes não devem enviar respostas JSON-RPC. Uma sutileza é importante para os implementadores: embora o transporte defina como um POST de notificação se comporta, o protocolo central de 28/07/2026 não define notificações de cliente para servidor via HTTP transmissível (Streamable HTTP) e não define requisitos de cabeçalho de metadados para POSTs de notificação.

Notificações. Se o servidor aceitar uma, ele retorna 202 Aceito sem corpo; se não puder, um status de erro HTTP, opcionalmente contendo uma resposta de erro JSON-RPC sem id.

Requisições. O servidor retorna ou Content-Type: application/json com um único objeto JSON, ou Content-Type: text/event-stream com um fluxo SSE vinculado a essa requisição. O cliente deve suportar ambos — o servidor escolhe por requisição, portanto, um cliente que lida apenas com um deles falhará de forma imprevisível.

O que trafega em um fluxo de resposta. O servidor pode enviar notificações relacionadas à requisição original — mensagens de progresso e log — antes da resposta final, e a resposta final deve encerrar o fluxo. O servidor não deve enviar requisições JSON-RPC independentes nele. Esta é a ruptura explícita com revisões anteriores.

Cancelamento. O fechamento do fluxo de resposta SSE deve ser tratado pelo servidor como cancelamento daquela requisição e, como cada requisição possui seu próprio fluxo, a desconexão é inequívoca. A notificação de cancelamento do protocolo principal é usada apenas em stdio; neste transporte, não há mensagem de cancelamento e nenhuma é esperada.

3. Para onde foi o trabalho iniciado pelo servidor

Duas coisas que anteriormente precisavam de um canal do servidor para o cliente foram separadas em mecanismos diferentes.

Solicitar algo ao cliente — amostragem, elicitação, raízes — agora está incorporado nos resultados como requisições de entrada sob o padrão de Requisições de Múltiplas Idas e Voltas. O servidor retorna um InputRequiredResult contendo inputRequests; o cliente reúne o que foi solicitado e reenvia a chamada original com o inputResponses. Trata-se de um segundo POST, não de um push.

Notificações de alteração de longa duração — alterações na lista de ferramentas, atualizações de recursos — são obtidas enviando uma subscriptions/listen solicitação cuja resposta é, por si só, um fluxo SSE que permanece aberto e entrega apenas os tipos de notificação que o cliente escolheu receber. Notificações com escopo de solicitação, como progresso, não aparecem lá; elas fluem apenas no fluxo da solicitação à qual pertencem.

Essa separação é mais organizada do que parece. O fluxo de notificação de longa duração padronizado existe porque o cliente o solicitou, e seu conteúdo é filtrado pela própria assinatura do cliente. O trabalho de múltiplas viagens de ida e volta pode permanecer sem estado na camada de transporte MCP, pois o servidor pode codificar o contexto necessário em requestState e o cliente ecoa esse valor opaco ao tentar novamente.

4. Dois detalhes que causam problemas atrás de um proxy

A especificação inclui duas notas operacionais que existem porque o SSE e os proxies reversos têm um relacionamento difícil.

Buffer. Ao iniciar um fluxo SSE, os servidores devem incluir X-Accel-Buffering: no. Isso instrui proxies reversos, como o nginx, a desativar o buffer de resposta. Sem isso, um proxy pode acumular mensagens antes de encaminhá-las — introduzindo latência e prejudicando o propósito do streaming. Se as atualizações de progresso transmitidas chegarem em um bloco no final, o buffer de resposta é um dos primeiros comportamentos intermediários a serem verificados.

Keep-alives. Para fluxos de longa duração, particularmente a resposta subscriptions/listen , incentiva-se que os servidores emitam periodicamente uma linha de comentário SSE — uma linha começando com dois pontos — como um keep-alive, para que intermediários e timeouts de inatividade não fechem uma conexão silenciosa. De acordo com a especificação SSE, um comentário não carrega dados de evento, e os clientes devem ignorar tais linhas em vez de tratá-las como malformadas.

5. O Contrato de Cabeçalho

Esta é a parte que torna o transporte genuinamente diferente de uma convenção JSON-RPC-over-HTTP, e a especificação declara seu propósito diretamente: o transporte espelha campos selecionados do corpo JSON-RPC em cabeçalhos HTTP para que intermediários — balanceadores de carga, gateways, ferramentas de observabilidade — possam rotear e inspecionar solicitações sem analisar o corpo.

MCP-Protocol-Version — obrigatório em cada POST, e seu valor deve corresponder à versão do protocolo contida no campo _metado corpo. Uma incompatibilidade é rejeitada com 400 Bad Request e um erro HeaderMismatch . Uma versão que o servidor não implementa recebe 400 com um erro listando as versões que ele suporta. Um método não implementado recebe 404 com o erro JSON-RPC -32601, que é o que o distingue do erro de um servidor legado 404.

Mcp-Method — espelha method. Obrigatório em todas as solicitações JSON-RPC.

Mcp-Name — espelha params.nameouparams.uri. Obrigatório para tools/call,resources/read, eprompts/get.

Para solicitações JSON-RPC, esses cabeçalhos de solicitação padrão são necessários para conformidade nos escopos acima. POSTs de notificação são um caso especial à parte: esta revisão define seus mecanismos de transporte, mas não seus requisitos de cabeçalho de metadados. Uma solicitação tools/call em conformidade mínima, portanto, tem a seguinte aparência na rede:

POST to the MCP endpoint
POST /mcp HTTP/1.1
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"get_weather","arguments":{"location":"Seattle, WA"},
 "_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}

Os servidores podem ir além e designar parâmetros de ferramenta específicos para serem espelhados, usando uma extensão x-mcp-header no esquema do parâmetro, o que produz cabeçalhos chamados Mcp-Param-{Name}. Um servidor que anota um parâmetro de região obtém Mcp-Param-Region: us-west1 ao lado do corpo — que é exatamente o formato que um roteador precisa para enviar uma consulta ao backend regional correto sem ler o payload.

As restrições dessa extensão são rígidas e vale a pena conhecê-las antes de projetar algo em torno dela. Os valores não podem ser vazios, devem seguir a sintaxe de token HTTP, não podem conter caracteres de controle e devem ser únicos dentro do esquema, independentemente de maiúsculas ou minúsculas. Apenas tipos primitivos são permitidos — string, booleano e inteiro, com number explicitamente excluído. Além disso, a propriedade anotada deve ser estaticamente acessível a partir da raiz do esquema por meio de uma cadeia composta exclusivamente por properties chaves: não através de palavras-chave de array, não através de oneOf,anyOf,allOf, ounão, não através de condicionais e não através de $ref. Objetos aninhados são permitidos, desde que cada etapa seja uma chave properties . Uma anotação em qualquer outro lugar torna a definição da ferramenta inválida, e um cliente em conformidade deve excluir essa ferramenta de tools/list enquanto registra um aviso — para que uma definição malformada não desabilite as demais.

Valores que não podem ser representados com segurança como ASCII simples são codificados em Base64 dentro de um sentinela, =?base64?...?=, e a mesma codificação se aplica a Mcp-NameUm detalhe importante: um valor em ASCII simples que por acaso se pareça com o delimitador também deve ser codificado, para eliminar a ambiguidade.

6. Por que a divergência é um erro

Servidores que processam o corpo da requisição devem rejeitar requisições onde os valores do cabeçalho não correspondam aos valores correspondentes no corpo, retornando 400 com o erro JSON-RPC -32020. A especificação apresenta o motivo explicitamente, e trata-se de um argumento de segurança, não apenas de organização: isso evita vulnerabilidades quando diferentes componentes na rede dependem de fontes de verdade distintas — um balanceador de carga que roteia com base no valor do cabeçalho, enquanto o servidor MCP executa com base no valor do corpo.

Considere isso como um modelo de ameaça. Se um intermediário toma uma decisão a partir de um cabeçalho e o servidor age sobre um corpo que diz algo diferente, um cliente que os configure de forma divergente pode induzir uma condição de fonte de verdade dividida — por exemplo, roteamento ou política avaliada contra um valor enquanto a execução utiliza outro. A validação obrigatória no lado do servidor elimina essa classe de divergência para a revisão atual, e os valores codificados devem ser decodificados antes da comparação.

7. O que isso significa para um gateway

É raro um protocolo especificar o que o componente intermediário deve fazer. Como este especifica, o mapeamento é incomumente direto.

Roteie sem analisar. Mcp-MethodeMcp-Name significam que um proxy pode distinguir uma chamada de ferramenta de uma leitura de recurso, e identificar qual ferramenta, apenas pelos cabeçalhos. Essa é a diferença entre uma camada que entende MCP e uma que precisa desserializar cada payload para tomar uma decisão (visão geral do MCP).

Exponha a identidade da ferramenta para uma camada de autorização sem analisar o corpo. Uma tools/call requisição em conformidade carrega o nome da ferramenta em Mcp-Name. Isso fornece a um intermediário que entende MCP uma entrada definida pelo protocolo que ele pode usar ao aplicar políticas por ferramenta; a autenticação e a autorização ainda precisam ser aplicadas pelo gateway/servidor, em vez de inferidas apenas a partir do cabeçalho (Documentação de autenticação e segurança do MCP).

Limite de taxa por ferramenta ou locatário. A especificação define a limitação de taxa por locatário como um uso intermediário pretendido de cabeçalhos espelhados, com a verificação de versão como condição de segurança (limitação de taxa).

Observe com dimensões úteis. O nome do método e da ferramenta disponível sem a análise do corpo é exatamente o que a telemetria por ferramenta exige, e isso se alinha às convenções de chamada de ferramenta que estão surgindo nos padrões de telemetria (documentação de análise e rastreamento).

Remova a afinidade de sessão MCP da camada de transporte. Com as sessões em nível de protocolo removidas e os fluxos de resposta limitados a solicitações individuais, o transporte MCP não requer mais roteamento fixo ou um armazenamento de sessão MCP compartilhado. As aplicações ainda podem manter um estado durável por trás de identificadores explícitos ou armazenamentos compartilhados, portanto, "transporte sem estado" não deve ser interpretado como "aplicação sem estado". Para obter informações sobre o formato de transporte anterior de 2025, consulte nosso comparação entre stdio e HTTP transmissível; padrões gerais de distribuição de gateway são discutidos em failover e balanceamento de carga.

Uma obrigação funciona no sentido inverso e se aplica a qualquer coisa que esteja no caminho. Um intermediário que não reconheça um Mcp-Param-{Name} cabeçalho deve encaminhá-lo e, caso contrário, ignorá-lo. Remover cabeçalhos desconhecidos — um padrão comum em proxies protegidos — quebrará servidores em conformidade que os esperam.

Onde um harness de agente se encaixa. O transporte ainda precisa de um chamador que decida quando uma ferramenta deve ser invocada. TrueForge, o harness de agente de código aberto da TrueFoundry, executa esse loop de execução em chamadas de modelo, ferramentas MCP remotas, habilidades, sandboxing, aprovações, gerenciamento de contexto e estado de sessão. Seu conector MCP oferece suporte a servidores remotos com autenticação de cabeçalho ou OAuth, incluindo uma pausa de autorização no chat quando um usuário ainda não conectou um servidor. Isso torna a separação clara: o TrueForge orquestra a etapa do agente; o HTTP transmissível define o contrato de comunicação cliente-servidor; e um Gateway MCP da TrueFoundry pode controlar o tráfego de ferramentas que é deliberadamente roteado por ele. Nenhuma dessas camadas substitui as outras.

8. Uma Postura Implantável

Se você opera servidores MCP, valide Origem, autentique conexões e vincule servidores locais de forma conservadora antes de se preocupar com o refinamento do streaming. Em seguida, emita X-Accel-Buffering: no em respostas SSE e comentários keep-alive em fluxos de longa duração; timeouts de buffer e de inatividade podem se disfarçar como latência de aplicação ou falha de streaming. Valide a concordância entre cabeçalho e corpo em vez de confiar apenas em um deles, e decodifique valores codificados por sentinela antes de comparar. Para tráfego de revisões anteriores do Streamable HTTP, retorne o comportamento de compatibilidade especificado — 405 em GET e DELETE, e ignore os cabeçalhos de sessão e event-id — para que clientes mais antigos falhem ou se adaptem de forma previsível.

Se você opera um intermediário no caminho, encaminhe cabeçalhos Mcp-Param-* desconhecidos, verifique a versão do protocolo antes de tratar cabeçalhos espelhados como autoritativos e aproveite o que o espelhamento foi criado para permitir: roteamento, entradas de política, limitação de taxa e telemetria baseada no método e no nome da ferramenta, sem desserializar cada payload. O cabeçalho fornece metadados; sua camada de identidade e autorização ainda decide se o chamador pode realizar a ação.

Se você está escrevendo um cliente, suporte ambos os tipos de conteúdo de resposta, trate linhas de comentário SSE como ignoráveis e siga a sequência de fallback — tente uma solicitação moderna e, em um 400 inspecione o corpo antes de concluir qualquer coisa, já que servidores modernos também retornam 400 para versões não suportadas e falhas de validação de cabeçalho. Um erro moderno reconhecido significa tentar novamente em vez de recorrer ao fallback.

9. O que o protocolo resolve — e o que não resolve

O transporte de 2026-07-28 simplifica o contrato de rede; ele não decide a lógica de negócios do agente. Ele remove a afinidade de sessão em nível de MCP, define como funcionam o streaming e as tentativas de repetição com escopo de solicitação e fornece aos intermediários metadados validados que podem ser usados para roteamento e entradas de política. Ele não escolhe qual ferramenta um agente deve chamar, não concede ao chamador permissão para usar essa ferramenta, não define política de aprovação, não persiste a memória da aplicação nem prova que um efeito colateral downstream foi autorizado pelo sistema de registro.

Essas responsabilidades pertencem a camadas adjacentes. Um runtime de agente como o TrueForge detém o loop de execução e pode gerenciar conectores MCP, aprovações, contexto e estado da sessão. Um Gateway MCP da TrueFoundry pode centralizar autenticação, autorização, acesso a ferramentas e observabilidade para o tráfego roteado através dele. O servidor MCP e a aplicação downstream ainda são responsáveis por suas próprias autorizações de negócio e efeitos. Manter esses limites explícitos é mais útil do que tratar um transporte mais limpo como um modelo completo de segurança de agentes.

Por fim, este artigo descreve uma revisão de uma especificação em rápida evolução. Os níveis de requisitos aqui apresentados baseiam-se no texto de 28/07/2026; clientes e servidores reais podem estar em versões anteriores, e a especificação prevalece sobre qualquer resumo. Esta publicação também não afirma que uma versão específica do Gateway TrueFoundry implantada consuma internamente todos os cabeçalhos espelhados de 28/07/2026.

Referências

• Protocolo de Contexto de Modelo — Especificação de transporte HTTP transmissível (28/07/2026), a fonte para os mecanismos de transporte, base de segurança, metadados de solicitação, validação e regras de compatibilidade descritas aqui.
• Protocolo de Contexto de Modelo — Registro de alterações de 28/07/2026, e oRevisão de transporte de 25/11/2025 para o formato anterior.
• Protocolo de Contexto de Modelo — Solicitações de Múltiplas Idas e Voltaseassinaturas.
• TrueFoundry — stdio vs. HTTP transmissível — contexto de transporte anterior;autenticação e segurança MCP;limitação de taxa;análise.
• TrueForge — ambiente de execução de agentes de código abertoeconfiguração do servidor MCP, documentando conectores MCP remotos com autenticação via cabeçalho ou OAuth, autorização no chat, aprovações, gerenciamento de contexto e sessões persistentes.

Mecanismos, níveis de requisitos, nomes de cabeçalhos, códigos de erro, regras de compatibilidade e requisitos de segurança de estado MRTR são parafraseados do texto da especificação de 28/07/2026 vinculado; o exemplo de solicitação foi adaptado da própria ilustração da especificação. O design de rede HTTP remoto do MCP mudou materialmente ao longo de três eras, e a especificação prevalece sobre este resumo. As alegações de produto da TrueFoundry limitam-se às capacidades documentadas nas páginas atuais vinculadas; esta publicação não afirma que uma versão específica do gateway implantada utilize internamente todos os cabeçalhos espelhados de 28/07/2026.

‍