O Release Candidate da spec 2026-07-28 é a maior revisão do Model Context Protocol desde o lançamento — e o que ela muda é operacional, não conceitual. Não há uma nova ideia de como agentes falam com sistemas. Há uma mudança em como o servidor que atende esses agentes roda, escala e custa.
A distinção importa porque MCP deixou de ser assunto de prova de conceito. Os números de julho de 2026 são consistentes: 78% dos times de IA enterprise já têm agentes com MCP em produção, 28% da Fortune 500 rodam servidores MCP e os SDKs somam algo em torno de 97 milhões de downloads por mês. Quando um protocolo chega nesse patamar, ele para de ser decisão de arquiteto e vira linha de custo de infraestrutura — com sizing, política de cache, política de retry e alguém respondendo pela fatura.
Este artigo é sobre as três entregas que mudam essa conta: núcleo stateless, extensão Tasks e MCP Apps. E sobre o que a spec deliberadamente não resolve.
1. O que o RC 2026-07-28 entrega
Núcleo stateless. É a mudança de maior impacto financeiro. O servidor MCP remoto deixa de exigir estado de sessão preso a uma instância, o que dissolve uma pilha inteira de requisitos de infraestrutura que existiam só para manter esse estado de pé.
Extensão Tasks. Trabalho de longa duração passa a ser cidadão de primeira classe do protocolo. Em vez de forçar toda operação a caber num ciclo request/response curto, existe um modelo explícito para iniciar trabalho, consultar progresso e recuperar resultado depois.
MCP Apps. Interface renderizada pelo servidor, exibida dentro do agente. Muda quem é dono da experiência: o servidor deixa de ser apenas um provedor de ferramentas e passa a poder entregar UI — com implicações de produto e de segurança que valem uma discussão própria.
Auth alinhada a OAuth/OIDC. Complementa a autorização centralizada que se estabilizou nos últimos meses, encaixando o protocolo nos padrões de identidade que a empresa já opera em vez de exigir um universo paralelo.
2. Antes e depois: o que sai da sua fatura
Vale ser concreto sobre o "antes", porque é ele que está no orçamento de quem já subiu servidores MCP.
Antes. Servidor remoto com estado de sessão significava sticky session no balanceador: cada cliente precisava voltar sempre para a mesma instância. Sticky session, por sua vez, arruína a distribuição de carga — instâncias ficam desbalanceadas, você superdimensiona para absorver o pico da instância mais quente, e o deploy vira um problema (derrubar um nó derruba sessões). Para contornar, muitos times colocaram um session store compartilhado (Redis, tipicamente) e passaram a pagar mais um componente com HA, latência e failover próprios. E como o roteamento precisava entender o conteúdo da requisição, o gateway fazia inspeção profunda de pacote — o item mais caro e mais lento da cadeia.
Depois. Com o núcleo stateless, o servidor roda atrás de um round-robin comum. O roteamento é feito pelo header Mcp-Method, sem abrir o corpo da requisição — o gateway volta a fazer o que gateway faz bem. E tools/list, que é a chamada mais repetitiva de todas, passa a ser cacheável pelo ttlMs anunciado pelo servidor, o que corta uma fatia relevante do tráfego antes de ele chegar à aplicação.
Traduzindo para o orçamento: sai o session store dedicado, sai o gateway com DPI, sai a superprovisão que a sticky session obrigava, e entra a possibilidade de escalar horizontalmente com instâncias pequenas e intercambiáveis. Autoscaling volta a funcionar como deveria, porque qualquer instância atende qualquer requisição.
Uma ressalva de engenharia honesta: "stateless" no protocolo não significa que o seu domínio deixou de ter estado. Se a sua ferramenta precisa saber o que aconteceu na chamada anterior, esse estado continua existindo — a diferença é que ele passa a ser estado de aplicação, explícito e persistido por você, em vez de estado de transporte implícito preso à conexão. Isso é uma melhora, mas exige decisão consciente sobre onde ele mora.
3. Tasks: o buraco que toda integração agente↔ERP tinha
Quem tentou ligar um agente a um sistema de registro real conhece esse problema de cor: nada que importa responde em dois segundos.
Fechamento de pedido não responde. Reprocessamento de nota fiscal não responde. Consulta a batch, geração de relatório, recálculo de estoque, integração que passa por fila do ERP — nenhum desses cabe numa chamada síncrona. Antes da extensão Tasks, o time tinha três saídas, todas ruins: aumentar timeout até um número absurdo (e prender worker do lado do agente enquanto isso), inventar um protocolo de polling caseiro por cima das ferramentas (cada servidor com o seu, sem padrão), ou simplesmente não expor essas operações ao agente — que é o que a maioria fez, e é a razão pela qual tantos agentes só conseguem ler e nunca escrever.
Tasks resolve isso no protocolo: iniciar trabalho, receber um identificador, consultar progresso, recuperar resultado. É o padrão de trabalho assíncrono que integração enterprise sempre usou, agora falado pelo agente.
Mas — e este é o ponto que se perde na leitura otimista — o protocolo padroniza a conversa, não a implementação. Ter Tasks na spec não te dá fila durável, não te dá idempotência, não te dá retry com backoff, não te dá reconciliação e não te dá visibilidade de execução. Isso continua sendo trabalho de engenharia do seu lado. Se a operação de "fechar pedido" é disparada duas vezes porque o agente reenviou, quem impede o pedido duplicado é a sua chave de idempotência, não a spec. Se o worker morre no meio, quem garante que o trabalho não se perde é a sua fila com acknowledgment, não a spec.
Ou seja: Tasks remove a desculpa técnica para não expor operações longas ao agente. E, ao remover a desculpa, expõe quem não tem a fundação de trabalho assíncrono montada.
4. O que a spec não resolve (e volta para o seu time)
A leitura da SecurityWeek sobre o RC é direta e merece ser levada a sério: a spec habilita escala enterprise, mas desloca responsabilidades de segurança do protocolo para o desenvolvedor e o operador da plataforma. Quem escreve o servidor herda o problema.
Isso é uma consequência natural de ficar stateless e de introduzir UI renderizada no servidor. Sem sessão no transporte, cada requisição precisa carregar e validar sua própria autorização — não existe mais "essa conexão já foi autenticada lá atrás". Com MCP Apps, o servidor passa a entregar interface que roda dentro do contexto do agente, o que amplia a superfície: agora há conteúdo ativo vindo do servidor, e as perguntas de isolamento, origem e permissão de UI passam a valer.
A lista prática do que sobra para o seu time é razoavelmente estável: validação de token por requisição com escopo mínimo por ferramenta; limite de taxa por identidade (não por IP, porque atrás de round-robin isso perde sentido); autorização no nível da ferramenta e do recurso, não só no nível do servidor; trilha de auditoria de quem chamou o quê, com qual credencial e qual payload; e política explícita para o que um MCP App pode renderizar e acessar. Nada disso é novo em segurança de API — o que é novo é que agora o chamador é um agente, que erra de formas diferentes de um cliente programado.
5. Como a CCX faz: camada de integração event-driven com outbox, idempotência e reconciliação
A conclusão prática da nova spec é confortável e desconfortável ao mesmo tempo: o protocolo ficou mais barato de operar, e a parte cara continua sendo a de sempre — a camada de integração entre o agente e o sistema de registro.
É exatamente essa camada que a CCX constrói na prática de Integrações & APIs Enterprise: REST, GraphQL e gRPC para o síncrono, e arquitetura event-driven com Kafka e RabbitMQ para tudo que a extensão Tasks agora permite expor. O padrão de trabalho assíncrono que sustenta isso não é improvisado por projeto — é outbox pattern (a mensagem e a linha de outbox persistidas na mesma transação, para que nada seja publicado sem ter sido gravado), idempotência por chave de operação, retry exponencial e reconciliação periódica comparando o que o agente acredita ter feito com o que existe de fato no ERP. É a diferença entre "o agente disse que fechou o pedido" e "o pedido está no sistema de registro".
Do lado da plataforma, três coisas complementam. Consultoria em tecnologia para desenhar a arquitetura-alvo e o TCO antes de multiplicar servidores MCP — porque a mudança para stateless é justamente o momento certo de refazer o sizing em vez de herdar o dimensionamento da era da sticky session. Observabilidade 360° com Datadog, Grafana e OpenTelemetry, para que cada chamada de ferramenta tenha trace e cada Task tenha estado visível — sem isso, incidente com agente vira arqueologia. E Security Engineering para a parte que a spec devolveu ao operador: OAuth2, gestão de segredos com Vault, integração com SIEM e escopo mínimo por ferramenta.
Se seus agentes já falam com sistemas em produção, a CCX redesenha a camada de integração para o modelo stateless + trabalho assíncrono — com fila, idempotência, cache e observabilidade ponta a ponta. Fale com um especialista CCX →
6. FAQ
Preciso migrar meus servidores MCP agora?
É um Release Candidate, então o movimento sensato é planejar sem correr. O ganho de custo é real e vem principalmente de sair da sticky session, mas ele só se materializa se a sua implementação de fato não depender de estado de transporte. Vale começar pelo inventário: quais servidores MCP existem, quais guardam estado, quanto custa hoje a infraestrutura que existe só para manter esse estado.
Stateless significa que meu servidor não pode ter estado nenhum?
Não. Significa que o protocolo não carrega estado de sessão entre requisições. Estado de domínio continua existindo e continua sendo seu — a diferença é que ele passa a ser explícito e persistido em um lugar que você escolheu, em vez de implícito e preso à conexão. Na prática, é o que torna possível escalar horizontalmente.
A extensão Tasks substitui minha fila?
Não. Tasks padroniza como o agente inicia trabalho longo e consulta o resultado. Durabilidade, ordem, retry, dead-letter, idempotência e reconciliação continuam sendo responsabilidade da sua infraestrutura de mensageria. Tasks tira a desculpa para não expor operação longa; a fila é que garante que essa operação não se perca.
O que muda no gateway na prática?
Sai a necessidade de inspeção profunda para rotear e sai a afinidade de sessão. O roteamento passa a ser feito por header (Mcp-Method) e a distribuição volta a ser round-robin simples. Some-se o cache de tools/list respeitando o ttlMs do servidor, que reduz tráfego repetitivo. Em compensação, autenticação e rate limiting precisam ser por requisição e por identidade.
MCP Apps aumenta o risco de segurança?
Aumenta a superfície, que é diferente de dizer que é inseguro. Ao permitir que o servidor renderize interface dentro do agente, entram perguntas de isolamento, origem do conteúdo e permissão do que aquela UI pode acessar. É um recurso que pede política explícita antes de ser habilitado em ambiente com dado sensível.