MCP

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

Коротко

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

Что такое MCP

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

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

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

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

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

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

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

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

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

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

MCP использует сообщения JSON-RPC и отдельный транспорт. Для локальных процессов часто подходит stdio — стандартные потоки ввода и вывода; для удалённых серверов — Streamable 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-сервер — исполняемый код в вашем окружении, удалённый — внешний сервис. В обоих случаях важны данные и действия, которые ему доступны. Знакомый формат подключения не подтверждает надёжность автора или безопасность реализации.

Защита складывается из нескольких мер:

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

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

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

MCP не меняет формат графа ComfyUI. Официальная интеграция Comfy MCP даёт совместимому AI-приложению инструменты для работы с ComfyUI; способ подключения и доступные действия описаны в её документации. Само наличие workflow не означает, что агент уже имеет к нему доступ.

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное

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

Источники

• MCP: архитектура и обмен между хостом, клиентом и сервером
• MCP: безопасность и разделение токенов доступа
• Comfy MCP: официальная интеграция