MCP без путаницы: как разложить Tools, Resources и Prompts по полочкам

Что нового

Model Context Protocol (MCP) — это не ещё один «слой магии» вокруг ИИ, а чёткий способ разложить ИИ‑систему на три типа компонентов:

• MCP Tools — действия: что ИИ может делать во внешнем мире.
• MCP Resources — данные: что ИИ может читать.
• MCP Prompts — инструкции: как ИИ должен думать и отвечать.

Новое здесь не в скорости или ценах, а в архитектуре. MCP предлагает стандартный, формализованный способ описывать:

• какие функции ИИ может вызывать (Tools),
• какие источники данных ему доступны (Resources),
• какие промпты он использует как готовые «шаблоны мышления» (Prompts).

Главное изменение для разработчика: вместо одного гигантского «суперпомпта» и случайных API‑вызовов вы получаете три явных слоя, каждый со своей ролью. Это снижает количество багов, упрощает масштабирование и делает поведение ИИ предсказуемее.

Как это работает

MCP описывает интерфейсы между моделью и внешним миром.

MCP Tools: действия

Что это: функции или сервисы, которые модель может вызывать, чтобы сделать что‑то вне себя.

Примеры:

• получить данные пользователя из базы;
• создать или обновить тикет в системе поддержки;
• отправить письмо или пуш‑уведомление;
• вызвать платёжный шлюз;
• запустить бизнес‑процесс в корпоративной системе.

Технически это обычные API или процедуры, но MCP описывает их так, чтобы ИИ мог сам решать, когда и как их вызывать. Инструмент:

• принимает параметры,
• выполняет действие во внешней системе,
• возвращает результат (успех, ошибка, данные).

MCP Resources: данные

Что это: источники информации, которые модель может читать, но не менять напрямую.

Примеры:

• таблица с данными клиентов;
• база знаний и документация;
• логи активности пользователей;
• конфигурационные файлы;
• корпоративные регламенты и политики.

С точки зрения протокола это «читалки»: вы описываете, где лежат данные и как к ним обратиться. Модель запрашивает ресурс, получает содержимое и использует его как контекст для ответа или решения.

MCP Prompts: инструкции

Что это: структурированные шаблоны, которые задают стиль, логику и формат ответа модели.

Примеры:

• «Суммируй отзывы клиентов по пунктам»;
• «Ответь пользователю в вежливом тоне и предложи два варианта решения»;
• «Проанализируй данные и сделай выводы»;
• «Переведи текст на другой язык»;
• «Сгенерируй код по описанию требований».

Промпт в MCP — это не просто строка текста. Это может быть отдельный компонент с параметрами, который вы многократно переиспользуете в разных сценариях.

Как всё связывается

Типичный поток работы в ИИ‑приложении с MCP:

1. Пользователь отправляет запрос (например, «поменяйте адрес доставки»).
2. Срабатывает нужный Prompt, который объясняет модели, как себя вести (вежливо, структурированно, с проверкой данных).
3. Модель запрашивает нужные Resources: историю заказов, профиль пользователя, прошлые тикеты.
4. Если нужно действие, модель вызывает Tool: обновляет адрес в базе, создаёт запись в CRM, отправляет письмо.
5. Модель собирает всё вместе и формирует финальный ответ пользователю.

Что это значит для вас

Когда MCP реально помогает

MCP имеет смысл, если вы строите что‑то сложнее простого чата с GPT‑4o:

• Корпоративные ассистенты и копилоты.

  • ИИ читает внутренние документы (Resources),
  • действует в боевых системах — CRM, тикетинг, ERP (Tools),
  • общается с сотрудниками по заданным сценариям (Prompts).

• Системы поддержки клиентов.

  • Prompts задают тон и формат поддержки.
  • Resources дают историю обращений и базу знаний.
  • Tools меняют статусы тикетов, создают заявки, шлют уведомления.

• Автоматизация бизнес‑процессов.

  • ИИ не просто отвечает текстом, а запускает реальные процессы: платежи, согласования, обновление заказов.

• Многокомпонентные ИИ‑агенты.

  • Один агент специализируется на аналитике, другой — на действиях в системе.
  • MCP позволяет явно разделить, кто читает данные, кто действует, а кто управляет логикой.

Если вы сейчас всё решаете одним гигантским промптом и ручной обвязкой вокруг API, MCP помогает:

• не смешивать бизнес‑логику и промптинг,
• переиспользовать одни и те же Tools и Resources в разных сценариях,
• проще тестировать: отдельно проверяете инструменты, ресурсы и промпты.

Где MCP избыточен

MCP даёт выигрыш не всегда. Можно не заморачиваться, если:

• У вас маленький прототип без доступа к внешним системам.
• Вы делаете один статичный сценарий: «вставь текст — получи текст» (перевод, резюме, простая генерация).
• Модель не должна ничего менять во внешнем мире и достаточно одного‑двух простых промптов.

В этих случаях MCP добавит архитектуры, но не даст ощутимой пользы.

Практические советы по применению

• Используйте Tools, когда:

  • нужно изменить состояние системы: создать/обновить запись, отправить сообщение, вызвать внешний сервис;
  • требуется транзакционная логика: платёж, бронирование, изменение прав доступа.

• Используйте Resources, когда:

  • модели нужно больше контекста для решения;
  • вы хотите подключить базы знаний, логи, справочники;
  • важно, чтобы ИИ ничего не менял в этих данных напрямую.

• Используйте Prompts, когда:

  • нужно жёстко задать стиль и формат ответа;
  • вы строите повторяемые сценарии: «ответ поддержки», «аналитический отчёт», «генерация кода»;
  • хотите, чтобы разные команды могли переиспользовать одни и те же шаблоны.

Ограничения и подводные камни

• Нельзя подменять одно другим.

  • Если вам нужно только прочитать данные, не делайте это через Tool — используйте Resource.
  • Не пытайтесь «зашить» всю бизнес‑логику в один Prompt.

• Нужна дисциплина в архитектуре.

  • Придётся заранее решить, что считается действием, что — данными, а что — инструкцией.

• Продукты на MCP могут быть недоступны в России.

  • MCP — это протокол, а не конкретный сервис, но многие реализации завязаны на экосистему Microsoft и западные ИИ‑модели.
  • Для части сервисов потребуется VPN или корпоративная инфраструктура за границей.

Место на рынке

MCP — это архитектурный подход и протокол, а не конкретная модель вроде GPT‑4o или Claude 3.5. Его корректно сравнивать не с ИИ‑моделями, а с подходами к интеграции ИИ в приложения.

Если смотреть на текущий ландшафт:

• Без MCP:

  • разработчики часто пишут монолитные промпты,
  • вызывают API напрямую из кода,
  • смешивают доступ к данным, действия и инструкции в одной функции.

• С MCP:

  • появляется явное разделение ответственности: Tools / Resources / Prompts;
  • проще переносить приложение между моделями (вы меняете модель, а не всю архитектуру);
  • легче подключать новые внешние сервисы как отдельные Tools и Resources.

Конкретных цифр по скорости или стоимости MCP по сравнению с другими подходами нет: протокол сам по себе не ускоряет модель и не удешевляет запросы. Он влияет на архитектуру и удобство разработки.

Если вы уже используете экосистему Microsoft и строите ассистентов поверх мощных моделей вроде GPT‑4o, MCP логично рассматривать как стандартный каркас для таких приложений.

Лучшие практики

Что делать

• Чётко описывать роли компонентов до начала разработки.

  • Сначала решите: какие действия нужны (Tools), какие данные читать (Resources), какие сценарии общения (Prompts).

• Использовать Tools только для действий, которые меняют состояние.

  • Обновление базы, запуск процесса, отправка сообщений.

• Resources — только для чтения.

  • Не превращайте их в скрытые «инструменты», которые что‑то меняют.

• Писать промпты так же аккуратно, как код.

  • Конкретные требования к тону, формату, шагам рассуждения;
  • минимизировать двусмысленность.

• Тестировать всё по отдельности.

  • Tools: корректность параметров и побочных эффектов;
  • Resources: полнота и актуальность данных;
  • Prompts: стабильность и предсказуемость ответов.

• Держать архитектуру модульной.

  • Новый бизнес‑процесс = комбинация уже существующих Tools, Resources и Prompts, а не переписывание всего с нуля.

Чего избегать

• Использовать Tool там, где нужен простой запрос к данным.
• Давать модели возможность «редактировать» Resources.
• Писать расплывчатые Prompts без чётких инструкций.
• Смешивать в одном компоненте и действия, и данные, и инструкции.

Итог

MCP предлагает разработчикам простой принцип: разделяйте что ИИ может делать (Tools), что он может читать (Resources) и как он должен думать и отвечать (Prompts).

Если вы строите реальные продукты — чат‑боты, копилоты, ИИ‑агентов — это снижает хаос в коде, упрощает поддержку и даёт больше контроля над поведением системы. Для маленьких прототипов MCP может быть избыточен, но на масштабе такая архитектура быстро окупается.

---

Читайте также

• Anthropic запустила Claude Design: быстрые прототипы и презентации без дизайнера
• Azure SRE Agent научился сам разбирать Terraform-drift и не ломать прод
• Microsoft Agent Framework и Foundry Toolkit теперь доступны всем: как запускать своих ИИ-агентов в Python и .NET