MCP para quem decide · Capítulo 18 de 21 · 21 min
Testar e contratar antes de aprovar
Transforme cada exigência técnica em cláusula assinada ou em teste executado, e trave o servidor aprovado contra mudanças silenciosas do fornecedor.
Este capítulo faz parte do curso gratuito MCP para quem decide.
Contrato de servidor MCP que diz apenas "compatível com MCP" não obriga o fornecedor a nada que a empresa consiga testar. Desde 28/07/2026 convivem no mercado a revisão 2026-07-28 e a anterior, 2025-11-25, e as duas falam protocolos diferentes no núcleo.
A diretora jurídica da rede de distribuição travou a assinatura do primeiro contrato de servidor de agente com uma observação de uma linha: o objeto está descrito como integração compatível com MCP, e ela não sabe testar essa frase. Ela está certa, e o remédio custa uma frase no contrato.
A string da revisão do protocolo, o piso de doze meses da política de ciclo de vida, o nível oficial da biblioteca e cada extensão de que o caso de uso depende. E precisa dizer o que acontece com a aprovação quando o fornecedor acrescenta uma ferramenta ao servidor já aprovado.
O identificador de versão do protocolo é uma string no formato ano-mês-dia, a data da última mudança incompatível. A revisão 2026-07-28 foi a maior desde o lançamento: tirou o estado do protocolo, eliminou o aperto de mão initialize e passou a exigir o pedido server/discover, a ficha de apresentação do servidor.
Duas implementações podem estar atualizadas, uma em cada revisão, sem que nenhuma esteja tecnicamente errada. Por isso contrato sem a string está subespecificado. Este capítulo converte em cláusula e em teste o que os capítulos anteriores levantaram. O que não vira texto assinado ou teste executado continua sendo boa intenção.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
De achado de pesquisa a cláusula redigível
| O que virou cláusula | Texto que a empresa exige | Por que essa é a redação certa |
|---|---|---|
| Revisão do protocolo | O fornecedor declara que implementa a revisão 2026-07-28 e o prazo, em trimestre, para atender a revisão seguinte. | Desde 28/07/2026 a expressão compatível com MCP deixou de ser verificável. Duas pontas atualizadas podem falar revisões diferentes. |
| Continuidade de recurso | Nenhuma entrega depende de recurso depreciado, e mudança que deprecie recurso em uso respeita o piso de doze meses da política oficial. | Roots, Sampling, Logging, o transporte HTTP com SSE e o registro dinâmico de cliente foram depreciados em 28/07/2026. A política aceita prazo menor em risco de segurança ativo. |
| Nível da biblioteca | As bibliotecas da entrega são de nível 1 do sistema oficial, ou o fornecedor justifica o nível inferior e assume o risco de defasagem. | Nível 1 traz 100% de conformidade, triagem em dois dias úteis e correção de bug crítico em sete dias. É compromisso publicado, não promessa comercial. |
| Extensão nomeada | O fornecedor declara, pelo nome, cada extensão de que o caso de uso depende: MCP Apps, Tasks (io.modelcontextprotocol/tasks) ou Enterprise Managed Authorization. | Suporte ao protocolo e suporte à extensão são afirmações distintas. Extensões ficam desligadas por padrão e exigem adesão explícita das duas pontas. |
| Retenção de dados e canal | O fornecedor declara por onde o modelo chama o servidor e se esse caminho está coberto pelo acordo de retenção de dados da empresa. | O conector MCP da API do Claude está em beta, fora do Bedrock e do Google Cloud, e não é elegível a retenção zero de dados. |
| Correção e rescisão | Prazo acordado de correção de falha de segurança reportada, com direito de rescisão em caso de recusa de corrigir. | A Akamai publicou em 12/05/2026 o caso de um fornecedor de nuvem que recebeu relato de exfiltração não autenticada e optou por não corrigir. |
| Registro de cliente | O fornecedor usa documentos de metadados de cliente, e não o registro dinâmico depreciado. | O registro dinâmico foi depreciado em 28/07/2026 e permanece só por compatibilidade. Proposta que o vende como diferencial está vendendo caminho em saída. |
Fonte: Changelog da revisão 2026-07-28, documentação do MCP e do Claude, Akamai (12/05/2026)
As datas que a cláusula precisa citar
- 23/02/2026Concluído
Níveis oficiais de biblioteca publicados
Apoiados em testes de conformidade disponíveis desde 23/01/2026. Transformam escolha de linguagem em critério defensável em auditoria.
- 12/05/2026Concluído
Caso publicado de recusa de correção
Fornecedor de nuvem de grande porte recebeu relato de exfiltração não autenticada e optou por não corrigir. É a motivação concreta da cláusula de rescisão.
- 28/07/2026Concluído
Revisão 2026-07-28 publicada
Protocolo sem estado, server/discover obrigatório, Tasks como extensão e recursos depreciados com prazo. Toda minuta anterior precisa de revisão.
- 25/09/2026Agora
Portal de plugins e conectores do Claude aberto
Submissões passam por varredura de segurança e revisão. A vitrine filtra melhor, e a homologação interna continua obrigatória.
- 28/07/2027Previsto
Primeira data elegível de remoção dos recursos depreciados
Piso de doze meses da política de ciclo de vida. É o prazo que a cláusula de continuidade cita e o horizonte do inventário interno.
As perguntas de autorização levantadas em "Amarrar o acesso do agente ao crachá da pessoa" entram aqui como item de ata, e a revisão 2026-07-28 acrescentou uma quinta:
- 01O token emitido para o servidor do fornecedor vale só para ele, ou abre outros sistemas da casa.
- 02Existe tela de consentimento própria por cliente antes de redirecionar a terceiro.
- 03A primeira conexão pede escopo mínimo com elevação gradual.
- 04O registro de cliente usa documentos de metadados, e não o registro dinâmico depreciado.
- 05O cliente valida o emissor (
iss, o carimbo que identifica quem emitiu a credencial) antes de aceitar a credencial.
Uma nota de pesquisa da Cloud Security Alliance, de 25/04/2026, propõe quatro cláusulas que merecem entrar na minuta padrão: documentação de comportamento com remédio não limitado ao valor da assinatura, indenização para dano gerado por inteligência artificial, direito de auditoria sobre mudança de comportamento após a implantação e autorização formal do servidor antes da implantação. Os percentuais da mesma nota não têm metodologia publicada e ficam fora do comitê. A terceira cláusula é a mais importante, e o próximo bloco explica por quê.
Controle de mudança depois da aprovação é o item mais subestimado da governança de agente. Um servidor aprovado hoje pode ganhar amanhã uma ferramenta que escreve. Se ela entra sozinha, a aprovação inicial perde o objeto, porque o servidor aprovado deixou de existir.
A OpenAI documenta no ChatGPT quatro controles que viraram referência de mercado. Só administrador habilita e publica. Atualização do servidor exige ação explícita. Ação nova entra desabilitada. Mudança em ação existente aparece como diferença lado a lado antes de valer. A mesma documentação diz que verificar se o servidor é seguro antes de publicar é responsabilidade do cliente.
O que acontece quando o fornecedor mexe no servidor já aprovado
Propagação automática
Aprovação que não vale nada
- Ferramenta nova entra habilitada sem intervenção de ninguém
- Mudança em ferramenta existente vale imediatamente, sem revisão
- Qualquer usuário habilita e publica servidor
- Nenhum registro de qual versão foi efetivamente aprovada
- O objeto aprovado deixa de existir na primeira atualização do fornecedor
Mudança sob ação explícita
Aprovação que sobrevive à auditoria
- Somente administrador habilita e publica
- A atualização do servidor exige ação explícita, sem propagação automática
- Ação nova entra desabilitada por padrão, e alguém precisa ligar
- Mudança em ação existente aparece como diferença lado a lado antes de valer
- Responsabilidade por escrito: verificar se o servidor é seguro antes de publicar é obrigação de quem consome
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Glossário rápido
String da revisão
Identificador da versão do protocolo no formato ano-mês-dia, como 2026-07-28. É o único valor que torna verificável, num contrato, a frase compatível com MCP.
Recurso depreciado
Recurso que ainda funciona e não deve ser adotado por implementação nova, com data de remoção elegível em página pública. A cláusula de continuidade se apoia nesse registro.
Extensão
Adição opcional ao protocolo, como MCP Apps, Tasks e Enterprise Managed Authorization. Fica desligada por padrão, como um acessório vendido à parte, e precisa estar nomeada no contrato.
Documento de metadados de cliente
Mecanismo corrente de registro de cliente na autorização, uma ficha pública do aplicativo. Substitui o registro dinâmico, depreciado em 28/07/2026.
Ambiente de teste
Cópia isolada da operação, com dados fictícios e credenciais próprias, onde o servidor pode errar sem tocar cliente real.
Inspetor oficial
Ferramenta mantida pelo projeto do protocolo que conecta a um servidor e lista o que ele expõe. É a evidência mais barata de que o fornecedor entrega o que a proposta descreve.
Dois critérios de listagem que o mercado já publicou viram critério de aceite sem custo de elaboração. O primeiro separa ferramenta de leitura de ferramenta de escrita: servidor com uma única ferramenta que lê e escreve pede confirmação humana na hora errada e deixa de pedir na hora perigosa.
O segundo rejeita ferramenta genérica que recebe o método por parâmetro, uma chamada única que faz qualquer coisa conforme o campo enviado. Nela o nome aprovado não descreve a operação executada. Para conferir os dois, o inspetor oficial conecta ao servidor e lista o que ele expõe, sem que a empresa escreva uma linha de cliente.
Homologação em ambiente de teste, do roteiro ao aceite assinado
Três semanas, com dono em cada etapa. Nada vai para produção sem a última assinatura.
Passo 1: Montar o ambiente de teste
Dono: TI de infraestrutura, em cinco dias úteis. Dados fictícios, credenciais próprias do teste e o mesmo gateway que a produção vai usar.
Deu certo quando: O servidor responde no ambiente de teste sem nenhuma credencial de produção.
Erro comum: Testar com dado real de cliente para ganhar tempo.
Passo 2: Escrever o roteiro antes de ligar
Dono: dono do processo de negócio com segurança. Para cada ferramenta: caso de leitura, caso de escrita, erro esperado e permissão negada, com o resultado esperado escrito.
Deu certo quando: Roteiro assinado pelos dois antes do primeiro teste.
Erro comum: Roteiro escrito depois do teste, para caber no que o servidor fez.
Passo 3: Rodar o inspetor oficial e guardar a evidência
Dono: líder de plataforma. Conferir server/discover com a revisão 2026-07-28, ordem igual de tools/list em duas chamadas seguidas, ttlMs e cacheScope preenchidos, cabeçalhos Mcp-Method e Mcp-Name.
Deu certo quando: Capturas datadas de cada conferência, anexadas ao processo.
Erro comum: Aceitar captura enviada pelo fornecedor em vez de gerar a própria.
Passo 4: Testar autorização e controle de mudança
Dono: segurança. Token com audiência restrita, emissor validado, escopo mínimo. Depois, simular atualização do fornecedor com ferramenta nova.
Deu certo quando: A ferramenta nova aparece desabilitada e a mudança só vale após ação do administrador.
Erro comum: Pular o teste de mudança porque o servidor ainda não mudou.
Passo 5: Fechar o relatório de uma página
Dono: líder de plataforma. Para cada item reprovado: o que foi testado, o retorno observado, a cláusula violada e o prazo pedido para correção.
Deu certo quando: Relatório entregue ao fornecedor com prazo, se houver reprovação.
Erro comum: Devolução sem cláusula citada, que vira discussão de interpretação.
Passo 6: Colher o aceite assinado
Dono: CFO como aprovador final. Assinam dono do processo, segurança e jurídico, com a versão do servidor fixada no termo.
Deu certo quando: Termo de aceite com três assinaturas e versão fixada, anexado ao contrato.
Erro comum: Aceite sem versão, que aprova também as atualizações futuras.
No fim você tem: Um servidor aprovado com evidência própria, versão fixada e contrato que diz o que acontece quando ele mudar.
Material para o time técnico: roteiro de homologação em uma sessão
O que conferir no retorno de server/discover
Na revisão 2026-07-28 todo servidor deve implementar server/discover para anunciar versões de protocolo atendidas, capacidades e identidade. Confira se a lista de revisões inclui a que o contrato exige, se as extensões declaradas incluem as que o caso de uso usa e se a identidade corresponde ao fornecedor da proposta. Divergência de versão retorna o erro UnsupportedProtocolVersion, o que já é um teste em si.
Quais cabeçalhos padrão precisam aparecer nas requisições
A revisão 2026-07-28 exige Mcp-Method e Mcp-Name nas requisições POST do transporte Streamable HTTP (SEP-2243). Eles permitem a gateway, firewall de aplicação e limitador de taxa filtrar sem abrir o corpo da mensagem. Cabeçalhos derivados de parâmetro de ferramenta ficam visíveis a intermediários, então senha, chave de API, token ou dado pessoal não devem ir por esse caminho.
Que campos de cache precisam vir preenchidos
ttlMs e cacheScope, obrigatórios nos retornos de tools/list, prompts/list, resources/list, resources/read e resources/templates/list pelo SEP-2549. Confira também a ordem da lista de ferramentas entre duas chamadas seguidas: ordem que muda a cada chamada quebra o cache de todos os clientes, como mostrado em "Medir a fatura invisível do contexto".
O que muda quando o modelo chama o servidor pela API do Claude
O conector MCP da API do Claude está em beta, ativado pelo cabeçalho mcp-client-2025-11-20, com lista de ferramentas permitidas e bloqueadas e autenticação OAuth Bearer. Ele não está disponível no Bedrock nem no Google Cloud e não é elegível a retenção zero de dados. Empresa com acordo de retenção zero precisa de outro caminho para esse fluxo.
Que transporte reprova de imediato
O HTTP com SSE de 2024-11-05, depreciado desde 2025-03-26 e reclassificado como depreciado na revisão 2026-07-28 sob a política de ciclo de vida. Servidor entregue nesse transporte nasce com prazo contado. O caminho corrente é o Streamable HTTP.
Três propostas chegaram para o mesmo escopo: consulta de estoque e condição comercial pelo agente, com aprovação humana em pedido acima de um teto. A proposta A cita compatibilidade com MCP sem nomear revisão, vende registro dinâmico de cliente como diferencial e entrega no transporte HTTP com SSE. A proposta B nomeia a revisão 2026-07-28, usa biblioteca de nível 1 e declara a extensão Tasks pelo identificador, mas propaga atualizações automaticamente. A proposta C nomeia a revisão, usa biblioteca de nível 3, exige ação explícita para cada atualização e expõe uma única ferramenta executar_operacao, que recebe o tipo de operação por parâmetro.
Qual proposta passa na homologação, e qual cláusula barra cada uma das outras?
Verificação rápida
O fornecedor confirma por escrito que atende a revisão 2026-07-28. O caso de uso é aprovação humana em pedido acima de um teto, com processamento que pode levar minutos. O que ainda falta perguntar?
Checklist contratual em nove itens, para a área de compras
Objeto verificável
0/3Continuidade e responsabilidade
0/3Depois da assinatura
0/3Tire da gaveta o contrato de servidor ou conector mais crítico que a empresa já assinou e procure a string 2026-07-28 no objeto. Se ela não estiver lá, abra aditivo com os nove itens do checklist em até 60 dias. Confira no fim do prazo: aditivo assinado e homologação refeita no ambiente de teste, com termo de aceite de três assinaturas.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Depois, siga para
- CursoMCP com Chrome: Automação com IAsugerido pelo grafo7 capítulos de “MCP com Chrome: Automação com IA” usam conceitos apresentados em “MCP para quem decide”.
- CursoClaude Code CLI: Programação com IAsugerido pelo grafo7 capítulos de “Claude Code CLI: Programação com IA” usam conceitos apresentados em “MCP para quem decide”.
- CursoDo Agile ao Agentic Operating Modelsugerido pelo grafo4 capítulos de “Do Agile ao Agentic Operating Model” usam conceitos apresentados em “MCP para quem decide”.
- CursoSegundo cérebro com IAsugerido pelo grafo3 capítulos de “Segundo cérebro com IA” usam conceitos apresentados em “MCP para quem decide”.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- Software e IA para executivosConferir quem publicou cada plugue que liga o agente aos sistemasExaminar conexões de Conferir quem publicou cada plugue que liga o agente aos sistemas
- Deploy para decisão executivaO calendário que o fornecedor controla e a dívida com prazoExaminar conexões de O calendário que o fornecedor controla e a dívida com prazo
- MCP com Chrome: Automação com IAConfigurar o servidor MCP sem herdar um prazo de validadeExaminar conexões de Configurar o servidor MCP sem herdar um prazo de validade
- Letramento em IA para ExecutivosFaça a IA responder com o que a empresa sabeExaminar conexões de Faça a IA responder com o que a empresa sabe
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.