Capítulo 5 — Protocolos de Transporte e Descoberta

Quinta postagem do passeio capítulo a capítulo pelo LLM Primer IV: Projetando a Cognição da IA com MCP. Cada mensagem dos Capítulos 3 e 4 esteve flutuando no ar entre host e servidor — mas mensagens não flutuam, elas pegam carona em um transporte, e o transporte decide silenciosamente quase tudo de operacional sobre uma integração.

Por que este capítulo existe

O MCP define seu formato de mensagem — JSON-RPC 2.0 sobre um canal duplex — e então define três transportes que implementam o canal. Os transportes não são intercambiáveis. Cada um se encaixa num padrão de deployment, carrega bagagem operacional diferente, e expõe superfícies de segurança diferentes. Uma segunda pergunta paira sobre o mesmo território: como um host encontra um servidor para começo de conversa? Até que o host saiba que um servidor existe e onde mora, o protocolo mais belamente especificado não produz nenhuma conversa.

Este capítulo percorre ambos. Os transportes decidem se o servidor é co-localizado ou remoto, se você tem autenticação ou isolamento de processo, e como o servidor escala. A camada de descoberta decide se seu servidor é algo que um engenheiro usa ou algo que um time pode adotar.

5.1 stdio, SSE e Streamable HTTP

stdio é o host lançando o servidor como processo filho. O host escreve JSON-RPC no stdin do filho e lê respostas do stdout; stderr carrega logs. Sem porta, sem socket, sem rede. A autenticação é tratada pela fronteira de lançamento de processo do SO. Claude Desktop, Cursor, e o inspector oficial de MCP todos usam stdio para servidores locais. O modelo é honesto sobre o que é: uma ferramenta na sua própria máquina, co-localizada, no mesmo domínio de confiança que o host. Não pode ser compartilhada entre hosts, não pode rodar em outra máquina, e um-por-host é a única multiplicidade disponível — cinco clientes querendo o mesmo servidor queimam cinco processos.

HTTP+SSE foi a primeira resposta do MCP para o caso de rede. Bidirecional, mas duplex aparafusado a partir de duas peças unidirecionais. Depreciado. Ainda solto por aí. Você vai encontrar servidores baseados em SSE por algum tempo ainda.

Streamable HTTP é o transporte de rede preferido. Um endpoint único — tipicamente /mcp — aceita requisições JSON-RPC e responde ou com uma resposta única (para chamadas síncronas) ou com um stream de Server-Sent Events quando há múltiplas mensagens, incluindo notificações iniciadas pelo servidor. Sessões são identificadas por um cabeçalho Mcp-Session-Id definido na inicialização e passado em toda requisição subsequente. A sessão é a unidade de estado, liberável por DELETE ou colhida por timeout. O transporte compõe limpo com load balancers, reverse proxies, edge caches e TLS. Escalonamento horizontal é sticky-session por session ID. Nada disso é engenharia HTTP nova; o ponto é que o MCP se encaixa lá dentro sem inventar uma camada nova.

A escolha é tanto uma decisão de segurança quanto de deployment. Servidores stdio tendem a privilégio excessivo — herdam os direitos de filesystem e rede do usuário, sem autenticação porque não há chamador remoto. Servidores de rede encaram a internet aberta e devem autenticar cada requisição, com OAuth 2.1 agora sendo o padrão convergente. Escolher o transporte errado para sua postura de segurança força você a parafusar depois o que deveria ter sido embutido desde o começo.

5.2 Descoberta de servidor: .well-known/mcp.json e Server Cards

Um protocolo que exige que todo host seja configurado à mão com o endereço de todo servidor não vira ecossistema. Vira pesadelo de configuração. A camada de descoberta do MCP toma emprestado o padrão de URI well-known da RFC 8615 — o mesmo mecanismo usado por robots.txt e .well-known/openid-configuration. Um servidor publica .well-known/mcp.json na sua URL base. Um host busca, parseia e aprende o que o servidor afirma sobre si: o endpoint MCP, a versão de protocolo, o esquema de auth, metadados de identidade, e um ponteiro para o Server Card.

