Como expor contexto governado via MCP: guia técnico

Se você chegou até aqui, provavelmente já decidiu usar MCP para conectar agentes de IA às fontes internas da empresa. A pergunta que sobra já passou de “o que é o protocolo” para implementação: como expor contexto via MCP sem herdar os problemas que qualquer arquiteto já viu em produção, acesso amplo demais herdado de um token, resposta sem fonte confiável por trás, e nenhuma forma de provar por que o agente respondeu aquilo. Este guia parte da decisão já tomada e vai direto às escolhas técnicas que separam um servidor MCP que funciona bem numa demonstração de um que passa pela revisão de segurança e jurídico antes de ir para produção.

O protocolo em si resolve transporte. Desde dezembro de 2025, o MCP integra a Agentic AI Foundation, sob a Linux Foundation, com Anthropic, Block e OpenAI como fundadores e apoio de Google, Microsoft, AWS, Cloudflare e Bloomberg, e virou o jeito padrão de um agente descobrir e consumir ferramentas e fontes externas sem uma integração ponto a ponto para cada runtime. Isso já está coberto em outro texto, sobre MCP corporativo e segurança, e na comparação entre MCP, function calling e RAG. O que falta na maioria dos guias por aí é o degrau abaixo: as decisões de arquitetura que o protocolo não toma por você.

Resource ou tool: qual interface expor primeiro

A primeira decisão de implementação é simples de enunciar e fácil de errar na prática: o que você está expondo é uma leitura de conhecimento ou uma ação com efeito real? Um MCP server oferece dois tipos de interface, resources e tools, e cada um pede um nível de controle diferente.

Um resource é uma leitura. Tem uma URI, pode ser versionado, e não altera nada em nenhum sistema quando é consumido. Expor uma coleção aprovada de políticas internas, um conjunto de FAQs curadas ou um trecho de manual técnico como resource é o caminho certo: o pior cenário é o agente ler algo que não devia, não é o agente executar algo que não devia.

Uma tool é diferente. Ela aciona uma função, e essa função pode escrever num sistema, disparar um envio ou criar um registro que passa a existir fora do MCP server. Uma tool exige um fluxo de aprovação mais rígido do que um resource, porque o custo de errar é maior e, muitas vezes, irreversível.

O erro mais comum em implementações iniciais é preguiça de modelagem: em vez de expor coleções específicas como resources, alguém cria uma única tool genérica de “consulta ao banco” ou “busca em documentos”, que aceita um parâmetro livre e devolve o que encontrar. Isso parece prático, mas reproduz exatamente o problema que a governança deveria resolver, porque transforma uma decisão de escopo em um parâmetro de texto que o próprio modelo escreve.

Na prática, uma implementação madura nomeia cada resource pela coleção que ele representa, algo como o URI da coleção de políticas de RH aprovadas, separado do URI da coleção de contratos jurídicos. Cada coleção tem seu próprio ciclo de aprovação e seu próprio owner, então o servidor nunca precisa decidir em tempo real “essa pergunta é sobre RH ou sobre jurídico”: a separação já está no desenho das interfaces, e o agente só enxerga os resources para os quais o token tem permissão.

Onde amarrar o escopo: no token, não no prompt

A segunda decisão é sobre onde vive a trava de acesso, e aqui mora o erro mais caro. Muita implementação tenta resolver escopo escrevendo instrução no prompt de sistema: “responda apenas sobre o produto X” ou “não acesse dados do cliente Y”. Isso é uma sugestão para o modelo, não uma trava para o sistema.

Um prompt de sistema pode ser sobrescrito por conteúdo malicioso vindo de um documento, de outra ferramenta ou de um agente terceiro que o seu agente consulta na cadeia. O modelo não tem como diferenciar, com confiabilidade, uma instrução legítima de uma instrução embutida no meio de um texto que ele está processando como dado. Se a única barreira entre um agente e uma fonte sensível é o que está escrito no prompt, essa barreira não existe de fato.

O escopo precisa ser resolvido no servidor, a partir da identidade que fez a chamada, antes de qualquer conteúdo sair. Na prática, isso significa que cada token carrega, do lado do servidor, a lista de coleções e workspaces que aquele agente está autorizado a consumir, e o MCP server resolve essa lista a cada chamada, não uma vez no início da sessão. Um agente de cobrança e um agente de suporte técnico podem consumir o mesmo servidor MCP e a mesma infraestrutura de contexto, desde que cada token resolva para um recorte diferente do que existe. É o mesmo princípio de controlar fontes, permissões e escopo em agentes de IA, aplicado especificamente ao ponto onde o protocolo entrega o conteúdo.

Fonte obrigatória e recusa honesta, sem gambiarra

A terceira decisão é o que o servidor faz quando não encontra nada para devolver. Aqui a tentação de implementação rápida é perigosa: devolver uma resposta vazia com status de sucesso, e deixar o modelo lidar com isso. Na prática, o modelo trata silêncio como espaço livre e completa com conhecimento próprio, produzindo uma resposta que parece fundamentada em contexto real mas não está.

O jeito certo é o servidor devolver uma recusa estruturada, e essa recusa precisa carregar o motivo, não só o fato de ter falhado. Existem pelo menos três motivos distintos, e tratá-los como um único “nada encontrado” esconde informação importante: não existe fonte sobre o assunto, a fonte existe mas ainda está em rascunho e não passou pela aprovação, ou a fonte existe e está aprovada mas fora do escopo daquele token específico. Essa distinção decide se o problema é de conteúdo, de curadoria ou de permissão, e cada um tem um dono diferente para resolver.

