Anthropic, Simon Willison e a Reviravolta do MCP Stateless

A Anthropic apresentou o MCP em 2024, mas Simon Willison posteriormente considerou as ferramentas de terminal mais flexíveis. A especificação de 28 de julho de 2026 agora reverteu parte desse veredito. Ela elimina as sessões de protocolo e transforma chamadas remotas de MCP em requisições autocontidas.

A mudança renovou o interesse de Willison e inspirou dois projetos: mcp-explorer e datasette-mcp. Mais importante, ela ataca a fragilidade arquitetural que tornava servidores MCP remotos mais difíceis de implantar do que serviços HTTP comuns.

A história entre Anthropic e Simon Willison, portanto, não é apenas mais uma atualização de protocolo. É um teste para saber se o MCP consegue deixar de competir com ferramentas de linha de comando e assumir um papel mais defensável. Skills continuam atraentes para ensinar agentes a usar softwares existentes, enquanto o MCP stateless oferece ferramentas remotas estruturadas, descoberta, autorização e infraestrutura compartilhada.

O MCP stateless elimina a sessão de todos os caminhos de requisição

A nova especificação transforma o MCP de um protocolo centrado em conexões em um protocolo centrado em requisições.

O Model Context Protocol define uma interface padrão pela qual agentes de IA podem descobrir e chamar ferramentas externas. A Anthropic o apresentou em novembro de 2024, e desenvolvedores rapidamente criaram servidores para bancos de dados, navegadores, plataformas de comunicação e aplicações empresariais.

Versões anteriores impunham um processo de inicialização antes das chamadas regulares de ferramentas. O cliente e o servidor trocavam suas versões de protocolo, capacidades e informações de identificação. Essa negociação estabelecia um contexto que as mensagens subsequentes deveriam preservar.

Servidores HTTP também podiam emitir um Mcp-Session-Id. Os clientes então retornavam esse identificador em requisições posteriores. O arranjo fazia uma sequência de chamadas se comportar como uma única conversa contínua entre um cliente específico e uma instância de servidor.

Esse desenho gerava consequências para a infraestrutura. Um balanceador de carga precisava direcionar chamadas relacionadas à instância correta ou armazenar dados de sessão em armazenamento compartilhado. Os operadores também precisavam de políticas para expiração, reconexão, recuperação e limpeza.

A revisão final 2026-07-28 elimina o handshake obrigatório de initialize. Ela também remove a sessão no nível do protocolo e seu cabeçalho associado. Cada requisição agora inclui as informações necessárias para ser interpretada de forma independente.

O lançamento oficial do MCP descreve a revisão como a maior mudança desde o lançamento do protocolo. Seu núcleo stateless vem acompanhado de extensões, suporte revisado a Tasks, mudanças de autorização e um ciclo de vida formal para recursos.

Agora, um cliente pode enviar diretamente uma chamada de ferramenta. A requisição carrega sua versão de protocolo, método, nome da ferramenta, informações do cliente e capacidades relevantes. Qualquer instância de servidor compatível pode processá-la sem depender de uma troca anterior.

A mudança também adiciona server/discover, que permite aos clientes solicitar capacidades do servidor quando necessário. A descoberta deixa de obrigar cada chamador a criar e manter uma sessão de protocolo.

Isso é diferente de afirmar que toda aplicação deve descartar o estado. Um serviço de automação de navegador, carrinho de compras, transação de banco de dados ou fluxo de pesquisa ainda pode reter informações entre chamadas.

A diferença está em onde essas informações vivem e como são endereçadas. Em vez de ocultá-las atrás de uma sessão, o servidor pode retornar um identificador explícito. O modelo fornece esse identificador nas chamadas posteriores.

Um servidor de navegador pode retornar um browser_id após iniciar uma instância. Ferramentas posteriores podem aceitar esse valor ao navegar, capturar uma página ou fechar o navegador. Uma ferramenta de banco de dados pode aplicar o mesmo padrão a um identificador de transação.

A proposta aceita sem sessões descreve esses valores como identificadores explícitos de estado. Eles não são um novo tipo de dado do MCP. São entradas e saídas comuns de ferramentas que tornam o estado da aplicação visível.

