MCP é suficiente para dar contexto compartilhado a agentes de IA?

O MCP basta para alcançar todas as fontes da sua empresa e não basta para fazer duas delas concordarem. Abra o schema normativo do Model Context Protocol na revisão 2025-11-25 e leia o tipo Resource: nove campos, dois obrigatórios, uri e name, e sete opcionais, title, description, icons, mimeType, annotations, size e _meta. Nenhum deles registra onde aquele recurso está na hierarquia da sua empresa, em que versão ele está, ou qual de dois recursos contraditórios vence. Eu estava dentro de um marketplace de caronas no fim de 2025, contratado para acompanhar o dia a dia da engenharia e achar o que quebraria numa due diligence de investidor, e o que eu achei não estava no código. Um agente filtrou por uma palavra que todo humano da empresa entendia, o banco não encontrou nada, nenhum erro foi gerado, e os usuários pararam de ver as caronas que tinham reservado.

O lugar de onde eu vi define o que eu posso te contar. Eu não estava na adoção de IA e não escrevi nem revisei o código desta história. Reparar nas coisas era a tarefa inteira, e foi isso que ela trouxe. A empresa segue anônima. Um detalhe do produto sustenta o resto: a carona era uma das entidades centrais, e produto, marketing, diagramas técnicos e código davam nomes diferentes a ela.

O tipo Resource do MCP declara nove campos e nenhum deles diz qual fonte está certa

Isto é tudo o que o Model Context Protocol conta a um agente sobre um recurso. A especificação é explícita ao dizer que o schema TypeScript dela, e não suas páginas de prosa, é "the source of truth for all protocol messages and structures". E nesse schema, na revisão 2025-11-25, um Resource declara nove campos, depois que você resolve o que ele herda: seis no próprio tipo, mais name e title vindos de BaseMetadata e icons vindo de Icons. Dois são obrigatórios, uri e name. Sete são opcionais: title, description, icons, mimeType, annotations, size e _meta. Agora ache, nessa lista, o campo que diz a um agente se trip, offer ou carona é a palavra que o banco vai de fato atender. Não existe, e a ausência não é descuido. A visão geral de arquitetura do protocolo diz que o MCP "focuses solely on the protocol for context exchange" e que ele "does not dictate how AI applications use LLMs or manage the provided context".

O mais perto que o protocolo chega de ranquear uma fonte é priority, um número de 0.0 a 1.0 que o servidor declara sobre o próprio recurso, e a spec diz que o valor 1 significa "most important". O mais perto que ele chega de atualidade é lastModified, um carimbo ISO 8601 de quando o recurso mudou pela última vez, o que é um fato sobre bytes e não sobre verdade. Os dois vivem nas annotations opcionais do recurso, que o servidor escreve sobre si mesmo e nada verifica. A postura da especificação diante da autodescrição fica mais visível um tipo ao lado. No tipo Tool a especificação traz um aviso em linguagem normativa: clientes "MUST consider tool annotations to be untrusted unless they come from trusted servers". Esse aviso se limita a tools, então não fala diretamente sobre priority. O que ele mostra é a postura do protocolo na própria voz normativa: quando um servidor se descreve, o instinto da especificação é dizer ao cliente para não acreditar.

Nada disso é defeito do MCP. É um protocolo fazendo o trabalho dele e recusando um que nunca foi dele. O problema começa quando uma empresa confunde alcance com prontidão, conecta nove fontes a um agente e supõe que alguma coisa no encanamento está decidindo qual delas está certa. Em geral a suposição recai sobre a recuperação, que ordena trechos por similaridade e deixa a autoridade onde a encontrou: MCP e RAG estão em camadas diferentes, e nenhuma das duas é a camada que decide (em inglês).

Por que um agente de IA devolve resultado vazio sem erro: a palavra era válida, a entidade não

O null de Tony Hoare tinha uma qualidade redentora. Ele quebrava. Ao apresentar sua palestra na QCon London 2009, Hoare chamou a referência nula de 1965 de seu "billion-dollar mistake": ele tinha se proposto a tornar todo uso de referência "absolutely safe, with checking performed automatically by the compiler", não resistiu a colocar o null mesmo assim, e aquilo passou a causar "innumerable errors, vulnerabilities, and system crashes". Uma quebra é um presente. Ela para o programa, aponta uma linha e denuncia a si mesma. O que o marketplace entregou em dezembro de 2025 fez o oposto. Chame isso de null semântico: um resultado estruturalmente válido e semanticamente vazio, em que a consulta rodou, os tipos bateram, voltaram zero linhas, e nada no sistema sabia que a palavra estava errada.

O vocabulário tinha crescido por função, do jeito que cresce em todo lugar:

As pessoas transitavam entre essas palavras sem esforço. Numa conversa, a equivalência era óbvia. Então um método filtrou pela string offer onde o contrato executável definia trips. O filtro aceitou a string, rodou normalmente, não encontrou registro nenhum e não devolveu nada. Nada quebrou. Nenhum erro foi gerado.

A maior parte do produto continuou funcionando, o que tornou aquilo suportável e o que tornou aquilo invisível. Os usuários ainda conseguiam reservar caronas, e as telas mais amplas continuavam consultando trips. O defeito ficou em exatamente um filtro, o que selecionava as caronas agendadas de um usuário para a visão personalizada e as notificações construídas em cima dela. Um release quase inteiramente correto escondeu justamente os registros que mais importavam para quem estava procurando por eles. A fila do suporte foi onde aquilo apareceu: da noite para o dia, a reclamação principal numa empresa cuja reclamação principal costumava ser cancelamento de carona passou a ser gente dizendo que não achava suas caronas.

É por isso que um incidente semântico sobrevive às verificações comuns. Um teste que só olha a resposta passa. O verificador de tipos aceita a string. O monitoramento que só observa erro classifica a requisição como saudável, porque ela era. Se nenhum teste afirma que um usuário com trips agendados não pode receber uma coleção vazia quando outro artefato diz offer, não existe nada no pipeline procurando por essa falha.

Uma revisão mais nova do MCP não vai decidir significado, porque significado é conhecimento que mora nas pontas

A objeção óbvia a uma contagem de campos é que a contagem de campos muda. Alguém vai adicionar um campo de autoridade numa revisão futura, e aí? E aí nada, e o motivo tem quarenta anos. Em 1984, na ACM Transactions on Computer Systems, Saltzer, Reed e Clark deram nome ao princípio: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system."

Eles estavam falando de confiabilidade. Checagem de erro, criptografia, mensagens duplicadas. Nunca escreveram uma palavra sobre significado, e sou eu que estou estendendo o argumento deles, não citando. Mas repare naquilo de que o próprio exemplo de duplicatas deles depende. A rede não consegue suprimir as mensagens duplicadas de uma aplicação, eles escrevem, porque essas duplicatas "look like different messages to the communication system", então a supressão "must be accomplished by the application itself with knowledge of how to detect its own duplicates". O que conta como a mesma mensagem é uma definição que a aplicação guarda e o protocolo não enxerga. Um fato de definição já está sustentando peso dentro do argumento de confiabilidade deles. É esse o desenho do problema, e ele vale para vocabulário também. Se offer e trips são a mesma entidade, isso é conhecimento que mora na sua empresa, na cabeça das pessoas que deixaram as palavras se afastarem. Nunca esteve no protocolo, e revisão nenhuma vai botar isso lá.

Acesso não é acordo. Um protocolo torna toda fonte autorizada alcançável sem fazer duas delas significarem a mesma coisa, o que é a formulação, no nível do protocolo, da mesma lei que faz uma stack de IA nascer com o cérebro dividido.

Autoridade pertence a um fato, não a uma ferramenta, e proveniência nunca diz qual fato vence

A proveniência registra de onde um fato veio e como ele mudou; nunca registra que o fato vence. A nota PROV de acesso e consulta do W3C (2013) traça essa linha na própria voz: "A provenance record is not of itself guaranteed to be authoritative or correct. Trust in provenance records must be determined separately from trust in the original resource." Essa separação é o problema inteiro em duas frases, porque um agente que alcança quatro fontes precisa do julgamento, não do registro.

O marketplace não tinha esse julgamento escrito em lugar nenhum. Nada dizia que o código era dono do identificador operacional, que produto era dono do comportamento pretendido, que marketing era dono da palavra que o cliente vê, e que vocabulário de marketing nunca pode ser copiado para um filtro de dados. Então nada protestou quando uma palavra interna de produto virou exatamente isso. Autoridade desse tipo não pode ser concedida a uma ferramenta de uma vez por todas, porque ela não mora no grão de uma ferramenta. Para uma mesma entidade, num mesmo instante, o schema em produção governa trips, uma decisão de produto aprovada governa o que a funcionalidade deve fazer, e o marketing governa carona. Três fontes, todas com autoridade, nenhuma delas o sistema de registro.

A gestão de dados sabe disso há décadas, o que vale dizer com todas as letras em vez de fingir que a gente descobriu. Master data management atribui autoridade por campo, e não por sistema, e a parte difícil dela sempre foi decidir em qual campo de qual fonte confiar; as regras de sobrevivência são exatamente isso. O que a disciplina nunca precisou resolver foi prosa. As regras de sobrevivência arbitram valores tipados dentro de um schema, e não existe score de confiança computável entre uma frase num documento de produto e a definição de uma coluna. O grão sempre esteve certo. Ninguém construiu isso para as palavras.

