support@routerai.ru

Загрузка...

MCP (Model Context Protocol): что это и как работает

Содержание статьи

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

Авторы документации сравнивают MCP с портом USB-C: раньше для каждой связки «приложение — инструмент» писали отдельную интеграцию, а теперь есть единый разъём. Приложение (например, Cline или Claude Code) подключает MCP-серверы, получает от них список доступных инструментов и данных, а языковая модель решает, что из этого вызвать.

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

В MCP три роли:

  • Хост (host) — ИИ-приложение, которое общается с пользователем и управляет подключениями: IDE, чат, CLI-агент.
  • Клиент (client) — компонент внутри хоста. Хост создаёт по одному клиенту на каждый MCP-сервер, и каждый клиент держит с ним отдельное соединение.
  • Сервер (server) — программа, которая отдаёт контекст: инструменты, данные, шаблоны промптов. Он может работать на вашем компьютере или удалённо.

Важно, что модель не подключается к MCP-серверу напрямую. Она вообще не знает о существовании протокола: приложение через MCP-клиент забирает у серверов список инструментов и данные, а модели отдаёт их в обычном запросе к API. Вся «магия» происходит в приложении.

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

  • stdio — клиент запускает локальный сервер как дочерний процесс и обменивается с ним через стандартные потоки ввода-вывода. Так работают локальные серверы, например файловой системы.
  • Streamable HTTP — HTTP POST и, при необходимости, Server-Sent Events для потоковой передачи. Так работают удалённые серверы; для авторизации рекомендован OAuth.

Что умеет сервер: tools, resources, prompts

Сервер предлагает клиенту три типа возможностей (primitives):

Примитив Что это Пример
Tools Функции, которые модель может вызвать прочитать файл, выполнить SQL-запрос, создать задачу
Resources Данные, которые приложение подкладывает модели как контекст содержимое файла, схема базы данных
Prompts Готовые шаблоны взаимодействия системный промпт, примеры для задачи

Соединение начинается с рукопожатия: клиент отправляет запрос initialize с версией протокола и своими возможностями, сервер отвечает тем же. После этого обе стороны знают, что поддерживает другая, и обмениваются сообщениями до закрытия соединения.

Клиент находит доступное методами tools/list, resources/list, prompts/list, а инструмент вызывает методом tools/call. Список динамический: если у сервера появились новые инструменты, он присылает уведомление. Есть и возможности в обратную сторону: сервер может попросить клиента получить ответ от модели (sampling), запросить у пользователя дополнительные данные или подтверждение (elicitation) и отправить лог.

Пример подключения

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

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/files"]
    }
  }
}

Формат файла и его расположение зависят от приложения — смотрите документацию конкретного клиента.

Чем MCP отличается от function calling и плагинов

Function calling (или tool calling) — это способность модели вернуть вместо текста структурированный вызов функции. Это механизм на уровне API модели: вы описываете функции в запросе, модель выбирает одну из них, а выполнять её должно ваше приложение.

MCP работает на другом уровне. Он не заставляет модель вызывать функции, а стандартизирует, откуда приложение берёт эти функции и данные. Типичная цепочка такая: приложение подключает MCP-серверы, собирает их инструменты в список tools и передаёт в запросе к модели; модель возвращает tool call; приложение отправляет его на нужный MCP-сервер и возвращает результат модели. То есть MCP опирается на tool calling, а не заменяет его.

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

Примеры MCP-серверов

В репозитории modelcontextprotocol/servers лежат эталонные реализации: Filesystem (операции с файлами с настраиваемым доступом), Git (чтение и поиск по репозиториям), Fetch (загрузка веб-страниц для модели), Memory (память на основе графа знаний), Time, Sequential Thinking. Это учебные примеры, а не готовые продакшен-решения.

Серверы для GitHub, баз данных (PostgreSQL, SQLite), браузера (Puppeteer) и других сервисов тоже существуют, но часть из них перенесена в архив или поддерживается компаниями и сообществом. Актуальный список ищите в реестре MCP-серверов.

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

Риски и безопасность

MCP даёт модели доступ к реальным данным и действиям, поэтому ошибки в настройке стоят дороже, чем в обычном чате:

  • Prompt injection через инструменты. Результат вызова — это текст, который попадает в контекст модели. Если сервер вернёт страницу или документ со вставленной инструкцией, модель может принять её за команду. Чем больше прав у инструментов, тем опаснее такая инъекция.
  • Лишние права. Давайте серверу только нужное: конкретную папку, а не весь диск; базу в режиме чтения, а не запись. Подтверждайте опасные действия вручную: так работает, например, Cline, который спрашивает разрешение перед записью файла или командой в терминале.
  • Недоверенные серверы. Локальный сервер — это программа, запущенная на вашем компьютере. Ставьте серверы только из источников, которым доверяете.
  • Авторизация удалённых серверов. В официальном документе по безопасности MCP описаны, например, проблема «запутавшегося заместителя» (confused deputy), запрещённая передача чужих токенов (token passthrough) и перехват сессий (session hijacking).

Связь с RouterAI

MCP живёт на стороне приложения, а не модели. RouterAI — это API-шлюз к моделям, поэтому схема выглядит так: MCP-серверы подключены к вашему клиенту (например, Cline в VS Code), а сама модель вызывается через RouterAI по OpenAI-совместимому API (https://routerai.ru/api/v1) или Anthropic Messages API (https://routerai.ru/api). Работает из России без VPN, оплата в рублях. Клиент передаёт инструменты MCP-серверов в параметре tools, а RouterAI возвращает ответ модели с вызовами.

Из этого следует главное требование: модель должна поддерживать tool calling. В каталоге моделей такие модели отмечены поддержкой параметров tools и tool_choice — например, anthropic/claude-sonnet-5.5, openai/gpt-5.5, deepseek/deepseek-v4-flash. Чем надёжнее модель вызывает инструменты, тем стабильнее работает агент.

У RouterAI есть и собственные функции на основе MCP:

  • MCP-сервер RouterAI (https://routerai.ru/api/v1/mcp) подключает агента (Claude Code, Codex, OpenCode, Cursor) к вашему аккаунту: подбор модели по каталогу, баланс, разбор генераций, поиск по документации.
  • Коннекторы в веб-чате — наоборот, подключают к чату RouterAI внешние MCP-серверы, чтобы модель вызывала их инструменты. Работают только с моделями, которые поддерживают инструменты.

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

Нужен ли MCP для обычных API-запросов? Нет. Запрос к Chat Completions API работает без MCP. MCP нужен приложению, которое хочет подключать внешние инструменты по стандарту. Разработчик может и сам описать функции в tools без всякого MCP.

Работает ли MCP с любыми моделями? С теми, что поддерживают tool calling. Модель без поддержки инструментов ответит без них, а приложение не сможет вызвать MCP-серверы.

Надо ли писать свой MCP-сервер? Часто хватает готовых. Свой сервер нужен, если инструмент специфичен для вашей системы: для этого есть SDK на Python, TypeScript, Go, Java и других языках.

Что почитать