Essa visibilidade é importante para agentes. Um orquestrador pode compartilhar um identificador com um subagente enquanto mantém outro isolado. Também pode registrar o identificador para trabalhos posteriores ou entregá-lo a outro processo autorizado.

Operações de listagem obtêm uma vantagem separada. Quando ferramentas e recursos não podem mais mudar de acordo com uma sessão ambígua, os clientes podem armazenar resultados de descoberta em cache com mais segurança. Isso reduz chamadas repetidas entre agentes de curta duração.

O MCP stateless também se mapeia de forma mais limpa para operações HTTP conhecidas. Servidores remotos podem usar balanceamento round-robin padrão, roteamento comum por gateway, autenticação por requisição e sistemas estabelecidos de observabilidade.

Essa combinação foi o que renovou a atenção de Willison. A atualização não apenas encurta o handshake. Ela remove um compromisso arquitetural que antes se infiltrava em cada implantação e em cada implementação de cliente.

Por que a reviravolta entre Anthropic e Simon Willison importa

O interesse renovado de Willison importa porque sua crítica anterior capturou uma mudança real de usuários de agentes de programação para longe do MCP.

O MCP atraiu atenção intensa durante boa parte de 2025. Sua proposta de valor era fácil de entender: implementar uma interface de servidor e então expor as mesmas ferramentas a diversos clientes de IA compatíveis.

No entanto, os agentes de programação estavam melhorando ao mesmo tempo. Eles ganharam acesso confiável ao terminal, melhor uso do shell e maior capacidade de inspecionar documentação. Muitos podiam instalar uma biblioteca ou chamar uma API convencional com curl.

Isso criou um desafio direto. Um programa de linha de comando bem documentado já oferece uma interface de ferramentas componível. O agente pode combinar comandos, redirecionar saídas, escrever pequenos scripts e inspecionar erros sem um adaptador de protocolo.

Skills reforçaram esse caminho. Uma skill é um pacote de instruções, scripts e referências que ensina um agente a realizar uma tarefa. Ela pode explicar uma API existente sem exigir que seu proprietário opere um servidor MCP.

Willison resumiu seu ceticismo em sua análise de 2025. Para agentes de programação, ele preferia utilitários de linha de comando e bibliotecas ao MCP. Essas opções davam mais liberdade ao modelo, evitando outra camada de serviço.

A crítica nunca foi que chamadas estruturadas de ferramentas não tinham valor. A questão mais difícil era saber se o MCP oferecia valor adicional suficiente para justificar sessões, gerenciamento de transporte, trabalho de compatibilidade entre clientes e sobrecarga de contexto.

O MCP stateless reduz essa diferença. Uma pequena ferramenta remota agora pode se comportar mais como um endpoint web convencional, preservando ao mesmo tempo um contrato legível por máquina para clientes de agentes.

A análise de Willison sobre MCP stateless relaciona essa mudança a dois experimentos. O primeiro é mcp-explorer, destinado a facilitar a inspeção e a compreensão de servidores MCP. O segundo é datasette-mcp, que aplica a nova abordagem ao Datasette.

Datasette é o sistema open source de Willison para explorar e publicar dados estruturados. Ele já expõe bancos de dados por meio de interfaces web e APIs. O MCP oferece outra superfície projetada especificamente para modelos de linguagem que usam ferramentas.

A combinação é instrutiva. Uma implantação do Datasette é naturalmente remota, estruturada e compartilhada entre usuários. Ela não se encaixa tão bem no modelo local de linha de comando quanto um utilitário para desenvolvedores instalado ao lado de um agente.

Um servidor MCP pode anunciar ferramentas de banco de dados usando esquemas que os clientes entendem. Os agentes podem inspecionar as operações disponíveis antes de enviar consultas. Os operadores do servidor mantêm o controle sobre autenticação, permissões, limites e detalhes de implementação.

Isso torna a comparação entre Anthropic e Simon mais sutil do que MCP versus Skills. Uma skill pode ensinar um agente a consultar uma API. O MCP pode oferecer a muitos clientes um contrato compartilhado para descobrir e invocar essa API.

