MCP

MCP (Model Context Protocol) задаёт общий способ, которым AI-приложение обнаруживает инструменты, читает доступные данные и вызывает внешние действия. Протокол разделяет хост, клиент и сервер, но не отменяет проверку прав, аргументов и результатов.

Коротко

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

Что такое MCP

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

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

У архитектуры три участника:

• Хост — AI-приложение, которое управляет подключениями, разрешениями и взаимодействием с моделью.
• Клиент — компонент внутри хоста. Он поддерживает отдельную сессию с конкретным сервером.
• Сервер — локальная программа или удалённый сервис, который предоставляет возможности по MCP.

Если хост подключён к трём серверам, обычно он создаёт три изолированных клиента. Так проще не смешивать соединения и права разных источников.

Что может предоставить сервер

Основные примитивы MCP решают разные задачи:

• Tools — действия с описанными аргументами: найти запись, создать задачу, выполнить запрос.
• Resources — данные для чтения: файл, запись базы, схема, справочник или ответ API.
• Prompts — готовые шаблоны взаимодействия, которые хост может показать пользователю.

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

Как проходит подключение

MCP использует сообщения JSON-RPC и отдельный транспорт. Для локальных процессов часто подходит stdio; для удалённых серверов — потоковый HTTP.

Типичная сессия выглядит так:

1. Хост создаёт клиент и соединяется с сервером.
2. Стороны согласуют версию протокола и поддерживаемые возможности.
3. Клиент запрашивает список доступных инструментов, ресурсов или промптов.
4. Хост решает, что из этого передать модели и показать человеку.
5. Если модель предлагает вызвать инструмент, хост проверяет запрос и отправляет tools/call.
6. Результат возвращается модели как новый контекст.

Сервер не становится частью модели. Он остаётся отдельной программой, а хост управляет тем, какие данные проходят между ними.

Наглядный пример

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

Сервер контента может предоставить:

• ресурс со схемой рубрик;
• инструмент search_articles для поиска материалов;
• инструмент create_draft_task для создания черновика задачи;
• промпт для проверки пересечений между новой темой и архивом.

Запрос «проверь, писали ли мы про локальный запуск распознавания речи, и подготовь задачу, если нет» превращается в цепочку: поиск, чтение найденных данных, решение модели и отдельное действие. Создание задачи лучше оставить на подтверждение человеку, потому что оно меняет внешнее состояние.

MCP и tool calling

Tool calling — механизм, с помощью которого модель предлагает вызвать функцию с аргументами. MCP решает другую задачу: даёт клиенту стандартный способ обнаружить и вызвать инструменты, пришедшие от внешнего сервера.

Их часто используют вместе:

MCP-сервер описывает инструмент
          ↓
хост передаёт схему модели
          ↓
модель предлагает имя и аргументы
          ↓
хост проверяет и вызывает инструмент по MCP

MCP также не заменяет REST API. Сервер может сам обращаться к REST API, базе или файловой системе, а наружу предоставлять единый MCP-интерфейс.

Локальный и удалённый сервер

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

Удалённый сервер работает по сети. Для него важны аутентификация, шифрование, области доступа и проверка адреса назначения. В официальной схеме авторизации для защищённых удалённых серверов используется поток на основе OAuth; конкретная реализация зависит от клиента и сервера.

Безопасность

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

Устойчивый контур строится из нескольких мер:

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

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

MCP в визуальных и других пайплайнах

MCP не является встроенной частью ComfyUI и не требует особого формата графа. При необходимости его добавляет отдельная интеграция: например, LLM-компонент получает данные через MCP, а затем передаёт проверенные параметры в API workflow. Совместимость и безопасность здесь зависят от конкретного расширения.

Тот же подход подходит редактору кода, CRM, базе знаний или внутренней панели. Протокол общий, а пользовательский интерфейс и политика подтверждений остаются задачей хоста.

С чем часто путают

• Function calling описывает структурированный вызов функции внутри конкретного API. MCP стандартизирует связь с внешним поставщиком возможностей.
• Плагин — пакет для конкретного приложения. MCP-сервер может работать с разными совместимыми хостами, но только в пределах поддерживаемых ими возможностей.
• REST API — общий стиль сетевого интерфейса. MCP-сервер может быть адаптером поверх REST API.
• AI-агент — система, которая планирует и повторяет действия. MCP лишь один из способов дать ей данные и инструменты.

Частые вопросы

Можно ли подключить один сервер к любому AI-приложению?

Только если приложение поддерживает нужную версию протокола, транспорт и примитивы сервера. Совместимость стандарта не гарантирует одинаковый интерфейс или одинаковые разрешения.

Можно ли написать собственный сервер?

Да. Для распространённых языков есть SDK, но важнее сначала определить узкий набор возможностей и модель прав. Чем меньше поверхность доступа, тем проще проверить сервер.

Где искать готовые серверы?

В официальном реестре и документации экосистемы. Перед запуском всё равно стоит проверить автора, исходный код, зависимости, требуемые разрешения и способ обновления.

Нужна ли модели поддержка MCP?

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

Главное

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