Руководство по дизайну Resources

Resource в понимании MCP — не сырой дамп базы данных. Это читаемый контекст данных — структурированный, отфильтрованный и адаптированный под агента, которому он сейчас нужен. В то время как Tool выполняет действие, Resource предоставляет контекст, на основе которого можно принимать осмысленные решения.

Resources с kind="resources" описывают именно это: какие контекстные объекты предоставляет система, как они устроены и какой уровень защиты они несут.

Effective AI Access

Доступ к данным для ИИ нельзя свести к одному вопросу. Правильная модель — аддитивная:

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

Каждый из этих факторов может ограничить доступ — даже если все предыдущие принципиально его разрешали бы.

Это слишком грубо. Права пользователя и права ИИ — разные измерения. Пользователь действует осознанно, в контексте, с ответственностью. Агент действует автоматически, без суждения о чувствительности, в рамках скоупа, который должен быть чётко ограничен.

Пример: данные о зарплатах

Руководитель в принципе имеет доступ к данным о зарплатах — это его право пользователя. Агент Sales Assistant, работающий в контексте этого пользователя, всё равно не должен получать эти данные в свой контекст.

Почему: агент имеет чётко определённую цель (ведение контактов, follow-up, проектная работа). Данные о зарплатах находятся за пределами этой цели. Agent Permission и Purpose исключают доступ — независимо от того, что сам пользователь вправе видеть.

User Permission:     ✓ (руководитель вправе видеть данные о зарплатах)
Agent Permission:    ✗ (Sales Assistant не имеет скоупа salary:read)
Resource Sensitivity: sensitive
Purpose:             ведение контактов / проектная работа
= Effective AI Access: отказано

Redaction и фильтрация контекста

Системы MCP-first должны целенаправленно подготавливать данные для AI-агентов, а не просто передавать их. Это означает: не каждое поле, существующее внутри системы, принадлежит контексту агента.

Полные внутренние данные

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

Эта версия содержит персональные данные, банковские данные, личные заметки и полную историю переписки. Она предназначена для внутренних представлений и пользователей с соответствующими правами — не для агента, которому нужно предложить follow-up.

Агентно-ориентированная версия

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

Агент получает только то, что нужно ему для задачи: имя, контекст, последний статус взаимодействия и рекомендацию к действию. Банковские данные, оценка риска и сырые данные электронной почты отфильтрованы. Это Redaction by Design.

Redaction — не запоздалая мера безопасности. Это часть дизайна Resource: каждый Resource имеет агентно-ориентированный вариант, содержащий только релевантные для данной цели поля.

Resources с контекстом

Хорошо спроектированные Resources предоставляют не просто сырые данные, а встроенный контекст: временные шкалы, сводки, рекомендации к действию. Именно эти Resources делают агентов действительно полезными.

Эти Resources выходят за рамки contacts.get или projects.list. Они предоставляют подготовленный контекст, позволяющий агенту рекомендовать осмысленное следующее действие — без необходимости самому делать сырые запросы к базе данных или анализировать чувствительные поля.