A falha foi escrita por um agente, revisada por um agente, e passou por um humano que não dava conta

O filtro não foi erro humano do jeito que essa frase costuma soar. A funcionalidade que o continha foi construída por um agente de código. O code review foi feito por outra IA. A revisão humana falhou do jeito que revisão humana falha hoje, afogada num volume de código que pessoa nenhuma ia ler naquele ritmo. Dois agentes, os dois com acesso aos documentos de produto, aos designs e à base de código, e nenhum deles com registro algum do que a empresa tinha acordado que as palavras significavam. Nenhum dos dois errou localmente. O agente que escreveu usou uma palavra que era verdadeira na linguagem de produto. O agente que revisou viu um código que fazia o que dizia. A falha morava entre eles, num lugar que nenhum dos dois tinha recebido.

Essa lacuna é a parte medida. A telemetria de 2026 da Faros AI, sobre 22 mil desenvolvedores, relata um aumento de 54% nos bugs por desenvolvedor e 31% a mais de pull requests entrando sem revisão nenhuma. O árbitro humano está saindo do caminho exatamente no momento em que o protocolo se recusa a arbitrar.

Um preprint de 2026 tem a versão mais limpa disso que eu conheço, e vem com uma ressalva que eu prefiro dizer a esconder: Dillon e Varanasi testaram um agente de código contra 41 decisões de time num único repositório, e eles constroem a ferramenta de contexto que estavam testando. Deixe o número de manchete de lado e leia uma linha da tabela deles. O repositório tinha duas funções de auditoria, e uma regra de SOC-2 tornava exatamente uma delas obrigatória nas exportações. A função estava ali, no código. A regra não estava escrita em nenhum lugar que o agente alcançasse. Quando mandaram garantir que a ação fosse registrada, o agente foi procurar, achou uma função de auditoria e usou a errada, uma distinção que, nas palavras dos autores, exige saber por que a certa existe. Ele conseguia ler as duas funções. O que ele não conseguia ler era qual delas o time tinha escolhido, e ler o código não teria contado isso a ele, porque a resposta nunca esteve no código. A conclusão dos próprios autores é a forma honesta disso: recuperação torna a conformidade possível, e é o fluxo estruturado que a torna confiável.

Mapeie todo alias aceito para uma entidade governada antes que um agente possa filtrar por ele

Eric Evans escreveu o padrão para isso, e a maioria dos times lembra só de metade. A metade famosa é a linguagem ubíqua: no Domain-Driven Design Reference (2015) ele pede que o time exercite essa linguagem sem trégua em toda a comunicação e no código, e que use a mesma linguagem em diagramas, textos e, principalmente, na fala, dentro de um contexto delimitado. A metade que os times esquecem é o que ele pede nas fronteiras. Onde modelos realmente diferentes se encontram, o Context Map dele torna explícita a tradução nos pontos de contato, "outlining explicit translation for any communication". O marketplace não tinha nenhuma das duas proteções nesse fluxo, então offer entrou no contrato executável de trips sem nada de pé na fronteira.

Marketing não deveria ter que escrever trips. É esse o ponto que se perde quando alguém ouve isso e parte para um projeto de glossário. Produto deve continuar descrevendo uma offer, marketing deve continuar falando a língua do cliente, e engenharia deve continuar com um contrato estável. O que precisa existir é um registro, legível por máquina, que diga que essas coisas são a mesma entidade, que trips é a que o banco vai atender, e que as outras nunca podem chegar perto de uma consulta. Esse registro pertence a uma camada de contexto governada entre os sistemas de trabalho e os agentes, que é o que a LoomSignal é, self-hosted, para times cujos dados internos não vão para um fornecedor na nuvem.

Aí o teste que teria pegado isso fica trivial de escrever: um usuário com trips agendados nunca pode receber uma coleção vazia, seja qual for a palavra que o artefato chamador usou.

O marketplace achou o filtro e entregou a correção em três horas. É essa a parte à qual eu fico voltando. Quando alguém soube onde olhar, uma plataforma grande, com muitas funcionalidades, levou uma tarde para reproduzir e consertar um defeito de uma palavra. As três horas nunca foram o custo. O custo foi tudo que veio antes delas, com o código rodando exatamente como escrito, o monitoramento verde, a revisão aprovada, e o único sistema da empresa que sabia que algo estava errado era uma fila de gente digitando que não achava suas caronas.

Vá abrir o tipo Resource na sua própria stack. Nove campos. Nenhum deles é o que você precisava.