O Server Card é o openapi.json do MCP: um artefato auto-descritivo que máquinas e humanos podem ambos consumir. Um host pode mostrar o card ao usuário durante o fluxo de conexão — "este servidor diz que pode acessar seu workspace Linear, vai ler tickets mas não apagá-los, é operado pela própria Linear, usa OAuth" — e o usuário pode decidir se a alegação é aceitável. Os cards em sua forma não assinada são alegações, não prova. A mitigação é atestação assinada, com um modelo de assinatura que convergiu para OIDC estilo sigstore: um card assinado via integração OIDC do GitHub sob github.com/some-org/mcp-server pode ser verificado por qualquer host que confie nas alegações de identidade do GitHub. Hosts podem empilhar política em cima — confiar só em cards assinados, só em cards assinados de um provedor específico, só naqueles fora de uma lista de revogação.

O fluxo se parece com adicionar uma rede Wi-Fi. Uma vez. O host guarda a configuração; sessões subsequentes pulam a descoberta. O que "algo mudou" significa na prática — bumps de versão, expansões de escopo, mudanças de capacidade — deveria disparar renovação de consentimento, do mesmo jeito que uma mudança de certificado TLS faz. Hosts que pulam esse passo deixam servidores expandir silenciosamente seu alcance ao longo do tempo, que é exatamente o lento creep de capacidade que compromete a confiança em qualquer integração de vida longa.

5.3 As partes sem glamour que decidem se você entrega

Três preocupações operacionais merecem tratamento próprio porque cada uma é um lugar onde implementação descuidada produz ou integrações quebradas ou buracos de segurança.

CORS importa para qualquer servidor MCP alcançável a partir de um host baseado em navegador. A tentação é setar Access-Control-Allow-Origin: * e seguir. Isso está errado. Combinado com auth de cookie é um desastre de CSRF; combinado com bearer tokens em localStorage é um risco de exfiltração de token. Use uma allowlist por origem, e prefira cabeçalhos Authorization a cookies para que same-origin não seja sua única linha de defesa.

Validação de origem é CORS aplicada no lado servidor, porque clientes não-navegador não aplicam nada. A falha clássica: um desenvolvedor roda um servidor MCP em localhost:8000, visita uma página web que conhece a convenção, a página dispara uma requisição, e o servidor — sem checagem de origem — faz o que a página pediu. Valide Origin em cada servidor Streamable HTTP.

Cabeçalhos de caching são o terceiro. Documentação estática pode ser cacheada agressivamente; uma linha de banco somente enquanto subscriptions estiverem fiadas; um documento sendo editado ativamente, de jeito nenhum. Retorne o Cache-Control e ETag certos por resource. A interação entre caching e subscriptions é onde engenheiros se machucam — um intermediário que serve uma cópia velha significa que a notificação resources/updated do host nunca dispara, porque o mecanismo de subscription nunca chega ao servidor ao vivo.

DNS rebinding completa a vizinhança e afeta desproporcionalmente servidores locais. Bind em 127.0.0.1 não em 0.0.0.0, valide o cabeçalho Host contra uma allowlist, exija token de auth mesmo para localhost. Um servidor MCP local sem isso está a uma demo de virar um advisory de segurança.

O que o Capítulo 5 prepara

Isso fecha a Parte II do livro. Temos o protocolo na mão: primitivas de servidor no Capítulo 3, primitivas de cliente no Capítulo 4, a camada de wire e descoberta aqui. Sabemos que mensagens trafegam, em que direção, sobre qual transporte, entre quais domínios de confiança, após qual handshake. A Parte III vira de primitivas para padrões. Um servidor único conectado a um host único é útil; o payoff arquitetural do MCP é composição — múltiplos servidores, múltiplos agentes, múltiplos modelos, cooperando rumo a metas maiores.

Próximo — Capítulo 6: Estratégias Fundamentais de Orquestração. Quando um único agente bem-equipado bate um design multi-agente, e os dois formatos fundamentais — pipelines sequenciais e concorrência scatter-gather — em que a maioria dos deploys em produção se apoia.