Guia de Design de Resources

Uma Resource no sentido do MCP não é um dump bruto de banco de dados. É contexto de dados legível, estruturado, filtrado e adaptado ao agente que precisa dele naquele momento. Enquanto uma tool executa uma ação, uma resource fornece o contexto sobre o qual decisões sensatas são possíveis.

Resources com kind="resources" descrevem exatamente isso: quais objetos de contexto um sistema disponibiliza, como são estruturados e qual nível de proteção carregam.

Effective AI Access

O acesso a dados para IA não pode ser reduzido a uma única pergunta. O modelo correto é aditivo:

User Permission
+ Agent Permission
+ Client Trust Level
+ Resource Sensitivity
+ Purpose
+ Context
+ Confirmation State
= Effective AI Access

Cada um desses fatores pode restringir o acesso, mesmo que todos os anteriores o permitissem em princípio.

Isso é grosseiro demais. Permissões de usuário e permissões de IA são dimensões diferentes. Um usuário age conscientemente, com contexto e responsabilidade. Um agente age automaticamente, sem julgamento sobre sensibilidade, dentro de um escopo que deve ser claramente limitado.

Exemplo: Dados salariais

O diretor tem acesso a dados salariais em princípio, é seu direito de usuário. Um Assistente de Vendas Agent rodando no contexto desse usuário não deve, mesmo assim, receber esses dados em seu contexto.

Por quê: o agente tem um propósito claramente definido (gestão de contatos, follow-ups, trabalho em projetos). Dados salariais estão fora desse propósito. A Agent Permission e o Purpose excluem o acesso, independentemente do que o próprio usuário pode ver.

User Permission:     ✓ (diretor pode ver dados salariais)
Agent Permission:    ✗ (Assistente de Vendas não tem scope salary:read)
Resource Sensitivity: sensitive
Purpose:             Gestão de contatos / Trabalho em projetos
= Effective AI Access: negado

Redaction & Context Filtering

Sistemas MCP-first devem preparar dados especificamente para AI Agents, não simplesmente repassá-los. Isso significa: nem todo campo que existe internamente pertence ao contexto do agente.

Dados internos completos

{
  "name": "Max Müller",
  "email": "[email protected]",
  "phone": "+49...",
  "privateNotes": "...",
  "bankAccount": "...",
  "internalRiskScore": "...",
  "lastEmails": ["..."]
}

Esta versão contém dados pessoais, dados bancários, notas privadas e o histórico completo de e-mails. Destina-se a visualizações internas e usuários com as permissões correspondentes, não a um agente que deve sugerir um follow-up.

Versão preparada para agentes

{
  "name": "Max Müller",
  "company": "Müller GmbH",
  "role": "Investment Manager",
  "lastInteractionSummary": "Opened exposé but did not reply.",
  "recommendedNextAction": "Follow up by email."
}

O agente recebe apenas o que precisa para sua tarefa: nome, contexto, último status de interação e uma recomendação de ação. Dados bancários, score de risco e dados brutos de e-mail são filtrados. Isso é Redaction by Design.

A redaction não é uma medida de segurança posterior. É parte do design da resource: cada resource tem uma variante preparada para agentes que contém apenas os campos relevantes para o propósito em questão.

Resources com contexto

Resources bem projetadas fornecem não apenas dados brutos, mas contexto incorporado: cronogramas, resumos, recomendações de ação. Essas são as resources que tornam os agentes verdadeiramente úteis.

Essas resources vão além de contacts.get ou projects.list. Elas fornecem contexto processado que permite a um agente recomendar uma próxima ação sensata, sem que ele precise fazer consultas brutas ao banco de dados ou avaliar campos sensíveis.