Что такое Model Context Protocol (MCP) и зачем он нужен?

MCP (Model Context Protocol) — это открытый стандарт и протокол для подключения ИИ-приложений к внешним системам. С помощью MCP ИИ-приложения, такие как Claude или ChatGPT, могут подключаться к источникам данных (например, локальным файлам, базам данных), инструментам (например, поисковым системам, калькуляторам) и рабочим процессам (например, специализированным промптам), что позволяет им получать доступ к ключевой информации и выполнять задачи. MCP можно сравнить с портом USB-C для ИИ-приложений: так же, как USB-C обеспечивает стандартный способ подключения электронных устройств, MCP предоставляет стандартный способ подключения ИИ-приложений к внешним системам.

Model Context Protocol (MCP) был разработан компанией Anthropic для стандартизации взаимодействия между большими языковыми моделями (LLM) и внешними системами. MCP представляет собой открытый стандарт, который позволяет искусственному интеллекту взаимодействовать с различными источниками данных и инструментами через унифицированный интерфейс.

Рис. 1. Для чего используется MCP

Простыми словами зачем нужен этот MCP и для чего его придумали?

Вы пишете ИИ приожение. Приложение это какой-то программный процесс и он должен получать какие-то данные, в том числе из внешних источников.

Например вы пишете ИИ чат-бота поддержки. Туда пришел пользователь и начал что-то спрашивать про гарантию на товар в его последнем заказе. И чтобы бот смог что-то отвечать пользователю, ему надо:

• сходить в CRM систему, чтобы найт информацию о товаре и контакты клиента
• сходить в базу данных, чтобы получить информацию о товаре и условиях гарантии
• сходить во внутреннюю wiki чтобы найти информацию из регламента о гарантиях и врзвратах

Далее допустим бот смог порешать вопрос с клиентом и по итогу общения надо оформить задачу на оформление возврата, например получает штрих код или код возврата. Или бот не смог решить вопрос и надо создать завку в службу поддержки на живого человека.

Получается еще два варианта запроса

• сходить в сервис оформления возвратов и получить код
• сходить в серисв-деск и оформить заявку в поддержку.

А могут понадобиться и еще сервисы, например:

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

И получается что наше ИИ приложение должно ходить в несколько сервисов.

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

А теперь начнем ухудшать условия.

Вам надо добавить еще несколько источников данных

• Вы лезете руками в код ИИ приложения и дописываете в нем коннекторы и обработку.
• А вот если бы был MCP писать код внутри ИИ приложения не понадобится - достаточно будет просто поправить промпты-конфиги и ИИ приложение начнет работать с источником (выше скорость разработки).

Вы поставили ИИ приложение в контур клиента

• Вам надо что-то поправить в коннекторе к источнику - значит надо идти в конутр клиента и там что-то обновлять...
• А если вы поставили 10-ти разным клиентам и у них должны быть разные источники. Вы начинаете тонуть в деталях реализации - разные инстансы у разных клиентов и все надо поддерживать в коде руками.
• А с MCP ваше ИИ приложение у всех клиентов идентично и вы не правите там ничего. Вы правите MCP серверы на стороне источников данных

Вы хотите добавлять в ваше ИИ приложение новые источники в открытом формате

• Вы хотите дать вендорам возможность подключать свои источники данных к вашему приложению. Какую спецификацию им дать? Приятно иметь единый стандарт, который позволит подключать источники данных только правя конфиги ИИ приложения.
• MCP позволяет дать такой стандарт: источник данных оборачиваем в MCP сервер. ИИ приложение - это MCP клиент, и вы в конфигах указываете еще один MCP сервер с источником данных. И приложение начнет работать с данными.

Вы не владелец ИИ агента

• У вас есть данные и вы хотите пользоваться ИИ приложением какого-то вендора. Как вам подключить свои данных к чужому ИИ приложению и как дать ИИ приложению возможность что-то делать в ваших информационных системах.
• MCP как раз позволяет решить эту задачу. Вы оборачиваете свои источники данных и доступ к своим информационным системам в MCP серверы (один или несколько) и в чужом ИИ приожении вы просто в конфиге указываете доступ к вашим серверам и оно начинает работать - смотреть ваши данные, создавать вам документы и т.д., в зависимости от возможностей ИИ приложения и ваших сервисов обернутых в MCP серверы.

Вы делаете широкую дистрибуцию вашего ИИ приложения (например плагин для браузера, плагин для IDE)

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

Те MCP позволяет ИИ приложениям рабоать с любым количеством сервисов и источников данных если их обернуть в MCP серверы, а информацию об этих серверах добавить в конфиги ИИ приложения, поддерживающего стандарт MCP клиента.

Остается вопрос - а как завернуть любой источник данных, сервис или инструмент в MCP сервер. А вот это просто. Не сложнее чем сделать REST API. Это просто еще один протокод API с готовыми реализациями на Python, Javascript и ряде других языков программирования.

Итого, ключевой принцип MCP - отделение логики ИИ-приложения от логики интеграции с источниками данных. Это фундаментальная архитектурная особенность, которая сильно упрощает архитектуру и поддержку самого ИИ приложения. И сильно упрощает архитектуру и поддержку самих интеграций с источниками данных изолируя их в том числе между собой.

с MCP не нужно менять код ИИ-приложения при добавлении источников. Но важно понимать, что это не просто "меньше кода", а фундаментальное изменение архитектуры:

• Традиционный подход: ИИ-приложение → (Кастомные коннекторы) → Внешние системы
• MCP подход: ИИ-приложение → MCP Client → (Стандартизированный протокол) → MCP Servers → Внешние системы

Это разделение создает четкую границу ответственности:

• ИИ-приложение отвечает за логику обработки запросов
• MCP-серверы отвечают за безопасный доступ к данным
• MCP Client отвечает за маршрутизацию запросов

