Model Context Protocol (MCP) em Produção: Transporte Streamable HTTP, Injeção Indireta e o Custo Real de Contexto

Em novembro de 2024, a Anthropic publicou a versão inicial do Model Context Protocol (MCP) com uma promessa ambiciosa: resolver para os agentes de inteligência artificial o mesmo problema de fragmentação que o Language Server Protocol (LSP) resolveu para as IDEs e compiladores em 2016. Em vez de cada host de IA — Claude Desktop, Codex CLI, Cursor, gateways empresariais — implementar um conector proprietário para cada banco de dados, repositório Git ou API externa, o mercado ganharia uma interface universal baseada em JSON-RPC 2.0.

Menos de dois anos depois, o protocolo amadureceu: a especificação formal versão 2026-07-28 consolidou o padrão aberto mantido sob governança comunitária, formalizou a transição de transporte para Streamable HTTP e aposentou modelos legados de conexão persistente. Contudo, quando equipes de engenharia movem o MCP de experimentos locais na máquina do desenvolvedor para clusters de produção e frotas de agentes autônomos, deparam-se com desafios severos de infraestrutura: consumo explosivo da janela de contexto (context bloat), cascata de latência no roundtrip de inferência, vetores críticos de injeção indireta de prompt e a necessidade de isolamento criptográfico de credenciais.

O precedente arquitetural: de LSP (2016) para MCP

Para compreender as decisões de design do MCP, é indispensável examinar o precedente estabelecido pela Microsoft em 2016 com o Language Server Protocol (LSP).

