O que saiu a 28 de julho

O Model Context Protocol publicou a sua quinta especificação a 28 de julho, e é a maior alteração desde que o protocolo nasceu. O núcleo é agora sem estado. A negociação entre initialize e initialized desaparece, o cabeçalho Mcp-Session-Id é retirado, e cada pedido leva em vez disso a versão do protocolo, a identidade do cliente e as suas capacidades num campo _meta. O efeito prático é que basta um distribuidor de carga round robin: qualquer instância pode servir qualquer pedido e deixa de haver armazenamento de sessões para manter.

Dessa decisão decorrem várias outras peças. Os Multi Round-Trip Requests substituem as chamadas iniciadas pelo servidor que até aqui exigiam um fluxo mantido aberto: em vez de empurrar um pedido por um canal aberto, o servidor devolve um tipo de resultado input_required e o cliente repete a chamada original com as respostas em anexo. Os pedidos Streamable HTTP levam agora os cabeçalhos Mcp-Method e Mcp-Name, para que um gateway ou um limitador de débito possa encaminhar e medir sem analisar o corpo JSON. Os resultados de listagem de ferramentas, prompts e recursos levam um tempo de vida e um âmbito de cache. As Tasks e as MCP Apps passam para um quadro formal de extensões em vez de ficarem no núcleo.

Os números de adoção explicam porque isto conta para além de quem escreve servidores. Os kits de desenvolvimento de nível 1 para TypeScript, Python, Go e C sharp aproximam-se em conjunto dos 500 milhões de descarregamentos por mês, e os pacotes de TypeScript e Python ultrapassaram cada um os mil milhões de descarregamentos totais. David Soria Parra, um dos principais responsáveis pela manutenção, chamou-lhe a publicação mais importante desde que o remote MCP arrancou há mais de um ano. Se a sua empresa comprou nos últimos dezoito meses um produto que liga um assistente aos seus sistemas, esta especificação está por baixo, tenham-lhe dito o nome ou não.

Retirar o Sampling desloca uma fatura de inferência

A lista de descontinuações lê-se como arrumação: Roots, Sampling e Logging, todos com uma janela de doze meses. Dois deles são realmente menores. O Roots passa a caminhos de pastas e ficheiros passados como parâmetros da ferramenta ou fixados na configuração do servidor. O Logging muda para a saída de erro padrão ou para o OpenTelemetry, que é onde a maioria de quem opera já o queria. O Sampling é outro caso, e é-o de uma maneira que toca num orçamento e não numa base de código.

O Sampling era o mecanismo pelo qual um servidor MCP podia pedir ao cliente que executasse uma resposta do modelo em seu nome. O servidor precisava da saída de um modelo de linguagem mas não tinha de guardar credenciais, porque era o cliente que fazia a inferência e era o cliente que a pagava. Trata-se de uma repartição comercial real expressa como função de protocolo. A orientação de migração publicada para os servidores que perdem o Sampling manda integrar diretamente com as interfaces de um fornecedor de modelos a partir do lado do servidor. Lida por quem opera, a consequência é clara: quem mantém o servidor precisa agora de conta própria junto do fornecedor, de chave própria e de rubrica própria no orçamento.

Para que lado se move o dinheiro depende da cadeira em que está sentado. Se mantém servidores MCP para o seu próprio pessoal contra o cliente de um fornecedor, aterra na sua conta uma inferência que antes não pagava, e numa instalação de média dimensão isso é um novo compromisso mensal de quatro algarismos em euros e não um erro de arredondamento. Se consome o servidor MCP de um fornecedor, conte com uma revisão de preços, porque um custo que antes era empurrado para o seu cliente passa a ser do próprio fornecedor. Nada disto é anunciado nas notas de versão. Ambas as coisas aparecem numa fatura em menos de um ano.

Sem estado deslocou o estado, não o apagou

Os comentários dos fornecedores em torno desta publicação giram unanimemente em torno da escala, e vêm das empresas que mais ganham quando os servidores se tornam fáceis de alojar: fornecedores de nuvem e de periferia que descrevem o protocolo como encaminhável, guardável em cache e escalável à escala global, e plataformas que saúdam o fim da gestão de sessões. Tudo isso é verdade. Abandonar a ligação de cada sessão à mesma instância elimina uma classe de falhas em que um fluxo interrompido destruía a conversa inteira, e permite correr um servidor sobre infraestrutura sem servidor que nunca poderia ter mantido uma sessão aberta.

O que nenhum deles diz é que o estado não se evaporou. Tudo o que tem mesmo de persistir entre chamadas passa agora a ter de ser representado de forma explícita: o servidor emite um identificador - o de um carrinho, um token, uma referência a um fluxo de trabalho - e devolve-o dentro de um resultado para que o cliente o reenvie. É um desenho sólido, mas converte uma preocupação invisível do protocolo numa parte visível dos seus contratos de ferramentas. Alguém tem de decidir o que significam esses identificadores, quanto tempo duram e o que acontece quando um cliente reenvia um já caducado. Esse trabalho não desapareceu com o cabeçalho de sessão. Mudou-se para os seus esquemas, onde cabe à sua equipa acertar.

Ponha 28 de julho de 2027 no plano

A regra que manda é que tudo o que está marcado como descontinuado se mantém funcional durante pelo menos doze meses. Isso faz de 28 de julho de 2027 a primeira data em que Roots, Sampling, Logging, o registo dinâmico de clientes ou o antigo transporte por HTTP e SSE podem de facto ser removidos, e é a única data desta publicação que merece ficar escrita num roteiro. Nada se parte esta semana. Ainda assim, as alterações à autorização são as primeiras a ler: os servidores de autorização passam a ter de devolver um parâmetro de emissor e os clientes têm de o validar antes de trocarem um código, as credenciais de cliente ficam ligadas ao servidor que as emitiu, e o registo dinâmico de clientes dá lugar aos Client ID Metadata Documents.

Para uma operação europeia, a peça sobre a qual convém agir cedo é a Enterprise Managed Authorization, que chega como extensão e permite à administração atribuir acesso a servidores MCP de forma centralizada através de um fornecedor de identidade. Até agora a autorização nas instalações de MCP ficou muitas vezes para o fim, e é precisamente por isso que tantos projetos internos de agentes encalharam na revisão de segurança. Se o seu é um deles, o motivo do encalhe está agora tratado na especificação, e o passo honesto é perguntar aos seus fornecedores quando irão suportar a extensão em vez de esperar que lho digam.

Leia a seguir: Uma mensagem alcançou as chaves SSH  |  Anthropic pede chips a um fabricante de memória