MCP em 2026: transport scaling, governance e enterprise readiness

Resposta atômica: O roadmap MCP 2026 prioriza três frentes: escalar Streamable HTTP horizontalmente sem state, evoluir o Tasks primitive (retry semantics + expiry policies), e maturar governance enterprise (audit, SSO, gateway). MCP suporta hoje apenas dois transports oficiais: STDIO local e Streamable HTTP remoto.

A virada conceitual: MCP saiu do laptop

Em 2025, MCP era predominantemente conexão local entre cliente (Claude Desktop, IDE) e ferramentas no mesmo host. O modelo mental era "tool plumbing pessoal".

Em 2026, mudou. MCP agora roda em produção em empresas grandes e pequenas, alimenta workflows agentic, e é moldado por Working Groups e SEPs (Spec Enhancement Proposals). O foco da spec mudou junto: de "como rodar ferramentas no meu laptop" para "como expor capacidade de agente como serviço".

Isso muda quem precisa entender MCP. Não é mais só desenvolvedor de tooling — é arquiteto de plataforma.

Os dois transports oficiais

A spec consolidou: STDIO para local, Streamable HTTP para remoto. Ponto.

SSE (Server-Sent Events) saiu — era um beco sem saída para escalar. Streamable HTTP é a resposta: HTTP comum com framing que permite streaming bidirecional, compatível com infra HTTP existente (load balancer, WAF, gateway), trivial de cachear e observar.

A consequência prática: o "MCP server remoto" agora é só um endpoint HTTP. Você pode fazer deploy em qualquer plataforma serverless (Vercel Functions, Cloud Run, Lambda), atrás de qualquer ingress, com qualquer stack de auth.

Streamable HTTP horizontal: o trabalho pesado de 2026

O grande desafio do roadmap é deixar Streamable HTTP stateless em modo horizontal. Hoje, sessões ainda guardam estado no processo do servidor. Em uma instância só, isso é OK. Em frota de N instâncias atrás de um load balancer, sticky sessions ou broadcast viram problema.

A direção: mover sessions do transport para o data model layer. A sessão deixa de ser implícita (estado da conexão) e vira explícita (parte do payload, gerenciada pela aplicação MCP).

Para quem opera SaaS, isso muda decisões de infra:

• Instâncias fungíveis (qualquer instância atende qualquer request)
• Auto-scaling agressivo (sem warm-up de sessão)
• Sessão portável (cliente pode mudar de instância sem perder contexto)

É a evolução que torna MCP viável em workload de milhões de requests/dia.

Tasks primitive: o que falta

Tasks foi enviado experimental. A ideia: o cliente dispara uma tarefa de longa duração no servidor MCP, recebe um ID, e consulta status depois — em vez de manter conexão aberta esperando.

Cenário de uso: agent precisa rodar uma transformação que demora 2 minutos. Sem Tasks, o cliente fica pendurado, o request pode timeout, e retry é confuso. Com Tasks, o pattern é fire-and-poll.

O que ainda falta no roadmap:

• Retry semantics para falhas transientes — hoje, quando uma task falha por motivo transiente (network blip, rate limit), não há padrão único de retry
• Expiry policies — por quanto tempo o resultado fica acessível? Quando o servidor pode descartar?

Sem esses dois, Tasks ainda exige convenções específicas de cada implementação. Esperar até esses gaps fecharem antes de comprometer arquitetura de produção é uma decisão razoável para times com SLA apertado.

Governance enterprise — o que muda em compliance

O roadmap explicita quatro itens que ninguém vinha falando em 2025:

1. Audit trails. Quem chamou qual ferramenta, quando, com quais argumentos, com qual resultado. Pré-requisito para SOC 2, LGPD, HIPAA. Sem isso padronizado, cada empresa monta o próprio sistema — e auditores recusam.

2. SSO-integrated auth. Hoje MCP usa OAuth para auth remota. A próxima camada: integrar com IdPs corporativos (Azure AD, Okta, Google Workspace) de forma padronizada.

3. Gateway behavior. Como gateways (Kong, Apigee, AWS API Gateway) devem tratar requests MCP. Headers de rate limit, transformações, observabilidade. Sem spec clara, cada gateway implementa diferente.

4. Configuration portability. Hoje, configurar um MCP server em um cliente e mover para outro envolve recriar JSON ou copiar arquivos. A meta é format único, machine-readable, que clients respeitem.

O que muda para quem constrói agora

Três decisões práticas:

1. Se você vai expor capacidade interna como MCP server, comprometa com Streamable HTTP. STDIO é só para tooling local. Não invista em SSE — saiu.

2. Se você está construindo cliente MCP, prepare para sessões explícitas. Hoje funciona com implícito; o roadmap aponta para explícito. Modele a aplicação considerando isso desde já.

3. Se você opera em ambiente regulado, levante hoje os quatro itens de governance acima como requisitos. Pergunte a fornecedores de tooling MCP como pretendem resolver. Quem não tem resposta vai ficar pra trás em 6-12 meses.

A leitura estratégica

MCP em 2026 está virando o equivalente de "HTTP para agentes". Os transports estabilizam, a primitiva de execução longa amadurece, e governance entra no roadmap.

Isso significa que construir sobre MCP hoje é mais seguro do que construir orchestração proprietária. A pergunta deixa de ser "vamos adotar MCP?" e passa a ser "como nossa arquitetura interna vira MCP server bem desenhado, com auth, audit e telemetria?".

Times que entenderem isso primeiro ganham distribuição — produtos de agente naturalmente vão consumir MCP servers públicos antes de integrar API proprietária.

Próximo passo

Para times que rodam agentes em produção e querem profissionalizar a camada de tooling com disciplina (definir quais capacidades expor, escolher transport correto, modelar sessions, antecipar governance enterprise): diagnóstico técnico cobre exatamente esse escopo, com saída de ADR formal sobre o caminho.

Fontes citadas

1. The 2026 MCP Roadmap — Model Context Protocol Blog · acessado em 2026-05-19
2. MCP Specification 2025-11-25 · acessado em 2026-05-19
3. Code execution with MCP — Anthropic Engineering · acessado em 2026-05-19
4. Official MCP Registry · acessado em 2026-05-19