MCP just changed its architecture: what the 2026-07-28 spec is
On July 28, 2026 (yesterday), the Model Context Protocol — the standard that connects models like Claude to external tools, data and systems — published a new spec version that rewrites much of the protocol's internal architecture. Anthropic has already announced expanded support for it in Claude. Worth understanding what changes and why, since this is a protocol that already passes 400 million SDK downloads a month.
01A quick refresher: what MCP is
The Model Context Protocol is an open standard, created by Anthropic and now maintained independently, that defines how an AI assistant (like Claude) connects to "servers" that expose tools, data or resources — a database server, a calendar API, a file system. Before MCP, every integration like this was built differently; the protocol standardizes that conversation.
02The central change: from a stateful protocol to a stateless one
The most important change in the 2026-07-28 spec is that MCP stops being a stateful protocol and becomes stateless at its core. In practice, this means:
What goes away
The initial handshake (initialize / notifications/initialized) disappears, along with the concept of a persistent connection session and the Mcp-Session-Id header on the HTTP transport. Every tool call becomes a self-contained HTTP request, carrying its own protocol version, identity and capabilities.
The practical reason is infrastructure: a stateless protocol can run in serverless and edge computing environments, which don't keep long-lived open connections. A traditional stateful MCP server needs a process alive at all times — which is expensive and complicates auto-scaling.
03Other relevant changes
Change
What it solves
Multi round-trip requests
Allows multi-turn exchanges within a single logical operation, even without a persistent session
HTTP header-based routing
Makes load balancing and routing easier in distributed infrastructure, since every request carries the context it needs
Cacheable listing results
tools/list, resources/list and prompts/list no longer vary per connection, enabling caching — previously each connection could get a different response
Reinforced OAuth 2.0 / OIDC
Authorization aligned with enterprise standards, enabling direct integration with identity providers like Entra ID or Okta, without workarounds
Versioned extension framework
MCP Apps (embedded interactive UIs) and MCP Tasks (long-running work) become formal extensions, without needing to touch the protocol core
04Spotlight: how long-running work (Tasks) works now
A natural problem with a stateless protocol is: how do you handle a task that takes minutes or hours to finish, if there's no longer a continuous connection to "notify" when it's done? The Tasks extension solves this with a handle model: the server responds to a tools/call with a task identifier, and the client checks progress on its own, with calls like tasks/get, tasks/update and tasks/cancel.
05Pros and cons of this change
Advantage
Why
Scales on modern infrastructure
MCP servers can run on serverless functions and edge, with no dedicated process always on
More robust security
Authorization aligned with production-grade OAuth/OIDC makes adoption easier in enterprise environments with strict identity requirements
Servers on the new version may not work with old clients, and vice versa, requiring both sides to share a supported version or implement translation
Costly migration
Existing integrations that relied on persistent sessions need to be rewritten for the self-contained request model
Adaptation curve
Teams that had already mastered the old (stateful) model need to relearn parts of the architecture
06What this means in practice
For anyone already using MCP integrations (for example inside Claude or tools like Claude Code), the transition should be mostly invisible in the short term: the official TypeScript and Python SDKs keep receiving fixes and security updates on the old version for at least six months after the v2 launch, giving time for a gradual migration. For anyone building their own MCP servers, it's worth following the official changelog before updating SDKs in production, since a protocol change like this usually requires deliberate compatibility work.
To remember
The MCP 2026-07-28 spec changes the protocol from "stateful, always-alive connection" to "self-contained, stateless requests" — a change designed to scale on serverless and edge infrastructure, reinforce enterprise authorization, and formalize extensions like embedded UIs and long-running tasks. It's an architecture change, not just a new feature, which is why it comes with breaking compatibility that requires attention from anyone maintaining MCP servers or clients.
Share:
Newsletter
Learn what AI is creating for you. Don't get lost.
Get notified when a new deep dive or lesson goes up. No spam, just new posts.
Cooldecode · IA Watch · Ferramentas e ecossistema de IA
MCP acaba de mudar de arquitetura: o que é a spec 2026-07-28
Em 28 de julho de 2026 (ontem), o Model Context Protocol — o padrão que conecta modelos como o Claude a ferramentas, dados e sistemas externos — publicou uma nova versão de especificação que reescreve boa parte da arquitetura interna do protocolo. A Anthropic já anunciou suporte ampliado a ela no Claude. Vale entender o que muda e por quê, porque é um protocolo que hoje já passa de 400 milhões de downloads de SDK por mês.
01Relembrando: o que é o MCP
O Model Context Protocol é um padrão aberto, criado pela Anthropic e hoje mantido de forma independente, que define como um assistente de IA (como o Claude) se conecta a "servidores" que expõem ferramentas, dados ou recursos — um servidor de banco de dados, uma API de calendário, um sistema de arquivos. Antes do MCP, cada integração desse tipo era feita de um jeito diferente; o protocolo padroniza essa conversa.
02A mudança central: de protocolo com estado para protocolo sem estado
A mudança mais importante da spec 2026-07-28 é que o MCP deixa de ser um protocolo stateful (com estado) e passa a ser stateless (sem estado) no núcleo. Na prática, isso significa:
O que sai
O handshake inicial (initialize / notifications/initialized) desaparece, junto com o conceito de sessão de conexão persistente e o cabeçalho Mcp-Session-Id do transporte HTTP. Cada chamada de ferramenta passa a ser uma requisição HTTP autocontida, carregando sua própria versão de protocolo, identidade e capacidades.
O motivo prático é infraestrutura: um protocolo sem estado pode rodar em ambientes serverless e de edge computing, que não mantêm conexões abertas por longos períodos. Um servidor MCP com estado tradicionalmente precisa de um processo vivo o tempo todo — o que é caro e complica escala automática.
03Outras mudanças relevantes
Mudança
O que resolve
Multi Round-Trip Requests
Permite trocas de múltiplas idas e vindas dentro de uma mesma operação lógica, mesmo sem sessão persistente
Roteamento por cabeçalho HTTP
Facilita balanceamento de carga e roteamento em infraestrutura distribuída, já que cada requisição carrega o contexto necessário
Resultados de listagem cacheáveis
tools/list, resources/list e prompts/list deixam de variar por conexão, permitindo cache — antes cada conexão podia receber uma resposta diferente
OAuth 2.0 / OIDC reforçados
Autorização alinhada a padrões corporativos, permitindo integração direta com provedores de identidade como Entra ID ou Okta, sem gambiarras
Framework de extensões versionado
MCP Apps (UIs interativas embutidas) e MCP Tasks (trabalho de longa duração) viram extensões formais, sem precisar mexer no núcleo do protocolo
04Destaque: como fica o trabalho de longa duração (Tasks)
Um problema natural de um protocolo sem estado é: como lidar com uma tarefa que demora minutos ou horas para terminar, se não há mais uma conexão contínua para "avisar" quando ela acabar? A extensão Tasks resolve isso com um modelo de handle: o servidor responde a um tools/call com um identificador de tarefa, e o cliente consulta o andamento por conta própria, com chamadas como tasks/get, tasks/update e tasks/cancel.
05Prós e contras dessa mudança
Vantagem
Por quê
Escala em infraestrutura moderna
Servidores MCP podem rodar em funções serverless e edge, sem processo dedicado sempre ativo
Segurança mais robusta
Autorização alinhada a OAuth/OIDC de produção facilita adoção em ambientes corporativos com exigências rígidas de identidade
Cache e performance
Listagens cacheáveis reduzem chamadas repetidas de descoberta de ferramentas
Desvantagem
Por quê
Quebra de compatibilidade
Servidores na versão nova podem não funcionar com clientes antigos, e vice-versa, exigindo que os dois lados compartilhem uma versão suportada ou implementem tradução
Migração custosa
Integrações existentes que dependiam de sessão persistente precisam ser reescritas para o modelo de requisição autocontida
Curva de adaptação
Times que já dominavam o modelo antigo (stateful) precisam reaprender partes da arquitetura
06O que isso significa na prática
Para quem já usa integrações MCP (por exemplo dentro do Claude ou de ferramentas como Claude Code), a transição deve ser majoritariamente invisível no curto prazo: os SDKs oficiais em TypeScript e Python continuam recebendo correções e atualizações de segurança na versão antiga por pelo menos seis meses após o lançamento da v2, dando tempo para migração gradual. Para quem constrói servidores MCP próprios, vale acompanhar o changelog oficial antes de atualizar SDKs em produção, já que mudanças de protocolo como essa costumam exigir ajustes deliberados de compatibilidade.
Para fixar
A spec MCP 2026-07-28 muda o protocolo de "conexão com estado, sempre viva" para "requisições autocontidas, sem estado" — uma mudança pensada para escalar em infraestrutura serverless e de edge, reforçar autorização corporativa, e formalizar extensões como UIs embutidas e tarefas de longa duração. É uma mudança de arquitetura, não só uma feature nova, e por isso vem com quebra de compatibilidade que exige atenção de quem mantém servidores ou clientes MCP.
Compartilhar:
Newsletter
Saiba o que a IA está criando pra você. Não fique por fora.
Seja avisado quando eu postar uma imersão ou lição nova. Sem spam, só posts novos.