As duas abordagens também podem trabalhar juntas. Uma skill pode descrever quando usar um servidor MCP, explicar seus conceitos de domínio ou fornecer um fluxo de trabalho que abrange várias ferramentas. O MCP pode lidar com o limite de execução remota.

Essa divisão reduz a pressão sobre o MCP para se tornar a resposta universal para cada ação de um agente. Comandos locais podem continuar locais. Bibliotecas podem atender tarefas flexíveis de programação. Skills podem empacotar conhecimento operacional.

O MCP ganha um papel mais claro quando o servidor controla a execução e vários clientes precisam da mesma interface detectável. Dados empresariais, busca hospedada, serviços compartilhados e sistemas empresariais autenticados se encaixam nesse padrão.

A simplicidade do protocolo, portanto, muda a questão competitiva. Os desenvolvedores não precisam mais perguntar se toda ferramenta merece um wrapper MCP. Eles podem perguntar se uma capacidade remota se beneficia de descoberta e invocação padronizadas.

Essa é uma promessa menor do que as interpretações iniciais mais amplas do MCP. Também é mais crível. Padrões frequentemente se tornam úteis depois que seus limites ficam mais claros.

Requisições stateless fazem o MCP se encaixar na infraestrutura de nuvem comum

O MCP 2.0 importa porque elimina a coordenação especializada do caminho comum de implantação.

A proposta stateless aceita identifica três problemas do antigo modelo de inicialização. As sessões complicavam a escalabilidade, enfraqueciam a recuperação de falhas e aumentavam o trabalho de implementação em ambos os lados.

Considere uma ferramenta de busca remota executada em três instâncias de servidor. Sob um desenho orientado a sessões, chamadas posteriores poderiam precisar da mesma instância que processou a inicialização. Um balanceador de carga round-robin básico não consegue garantir esse resultado.

Os operadores podem resolver o problema com roteamento persistente. Também podem armazenar dados de sessão em um serviço compartilhado. Ambas as abordagens introduzem estado operacional, modos de falha adicionais e novos requisitos de monitoramento.

Sessões persistentes podem distribuir o trabalho de modo desigual. Armazenamentos compartilhados criam outra dependência. Reinicializações do servidor podem invalidar o estado local, enquanto os clientes precisam detectar falhas e repetir a inicialização.

Com o novo modelo de requisição, qualquer instância íntegra pode processar uma chamada de ferramenta compatível. O gateway pode rotear por método e metadados da ferramenta, em vez de pelo histórico de conexão.

Essa mudança também torna a implantação serverless mais plausível. Plataformas que iniciam e interrompem instâncias conforme a demanda funcionam melhor quando as requisições não dependem da memória deixada por uma requisição anterior.

O servidor ainda precisa de armazenamento durável para estados de aplicação realmente duráveis. O MCP stateless não elimina bancos de dados, armazenamentos de objetos, workers de navegador ou filas de jobs. Ele remove a premissa de que o estado do protocolo deve acompanhá-los.

Operações de longa duração agora se enquadram em um modelo baseado em extensões. Um servidor pode retornar um identificador de tarefa, enquanto o cliente posteriormente verifica, atualiza ou cancela essa tarefa por meio de operações explícitas.

A distinção é importante. O estado oculto de sessão acopla um fluxo de trabalho a uma relação de transporte. Um identificador de tarefa transforma o fluxo de trabalho em um recurso endereçável que outros componentes autorizados podem gerenciar.

Multi Round-Trip Requests tratam outro caso difícil. Algumas ferramentas precisam de mais informações de um usuário ou cliente antes de serem concluídas. Implementações anteriores associavam essa troca a uma sessão estabelecida.

O novo desenho permite uma requisição iniciada pelo servidor apenas enquanto ele está processando uma requisição do cliente. Os dados de correlação transitam pelo ciclo de requisição e resposta, evitando uma sessão de protocolo permanente.

