# 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-конфиг приложения. Пример из репозитория эталонных серверов: файловый сервер, которому разрешён доступ только к одной папке.

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

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

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

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

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

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

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

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

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

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

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

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

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

## Связь с RouterAI

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

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

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

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

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

**Нужен ли MCP для обычных API-запросов?** Нет. Запрос к [Chat Completions API](/pages/chat-completions-api) работает без MCP. MCP нужен приложению, которое хочет подключать внешние инструменты по стандарту. Разработчик может и сам описать функции в `tools` без всякого MCP.

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

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

## Что почитать

- [Документация Model Context Protocol](https://modelcontextprotocol.io) и [репозиторий эталонных серверов](https://github.com/modelcontextprotocol/servers).
- [Function Calling](/pages/function-calling) и [Tool Calling API](/pages/tool-calling-api) — механизм, на котором стоит MCP.
- [Prompt Injection](/pages/prompt-injection) — главный риск при работе с инструментами.
- [Автономный ИИ-агент](/pages/avtonomnyy-ii-agent) — где MCP применяется на практике.
- [Интеграции RouterAI](/docs/integrations) — клиенты, которые можно подключить к моделям RouterAI.