Antes do LSP, conectar M editores de código (VS Code, Neovim, Emacs, Sublime Text) a N linguagens de programação (TypeScript, Rust, Python, Go, C#) exigia construir e manter M x N plugins independentes. Cada plugin precisava implementar seu próprio parser, indexador de AST e analisador semântico para entregar autocomplete e go-to-definition. O LSP reduziu essa complexidade para M + N: cada editor implementa um único cliente LSP, e cada ecossistema de linguagem mantém um único servidor de linguagem.

O MCP replica com exatidão matemática essa topologia para o ecossistema de agentes e modelos fundacionais:

[ Hosts de IA / Clientes MCP ]               [ Fontes de Dados & Ferramentas ]
  • Claude Desktop / Codex CLI                  • PostgreSQL / SQLite
  • IDEs (Cursor / VS Code / MVCode)            • GitHub / GitLab
  • Gateways Corporativos Multiagente           • Slack / Notificações
            \                                            /
             \                  JSON-RPC 2.0            /
              ==========================================
                      Model Context Protocol (MCP)

Assim como o LSP padronizou métodos como textDocument/completion e textDocument/definition, a especificação formal do MCP padronizou três primitivas fundamentais que o servidor expõe ao cliente:

1. Tools (tools/list, tools/call): Ações executáveis com efeito colateral no mundo real ou consultas ativas com entrada e saída estruturadas via JSON Schema.
2. Resources (resources/list, resources/read): Dados de contexto somente-leitura (documentos, esquemas de tabelas, logs estruturados) identificados por URIs padronizadas.
3. Prompts (prompts/list, prompts/get): Modelos de prompt parametrizáveis e fluxos de conversa reutilizáveis controlados pelo servidor.

A evolução do transporte: STDIO vs. Streamable HTTP

A forma como mensagens JSON-RPC trafegam entre o host do agente e o servidor MCP dita a segurança, a latência e os limites de concorrência do sistema. A revisão formal da especificação 2026-07-28 reorganizou as camadas de transporte, descontinuando formalmente o modelo HTTP + SSE da versão de novembro de 2024 (via SEP-2596) e estabelecendo dois canais canônicos.

1. STDIO (Standard Input / Output): o padrão local

No transporte STDIO, o host do agente executa o binário do servidor MCP como um subprocesso filho direto no sistema operacional:

• Canal de Comunicação: O cliente envia comandos JSON-RPC através de stdin do processo filho; o servidor responde e emite eventos via stdout.
• Framing Rígido: Cada mensagem JSON-RPC é estritamente delimitada por quebra de linha (\n) em formato UTF-8 e não pode conter quebras de linha embutidas no payload JSON.
• Isolamento de Logs: O canal de stderr é reservado exclusivamente para logs diagnósticos e telemetria legível, garantindo que saídas de debug de bibliotecas nunca corrompam o parser JSON-RPC no stdout.
• Encerramento Gracioso: O cliente encerra a sessão fechando o stream de stdin. Caso o processo não finalize no tempo limite, o host escala para sinais POSIX (SIGTERM seguido de SIGKILL) ou TerminateProcess no Windows.

O STDIO oferece latência de transporte sub-milissegundo (abaixo de 1 ms) e simplificação operacional para ferramentas de desktop, mas não escala para arquiteturas distribuídas em nuvem onde dezenas de agentes concorrentes compartilham instâncias centralizadas de microsserviços.

2. Streamable HTTP: a arquitetura stateless para produção

Para servidores remotos e clusters em nuvem, a especificação introduziu o padrão Streamable HTTP (SEP-2567 e SEP-2575):

Ao contrário da versão legada — que mantinha uma conexão HTTP GET de streaming Server-Sent Events (SSE) aberta por longos períodos com identificadores de sessão (Mcp-Session-Id) —, o Streamable HTTP adota um modelo estritamente stateless baseado em requisições POST atômicas:

• Endpoint Único: O servidor expõe uma URL base (por exemplo, https://api.empresa.com/mcp) aceitando exclusivamente o método POST.
• Negociação de Resposta via Content-Type: O cliente envia a requisição POST incluindo o cabeçalho Accept: application/json, text/event-stream. O servidor pode responder de duas formas:
  1. Content-Type: application/json: Resposta síncrona tradicional para execuções rápidas e determinísticas.
  2. Content-Type: text/event-stream: Um stream SSE delimitado exclusivamente ao escopo temporal daquela requisição, permitindo emitir notificações de progresso (notifications/progress) ou logs intermediários antes do payload JSON-RPC final.
• Cancelamento por Quebra de Conexão: Caso o host decida abortar uma ação, fechar a conexão HTTP subjacente atua como o gatilho canônico para o servidor interromper o processamento no backend.

Transição para modelo stateless e inspeção de cabeçalhos

A especificação 2026-07-28 eliminou a obrigatoriedade do handshake síncrono de inicialização (initialize / notifications/initialized). Em vez disso:

• Metadados por Requisição (_meta): A versão do protocolo e as capacidades do cliente viajam anexadas em cada mensagem JSON-RPC sob o campo _meta (por exemplo, io.modelcontextprotocol/protocolVersion: "2026-07-28").
• Espelhamento em Headers HTTP: Para permitir que firewalls de aplicação (WAF), gateways de API e balanceadores de carga realizem roteamento inteligente e rate-limiting sem realizar o parse completo do corpo JSON, os metadados são espelhados em cabeçalhos HTTP:
  • MCP-Protocol-Version: 2026-07-28 (com validação estrita contra o payload, gerando erro -32020 HeaderMismatchError em caso de divergência).
  • Mcp-Method: tools/call
  • Mcp-Name: <nome_da_ferramenta>
• Multi Round-Trip Requests (MRTR — SEP-2322): Para fluxos que necessitam de confirmação humana ou dados adicionais do usuário durante a execução, o servidor não faz requisições inversas client-bound arbitrárias. Ele retorna um resultado InputRequiredResult (resultType: "input_required"), permitindo que o cliente solicite a intervenção e refaça a chamada fornecendo os inputResponses.

O mapa de ameaças OWASP e a segurança em Tool Calling

Conectar um modelo fundacional com permissão de execução a ferramentas corporativas cria superfícies de ataque que não existiam no software tradicional. As diretrizes do OWASP Top 10 for LLM Applications (2025/2026) mapeiam essas vulnerabilidades com rigor.

1. LLM01:2025 — Indirect Prompt Injection via Tool Outputs

O vetor de ataque mais prevalente ocorre quando um agente consome saídas de ferramentas que contêm dados não confiáveis externos (leitura de páginas web, análise de tickets em CRM, leitura de arquivos em repositórios abertos).

Se um servidor MCP executa resources/read em um documento PDF ou HTML contendo uma instrução maliciosa embutida — como comentários ocultos instruindo o modelo a ignorar suas diretrizes e disparar ferramentas destrutivas —, o modelo fundacional pode ser induzido a tratar esse texto injetado como comando operacional de prioridade máxima.

[ Usuário ] ──> [ Agente LLM ] ──> [ MCP Tool: Web Scraper ] ──> [ Site Externo ]
                      │                                                   │
                      │ <─── Output com Prompt Injection Oculto ──────────┘
                      ▼
       [ Execução Não Autorizada de Ferramenta Destrutiva ]

Defesas de Engenharia no Gateway

• Delimitação Semântica e Content Tagging: Envelopar todas as saídas de ferramentas em delimitadores estruturados explícitos (como blocos protegidos e tags de dados não confiáveis) que declarem que o conteúdo interno é dado cru não executável.
• Validação Estruturada de Saída (outputSchema): Todo servidor MCP em produção deve declarar esquemas rígidos de saída via JSON Schema 2020-12. O gateway valida a resposta antes de injetá-la no contexto do modelo; respostas malformadas ou com injeções grosseiras de controle são descartadas na borda.
• Scanners de CI para Servidores MCP: Ferramentas emergentes de auditoria estática e simulação de injeção, como o MCP Observatory (KryptosAI/mcp-observatory, lançado em agosto de 2026), testam servidores contra schema drift e injeção adversarial antes do deploy em produção.

2. LLM06:2025 — Excessive Agency e a Regra de Dois (Rule-of-Two)

A vulnerabilidade de autonomia excessiva surge quando o agente recebe ferramentas com escopo mais amplo do que o necessário (excessive functionality), credenciais com privilégios de superusuário no banco (excessive permissions) ou capacidade de executar mutações sem portão de aprovação (excessive autonomy).

A resposta arquitetural adotada em engenharia avançada de agentes é a Regra de Dois (Rule-of-Two):

• Agente Não Confiável (Low-Trust / Sandbox): O agente responsável por ingestão web, leitura de documentos externos ou parsing de código roda confinado em sandbox sem acesso a secrets, chaves de escrita ou tokens de infraestrutura.
• Gateway de Execução (SafeExecutor / Policy Enforcement): Ações com impacto colateral — mutação de banco, emissão de ordens de pagamento, deploy de código — passam por um gateway desacoplado com verificação determinística de políticas (como o padrão de referência decionis/agent-safe-pipeline), exigindo aprovação humana explícita (Human-in-the-Loop) ou tokens de uso único.

3. Autenticação estrita: OAuth 2.1 e RFC 8707 Resource Indicators

Para servidores MCP remotos, o protocolo estabelece conformidade mandatória com OAuth 2.1:

• RFC 8707 Resource Indicators: Todo token de acesso emitido para um servidor MCP deve conter o parâmetro resource conforme a RFC 8707 do IETF, atrelando a validade do token estritamente à URI do servidor de destino.
• Proibição Expressa de Token Passthrough: Um servidor MCP intermediário é proibido de reutilizar o token que recebeu do cliente para autenticar-se em serviços subsequentes (downstream). A validação de audiência (aud) no servidor previne ataques de replay e escalonamento lateral de privilégios.
• PKCE Mandatório: Clientes MCP que utilizam o fluxo Authorization Code devem obrigatoriamente implementar PKCE com o método S256 (code_challenge_method=S256).

O custo oculto: overhead de contexto e latência de roundtrip

Integrar dezenas de ferramentas MCP traz uma penalidade quantitativa imediata que costuma ser negligenciada na fase de prototipagem: o custo de tokens e a degradação de acurácia.

O imposto dos schemas JSON (Context Bloat)

Cada ferramenta exposta ao agente precisa ser descrita em JSON Schema para que o LLM compreenda o nome, a finalidade semântica, os tipos de argumentos, os campos obrigatórios e os enums aceitos.

Tool Schema Típico (JSON Schema)  ───────>  150 a 500 tokens por ferramenta
Catálogo com 50 ferramentas MCP    ───────>  7.500 a 25.000 tokens por requisição

Em um sistema com 50 ferramentas disponíveis, cada interação do usuário carrega um custo fixo de 15.000 a 25.000 tokens de entrada antes mesmo que a primeira palavra da resposta seja gerada. Se o diálogo possui 10 turnos, o consumo ultrapassa centenas de milhares de tokens, inflando a fatura de inferência e reduzindo o espaço útil para a memória de trabalho do agente.

Degradação de precisão: as medições do BFCL

Evidências empíricas consolidadas pelo Berkeley Function Calling Leaderboard (BFCL) do projeto Gorilla da UC Berkeley comprovam que a taxa de sucesso na seleção da ferramenta correta decai de forma não linear quando a contagem de ferramentas ativas excede 20 definições no mesmo prompt. O modelo sofre com interferência de atenção (distraction effect) e alucinação de argumentos.

Precisão de Seleção de Ferramenta vs. Número de Tools no Prompt
100% ├───────────┐
 95% │           └────────┐
 90% │                    └──────────┐
 80% │                               └─────────────────────
  0% └─────────────────────────────────────────────────────
     0           10       20         30         50+  (Tools Ativas)

Soluções arquiteturais: Dynamic Tool Retrieval e Cache Determinístico

Para contornar o problema do context bloat, os sistemas modernos de engenharia aplicam duas estratégias:

1. Dynamic Tool Retrieval (Semantic Tool Search): Em vez de injetar o catálogo completo de 60 ferramentas no system prompt, o orquestrador mantém um índice de busca semântica (vetorial ou BM25) com as assinaturas das ferramentas. Quando o usuário faz um pedido, um classificador leve seleciona apenas as 3 a 5 ferramentas relevantes para aquela intenção específica, reduzindo o consumo de tokens em até 85%.
2. Prompt Prefix Caching e Ordenação Determinística: Provedores de modelos fundacionais (Anthropic, OpenAI) utilizam cache de prefixo de prompt para reduzir a latência de TTFT (Time to First Token) em até 80% e o custo de tokens cacheados em 90%. Para garantir que o cache seja aproveitado, a especificação MCP versão 2026-07-28 instrui que a listagem de ferramentas em tools/list seja retornada em ordem determinística estável (ordenação alfabética por nome), evitando invalidações desnecessárias de cache causadas por variações na serialização JSON.

A cascata de latência do roundtrip

A execução de uma ferramenta via MCP compõe uma sequência de múltiplos saltos temporais:

1. Inferência de Decisão (LLM-1): O modelo processa o prompt e gera a chamada de ferramenta estruturada (~300–900ms).
2. Despacho e Validação no Gateway: Validação de esquema e permissões (~5–15ms).
3. Transporte de Rede: Chamada Streamable HTTP POST (~10–60ms).
4. Execução no Servidor de Backend: Processamento no banco de dados ou API externa (~50–2.000ms).
5. Re-injeção de Contexto: Adição do resultado no histórico do diálogo (~5ms).
6. Inferência de Síntese Final (LLM-2): O modelo lê o resultado da ferramenta e redige a resposta final para o usuário (~500–1.500ms).

Em fluxos com ferramentas encadeadas (multi-turn tool calling), a latência percebida pode ultrapassar 10 segundos se a arquitetura não adotar streaming de eventos de progresso (notifications/progress) para manter o usuário informado durante a execução.

Engenharia de confiabilidade: o padrão Fail-Closed

Operar servidores MCP em missão crítica exige abandonar o comportamento otimista e adotar garantias formais de confiabilidade:

1. Princípio Fail-Closed (Falha Segura): Se um servidor MCP retornar um erro de schema, expirar o timeout de execução ou responder com status HTTP 5xx, o orquestrador do agente deve abortar imediatamente a operação com erro explícito. O agente nunca deve tentar adivinhar o resultado de uma consulta falha nem assumir que uma mutação foi concluída com sucesso sem confirmação determinística.
2. Chaves de Idempotência Obrigatórias (Idempotency Keys): Em redes distribuídas, falhas de timeout em requisições POST criam a incerteza clássica: a ação falhou antes de ser executada ou a resposta se perdeu no caminho de volta? Toda ferramenta MCP que realize operações de escrita ou mutação financeira/operacional deve exigir uma chave de idempotência (idempotency_key) gerada pelo cliente no payload de argumentos. Se o host retransmitir a chamada após um timeout, o servidor reconhece a chave e não duplica a operação.
3. Circuit Breakers e Timeouts Granulares: Servidores MCP remotos devem operar sob circuit breakers na camada do gateway. Se um servidor externo degradar e falhar em mais de 50% das requisições em uma janela de 30 segundos, o circuito abre e as chamadas subsequentes falham instantaneamente sem bloquear as filas de processamento dos agentes.
4. Rastreabilidade Distribuída (OpenTelemetry / SEP-414): A integração do MCP com a especificação W3C Trace Context via convenção SEP-414 estabelece que cabeçalhos traceparent e tracestate sejam propagados dentro de _meta em todas as mensagens JSON-RPC, permitindo que ferramentas como Grafana, Jaeger e Datadog rastreiem a jornada completa de uma requisição desde o prompt inicial do usuário até a query SQL no microsserviço de destino.

Como o MaxVision Code estrutura seu ecossistema MCP

No ecossistema do MaxVision Code — nossa plataforma de desenvolvimento autônomo e ferramentas de engenharia —, o Model Context Protocol não é um detalhe de implementação, mas a fundação arquitetural que governa as frotas de agentes:

• Isolamento via Tool Gateway: Nossos agentes de pesquisa e coding operam sob sandbox estrita, sem tokens de infraestrutura. Todas as chamadas MCP passam por uma sessão autenticada com token efêmero (X-Paperclip-Tool-Gateway-Token), onde cada permissão é validada contra o catálogo efetivo do perfil antes do despacho.
• Roteamento Dinâmico de 8 Ferramentas: Em vez de poluir a janela de contexto com todos os esquemas simultâneos, o orquestrador despacha dinamicamente ferramentas especializadas (como os conectores MCP para LinkedIn, X, TikTok, YouTube, automações de n8n e Media Forge) apenas quando o fluxo de trabalho exige.
• Execução Determinística e Auditoria: Cada invocação de ferramenta gera um registro imutável com identificador único (invocationId), capturando parâmetros, tempo de execução e resposta para auditoria de compliance e depuração determinística.

O resultado é um ambiente onde agentes de IA podem interagir com sistemas reais de software e pipelines de deploy com previsibilidade matemática, segurança anti-injeção e mínimo overhead de contexto.

Checklist de implementação para servidores MCP em produção

Antes de promover um servidor MCP para o ambiente de produção, certifique-se de que sua arquitetura atende aos seguintes requisitos:

• Transporte Adequado: STDIO adotado apenas para ferramentas locais monolíticas; Streamable HTTP (POST stateless) utilizado para servidores remotos em nuvem.
• Validação de Versão e Cabeçalhos: Validação estrita do cabeçalho MCP-Protocol-Version contra o metadado _meta.io.modelcontextprotocol/protocolVersion.
• Delimitação Semântica: Saídas de ferramentas que processam conteúdo web ou documentos externos envelopadas em tags de dados não confiáveis.
• Defesa contra Injeção Indireta: Sanitização determinística e validação de outputSchema antes da reinjeção no contexto do LLM.
• Menor Privilégio (PoLP): Separação rigorosa entre servidores de leitura (read-only) e ferramentas de mutação (write/execute).
• OAuth 2.1 com RFC 8707: Tokens vinculados explicitamente ao servidor via parâmetro resource e PKCE com S256 habilitado.
• Otimização de Contexto: Adoção de busca dinâmica de ferramentas (Semantic Tool Search) caso o catálogo ultrapasse 15 a 20 ferramentas.
• Ordenação Determinística: Ferramentas retornadas em ordem alfabética estável em tools/list para maximizar o Prompt Prefix Caching.
• Idempotência e Timeouts: Chaves de idempotência em mutações e timeouts estritos configurados por ferramenta.
• Rastreabilidade W3C: Propagação de traceparent no metadado _meta para observabilidade em microsserviços.

Fontes primárias citadas

• Especificação Oficial do Model Context Protocol: modelcontextprotocol.io e repositório oficial da especificação modelcontextprotocol/modelcontextprotocol (versão formal 2026-07-28, revisando os SEPs 2567, 2575, 2322 e 2596).
• Language Server Protocol (LSP): Documentação técnica e repositório de referência da Microsoft em microsoft/language-server-protocol.
• OWASP GenAI Top 10 (2025/2026): Projeto e taxonomia de vulnerabilidades em grandes modelos de linguagem em OWASP/www-project-top-10-for-large-language-model-applications (destaque para LLM01:2025 Prompt Injection e LLM06:2025 Excessive Agency).
• IETF RFC 8707 — Resource Indicators for OAuth 2.0: Especificação de audiência e restrição de tokens em RFC 8707 e especificações do Draft OAuth 2.1.
• Berkeley Function Calling Leaderboard (BFCL / Gorilla): Benchmarks de precisão em chamadas de função e penalidades de distração em catálogos extensos em ShishirPatil/gorilla.
• W3C Distributed Tracing Standard: Especificação formal do W3C Trace Context e convenções do MCP SEP-414 para telemetria distribuída.
• Ecossistema Aberto de Segurança e Agentes (Agosto de 2026): Scanner de segurança KryptosAI/mcp-observatory, pipeline de execução segura decionis/agent-safe-pipeline e ambiente colaborativo yetone/cumora.