Isso restringe certos comportamentos. Um servidor não pode contatar inesperadamente um cliente muito tempo após a chamada inicial. Esse limite reduz a flexibilidade, mas dá aos prompts do usuário uma origem e um ciclo de vida mais claros.

A descoberta de ferramentas também se torna mais fácil de rotear e armazenar em cache. A especificação adiciona metadados de métodos e ferramentas aos cabeçalhos HTTP. Gateways podem inspecionar esses metadados sem analisar cada corpo de solicitação.

Servidores podem anexar um valor de tempo de vida às respostas de listagem. Os clientes podem então reutilizar as informações das ferramentas durante o período permitido, em vez de solicitar a mesma lista para cada subagente de curta duração.

A proposta sem sessão alerta que o comportamento anterior poderia gerar tráfego repetido de descoberta proporcional ao número de subagentes multiplicado pelo número de servidores. Listas sem estado oferecem aos orquestradores uma base melhor para evitar esse custo.

Isso importa à medida que os sistemas de agentes se tornam mais distribuídos. Uma solicitação de usuário pode acionar um planejador, vários trabalhadores especializados e um verificador. Repetir inicialização e descoberta para cada ramificação adiciona latência e tráfego.

O protocolo revisado também adota o JSON Schema 2020-12 completo para definições de ferramentas. JSON Schema é um vocabulário padrão para descrever dados estruturados, incluindo campos obrigatórios, tipos e regras de validação.

Esquemas mais ricos podem descrever entradas e saídas mais precisas. Isso dá aos clientes melhores informações para validar chamadas e construir interfaces. Também reduz a dependência de descrições de ferramentas escritas de forma vaga.

As extensões fornecem outra forma de separação arquitetural. MCP Apps podem oferecer interfaces renderizadas pelo servidor, enquanto Tasks lidam com operações mais longas. Esses recursos podem evoluir sem forçar todas as capacidades para o núcleo do protocolo.

Um ciclo de vida formal estabelece pelo menos 12 meses entre a descontinuação de um recurso e sua remoção mais precoce. Isso não elimina o trabalho de migração, mas dá aos implementadores uma janela de planejamento mais clara após essa ruptura limpa.

A orientação oficial do TypeScript mostra que a migração ainda exige trabalho deliberado. O guia de migração do SDK afirma que o novo formato de comunicação exige adoção explícita, em vez de alterar silenciosamente todas as aplicações existentes.

Essa cautela é apropriada. Uma nova especificação não pode criar interoperabilidade apenas por ser publicada. Clientes, servidores, gateways e SDKs precisam implementar os mesmos detalhes e testá-los com cargas de trabalho reais.

Ainda assim, o mecanismo aborda uma fragilidade concreta. Ele substitui a infraestrutura de sessão específica do MCP por padrões que equipes de nuvem já usam em serviços HTTP comuns.

O estado explícito cria novas questões de segurança e confiabilidade

O MCP sem estado elimina atritos de infraestrutura, mas transfere mais responsabilidade para o design das ferramentas, a autorização e a memória do agente.

Identificadores explícitos tornam o estado visível e portável. Esses benefícios também ampliam os lugares em que identificadores sensíveis podem aparecer. Um identificador pode entrar em históricos de chat, prompts, logs, rastros, conteúdo da área de transferência ou mensagens entre subagentes.

Um servidor não deve tratar o conhecimento de um identificador como autorização suficiente. Ele deve validar tanto o identificador quanto a identidade autenticada em cada chamada.

Isso se assemelha ao design usado por muitos serviços de documentos e projetos. Um ID de recurso identifica um objeto, enquanto o contexto de autorização atual determina se um chamador pode lê-lo ou alterá-lo.

Serviços sem autenticação enfrentam um problema mais difícil. Nesse contexto, um identificador imprevisível pode funcionar como um token de portador. Qualquer pessoa que o obtenha pode acessar o estado subjacente até que o identificador expire.

A especificação sem sessão recomenda identificadores de alta entropia e durações limitadas para esses casos. Essa recomendação permanece como orientação de implementação porque o MCP não define um tipo de identificador no nível do protocolo.

