Neste guia, você verá:
- O histórico das tecnologias de transporte MCP e por que a mudança de SSE para Streamable HTTP aconteceu.
- O que é o SSE e como ele era usado em versões anteriores do MCP.
- O que é o Streamable HTTP e como ele é aplicado na versão atual do MCP.
- Uma tabela de resumo comparando SSE e Streamable HTTP.
- Como se manter atualizado sobre os desenvolvimentos das especificações de protocolo.
Vamos mergulhar de cabeça!
Um pouco da história por trás dos protocolos de transporte usados pela MCP
O MCP(Modal Context Protocol), um dos protocolos de IA mais populares e amplamente usados atualmente, substituiu o mecanismo de transporte HTTP+SSE pelo Streamable HTTP a partir da versão 2025-03-26 do protocolo. Isso marcou uma mudança significativa na arquitetura do protocolo.
Agora, vamos entender melhor essa mudança antes de explicar o que são esses dois mecanismos de transporte.
Por que os protocolos de IA precisam de mecanismos de transporte
Os protocolos de IA, como o MCP, precisam de mecanismos de transporte para facilitar a troca de informações entre os diferentes componentes da arquitetura do protocolo.
Especificamente, o MCP usa o JSON-RPC 2.0 como seu formato de conexão entre clientes e servidores. Para a transmissão de mensagens JSON-RPC, ele se baseia em mecanismos de transporte padrão como HTTP+SSE ou Streamable HTTP (entre stdio – para comunicação sobre entrada e saída padrão em servidores locais).
Essas camadas de transporte especializadas são necessárias porque o modelo tradicional de solicitação-resposta do HTTP é ineficiente para a comunicação de IA em tempo real. Isso ocorre porque o HTTP simples apresenta alta sobrecarga e latência devido às frequentes configurações de conexão. Por outro lado, o MCP exige fluxos de dados contínuos e de baixa latência, algo que o HTTP+SSE e o Streamable HTTP foram projetados para lidar.
Por que a mudança foi feita
Inicialmente, o MCP usava HTTP+SSE para permitir o streaming de servidor para cliente em cenários remotos. No entanto, essas três grandes limitações justificaram a mudança:
- Não há suporte para fluxos retomáveis.
- Requer que o servidor mantenha uma conexão de longa duração e altamente disponível.
- Permite apenas que as mensagens do servidor sejam entregues via SSE.
O Streamable HTTP resolve esses problemas. Ele permite a comunicação sem estado e até mesmo suporta atualizações sob demanda para o SSE. Isso melhora a compatibilidade com a infraestrutura moderna e garante uma comunicação mais estável e eficiente.
Impacto da transição de HTTP+SSE para HTTP com streaming
A transição do HTTP+SSE para o Streamable HTTP como protocolo de transporte foi uma mudança importante para o MCP. Ela introduziu mudanças notáveis na implementação do protocolo, exigindo que muitas bibliotecas de clientes e servidores MCP de terceiros se adaptassem.
No entanto, até o momento em que este texto foi escrito, os clientes e servidores MCP podem manter a compatibilidade com versões anteriores do transporte HTTP+SSE obsoleto.
SSE (eventos enviados pelo servidor)
O SSE(Server-Sent Events) é um mecanismo que permite que os clientes da Web recebam atualizações automáticas de um servidor. Essas atualizações são conhecidas como “eventos” e são enviadas por meio de uma única conexão HTTP de longa duração.
Diferentemente dos WebSockets, o SSE é unidirecional, o que significa que os dados fluem apenas do servidor para o cliente. O SSE funciona com o servidor enviando um fluxo de eventos por essa conexão aberta, normalmente formatado como tipotext/event-streamMIME.
Uso de HTTP+SSE no MCP
Foi assim que o MCP contou com o SSE na versão 2024-11-05:
O servidor deve fornecer dois pontos de extremidade:
- Um ponto de extremidade SSE GET para que os clientes estabeleçam uma conexão e recebam mensagens do servidor.
- Um ponto de extremidade HTTP POST regular para que os clientes enviem mensagens JSON-RPC para o servidor.
Quando um cliente se conecta, o servidor deve enviar um evento de ponto de extremidade contendo um URI que o cliente usará para enviar mensagens. Todas as mensagens JSON-RPC do cliente são então enviadas como solicitações HTTP POST para esse URI.
O servidor responde transmitindo eventos pela conexão SSE aberta, simulando uma sessão persistente. Em detalhes, as mensagens do servidor são entregues como eventos de mensagem SSE, com o conteúdo codificado como JSON nos dados do evento.
Para respostas únicas, o servidor envia a mensagem e fecha o fluxo. Para a comunicação contínua, a conexão permanece aberta.
Prós e contras
Estes são os principais prós e contras do uso do SSE no MCP:
Transmissão de grandes resultados: Permite o envio imediato de resultados parciais, evitando atrasos enquanto as ferramentas de MCP processam dados grandes ou aguardam respostas de API externas.
Acionadores acionados por eventos: Oferece suporte a eventos de servidor não solicitados para notificar os clientes sobre alterações, com alertas ou atualizações de status.
Simplicidade: Usa HTTP padrão, não exigindo protocolos especiais ou configurações complexas.
Somente unidirecional: Os dados só podem fluir de servidores para clientes no canal SSE. Os clientes devem usar solicitações HTTP POST separadas para enviar mensagens.
Uso de recursos de conexão de longa duração: A manutenção de conexões abertas pode consumir muitos recursos do servidor, especialmente em escala.
HTTP transmitido
No contexto do MCP, o HTTP transmissível é um método de transmissão de dados entre o cliente e o servidor usando HTTP puro. Ele abre a porta para a comunicação em tempo real sem exigir conexões de longa duração.
Embora ele ainda possa usar o SSE para flexibilidade e compatibilidade com versões anteriores, esse método de transporte não é mais necessário. Isso permite que o MCP ofereça suporte a servidores sem estado sem a sobrecarga de manter conexões persistentes de alta disponibilidade.
ℹ️ Extra: Por que HTTP com streaming + SSE opcional em vez de WebSockets?
- O uso de WebSockets para chamadas RPC simples e sem estado adiciona uma sobrecarga operacional e de rede desnecessária.
- Os navegadores não podem anexar cabeçalhos como
Autorizaçãoaos WebSockets e, ao contrário do SSE, os WebSockets não podem ser reimplementados com ferramentas HTTP padrão. - As atualizações do WebSocket só funcionam com solicitações GET, tornando os fluxos baseados em POST complexos e mais lentos devido às etapas de atualização necessárias.
HTTP com streaming no MCP
No transporte Streamable HTTP, o servidor atua como um processo autônomo capaz de lidar com várias conexões de clientes. Ele usa solicitações HTTP POST e GET padrão para comunicação.
Opcionalmente, o servidor pode usar o SSE para transmitir várias mensagens para o cliente. Isso acomoda tanto servidores MCP básicos para ferramentas simples de solicitação/resposta quanto aqueles que oferecem recursos mais avançados, como streaming e notificações de servidor para cliente em tempo real.
O servidor deve expor um único ponto de extremidade HTTP (chamado de “ponto de extremidade MCP“) que ofereça suporte aos métodos POST e GET.
O diagrama abaixo ilustra o fluxo de comunicação entre clientes e servidores MCP usando Streamable HTTP:
Para dar suporte à retomada de conexões interrompidas e à reentrega de mensagens possivelmente perdidas, o servidor MCP atribui IDs por fluxo. Essas IDs funcionam como cursores em cada fluxo.
Dada a variedade de interações possíveis, consulte a documentação oficial do MCP para obter detalhes completos sobre a implementação.
Prós e contras
Estas são as principais vantagens de usar o Streamable HTTP no MCP:
👍 Suporte a servidores sem estado: Elimina a necessidade de conexões sempre ativas e de longa duração.
HTTP simples: pode ser implementado usando qualquer servidor HTTP padrão sem a necessidade de SSE.
Compatível com a infraestrutura: Compatível com middleware HTTP comum, proxies e plataformas de hospedagem.
Compatível com versões anteriores: É desenvolvido de forma incremental com base no transporte HTTP+SSE anterior.
Transmissão opcional: Os servidores podem fazer upgrade para SSE para respostas de streaming quando necessário.
Observação: no momento em que este artigo foi escrito, não havia nenhuma desvantagem no mecanismo de transporte Streamable HTTP que valesse a pena mencionar.
SSE vs. HTTP de fluxo contínuo: comparação resumida
Compare os dois mecanismos de transporte na tabela SSE vs. Streamable HTTP abaixo:
| Aspecto | HTTP+SSE | HTTP transmitido |
|---|---|---|
| Tipo de comunicação | Unidirecional (servidor → cliente) | Bidirecional (Cliente ↔ Servidor via GET/POST) |
| Uso do protocolo HTTP | GET para streaming, POST separado para mensagens do cliente | Usa HTTP POST e GET padrão de um único ponto de extremidade |
| Estado | Estatal | Estatal, mas suporta servidores sem estado |
| Requer conexão HTTP de longa duração | Sim | Não |
| Alta disponibilidade necessária | Sim, para persistência de conexão | Não, funciona com servidores sem estado ou efêmeros |
| Escalabilidade | Limitada | Alta |
| Suporte a streaming | Sim (via texto/fluxo de eventos) |
Sim (via SSE como aprimoramento opcional) |
| Suporte à autenticação | Sim | Sim |
| Suporte para a possibilidade de retomada e nova entrega | Não | Não |
| Número de clientes | Múltiplos | Múltiplos |
| Uso em MCP | Preterido desde a versão 2025-03-26 do protocolo |
Introduzido na versão do protocolo 2025-03-26 |
| Compatibilidade com versões anteriores | – | Totalmente compatível com versões anteriores de clientes baseados em SSE |
Futuro dos métodos de transporte no MCP
O MCP foi lançado em novembro de 2024, portanto, ainda é um protocolo muito novo. Para colocar isso em perspectiva, o HTTP 1.1 – a versão mais usada – existe há quase 20 anos.
Portanto, não é de surpreender que a especificação MCP ainda esteja evoluindo. Assim como alguns meses após o lançamento, a comunidade decidiu fazer a transição de SSE para Streamable HTTP, mais mudanças podem ocorrer em breve.
Mantenha-se atualizado verificando a página Discussões no repositório oficial do MCP no GitHub. O site do MCP também permite que você analise o rascunho mais recente da próxima versão do protocolo.
Conclusão
Nesta postagem do blog de comparação entre SSE e HTTP Streamable, você aprendeu por que o MCP fez a transição de SSE para HTTP Streamable. Em particular, você entendeu o que são esses dois mecanismos de transporte e como eles afetam a transmissão de informações no popular protocolo de IA MCP.
Conforme explicado aqui, os servidores MCP de terceiros que desejam seguir as especificações MCP mais recentes e não obsoletas devem implementar o Streamable HTTP. Se estiver procurando um servidor MCP atualizado, avançado e repleto de recursos, dê uma olhada no servidor MCP da Bright Data.
O servidor MCP da Bright Data foi desenvolvido com base na versão mais recente do fastmcp, garantindo suporte total ao Streamable HTTP e mantendo a compatibilidade com versões anteriores do SSE. Ele oferece mais de 20 ferramentas para expandir seus fluxos de trabalho de IA com dados novos da Web, interações do navegador do agente em qualquer página da Web e muito mais.
Para obter um tutorial completo, siga nosso artigo sobre a integração do Google ADK com um servidor MCP para o desenvolvimento de agentes de IA.
Crie uma conta da Bright Data gratuitamente hoje mesmo e teste nossa infraestrutura para alimentar seus agentes e aplicativos de IA!