Как обернуть свой источник данных или свой сервис в MCP сервер - смотрите в официальной документации https://modelcontextprotocol.io/docs/develop/build-server Есть готовые SDK для python, javascript, java, kotlin, C#.

Что позволяет делать MCP?

• Агенты могут получать доступ к вашему Google Календарю и Notion, выступая в роли более персонализированного ИИ-ассистента.
• Claude Code может создавать целое веб-приложение на основе дизайна из Figma.
• Корпоративные чат-боты могут подключаться к нескольким базам данных по всей организации, позволяя пользователям анализировать данные с помощью чата.
• ИИ-модели могут создавать 3D-дизайны в Blender и печатать их на 3D-принтере.

Почему MCP важен?

В зависимости от вашей роли в экосистеме MCP может принести различные преимущества:

• Разработчикам: MCP сокращает время и сложность разработки или интеграции с ИИ-приложениями и агентами.
• ИИ-приложениям и агентам: MCP предоставляет доступ к экосистеме источников данных, инструментов и приложений, что расширяет их возможности и улучшает опыт конечных пользователей.
• Конечным пользователям: MCP позволяет создавать более функциональные ИИ-приложения и агенты, которые могут получать доступ к вашим данным и выполнять действия от вашего имени при необходимости.

MCP функционирует как посредник, который позволяет LLM взаимодействовать с внешними инструментами через структурированные API-вызовы. Вместо того чтобы каждому разработчику создавать собственные методы интеграции, MCP предоставляет универсальный протокол, который упрощает подключение ИИ-приложений к внешним системам.

Протокол позволяет ИИ-агентам не только отвечать на запросы пользователей, но и выполнять реальные действия во внешних системах, что значительно расширяет их функциональные возможности.

Зачем был придуман MCP?

1. Унификация взаимодействия: MCP разработан для унификации взаимодействия между различными моделями искусственного интеллекта и внешними системами, что решает проблему фрагментации в экосистеме ИИ.

2. Снижение избыточности: Использование MCP может сократить повторяющиеся разработки и повысить качество инструментов ИИ за счет стандартизации.

3. Расширение возможностей ИИ: Протокол позволяет моделям получать доступ к актуальной информации из внешних источников и выполнять действия в реальном мире, а не только генерировать текст на основе внутренних знаний.

4. Упрощение интеграции: MCP упрощает процесс подключения различных данных и инструментов к ИИ-моделям, что делает разработку ИИ-приложений более доступной.

Основное преимущество MCP заключается в его открытости и стандартизации. В отличие от проприетарных решений, MCP предоставляет универсальный протокол, который может использоваться разными разработчиками и компаниями, создавая более совместимую экосистему ИИ-инструментов. Это позволяет избежать "vendor lock-in" и дает разработчикам больше гибкости при создании ИИ-приложений.

Model Context Protocol представляет собой важный шаг в развитии экосистемы искусственного интеллекта, предоставляя стандартизированный способ взаимодействия ИИ с внешним миром. С внедрением MCP разработчики могут создавать более мощные и функциональные ИИ-приложения с меньшими усилиями, а пользователи получают доступ к ИИ, способному решать более сложные задачи через интеграцию с реальными системами и данными.

Примеры когда MCP полезен

• Запросы к базам данных и анализ данных MCP позволяет серверам предоставлять доступ к различным базам данных (SQL или NoSQL), что дает ИИ-моделям возможность выполнять сложные запросы и анализировать данные напрямую без посредников. Это особенно полезно для аналитиков, которым нужно быстро получать insights из больших объемов данных.

• Персонализированный маркетинг С помощью MCP ИИ-агенты могут создавать персонализированные коммуникации с клиентами, используя данные из CRM-систем и других источников для формирования релевантных предложений. Это значительно повышает эффективность маркетинговых кампаний за счет точного таргетирования.

• Телемедицинские консультации Приложение для телемедицины может использовать MCP для связывания симптомов пациента, медицинской истории и данных в реальном времени (например, с носимых устройств) во время консультации. Это позволяет врачам получать полную картину состояния пациента и принимать более обоснованные решения.

• Межплатформенная интеграция ИИ-моделей MCP обеспечивает бесшовную интеграцию ИИ-моделей на различных платформах (облако, edge-устройства и т.д.), что решает проблему совместимости между различными средами выполнения.

• Автоматизированные голосовые ответы клиентам Системы поддержки клиентов могут использовать MCP для отправки автоматизированных голосовых ответов с помощью интеграции с платформами вроде ElevenLabs, обеспечивая более естественное взаимодействие. Это улучшает пользовательский опыт и снижает нагрузку на живых операторов.

• Инструменты разработки и IDE MCP интегрируется в среды разработки, такие как GitHub Copilot, предоставляя разработчикам контекстно-зависимые предложения кода и документации напрямую из различных источников. Это значительно ускоряет процесс разработки и повышает качество кода.

• Управление IoT-устройствами Серверы MCP демонстрируют возможности протокола в управлении интернетом вещей, позволяя ИИ-моделям взаимодействовать с физическими устройствами через стандартизированный интерфейс. Это упрощает создание умных домов, промышленных систем автоматизации и других IoT-приложений.

• Интеграция с корпоративными системами MCP позволяет ИИ-приложениям, таким как Claude, подключаться к внешним системам, обеспечивая доступ к внутренним корпоративным данным и процессам. Это делает ИИ-ассистентов гораздо более полезными в бизнес-контексте, так как они могут работать с актуальной информацией компании.

• Многоагентные системы Платформы вроде PulseMCP предоставляют подробные примеры и инструкции по практическому применению Model Context Protocol в многоагентных системах. Это позволяет создавать сложные workflows, где несколько ИИ-агентов координируют свои действия через стандартизированный протокол для решения комплексных задач.