Implementar isso não exige nada exótico: o servidor consulta o registro de fontes aprovadas antes de montar a resposta, e quando a consulta não retorna nada dentro do escopo autorizado, ele devolve um objeto de recusa com o motivo, em vez de um payload de sucesso vazio.

O que registrar em cada chamada

A quarta decisão é o que fica registrado. Um MCP server que serve contexto governado precisa logar, por chamada, o suficiente para reconstruir depois por que um agente respondeu o que respondeu. Isso é mais estreito que logar a conversa inteira do agente: cobre o que aconteceu especificamente na interface entre o agente e o contexto.

O registro mínimo cobre um identificador da interação, a identidade que fez a chamada, o escopo resolvido para aquele token naquele momento, a coleção e a versão do conteúdo efetivamente devolvido, se houve recusa e qual motivo, e o timestamp. Esse conjunto é o que já descrevemos como a camada de evidência ao falar de inventário de agentes de IA: sem ela, o catálogo de agentes sabe o que existe, mas não consegue provar o que aconteceu. Com ela, uma pergunta de auditor como “por que o agente disse isso em março” tem resposta sem depender da memória de ninguém.

Esse log não pode ficar só na aplicação. Ele precisa alimentar um repositório central de evidências, consultável por segurança, jurídico e auditoria sem depender de acesso direto ao banco do agente. É a mesma lógica que sustenta a rotina de ContextOps: o log por chamada não é um artefato de depuração, é o insumo que mantém a operação auditável mês a mês, muito depois de o servidor ter sido colocado no ar.

Versionamento: servir contexto sem quebrar o agente

A quinta decisão aparece quando o conteúdo muda, o que é constante numa base viva. Uma política é revisada, um contrato é substituído, um manual ganha uma versão nova. O servidor precisa lidar com isso sem dois efeitos colaterais indesejados: quebrar respostas em produção com uma mudança abrupta, e reescrever silenciosamente o que uma auditoria retroativa vai encontrar.

A solução é simples de descrever e fácil de esquecer de implementar: cada chamada registra a versão da fonte que foi de fato usada naquele momento, não apenas o nome da coleção. Chamadas novas recebem a versão atual aprovada. O log de uma interação já ocorrida continua apontando para a versão que existia quando ela aconteceu, mesmo que a fonte tenha sido atualizada depois. Sem esse cuidado, uma correção de conteúdo feita hoje pode, na prática, alterar retroativamente a explicação de uma resposta dada há três meses, o que destrói a confiabilidade do próprio log.

Testar antes de produção: o conjunto que importa

A última decisão é sobre teste, e é a mais negligenciada. Testar um servidor MCP governado não é o mesmo que testar uma função de software convencional, porque o que está em jogo não é só “a função retorna o valor certo”, é “o servidor toma a decisão certa de escopo e recusa diante de um agente que decide em tempo real o que perguntar”.

Um conjunto de teste útil cobre três situações. A primeira: perguntas em que existe fonte aprovada dentro do escopo, e o servidor deve devolver o conteúdo certo com a versão certa. A segunda: perguntas em que não existe fonte, ou existe mas fora do escopo daquele token, e o servidor deve recusar com o motivo correto, não com silêncio. A terceira, e a mais fácil de esquecer: casos em que o conteúdo de uma fonte legítima contém algo que parece uma instrução, testando se o servidor e o agente tratam aquele texto como dado a ser citado, e não como comando a ser obedecido.

Rodar esse conjunto antes de liberar o primeiro escopo de produção custa pouco e evita o cenário mais caro de todos: descobrir, já com o agente em produção, que ele responde com confiança sobre algo que nunca deveria ter alcançado, ou que trata rascunho como se fosse material aprovado.

Esse conjunto de teste também não é estático. Cada incidente real, cada recusa que saiu errada, cada tentativa de injeção identificada em produção vira um novo caso permanente no conjunto, o que faz o teste crescer junto com a operação em vez de ficar congelado na versão inicial do servidor.

Checklist antes de expor o primeiro MCP server governado

Antes de liberar escopo real para um agente, vale confirmar cinco pontos. O servidor separa claramente o que é resource do que é tool, sem uma consulta genérica fazendo o papel dos dois. O escopo é resolvido a partir do token no servidor, e não depende de instrução no prompt. Toda ausência de contexto vira uma recusa com motivo explícito, nunca uma resposta vazia com status de sucesso. Cada chamada grava identidade, escopo, coleção, versão e resultado, formando a base do log de evidência. E existe um conjunto de perguntas de teste, incluindo casos de recusa esperada e casos de tentativa de injeção via conteúdo, rodado antes de qualquer aprovação de produção.

Nenhum desses cinco pontos está na especificação do protocolo. Todos vivem na camada de contexto governado que fica atrás do servidor, a mesma que sustenta a discussão mais ampla sobre MCP corporativo e sobre governança de agentes de IA. É essa camada, não o protocolo, que decide se segurança e jurídico assinam a liberação para produção.

Próximo passo: leve isso ao diagnóstico

Se você está prestes a expor o primeiro MCP server da empresa, vale confirmar essas cinco decisões antes de liberar qualquer token real. Um diagnóstico mapeia as fontes que hoje seriam expostas, o escopo que cada agente precisaria receber e as lacunas de aprovação, versionamento e log que ainda faltam fechar antes de produção.

Faça o diagnóstico gratuito e descubra o que falta para expor contexto governado com segurança pelo seu próprio MCP server.

Marcas citadas pertencem a seus respectivos proprietários. Contextfy é uma camada independente de contexto governado e não declara parceria oficial, certificação ou integração nativa, salvo quando explicitamente informado.