Isso cria uma lacuna de aplicação. Clientes não conseguem reconhecer automaticamente quais strings retornadas representam estado ativo. Um browser_id parece qualquer outro valor, a menos que nomes e descrições de ferramentas comuniquem seu papel.

Portanto, um orquestrador nem sempre consegue saber quais identificadores precisam sobreviver à compactação de contexto. Ele também pode ter dificuldade para determinar quais valores exigem limpeza ou nunca devem ser passados a outro subagente.

Modelos carregam rotineiramente caminhos de arquivos, hashes de commit, URLs e identificadores de transação. Ainda assim, podem copiar um identificador incorretamente, omiti-lo ou perdê-lo quando uma conversa longa é resumida.

O estado de sessão tinha fragilidades relacionadas. Clientes usavam tempos de vida inconsistentes, e muitos não restauravam sessões após desconexões. Remover sessões torna esses problemas explícitos, mas não automatiza o gerenciamento de estado.

A limpeza apresenta outro detalhe não resolvido. O fim de uma sessão antes oferecia um sinal teórico para liberar recursos. Na prática, os clientes frequentemente encerravam sessões com muita frequência, com pouca frequência ou após uma recarga de página sem relação.

Fluxos explícitos precisam de suas próprias políticas de expiração e destruição. Um serviço de navegador pode oferecer close_browser, ao mesmo tempo que impõe um tempo limite por inatividade. Um serviço de tarefas pode reter resultados concluídos por um período definido.

A compatibilidade retroativa adiciona complexidade operacional durante a adoção. Servidores existentes que dependem de IDs de sessão não podem simplesmente aceitar a nova revisão do protocolo sem mudar seu modelo de estado.

Clientes e SDKs podem negociar uma revisão anterior quando necessário. Isso permite migração gradual, mas também cria dois caminhos de comportamento que os desenvolvedores precisam testar.

Algumas capacidades se tornam menos diretas sob HTTP sem estado. Notificações não solicitadas e interações de longa duração orientadas pelo servidor não se encaixam tão naturalmente em solicitações independentes. Extensões e mecanismos de escuta precisam assumir esse trabalho.

Também não há garantia de que toda integração MCP se torne eficiente apenas porque as sessões desaparecem. Esquemas mal projetados podem consumir contexto. Catálogos grandes de ferramentas podem confundir modelos. Descrições pouco claras ainda podem provocar chamadas incorretas.

Skills e ferramentas de linha de comando preservam suas vantagens aqui. Um agente de programação muitas vezes pode inspecionar a saída de ajuda de um programa e escrever um script curto sem carregar um grande catálogo remoto de ferramentas.

Ferramentas locais também podem manter dados sensíveis na máquina do usuário. Uma implantação remota de MCP introduz preocupações com autenticação, exposição de rede, registro de logs e disponibilidade de serviço que a execução local evita.

O MCP também não resolve a injeção de prompt. Um agente habilitado para ferramentas pode combinar informações privadas, entradas não confiáveis e comunicação externa independentemente de o transporte ter estado.

Operadores de servidores devem restringir permissões e saídas. Criadores de agentes devem controlar quais ferramentas aparecem juntas. Usuários precisam de limites de aprovação claros para ações consequentes.

Essas restrições desafiam a interpretação mais forte da reviravolta de Simon, da Anthropic. O interesse renovado de Willison valida a mudança arquitetural, não toda implementação de MCP nem todo servidor proposto.

mcp-explorer e datasette-mcp são experimentos iniciais úteis porque expõem questões práticas. Clientes conseguem descobrir ferramentas de forma consistente? Os esquemas são compreensíveis? Autenticação e identificadores de estado sobrevivem a fluxos de trabalho reais?

O argumento mais forte para o MCP sem estado virá de evidências de interoperabilidade. Clientes independentes devem se conectar a servidores independentes sem correções personalizadas, enquanto operadores devem implantá-los usando infraestrutura comum.

Até que essas evidências cresçam, o MCP 2.0 continua sendo uma base melhor, e não uma vitória concluída. O protocolo eliminou uma grande fonte de atrito. Os implementadores ainda determinam se os sistemas resultantes permanecem seguros e compreensíveis.