• Динамическая контекстная загрузка: Не просто "еще один API" Одно из главных преимуществ MCP, которое вы не упомянули - контекстно-адаптивная загрузка данных:

  В традиционных системах (включая RAG) вы обычно:

  • Либо загружаете фиксированный набор данных
  • Либо загружаете все данные и фильтруете на стороне ИИ

  С MCP сервер может динамически определять, какие именно данные нужны в текущем контексте, основываясь на:

  • Текущем запросе пользователя
  • Предыдущих сообщениях в диалоге
  • Состоянии бизнес-процесса

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

• Бот поддержки (ваш пример)
• Бот для обработки возвратов
• Бот для логистики

Без MCP каждому агенту нужно реализовывать отдельные коннекторы к одним и тем же системам.

С MCP:

• Все агенты используют один и тот же MCP Client
• Все источники данных представлены через MCP-серверы
• Агенты могут безопасно обмениваться контекстом через MCP

Например, когда бот поддержки определяет, что нужен возврат:

• Он отправляет запрос через MCP: "Создать заявку на возврат для заказа #12345"
• MCP Client маршрутизирует запрос к MCP-серверу возвратов
• Сервер возвратов создает заявку и возвращает код
• Бот поддержки получает код и сообщает клиенту

При этом ни один из агентов не знает деталей реализации других систем - только стандартизированный MCP-интерфейс.

Как MCP помогает в долгосрочной перспективе

MCP помогает при изменении существующих систем, т.к. в реальных проектах:

• CRM меняет API каждые 6 месяцев
• База данных мигрирует на новую платформу
• Внутренняя wiki переходит на новый формат

Без MCP:

• Вам нужно менять код ИИ-приложения при каждом изменении
• Возможны регрессионные ошибки
• Тестирование занимает много времени

С MCP:

• Изменения происходят только на уровне MCP-серверов
• ИИ-приложение продолжает работать без изменений
• Можно постепенно мигрировать серверы, не останавливая систему

Обзор архитектуры MCP

Область применения

Протокол Model Context Protocol включает следующие проекты:

• Спецификация MCP: спецификация MCP, описывающая требования к реализации для клиентов и серверов.
• MCP SDK: SDK для различных языков программирования, реализующие MCP.
• Инструменты разработки MCP: инструменты для разработки MCP-серверов и клиентов, включая MCP Inspector.
• Референсные реализации MCP-серверов: референсные реализации MCP-серверов.

MCP фокусируется исключительно на протоколе обмена контекстом — он не диктует, как ИИ-приложения используют языковые модели (LLM) или управляют предоставленным контекстом.

MCP следует клиент-серверной архитектуре, где хост MCP (ИИ-приложение, такое как Claude Code или Claude Desktop, любой ИИ агент на удаленном сервере или у вас на компьютере) устанавливает соединения с одним или несколькими MCP-серверами - как локальными так и удаленными. Хост MCP делает это, создавая один MCP-клиент для каждого MCP-сервера. Каждый MCP-клиент поддерживает выделенное одно-к-одному соединение с соответствующим MCP-сервером. Ключевые участники архитектуры MCP:

• MCP-хост: ИИ-приложение, координирующее и управляющее одним или несколькими MCP-клиентами.
• MCP-клиент: компонент, поддерживающий соединение с MCP-сервером и получающий контекст от MCP-сервера для использования MCP-хостом.
• MCP-сервер: программа, предоставляющая контекст MCP-клиентам - как предоставляющая информацию по запросу, так и выполняющая команды и предоставлющие отчеты о выполнении.

Пример: Visual Studio Code выступает в роли MCP-хоста. Когда Visual Studio Code устанавливает соединение с MCP-сервером, например, с Sentry MCP-сервером, среда выполнения Visual Studio Code создает объект MCP-клиента, который поддерживает соединение с Sentry MCP-сервером. Когда Visual Studio Code затем подключается к другому MCP-серверу, например, к локальному файловому серверу, среда выполнения создает дополнительный объект MCP-клиента для поддержания этого соединения, тем самым поддерживая отношение "один к одному" между MCP-клиентами и MCP-серверами.

MCP Host (ИИ-приложение)
   │
   ├── One-to-one connection
   │      MCP Client 1 ─────► MCP Server 1 (например, Sentry Server)
   │
   ├── One-to-one connection
   │      MCP Client 2 ─────► MCP Server 2 (например, Local Filesystem)
   │
   └── One-to-one connection
          MCP Client 3 ─────► MCP Server 3 (например, Remote Database)

MCP-сервером называется программа, предоставляющая контекстные данные, независимо от места её выполнения. MCP-серверы могут выполняться локально или удаленно. Например, когда Claude Desktop запускает файловый сервер, сервер выполняется локально на той же машине, так как использует транспорт STDIO. Это обычно называют "локальным" MCP-сервером. Официальный Sentry MCP-сервер работает на платформе Sentry и использует транспорт Streamable HTTP. Это обычно называют "удаленным" MCP-сервером.

MCP состоит из двух уровней:

• Уровень данных: определяет протокол на основе JSON-RPC для клиент-серверного взаимодействия, включая управление жизненным циклом и основные примитивы, такие как инструменты, ресурсы, промпты и уведомления.
• Транспортный уровень: определяет механизмы и каналы связи, обеспечивающие обмен данными между клиентами и серверами, включая установление соединения, форматирование сообщений и авторизацию, специфичные для транспорта.

Концептуально уровень данных является внутренним, а транспортный уровень — внешним.

Уровень данных

Уровень данных реализует протокол обмена на основе JSON-RPC 2.0, который определяет структуру и семантику сообщений. Этот уровень включает:

• Управление жизненным циклом: обрабатывает инициализацию соединения, согласование возможностей и завершение соединения между клиентами и серверами.
• Функции сервера: позволяет серверам предоставлять основные функции, включая инструменты для действий ИИ, ресурсы для контекстных данных и промпты для шаблонов взаимодействия с клиентом.
• Функции клиента: позволяет серверам запрашивать у клиента выборки из хост-модели LLM, получать данные от пользователя и записывать сообщения в журнал клиента.
• Утилиты: поддерживает дополнительные возможности, такие как уведомления для обновлений в реальном времени и отслеживание прогресса для долгих операций.

Транспортный уровень

Транспортный уровень управляет каналами связи и аутентификацией между клиентами и серверами. Он обрабатывает установление соединения, форматирование сообщений и безопасную связь между участниками MCP. MCP поддерживает два транспортных механизма:

• Транспорт STDIO: использует стандартные потоки ввода/вывода для прямой связи между локальными процессами на одной машине, обеспечивая оптимальную производительность без сетевых накладных расходов. Используется когда инструмент обернутый в MCP сервер находится на той же машине, что и ИИ приложение (MCP клиент).
• Транспорт Streamable HTTP: использует HTTP POST для сообщений от клиента к серверу с опциональными Server-Sent Events для потоковой передачи. Этот транспорт позволяет общаться с удаленными серверами и поддерживает стандартные методы аутентификации HTTP, включая токены, API-ключи и пользовательские заголовки. MCP рекомендует использовать OAuth для получения токенов аутентификации. Удаленный MCP сервер.

Транспортный уровень абстрагирует детали связи от протокольного уровня, позволяя использовать один и тот же формат сообщений JSON-RPC 2.0 для всех транспортных механизмов.

Существенное ограничение MCP в том, что вы можете сделать или только локальный сервер или удаленный сервер на конкретном IP. Те общение через вебсокеты, обращение с вашего сервера к конкретным тулам конечного клиента - не реализуемо через готовую версию MCP, такое придется писать самостоятельно, делая вебсокет-сервер и обрабатывая JSON-RPC сообщения.

Протокол уровня данных

MCP использует JSON-RPC 2.0 в качестве базового RPC-протокола. Клиенты и серверы отправляют запросы друг другу и отвечают соответственно. Уведомления могут использоваться, когда ответ не требуется.

Пример данных в запроса и ответа в JSON-RPC 2.0

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

Примитивы

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

• Инструменты: исполняемые функции, которые ИИ-приложения могут вызывать для выполнения действий (например, операции с файлами, вызовы API, запросы к базе данных).
• Ресурсы: источники данных, предоставляющие контекстную информацию ИИ-приложениям (например, содержимое файлов, записи базы данных, ответы API).
• Промпты: многоразовые шаблоны, помогающие структурировать взаимодействия с языковыми моделями (например, системные промпты, примеры few-shot).

У каждого типа примитивов есть связанные методы для обнаружения (*/list), получения (*/get) и, в некоторых случаях, выполнения (tools/call). MCP-клиенты будут использовать методы */list для обнаружения доступных примитивов. Например, клиент может сначала перечислить все доступные инструменты (tools/list), а затем выполнить нужный инструмент. Этот дизайн позволяет динамически обновлять списки.

В качестве конкретного примера рассмотрим MCP-сервер, предоставляющий контекст о базе данных. Он может предоставлять инструменты для запросов к базе данных, ресурс, содержащий схему базы данных, и промпт, включающий примеры few-shot для взаимодействия с инструментами. Подробнее о серверных примитивах см. в концепциях сервера в документации к MCP.

MCP также определяет примитивы, которые могут предоставлять клиенты. Эти примитивы позволяют авторам MCP-серверов создавать более богатые взаимодействия:

• Выборка: позволяет серверам запрашивать генерации языковой модели у ИИ-приложения клиента. Это полезно, когда авторы серверов хотят получить доступ к языковой модели, но хотят оставаться независимыми от модели и не включать SDK языковой модели в свой MCP-сервер. Они могут использовать метод sampling/complete, чтобы запросить генерацию языковой модели у ИИ-приложения клиента.
• Запрос данных: позволяет серверам запрашивать дополнительную информацию у пользователей. Это полезно, когда авторы серверов хотят получить больше информации от пользователя или запросить подтверждение действия. Они могут использовать метод elicitation/request, чтобы запросить дополнительную информацию от пользователя.
• Логирование: позволяет серверам отправлять сообщения журнала клиентам для отладки и мониторинга.

Подробнее о клиентских примитивах в документации в концепциях клиента.

Уведомления

Протокол поддерживает уведомления в реальном времени, позволяющие серверам информировать клиентов об изменениях без явного запроса. Например, когда доступные инструменты сервера изменяются — например, когда появляется новая функциональность, существующие инструменты изменяются или становятся временно недоступными — сервер может отправить уведомления об изменении списка инструментов, чтобы проинформировать подключенных клиентов об этих изменениях. Уведомления отправляются как сообщения JSON-RPC 2.0 (без ожидания ответа) и позволяют MCP-серверам предоставлять клиентам обновления в реальном времени.

Пример

1. Инициализация (управление жизненным циклом)

MCP начинается с управления жизненным циклом через согласование возможностей. Как описано в разделе управления жизненным циклом, клиент отправляет запрос на инициализацию, чтобы установить соединение и согласовать поддерживаемые функции.

Запрос на инициализацию от клиента

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "elicitation": {}
    },
    "clientInfo": {
      "name": "example-client",
      "version": "1.0.0"
    }
  }
}

Ответ на запрос об инициализации от сервера

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": {
        "listChanged": true
      },
      "resources": {}
    },
    "serverInfo": {
      "name": "example-server",
      "version": "1.0.0"
    }
  }
}

Понимание обмена инициализацией

Процесс инициализации — ключевая часть управления жизненным циклом MCP и выполняет несколько критических функций:

• Согласование версии протокола: поле protocolVersion (например, "2025-06-18") гарантирует, что клиент и сервер используют совместимые версии протокола. Это предотвращает ошибки связи, которые могут возникнуть при взаимодействии разных версий. Если совместимая версия не согласована, соединение должно быть завершено.
• Обнаружение возможностей: объект capabilities позволяет каждой стороне объявить, какие функции они поддерживают, включая примитивы, которые они могут обрабатывать (инструменты, ресурсы, промпты), и поддерживают ли они функции, такие как уведомления. Это позволяет эффективно общаться, избегая неподдерживаемых операций.
• Обмен идентификацией: объекты clientInfo и serverInfo предоставляют информацию об идентификации и версии для отладки и совместимости.

В этом примере согласование возможностей демонстрирует, как объявляются примитивы MCP:

• Возможности клиента:

  "elicitation": {} 

  Клиент объявляет, что может работать с запросами взаимодействия с пользователем (может получать вызовы методов elicitation/create).

• Возможности сервера:

  "tools": {"listChanged": true} 

  Сервер поддерживает примитив инструментов И может отправлять уведомления tools/list_changed, когда его список инструментов изменяется.

  "resources": {} 

  Сервер также поддерживает примитив ресурсов (может обрабатывать методы resources/list и resources/read).

После успешной инициализации клиент отправляет уведомление, чтобы указать, что он готов:

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

Как это работает в ИИ-приложениях

Во время инициализации менеджер MCP-клиентов ИИ-приложения устанавливает соединения с настроенными серверами и сохраняет их возможности для дальнейшего использования. Приложение использует эту информацию, чтобы определить, какие серверы могут предоставлять определенные типы функциональности (инструменты, ресурсы, промпты) и поддерживают ли они обновления в реальном времени.

Псевдокод для инициализации ИИ-приложения

# Псевдокод
async with stdio_client(server_config) as (read, write):
    async with ClientSession(read, write) as session:
        init_response = await session.initialize()
        if init_response.capabilities.tools:
            app.register_mcp_server(session, supports_tools=True)
        app.set_server_ready(session)

2. Обнаружение инструментов (примитивы)

Теперь, когда соединение установлено, клиент может обнаружить доступные инструменты, отправив запрос tools/list. Этот запрос является основой механизма обнаружения инструментов MCP — он позволяет клиентам понять, какие инструменты доступны на сервере, прежде чем пытаться их использовать.

Запрос клиента на список инструментов, предоставляемых сервером.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list"
}

Пример ответа MCP сервера о доступных ресурсах и инструментах

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "calculator_arithmetic",
        "title": "Calculator",
        "description": "Perform mathematical calculations including basic arithmetic, trigonometric functions, and algebraic operations",
        "inputSchema": {
          "type": "object",
          "properties": {
            "expression": {
              "type": "string",
              "description": "Mathematical expression to evaluate (e.g., '2 + 3 * 4', 'sin(30)', 'sqrt(16)')"
            }
          },
          "required": ["expression"]
        }
      },
      {
        "name": "weather_current",
        "title": "Weather Information",
        "description": "Get current weather information for any location worldwide",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name, address, or coordinates (latitude,longitude)"
            },
            "units": {
              "type": "string",
              "enum": ["metric", "imperial", "kelvin"],
              "description": "Temperature units to use in response",
              "default": "metric"
            }
          },
          "required": ["location"]
        }
      }
    ]
  }
}

Понимание запроса на обнаружение инструментов

Запрос tools/list прост и не содержит параметров.

Понимание ответа на обнаружение инструментов

Ответ содержит массив tools, который предоставляет исчерпывающие метаданные о каждом доступном инструменте. Эта структура на основе массива позволяет серверам одновременно предоставлять несколько инструментов, сохраняя четкие границы между различными функциональностями. Каждый объект инструмента в ответе включает несколько ключевых полей:

• name: уникальный идентификатор инструмента в пространстве имен сервера. Служит первичным ключом для выполнения инструмента и должен следовать четкому шаблону именования (например, calculator_arithmetic, а не просто calculate).
• title: отображаемое имя инструмента, удобное для пользователя, которое клиенты могут показывать пользователям.
• description: подробное объяснение, что делает инструмент и когда его использовать.
• inputSchema: JSON-схема, определяющая ожидаемые входные параметры, обеспечивающая проверку типов и предоставляющая четкую документацию о требуемых и необязательных параметрах.

Как это работает в ИИ-приложениях

ИИ-приложение получает доступные инструменты со всех подключенных MCP-серверов и объединяет их в единый реестр инструментов, к которому может обращаться языковая модель. Это позволяет LLM понимать, какие действия она может выполнять, и автоматически генерировать соответствующие вызовы инструментов во время анализа ситуации со стороны ИИ.

Псевдокод для обнаружения инструментов ИИ-приложением

# Псевдокод с использованием шаблонов MCP Python SDK

available_tools = []

for session in app.mcp_server_sessions():
    tools_response = await session.list_tools()
    available_tools.extend(tools_response.tools)
conversation.register_available_tools(available_tools)

3. Выполнение инструмента (примитивы)

Теперь клиент может выполнить инструмент с помощью метода tools/call. Это демонстрирует, как примитивы MCP используются на практике: после обнаружения доступных инструментов клиент может вызывать их с соответствующими аргументами.

Понимание запроса на выполнение инструмента

Запрос tools/call следует структурированному формату, обеспечивающему безопасность типов и четкое взаимодействие между клиентом и сервером. Обратите внимание, что мы используем правильное имя инструмента из ответа на обнаружение (weather_current), а не упрощенное имя:

Пример запроса к MCP серверу со стороны ИИ приложения - какая погода в Сан Франциско (у нас есть MCP сервер, который имеет инструмент weather_current и рассказал об этом нашему ИИ приложению).

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": {
      "location": "San Francisco",
      "units": "imperial"
    }
  }
}

Пример ответа со стороны MCP сервера

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Current weather in San Francisco: 68°F, partly cloudy with light winds from the west at 8 mph. Humidity: 65%"
      }
    ]
  }
}

Ключевые элементы выполнения инструмента

Структура запроса включает несколько важных компонентов:

• name: должно точно совпадать с именем инструмента из ответа на обнаружение (weather_current). Это гарантирует, что сервер сможет правильно идентифицировать, какой инструмент выполнить.
• arguments: содержит входные параметры, как определено схемой ввода инструмента. В этом примере:
  • location: "San Francisco" (обязательный параметр)
  • units: "imperial" (необязательный параметр, по умолчанию "metric", если не указан)
• Структура JSON-RPC: использует стандартный формат JSON-RPC 2.0 с уникальным идентификатором для корреляции запросов и ответов.

Понимание ответа на выполнение инструмента

Ответ демонстрирует гибкую систему контента MCP:

• Массив content: ответы инструментов возвращают массив объектов контента, позволяя использовать богатые, многоформатные ответы (текст, изображения, ресурсы и т.д.).
• Типы контента: каждый объект контента имеет поле type. В этом примере "type": "text" указывает на текстовый контент, но MCP поддерживает различные типы контента для разных случаев использования.
• Структурированный вывод: ответ предоставляет практически применимую информацию, которую ИИ-приложение может использовать в качестве контекста для взаимодействия с языковой моделью.

Этот шаблон выполнения позволяет ИИ-приложениям динамически вызывать функциональность сервера и получать структурированные ответы, которые можно интегрировать в промпты и диалоги с языковыми моделями.

Как это работает в ИИ-приложениях

Когда языковая модель решает использовать инструмент во время разговора, ИИ-приложение перехватывает вызов инструмента, направляет его на соответствующий MCP-сервер, выполняет его и возвращает результаты обратно в LLM в рамках потока разговора. Это позволяет LLM получать доступ к данным в реальном времени и выполнять действия во внешнем мире.

# Псевдокод для выполнения инструмента ИИ-приложением

async def handle_tool_call(conversation, tool_name, arguments):
    session = app.find_mcp_session_for_tool(tool_name)
    result = await session.call_tool(tool_name, arguments)
    conversation.add_tool_result(result.content)

4. Обновления в реальном времени (уведомления)

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

Когда доступные инструменты сервера изменяются — например, когда появляется новая функциональность, существующие инструменты изменяются или становятся временно недоступными — сервер может активно уведомлять подключенных клиентов:

{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed"
}

Ключевые особенности уведомлений MCP

• Ответ не требуется: обратите внимание, что в уведомлении нет поля id. Это соответствует семантике уведомлений JSON-RPC 2.0, где ответ не ожидается и не отправляется.
• На основе возможностей: это уведомление отправляется только серверами, которые объявили "listChanged": true в своих возможностях инструментов во время инициализации (как показано на шаге 1).
• Событийно-ориентированный: сервер решает, когда отправлять уведомления на основе внутренних изменений состояния, делая MCP-соединения динамичными и отзывчивыми.

Реакция клиента на уведомления

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

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/list"
}

Почему уведомления важны

Эта система уведомлений важна по нескольким причинам:

• Динамические среды: инструменты могут появляться и исчезать в зависимости от состояния сервера, внешних зависимостей или разрешений пользователя.
• Эффективность: клиентам не нужно опрашивать изменения; они получают уведомления, когда происходят обновления.
• Согласованность: гарантирует, что клиенты всегда имеют актуальную информацию о доступных возможностях сервера.
• Сотрудничество в реальном времени: позволяет ИИ-приложениям быть отзывчивыми и адаптироваться к изменяющемуся контексту.

Этот шаблон уведомлений распространяется не только на инструменты, но и на другие примитивы MCP, обеспечивая всеобъемлющую синхронизацию в реальном времени между клиентами и серверами.

Как это работает в ИИ-приложениях

Когда ИИ-приложение получает уведомление об изменении инструментов, оно немедленно обновляет реестр инструментов и обновляет возможности LLM. Это гарантирует, что текущие разговоры всегда имеют доступ к самому актуальному набору инструментов, а LLM может динамически адаптироваться к новой функциональности по мере её появления.

# Псевдокод для обработки уведомлений ИИ-приложением

async def handle_tools_changed_notification(session):
    tools_response = await session.list_tools()
    app.update_available_tools(session, tools_response.tools)
    if app.conversation.is_active():
        app.conversation.notify_llm_of_new_capabilities()

Концепции MCP-серверов

MCP-серверы — это программы, которые предоставляют ИИ-приложениям специфические возможности через стандартизированные протокольные интерфейсы. Распространенные примеры включают файловые серверы для доступа к документам, серверы баз данных для выполнения запросов, GitHub-серверы для управления кодом, Slack-серверы для командного общения, серверы календарей для планирования и любые инструменты и источники данных, какие вы захотите.

Основные функции серверов

Серверы предоставляют функциональность через три основных строительных блока:

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

Инструменты

Инструменты позволяют ИИ-моделям выполнять действия. Каждый инструмент определяет конкретную операцию с типизированными входами и выходами. Модель запрашивает выполнение инструмента на основе контекста.

Как работают инструменты

Инструменты — это интерфейсы, определенные схемой, которые LLM могут вызывать. MCP использует JSON Schema для валидации. Каждый инструмент выполняет одну операцию с четко определенными входами и выходами. Инструменты могут требовать согласия пользователя перед выполнением, что помогает пользователям сохранять контроль над действиями модели.

Протокольные операции:

Пример определения инструмента:

{
  "name": "searchFlights",
  "description": "Поиск доступных рейсов",
  "inputSchema": {
    "type": "object",
    "properties": {
      "origin": { "type": "string", "description": "Город отправления" },
      "destination": { "type": "string", "description": "Город прибытия" },
      "date": { "type": "string", "format": "date", "description": "Дата поездки" }
    },
    "required": ["origin", "destination", "date"]
  }
}

Пример: бронирование путешествия

Инструменты позволяют ИИ-приложениям выполнять действия от имени пользователей. В сценарии планирования путешествия ИИ-приложение может использовать несколько инструментов для помощи в бронировании отпуска:

• Поиск рейсов

  searchFlights(origin: "NYC", destination: "Barcelona", date: "2024-06-15")

  Запрашивает несколько авиакомпаний и возвращает структурированные варианты рейсов.

• Блокировка календаря

  createCalendarEvent(title: "Поездка в Барселону", startDate: "2024-06-15", endDate: "2024-06-22")

  Помечает даты поездки в календаре пользователя.

• Уведомление по электронной почте

  sendEmail(to: "team@work.com", subject: "Вне офиса", body: "...")

  Отправляет автоматизированное сообщение "Вне офиса" коллегам.

Модель взаимодействия с пользователем

Инструменты контролируются моделью, то есть ИИ-модели могут автоматически обнаруживать и вызывать их. Однако MCP делает акцент на контроле со стороны человека через несколько механизмов. Для обеспечения доверия и безопасности приложения могут реализовывать контроль пользователя через:

• Отображение доступных инструментов в интерфейсе, позволяя пользователям определять, должен ли инструмент быть доступен в конкретных взаимодействиях.
• Диалоги подтверждения для отдельных выполнений инструментов.
• Настройки разрешений для предварительного одобрения определенных безопасных операций.
• Журналы активности, показывающие все выполнения инструментов с их результатами.

Почему это работает?

• Потому что LLM модели обучены генерировать вызов инструментов имея их описание. LLM может сгенерировать текст function_call: createCalendarEvent(title: "Поездка в Барселону", startDate: "2024-06-15", endDate: "2024-06-22")
• И этот текст мы разберем, выполним через обращение к MCP серверу данный инструмент, JSON с ответом сервера мы снова покажем LLM и в диалоге спросим ее что делать дальше.
• Это примерное объяснение того как LLM выбирают инструмент для исполнения и как получаю результат и снова решают что им делать.
• Те наш программный код ИИ приложения ведет диалог с LLM показывая ей список инструментов, вопрос пользователя и по шагам делаем то что она говорит - вызываем инструменты, показываем LLM полученные результаты и так до тех пор пока LLM не скажет final_answer: ...(конечный ответ пользователю). В этот момент ИИ приложение заказчивает цикл обработки вошедшего запроса поьзователя и может переходить к следующему вопросу.
• Причем один из инструментов ИИ приложения в процессе работы может быть и задать уточняющий вопрос пользователю и показать ответ пользователя LLM снова как шаг диалога.

Ресурсы

Ресурсы предоставляют структурированный доступ к информации, которую ИИ-приложение может извлекать и предоставлять моделям в качестве контекста.

Как работают ресурсы

