MCP para quem decide · Capítulo 9 de 21 · 22 min
Separar o que o padrão faz do que vendem
Cinco perguntas que conferem em documento público se a promessa do fornecedor tem lastro, antes que ela vire cláusula assinada.
Este capítulo faz parte do curso gratuito MCP para quem decide.
Proposta comercial de agente costuma atribuir ao protocolo capacidades que ele não declara ter, e quem assina paga depois pela auditoria, pelo catálogo e pela política de credencial que presumiu inclusos. Três obrigações continuam sendo da casa mesmo com o padrão funcionando: a trilha de quem decidiu o quê, a curadoria de qual servidor entra e a política de credencial e de rede em volta de tudo.
Nenhuma das três obrigações está no protocolo, e uma delas falta nos cinco protocolos de interoperabilidade avaliados academicamente. Para conferir promessa de fornecedor existe um método de cinco perguntas que roda em vinte minutos com o repositório oficial aberto.
A pergunta que chega depois de tudo funcionar
A CFO da rede de distribuição já viu o que o protocolo é, quanto tempo cada recurso dura e o que pode dar errado. Sobra a pergunta de fronteira: onde termina a responsabilidade do padrão e começa a nossa. Ela importa porque proposta comercial costuma preencher esse vazio por conta própria.
Antes do inventário, três correções de entendimento. Elas aparecem com frequência em documento de arquitetura já aprovado, e cada uma cria no papel um controle que não existe na prática.
Glossário rápido
Anotação de ferramenta
Campos que o servidor preenche declarando o próprio comportamento, do tipo somente leitura ou destrutivo. A revisão 2026-07-28, vigente desde 28/07/2026, manda que clientes tratem essas anotações como não confiáveis, salvo quando vierem de servidores confiáveis. Usá-las como controle de segurança é erro de arquitetura, porque são autodeclaração sem verificação. O controle de risco fica no host, com aprovação humana no laço.
Roots
Mecanismo pelo qual o cliente declarava ao servidor qual escopo de sistema de arquivos considerava relevante. Nunca foi fronteira de segurança imposta pelo protocolo, só declaração do cliente. Quem desenhou segurança sobre isso precisa revisar o desenho, e agora tem prazo: a revisão 2026-07-28 depreciou o recurso, com remoção possível a partir de 28/07/2027.
Sessão
Nunca valeu para autenticar. O texto normativo manda servidores com autorização verificarem todas as requisições de entrada, sem usar sessão para autenticação. Desde 28/07/2026 o protocolo ficou sem estado: o aperto de mão inicial e o cabeçalho de sessão saíram, e cada pedido carrega versão e capacidades.
Onde o controle mora, nas três correções acima
Apoiar-se no que o servidor declara sobre si mesmo
Controle que não existe
- Liberar automaticamente ferramenta marcada como somente leitura pelo próprio servidor
- Registrar em ata que o escopo de arquivos está limitado porque o cliente declarou Roots
- Tratar a sessão como prova de que a requisição vem de quem se espera
- Aceitar a declaração de comportamento do fornecedor como equivalente a verificação
- Documentar risco baixo com base em campo preenchido pela contraparte
Colocar a decisão no lado que responde por ela
Controle que existe
- Aprovação humana no host antes da operação privilegiada, com o comando visível
- Escopo imposto por parâmetro de ferramenta, URI de recurso ou configuração de servidor
- Verificação de autorização em toda requisição de entrada, sem depender de estado anterior
- Evidência pedida em demonstração, com a tela de consentimento real na frente
- Trilha própria registrando qual ferramenta foi chamada, por quem e com que resultado
Existe orientação pública dizendo que a defesa atual não cobre
Em 20/05/2026, a NSA, agência de inteligência de sinais dos Estados Unidos, publicou a folha de informação "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation". O comunicado oficial diz que a especificação exige implementação cautelosa e que sistemas agênticos trazem riscos novos, como invocação dinâmica de ferramenta e confiança implícita entre componentes.
A frase que muda a conversa em conselho vem em seguida: as estratégias estabelecidas de defesa cibernética não cobrem adequadamente esses riscos. Quem for citar o documento em apresentação deve ler o arquivo integral antes de pôr aspas, porque o resumo acima vem do comunicado de imprensa da agência.
E existe guia internacional dizendo por onde começar
Em 01/05/2026 saiu um guia conjunto da CISA, a agência americana de cibersegurança, com o centro australiano e outros parceiros, sobre adoção cuidadosa de serviços de inteligência artificial agêntica. Ele liga a gestão de risco de IA aos arcabouços de cibersegurança que a empresa já tem.
A recomendação que vira argumento imediato é adotar de forma incremental, começando por tarefa de baixo risco. É a resposta pronta para o piloto ambicioso que chega ao comitê pedindo aprovação de uma vez, com escopo largo e prazo curto.
A lacuna que nenhum protocolo da categoria cobre
Uma avaliação acadêmica de 30/06/2026 comparou cinco protocolos de interoperabilidade entre agentes contra seis dimensões de governança. Votação e preservação de divergência estão ausentes nos cinco, e deliberação está ausente ou atendida em parte. Os autores concluem que governança entre agentes é uma camada inteira que falta acima dos padrões atuais.
Para o comitê de risco, isso responde como se prova depois quem decidiu o quê. Nenhum protocolo carrega registro de deliberação, divergência ou aprovação humana em formato interoperável. Trilha de decisão e auditoria continuam obrigação da casa, fora do protocolo, e essa é a linha de orçamento que ninguém põe no plano porque presume que o padrão resolve.
O próprio roadmap admite o buraco
O documento oficial de prioridades organiza o ano em quatro frentes e declara que a prontidão corporativa é a menos definida das quatro, de propósito. Trilha de auditoria, autenticação integrada ao provedor de identidade, comportamento de gateway e portabilidade de configuração aparecem como direção, sem compromisso de entrega.
Quando o mantenedor do padrão escreve isso, a leitura de compras é direta: auditoria, gateway e portabilidade de configuração são responsabilidade do comprador em 2026. A revisão de 28/07/2026 trouxe a extensão de autorização gerenciada pela empresa, e o resto da camada corporativa segue fora do núcleo. Isso vira requisito de arquitetura interna e item de contrato com quem vende gateway.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
O que ainda não existe, com estado conferido em setembro de 2026
| Promessa que circula | Estado real | Data de referência | Leitura de decisão |
|---|---|---|---|
| Descoberta automática do servidor por endereço bem conhecido | A proposta SEP-2127, aberta em 21/01/2026, segue aberta e sem incorporação ao núcleo | Aberta em 21/01/2026, estado conferido em 24/09/2026 | Não reescrever infraestrutura de descoberta antes de o formato fechar |
| Catálogo oficial como fonte confiável de servidores | O registro oficial segue em preview, sem garantia de durabilidade, sem servidor privado e com a varredura de segurança delegada a terceiros | Preview desde 08/09/2025, ainda em preview em 26/09/2026 | Catálogo interno aprovado é construção própria ou compra, com dono e orçamento |
| Autorização gerenciada pela empresa para qualquer provedor de identidade | A extensão foi declarada estável com um único provedor de identidade atendido no lançamento, e passou a extensão formal na revisão 2026-07-28 | Estável em 18/06/2026 | Empresa em outro provedor tem cronograma real diferente do prometido em slide |
| O site vira ferramenta para agentes de navegador com uma configuração | Teste de origem em curso, sobre rascunho de grupo comunitário fora da trilha formal, com troca de interface entre versões | Teste desde 09/06/2026 | Piloto controlado em fluxo de baixo risco, sem prometer prazo à diretoria |
| Selo oficial de segurança em catálogo curado | Ausente do roadmap oficial e contrário à política de moderação publicada | Roadmap e política consultados em 2026 | Planejamento que depende desse selo aposta em algo que não foi prometido |
A coluna de estado separa recurso disponível de recurso anunciado. As cinco linhas aparecem em material comercial como se já estivessem disponíveis.
- Etapa 1 de 5: 1. Qual proposta
em qual SEP a funcionalidade se apoia
- Etapa 2 de 5: 2. Qual estado
aberta, final ou em trilha de extensão
- Etapa 3 de 5: 3. Qual revisão
a string que o produto implementa hoje
- Etapa 4 de 5: 4. Qual extensão
declarada por identificador, não por nome comercial
- Etapa 5 de 5: 5. Qual documento
a fonte pública que sustenta o número apresentado
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Como as cinco perguntas se comportam em uma reunião
A primeira e a segunda economizam mais tempo, porque funcionalidade sem proposta no repositório oficial não tem previsão de existir. SEP (proposta formal de mudança no padrão, como um projeto de lei numerado) é o que se pede. A terceira troca a resposta genérica de compatibilidade por uma string verificável, e desde 28/07/2026 isso pesa: a revisão 2026-07-28 quebrou compatibilidade no núcleo.
A quarta pergunta separa duas afirmações tratadas como uma. Aceitar o protocolo e aceitar uma extensão específica dele são coisas diferentes: extensões vêm desabilitadas por padrão, exigem adesão explícita e podem faltar num SDK sem afetar a conformidade. A quinta pergunta é a que este curso aplica a si mesmo, e a tabela seguinte mostra o resultado.
Sete números que circulam e não entraram neste curso, com o motivo
| Número | Onde aparece | Motivo da recusa |
|---|---|---|
| 78% dos times corporativos com agentes em produção | Conteúdo de mercado de junho e julho de 2026 | Sem pesquisa nomeada, sem amostra e sem metodologia. Uma das publicações que o divulgou registrou nota de verificação em 24/05/2026 dizendo que não pôde confirmar |
| 97 milhões de downloads mensais de SDK | Apresentação comercial usando o dado como retrato atual | O número é primário e a data é 09/12/2025. O post oficial de 28/07/2026 fala em perto de meio bilhão de downloads por mês nos SDKs principais. Usar o antigo como retrato atual é erro de datação |
| 150 milhões de downloads e 200.000 instâncias vulneráveis | Análise de fornecedor de segurança de 15/04/2026 | Sem metodologia publicada, de fonte com interesse comercial, e em conflito com a medição independente de 28/04/2026 |
| Selo oficial de segurança em catálogo curado no quarto trimestre de 2026 | Previsão em conteúdo de mercado | Ausente do roadmap oficial e contrário à política de moderação publicada, que declara moderação mínima a nula |
| 75% dos fornecedores de gateway com recursos deste protocolo até o fim de 2026 | Atribuído a casa de análise, em material de fornecedor | Não consta do release primário do analista, que fala em 40% das aplicações corporativas com agentes de tarefa até o fim de 2026, em publicação de 26/08/2025, sem mencionar o protocolo |
| Quase metade das empresas de software com o protocolo em produção | Relatório de fornecedor de gateway | Pesquisa de parte interessada, sem tamanho de amostra nem período de campo divulgados na página oficial. Vale como sinal de categoria, não como referência de setor |
| Cerca de 390 dólares de custo de definição de ferramenta em 2.600 conversas | Medição publicada em registro público de problema de um repositório, em 28/05/2026 | Medição de um único operador sobre a própria carga, sem auditoria de terceiro. Admitida apenas como ordem de grandeza |
A linha de baixo é a única que sobrevive como ordem de grandeza. As outras seis não sustentam uma frase em ata.
Verificação rápida
Cinco afirmações retiradas de material comercial da categoria. Qual delas é fato datado com fonte primária, e não promessa?
Recusar promessa sem lastro antes da assinatura
Roteiro para a reunião de homologação de qualquer produto que diga usar MCP. Dono: quem conduz a compra, com apoio de uma pessoa técnica. Prazo: a resposta por escrito do fornecedor chega em até dez dias úteis.
Passo 1: Pedir a revisão da especificação por escrito
Solicite a string da revisão implementada no formato ano-mês-dia e o trimestre previsto para a seguinte.
Deu certo quando: O fornecedor responde 2026-07-28, ou dá data para chegar lá.
Erro comum: Aceitar "a versão mais recente", que não prende nada em contrato.
Passo 2: Pedir o número do SEP de cada funcionalidade prometida
Para cada recurso citado na proposta, peça a proposta formal no repositório oficial e o estado dela hoje.
Deu certo quando: Cada recurso tem número de SEP e estado conferido pela pessoa técnica em dez minutos.
Erro comum: Aceitar "está no roadmap" como resposta. Roadmap declara direção, sem compromisso de entrega.
Passo 3: Pedir o identificador de cada extensão
Extensão oficial tem identificador do tipo io.modelcontextprotocol/tasks. Nome comercial não serve.
Deu certo quando: A lista de extensões do contrato usa só identificadores, e a demonstração mostra cada uma ligada.
Erro comum: Presumir que dar suporte ao protocolo inclui as extensões. Extensão vem desligada por padrão.
Passo 4: Pedir a evidência de cada número da apresentação
Para cada estatística do material de venda, peça autor, título, data e endereço do documento.
Deu certo quando: Todo número tem documento público com metodologia, ou sai da proposta.
Erro comum: Levar número sem fonte para a ata do conselho com o seu nome ao lado.
Passo 5: Converter lacuna em condição suspensiva
Toda pergunta sem resposta objetiva vira cláusula com prazo e critério de aceite verificável por terceiro.
Deu certo quando: A minuta lista cada lacuna com data-limite e o teste que a encerra.
Erro comum: Assinar com a promessa de resolver depois, sem prazo nem critério escrito.
No fim você tem: Ao fim de dez dias úteis, a proposta tem revisão declarada, SEP e identificador para cada recurso e documento para cada número, ou as lacunas estão amarradas em condição suspensiva.
Recolhido para o time técnico: onde conferir cada uma das cinco perguntas
Como se confere o estado de uma proposta?
As propostas vivem como proposta de alteração no repositório da especificação, identificadas por número de SEP. O estado útil é se ela está aberta, se alcançou o estado final, ou se migrou para a trilha de extensões, que tem ciclo próprio sob o SEP-2133 e exige ao menos uma implementação de referência em SDK oficial antes da revisão. Proposta em trilha de extensão evolui independentemente do núcleo.
Onde se lê a revisão que um produto implementa?
A revisão é uma string no formato ano-mês-dia que marca a data da última mudança incompatível. Peça a string, não a expressão última versão. Duas implementações podem estar ambas atualizadas e falarem revisões diferentes, o que quebra interoperabilidade sem que ninguém esteja tecnicamente errado. Desde a revisão 2026-07-28 existe o método obrigatório server/discover, que anuncia versões atendidas, capacidades e identidade do servidor, e ele é o ponto único de inventário.
Como se verifica suporte a extensão?
Extensões são identificadas em formato de domínio reverso e anunciadas no campo de extensões das capacidades. As oficiais usam o prefixo io.modelcontextprotocol; na revisão 2026-07-28 são MCP Apps, Tasks e Enterprise Managed Authorization. A verificação é pedir o identificador exato, e não o nome comercial. A matriz oficial de suporte por cliente é mantida pela comunidade, então ausência na matriz indica falta de registro e não prova de ausência de suporte.
O que substitui a trilha de auditoria que o protocolo não oferece?
A propagação de contexto de trace do OpenTelemetry passou a ser documentada no protocolo, com as chaves de correlação viajando em campos de metadados de cada requisição. A trilha de decisão, que registra qual ferramenta foi chamada, por quem e com que resultado, é construída na pilha de observabilidade que a empresa já opera. É o mesmo artefato que a orientação de segurança recomenda e que a fiscalização de proteção de dados vai pedir, então construir uma vez atende aos dois.
Como se declara o que o próprio produto não faz?
Pelo registro público de recursos depreciados e pela política de ciclo de vida, que define os estados ativo, depreciado e removido, com janela mínima de doze meses contada da publicação da revisão que marca a depreciação, e piso de noventa dias na exceção de risco de segurança ativo. É a página única que responde o que está saindo e até quando.
Roteiro de vinte minutos, executado com o repositório oficial aberto.
Use literalmente estas cinco perguntas na reunião de homologação.
1. Em qual SEP esta funcionalidade se apoia?
Resposta aceitável: um número. Resposta inaceitável: "está no roadmap".
2. Qual o estado desse SEP hoje no repositório oficial?
Aceitável: aberto, final, ou em trilha de extensão, com a data da última atividade.
3. Qual revisão do protocolo o produto implementa hoje?
Aceitável: a string no formato AAAA-MM-DD. Inaceitável: "a última".
4. Qual extensão o produto declara, por identificador?
Aceitável: io.modelcontextprotocol/<nome>. Inaceitável: o nome comercial do recurso.
5. Qual documento público sustenta o número que você apresentou?
Aceitável: autor, título, data e endereço. Inaceitável: "pesquisa de mercado".
Regra de encerramento: qualquer pergunta sem resposta objetiva vira condição
suspensiva no contrato, com prazo e critério de aceite verificável por terceiro.Fronteira de responsabilidade, agrupada por quem responde
Responde: o protocolo, por texto normativo
0/4Responde: o fornecedor, por contrato
0/4Responde: a casa, por construção própria
0/5Em disputa, e por isso precisa de decisão explícita
0/3Leve as cinco perguntas à próxima reunião com fornecedor de agente e leia-as em voz alta, na frente dele. Dê dez dias úteis para a resposta escrita e conte quantas voltaram com SEP, revisão, identificador e documento; cada lacuna vira condição suspensiva na minuta. Depois, abra "Inventariar o que já roda nas máquinas do time", que começa a Parte 4 contando os servidores já ligados dentro de casa.
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”.
O mesmo assunto em outros cursos
- 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
- 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
- Agentes de código para executivosMontar o plano de 90 dias com dono e dataExaminar conexões de Montar o plano de 90 dias com dono e data
- Prompt Engineering para ExecutivosClassificar cada fluxo de IA pela Regra dos Dois antes de aprovarExaminar conexões de Classificar cada fluxo de IA pela Regra dos Dois antes de aprovar
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.