O que os desenvolvedores devem acompanhar após o MCP 2.0

O próximo teste é a adoção em SDKs, servidores reais e clientes, não mais uma alta na contagem de repositórios.

O primeiro sinal é a cobertura de implementação da revisão 2026-07-28. SDKs oficiais precisam de suporte consistente para descoberta, metadados por solicitação, capacidades explícitas, Tasks e comportamento de autorização.

Rótulos de versão por si só não serão suficientes. Desenvolvedores devem acompanhar resultados de conformidade e testes entre linguagens. Um servidor Python, um cliente TypeScript e um gateway gerenciado devem concordar sobre as mesmas solicitações e erros.

Uma forte compatibilidade entre SDKs reforçaria o argumento de que o MCP agora oferece uma fronteira estável para ferramentas remotas. Incompatibilidades persistentes o enfraqueceriam ao levar desenvolvedores de volta a adaptadores específicos de cada cliente.

O segundo sinal é como servidores de produção migram fluxos de trabalho com estado. Automação de navegadores, transações, carrinhos de compras e trabalhos de pesquisa de longa duração oferecem testes exigentes para identificadores explícitos.

Migrações bem-sucedidas devem mostrar limpeza confiável, autorização por solicitação, transferência de identificadores e compactação de contexto. Também devem documentar o que acontece quando um agente perde ou repete um identificador.

Se esses padrões se tornarem reutilizáveis, o estado explícito parecerá uma abstração melhor do que sessões ambíguas. Se cada servidor inventar regras de ciclo de vida incompatíveis, o protocolo terá deslocado a complexidade em vez de reduzi-la.

O terceiro sinal é a relação entre MCP e Skills. Plataformas de agentes devem demonstrar quando escolhem um comando local, uma chamada de API orientada por skill ou um servidor MCP remoto.

Regras claras de seleção fortaleceriam a tese mais restrita. O MCP atenderia a capacidades remotas compartilhadas, enquanto Skills empacotariam instruções e fluxos de trabalho locais.

A sobreposição contínua poderia criar manutenção duplicada. Proprietários de ferramentas talvez precisem de uma API, CLI, pacote de skill, servidor MCP e integração específica de cliente para a mesma capacidade.

Desenvolvedores devem resistir a tratar essa duplicação como inevitável. Uma skill pode referenciar um servidor MCP, e um servidor MCP pode encapsular uma API existente. A questão útil é qual interface detém o contrato duradouro.

Para ferramentas de dados, os experimentos de Willison fornecem um ponto concreto a observar. Datasette já fornece informações estruturadas por meio de APIs web. datasette-mcp pode testar se um contrato voltado a agentes melhora a descoberta e as consultas seguras.

Equipes que constroem fluxos de trabalho de conhecimento enfrentam uma escolha semelhante. Documentos e notas locais frequentemente pertencem a uma base de conhecimento de engenharia privada e pesquisável. Sistemas empresariais compartilhados podem se adequar melhor a ferramentas remotas autenticadas.

O ponto central é evitar conceder a um agente uma coleção irrestrita de ferramentas apenas porque um protocolo comum facilita a conexão. A padronização reduz o trabalho de integração, mas não substitui o design de permissões.

A reviravolta de Simon Willison, da Anthropic, é valiosa porque ocorre após um período de ceticismo genuíno. O MCP não recuperou atenção por meio de branding. Seus mantenedores removeram uma carga estrutural que os críticos podiam apontar em sistemas implantados.

É assim que um protocolo deve evoluir. Ele deve absorver evidências de pressupostos fracassados, restringir suas responsabilidades e tornar operações comuns mais fáceis de compreender.

Nos próximos três meses, examine os clientes e servidores que você realmente usa. Verifique se eles oferecem suporte à revisão final, como representam o estado da aplicação e se a autorização acompanha cada identificador.

Depois, compare o resultado com a alternativa mais simples. Se um comando local continuar mais claro, mantenha-o. Se muitos agentes precisarem de uma capacidade remota governada, teste o MCP sem estado e registre onde a interoperabilidade ainda falha.