Ресурсы предоставляют данные из файлов, API, баз данных или любых других источников, которые ИИ должна понимать для контекста. Приложения могут напрямую получать доступ к этой информации и решать, как её использовать — будь то выбор релевантных частей, поиск с использованием эмбеддингов или передача всех данных модели. Каждый ресурс имеет уникальный URI (например, file:///path/to/document.md) и объявляет свой MIME-тип для соответствующей обработки контента. Они поддерживают два шаблона обнаружения:

• Прямые ресурсы — фиксированные URI, указывающие на конкретные данные. Пример: calendar://events/2024 — возвращает доступность календаря на 2024 год.
• Шаблоны ресурсов — динамические URI с параметрами для гибких запросов. Пример:
  • travel://activities/{city}/{category} — возвращает активности по городу и категории.
  • travel://activities/barcelona/museums — возвращает все музеи в Барселоне.

Шаблоны ресурсов включают метаданные, такие как название, описание и ожидаемый MIME-тип, что делает их обнаруживаемыми и самодокументируемыми.

Протокольные операции:

Пример: получение контекста для планирования путешествия

Продолжая пример с планированием путешествия, ресурсы предоставляют ИИ-приложению доступ к релевантной информации:

• Данные календаря (calendar://events/2024) — проверка доступности пользователя.
• Путевые документы (file:///Documents/Travel/passport.pdf) — доступ к важным документам.
• Предыдущие маршруты (trips://history/barcelona-2023) — ссылки на прошлые поездки и предпочтения.

ИИ-приложение извлекает эти ресурсы и решает, как их обрабатывать: выбирать подмножество данных с помощью эмбеддингов или ключевого поиска, или передавать необработанные данные напрямую модели. В данном случае оно предоставляет данные календаря, информацию о погоде и предпочтения в путешествиях модели, позволяя ей проверять доступность, изучать погодные условия и учитывать прошлые предпочтения.

Примеры шаблонов ресурсов:

{
  "uriTemplate": "weather://forecast/{city}/{date}",
  "name": "weather-forecast",
  "title": "Прогноз погоды",
  "description": "Получить прогноз погоды для любого города и даты",
  "mimeType": "application/json"
}

{
  "uriTemplate": "travel://flights/{origin}/{destination}",
  "name": "flight-search",
  "title": "Поиск рейсов",
  "description": "Поиск доступных рейсов между городами",
  "mimeType": "application/json"
}

Эти шаблоны позволяют выполнять гибкие запросы. Например, для данных о погоде пользователи могут получать прогнозы для любой комбинации города и даты. Для рейсов можно искать маршруты между любыми двумя аэропортами. Когда пользователь вводит "NYC" как аэропорт отправления и начинает вводить "Bar" как аэропорт назначения, система может предложить "Barcelona (BCN)" или "Barbados (BGI)".

Завершение параметров (completion)

Динамические ресурсы поддерживают завершение параметров. Например:

• Ввод "Par" для weather://forecast/{city} может предложить "Paris" или "Park City".
• Ввод "JFK" для flights://search/{airport} может предложить "JFK — Международный аэропорт имени Джона Ф. Кеннеди".

Система помогает обнаруживать допустимые значения без необходимости знать точный формат.

Модель взаимодействия с пользователем

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

• Древовидные или списковые представления для просмотра ресурсов в привычных структурах папок.
• Интерфейсы поиска и фильтрации для нахождения конкретных ресурсов.
• Автоматическое включение контекста или умные предложения на основе эвристик или выбора ИИ.
• Интерфейсы для ручного или пакетного выбора одного или нескольких ресурсов.

Приложения могут свободно реализовывать обнаружение ресурсов через любой подходящий интерфейс. Протокол не предписывает конкретные UI-шаблоны, позволяя использовать селекторы ресурсов с возможностью предварительного просмотра, умные предложения на основе текущего контекста разговора, пакетный выбор для включения нескольких ресурсов или интеграцию с существующими файловыми браузерами и средствами исследования данных.

Промпты

Промпты предоставляют многоразовые шаблоны. Они позволяют авторам MCP-серверов предоставлять параметризованные промпты для домена или демонстрировать, как лучше всего использовать MCP-сервер.

Как работают промпты

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

Протокольные операции:

Пример: оптимизированные рабочие процессы

Промпты предоставляют структурированные шаблоны для распространенных задач. В контексте планирования путешествия:

Промпт "Планирование отпуска":

{
  "name": "plan-vacation",
  "title": "Спланировать отпуск",
  "description": "Руководство по процессу планирования отпуска",
  "arguments": [
    { "name": "destination", "type": "string", "required": true },
    { "name": "duration", "type": "number", "description": "дней" },
    { "name": "budget", "type": "number", "required": false },
    { "name": "interests", "type": "array", "items": { "type": "string" } }
  ]
}

Вместо неструктурированного естественно-языкового ввода система промптов позволяет:

• Выбирать шаблон "Спланировать отпуск".
• Структурированный ввод: Барселона, 7 дней, 3000$, ["пляжи", "архитектура", "еда"].
• Последовательное выполнение рабочего процесса на основе шаблона.

Модель взаимодействия с пользователем

Промпты контролируются пользователем и требуют явного вызова. Протокол дает разработчикам свободу в проектировании интерфейсов, которые будут естественно вписываться в их приложение. Ключевые принципы включают:

• Легкое обнаружение доступных промптов.
• Четкие описания того, что делает каждый промпт.
• Естественный ввод аргументов с валидацией.
• Прозрачное отображение базового шаблона промпта.

Приложения обычно предоставляют промпты через различные UI-шаблоны, такие как:

• Команды с косой чертой (ввод "/" для просмотра доступных промптов, например, /plan-vacation).
• Командные палитры для поиска.
• Выделенные кнопки интерфейса для часто используемых промптов.
• Контекстные меню, предлагающие релевантные промпты.

Объединение серверов

Истинная мощь MCP проявляется, когда несколько серверов работают вместе, объединяя свои специализированные возможности через унифицированный интерфейс.

Пример: планирование путешествия с использованием нескольких серверов

Рассмотрим персональное ИИ-приложение для планирования путешествий с тремя подключенными серверами:

• Сервер путешествий — обрабатывает рейсы, отели и маршруты.
• Сервер погоды — предоставляет климатические данные и прогнозы.
• Сервер календаря/почты — управляет расписаниями и коммуникациями.

Полный процесс:

1. Пользователь вызывает промпт с параметрами:

   {
    "prompt": "plan-vacation",
    "arguments": {
      "destination": "Barcelona",
      "departure_date": "2024-06-15",
      "return_date": "2024-06-22",
      "budget": 3000,
      "travelers": 2
    }
   }

2. Пользователь выбирает ресурсы для включения:

   • calendar://my-calendar/June-2024 (с сервера календаря).
   • travel://preferences/europe (с сервера путешествий).
   • travel://past-trips/Spain-2023 (с сервера путешествий).

3. ИИ обрабатывает запрос с использованием инструментов:

   • ИИ сначала читает все выбранные ресурсы, чтобы собрать контекст: определяет доступные даты из календаря, узнает предпочитаемые авиакомпании и типы отелей из предпочтений в путешествиях, а также обнаруживает ранее посещенные места из прошлых поездок.
   • Используя этот контекст, ИИ выполняет серию инструментов:
     • searchFlights() — запрашивает авиакомпании о рейсах из Нью-Йорка в Барселону.
     • checkWeather() — получает климатические прогнозы на даты поездки.

4. Затем ИИ использует эту информацию для создания бронирования и следующих шагов, запрашивая подтверждение у пользователя, где это необходимо:

   • bookHotel() — находит отели в пределах указанного бюджета.
   • createCalendarEvent() — добавляет поездку в календарь пользователя.
   • sendEmail() — отправляет подтверждение с деталями поездки.

Результат: Через несколько MCP-серверов пользователь исследовал и забронировал поездку в Барселону, адаптированную к его расписанию. Промпт "Спланировать отпуск" направил ИИ на объединение ресурсов (доступность календаря и история путешествий) с инструментами (поиск рейсов, бронирование отелей, обновление календаря) на разных серверах — собирая контекст и выполняя бронирование. Задача, которая могла бы занять часы, была выполнена за несколько минут с помощью MCP.

Пишите MCP серверы, подключайте их к своим ИИ приложениям, делайте мир лучше!