Ler a data de validade de cada recurso

Um contrato de 36 meses apoiado em recurso que pode ser removido em 2027 vence por dentro antes de vencer no papel. A CFO da rede de distribuição de material de construção fez essa conta numa pergunta simples. O CTO pediu verba para ligar o agente ao CRM e ao e-commerce próprio, com proposta de 36 meses. Ela quis saber se havia prazo de aviso ou se o fornecedor podia mudar de rumo no segundo ano.

Até meados de 2026 a pergunta não tinha resposta contratável. Um recurso do protocolo podia entrar numa revisão e sair na seguinte, sem prazo publicado. A revisão 2026-07-28, publicada em 28/07/2026, trouxe política formal de ciclo de vida. Há também uma página única que diz o que está saindo e a partir de quando.

Este capítulo entrega a leitura de compras dessa política, a lista datada do que já está em contagem regressiva e um plano de migração com dono. Entrega também a distinção entre núcleo e extensão, que decide quanto tempo de suporte a empresa pode exigir e quase nunca aparece na proposta comercial.

Três consequências de compras aparecem na ordem de uma negociação

1. 01O piso de doze meses é citável em cláusula de continuidade, porque está publicado e independe da boa vontade do fornecedor. A ressalva vem junto: cai para noventa dias quando há vulnerabilidade com aviso publicado ou exploração documentada.
2. 02Uma página única responde o que está saindo e até quando, e ela abre sem login. O auditor confere sozinho, sem pedir declaração ao fornecedor.
3. 03As bibliotecas oficiais de nível 1 (TypeScript, Python, Go e C#) precisam marcar a interface depreciada na versão seguinte. A política recomenda também aviso em tempo de execução, então o log de produção denuncia a dívida. A parte que interessa ao caixa está no quadro seguinte.

Sampling aparece uma única vez neste curso, e por um motivo específico. A definição é curta: o servidor pede ao cliente que execute uma geração no modelo do cliente. Material antigo descrevia o recurso como captura de dados de amostra, o que está errado.

O desenho tinha uma virtude econômica. O servidor usava o modelo do lado do cliente e dispensava chave de API própria, então quem pagava a fatura do modelo era o cliente. A escolha do modelo seguia preferências de custo, velocidade e inteligência, com uma pessoa no laço com poder de negar.

A consequência executiva da migração cabe numa frase: a fatura do modelo volta para o lado do servidor. Quem construiu integração apoiada nisso tem, além do retrabalho, uma linha de custo nova. Pergunte ao fornecedor qual dos lados vai absorvê-la.

Roots pede uma correção mais grave. Era declaração do cliente sobre escopo, como um crachá de visitante que ninguém confere na porta, sem imposição pelo protocolo. Quem desenhou controle de segurança apoiado nisso precisa revisar o desenho. Essa classe de erro volta em "Reconhecer os ataques próprios deste protocolo".

A revisão 2026-07-28 mudou também o jeito de o servidor pedir informação no meio de uma tarefa. O protocolo ficou sem estado: cada pedido chega completo, com versão e capacidades, como uma carta que traz remetente e assunto sem depender da anterior. Saíram o aperto de mão inicial, chamado initialize, e o cabeçalho de sessão Mcp-Session-Id.

No lugar dos pedidos que o servidor fazia ao cliente entrou o MRTR, pedido de várias idas e voltas: o servidor devolve a resposta marcada como input_required, como um atendente que devolve o formulário pedindo o dado que faltou. O cliente reenvia o pedido original com a informação. Sampling, Roots e confirmação humana passam por esse caminho.

Falta a informação que decide contrato: onde o recurso mora. O protocolo tem duas classes de estabilidade, com regras diferentes. O núcleo segue a política de ciclo de vida com piso de doze meses. Extensão é adição opcional, com nome no formato de domínio invertido, e o prefixo io.modelcontextprotocol fica reservado às extensões oficiais.

Três regras publicadas mudam a conversa de compras

• Extensão vem desligada e exige adesão explícita das duas pontas, cliente e servidor.
• Biblioteca oficial pode não implementar uma extensão sem perder conformidade com o protocolo.
• Extensão evolui em ciclo próprio, e mudança que quebraria o que existe exige nome novo.

Dar suporte ao protocolo e dar suporte à extensão Tasks são afirmações diferentes. Tasks, o trabalho assíncrono de longa duração, saiu do núcleo em 28/07/2026. É o padrão da aprovação humana e do processamento em lote que interessa à operação.

Os oito meses do campo elicitationId são o argumento mais eficiente contra a pressa comercial. O campo entrou na especificação em 25/11/2025 para correlacionar pedidos de confirmação humana e saiu em 28/07/2026, quando o MRTR passou a resolver isso repetindo o pedido original.

Constar da especificação e ser estável são coisas distintas. Fornecedor que apresenta recurso recém-chegado como base de arquitetura pede à empresa um risco que a política ainda não cobre. O piso de doze meses protege quem já implementou algo depreciado, e não quem começa a implementar uma novidade agora.

Peça hoje o inventário ao time de arquitetura, com prazo de duas semanas e as seis linhas do quadro. Confira a entrega por dois números: servidores em produção sem linha no inventário, que precisa ser zero, e servidores ainda em HTTP+SSE, que precisa ter data de corte até 31/12/2026.