O Model Context Protocol (MCP) recebeu em 28 de julho de 2026 uma atualização que mexe menos com a aparência dos assistentes e mais com o que acontece por trás deles. A especificação 2026-07-28 troca o núcleo do protocolo por um desenho sem estado, acrescenta recursos para operações de ida e volta mais longas e endurece pontos de autorização. É uma mudança de infraestrutura, mas com efeito prático: agentes de IA que precisam consultar ferramentas, sistemas internos e dados de clientes podem se tornar mais fáceis de escalar, desde que quem os opera trate permissões como parte do produto, e não como um detalhe posterior.
O anúncio não significa que qualquer assistente passou a ganhar acesso a e-mails, planilhas ou bancos de dados. MCP é um protocolo: um conjunto de regras para que uma aplicação de IA converse com ferramentas e fontes externas. A autorização continua dependendo de cada cliente, de cada servidor e das credenciais concedidas pelo usuário ou pela empresa. Essa distinção é importante num momento em que “conectar uma IA a tudo” costuma soar mais simples e seguro do que realmente é.
Quando isso aconteceu
A Anthropic apresentou o MCP em 25 de novembro de 2024 como um padrão aberto para conectar aplicações de IA a dados e ferramentas. A proposta inicial era reduzir a quantidade de integrações feitas sob medida: em vez de cada aplicativo precisar criar um conector exclusivo para cada serviço, clientes e servidores poderiam seguir uma linguagem comum.
Em 28 de julho de 2026, o projeto publicou a especificação 2026-07-28. O texto descreve uma alteração central: o protocolo deixa de depender de um núcleo com sessão persistente e passa a operar de forma sem estado. O objetivo é permitir que requisições possam ser atendidas por instâncias diferentes de um serviço, algo relevante para quem distribui cargas em nuvem ou precisa recuperar um fluxo depois de uma falha.
O que mudou, em linguagem menos protocolar
Em uma arquitetura com estado, uma conexão guarda informações do que aconteceu antes. Isso é útil, mas cria dificuldades quando um serviço precisa atender muitas conexões, reiniciar processos ou dividir o trabalho entre vários servidores. O MCP atualizado passa a estruturar cada requisição para carregar as informações necessárias ao seu tratamento. Na prática, isso tende a combinar melhor com balanceadores de carga e com serviços que sobem e descem conforme a demanda.
A especificação também introduz as Multi Round-Trip Requests (MRTR), um mecanismo para interações que precisam de mais de uma troca entre cliente e servidor. Em vez de manter um canal bidirecional constantemente aberto para todos os cenários, o protocolo prevê uma sequência explícita de pedidos e respostas. Não é uma garantia de que toda integração ficará mais rápida; é uma forma de tornar fluxos longos mais previsíveis para quem implementa a infraestrutura.
Há ainda mudanças menores, mas úteis para operação: nomes de métodos e ferramentas podem viajar em cabeçalhos HTTP, respostas de listas passam a ter orientações de cache e a especificação formaliza um caminho para extensões. Para uma equipe que administra dezenas de ferramentas, saber antecipadamente qual chamada está chegando pode facilitar roteamento, observabilidade e políticas de acesso. Para um usuário comum, a consequência aparece de modo indireto: um agente pode conseguir encontrar e chamar uma ferramenta com menos improviso técnico no meio do caminho.
Por que isso ainda importa
O assunto merece atenção agora porque o MCP deixou de ser uma curiosidade de uma única ferramenta. A própria documentação do projeto descreve o protocolo como uma maneira de padronizar o contexto que aplicações fornecem a modelos de linguagem. Isso coloca o padrão numa camada diferente da do modelo: Claude, ChatGPT, Gemini ou outro assistente podem mudar, mas a integração com arquivos, sistemas de suporte, repositórios ou serviços internos continua exigindo uma ponte bem definida.
Para empresas, a mudança pode reduzir o custo de manter conectores específicos. Um time não precisa necessariamente reescrever a mesma integração toda vez que troca de interface de IA. Para desenvolvedores independentes, abre-se a possibilidade de construir servidores voltados a uma tarefa e fazê-los conversar com mais de um cliente compatível. Nenhuma das duas coisas elimina trabalho de engenharia: dados precisam estar organizados, permissões precisam ser mínimas e a ferramenta chamada pelo agente ainda precisa responder de forma confiável.
Também há um aspecto de governança. A versão de julho formaliza extensões e anuncia uma política de descontinuação com prazo mínimo de doze meses. Em plataformas que lidam com integrações de produção, previsibilidade vale tanto quanto novidade. Uma alteração incompatível pode interromper um fluxo de atendimento, uma automação financeira ou a revisão de código de uma empresa. Ter um prazo explícito não torna uma migração trivial, mas dá à equipe uma janela concreta para testar e planejar.
O ponto que não cabe no discurso de “conecte tudo”
Protocolos não criam segurança sozinhos. A documentação de autorização do MCP deixa claro que recursos de autorização existem no nível de transporte para servidores restritos; o suporte é opcional e varia conforme a implementação. Em conexões HTTP, clientes e servidores precisam seguir o fluxo adequado. Em cenários locais por stdio, as credenciais normalmente vêm do ambiente onde o processo foi iniciado. É justamente aí que nascem muitos dos riscos: uma chave exposta numa variável de ambiente, um servidor que pede acesso além do necessário ou uma ferramenta que executa ações sem confirmação suficiente.
Antes de instalar um servidor MCP ou autorizar um conector, vale fazer quatro perguntas simples:
- Que dados ele lê? Arquivos pessoais, repositórios privados, CRM e e-mail têm níveis de sensibilidade muito diferentes.
- Que ações ele pode executar? Ler uma tabela não é o mesmo que apagar linhas, enviar mensagens ou publicar mudanças.
- De onde veio o servidor? Prefira mantenedores identificados, código aberto revisável e documentação de permissões.
- Como revogar o acesso? Uma integração saudável precisa ter um caminho claro para remover tokens, desconectar contas e auditar o que foi feito.
Essas perguntas parecem básicas, mas evitam que uma melhoria de produtividade vire uma porta aberta para dados ou ações que ninguém pretendia delegar. O ganho de contexto só é útil quando o agente recebe o contexto certo, e só a autorização necessária.
Limites e incertezas
A nova especificação não obriga aplicativos de IA a adotarem MCP, nem garante compatibilidade automática entre clientes e servidores existentes. Cada produto decide quando suporta uma versão, quais extensões habilita e quais limites coloca em permissões, auditoria e confirmação de ações. Há ainda uma diferença decisiva entre demonstrar uma ferramenta conectada e mantê-la em produção: disponibilidade, logs, renovação de credenciais e resposta a incidentes continuam sendo responsabilidade de quem integra.
Por isso, o melhor uso inicial não é ligar todos os serviços da empresa a um agente. Comece por uma fonte delimitada, com dados não sensíveis ou uma conta de teste; deixe as ações de escrita para uma segunda etapa; registre o que o agente chamou; e só amplie o escopo depois de revisar o resultado. A especificação nova ajuda a infraestrutura a amadurecer, mas não substitui esse processo de validação.
Em resumo
A atualização 2026-07-28 torna o MCP mais adequado a cenários distribuídos e a fluxos de agentes que precisam durar mais do que uma conversa curta. O avanço mais relevante não é uma função vistosa na tela: é a tentativa de dar forma estável à camada que conecta IA, ferramentas e dados. Para quem usa IA no trabalho, a oportunidade é construir integrações mais reaproveitáveis. Para quem administra essas integrações, o recado é menos glamouroso e mais importante: padrão aberto não dispensa revisão de permissões.