Что такое MCP (Model Context Protocol)

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

MCP представила компания Anthropic в ноябре 2024 года. С декабря 2025 года протокол развивается в Agentic AI Foundation, входящем в Linux Foundation. Текущая версия спецификации - 2026-07-28.

Кратко

Какую задачу решает MCP

Языковая модель работает только с тем текстом, который получила. Чтобы прочитать файл, выполнить запрос к базе данных или создать задачу, модели нужно приложение, которое обращается к внешним системам от её имени и возвращает результаты в её контекст. Провайдеры моделей поддерживают это через function calling (его также называют tool use): приложение описывает функции в JSON Schema, модель возвращает запрос на вызов одной из них, приложение выполняет вызов.

Function calling определяет, как модель просит о вызове. Откуда берутся сами инструменты, он не определяет. До MCP у каждого ИИ-приложения был свой формат плагинов или интеграций, и интеграцию с одним и тем же сервисом писали отдельно под каждое приложение. При N приложениях и M сервисах это до N × M интеграций, у каждой свой код, своя аутентификация и своя поддержка.

MCP заменяет это одним контрактом. Сервис один раз реализует MCP-сервер, приложение один раз реализует MCP-клиент, и любая совместимая пара работает вместе: N + M реализаций вместо N × M.

Идея взята из Language Server Protocol (LSP), который решил ту же задачу для редакторов кода и языков программирования: один языковой сервер работает в любом редакторе с поддержкой LSP. MCP повторяет подход LSP к обмену сообщениями и использует тот же формат сообщений, JSON-RPC 2.0.

История

Архитектура

Участники

В MCP три роли:

• Хост (host) - ИИ-приложение, с которым работает пользователь: чат-ассистент, IDE, агент. Хост ведёт диалог с моделью и решает, что модели разрешено делать. Примеры: Claude Desktop, Claude Code, Visual Studio Code, ChatGPT.
• Клиент (client) - компонент внутри хоста, который держит соединение с одним MCP-сервером. Для каждого сервера хост создаёт отдельный клиент.
• Сервер (server) - программа, которая предоставляет контекст и действия: инструменты, данные, шаблоны промптов. Сервер может быть обёрткой над файловой системой, базой данных, API SaaS-сервиса или внутренним сервисом компании.

Хост (ИИ-приложение)
 |
 +-- MCP-клиент 1 --- stdio ------------- MCP-сервер: файловая система (локальный)
 +-- MCP-клиент 2 --- stdio ------------- MCP-сервер: база данных (локальный)
 +-- MCP-клиент 3 --- Streamable HTTP --- MCP-сервер: баг-трекер (удалённый)

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

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

Уровни

Протокол состоит из двух уровней:

• Уровень данных (data layer) определяет сообщения JSON-RPC 2.0 и их смысл: обнаружение возможностей, примитивы, уведомления, ошибки.
• Транспортный уровень (transport layer) определяет доставку сообщений: соединение, разбиение потока на сообщения, авторизацию.

Одни и те же сообщения JSON-RPC идут по любому транспорту, поэтому логика сервера не зависит от того, как он развёрнут.

Примитивы

Примитивы - это то, что стороны предлагают друг другу. Спецификация определяет три примитива сервера:

Инструмент описывается именем, заголовком для человека, описанием и JSON Schema входных параметров (inputSchema). Инструмент может объявить и схему своего результата (outputSchema). Модель выбирает инструмент и заполняет аргументы по имени, описанию и схеме. Поэтому текст описаний - часть интерфейса: неточное описание приводит к неверным или пропущенным вызовам, даже когда код инструмента работает правильно.

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

• Elicitation (запрос данных у пользователя): сервер просит пользователя ввести недостающие данные или подтвердить действие (elicitation/create).
• Sampling (устарел в 2026-07-28): сервер просит модель клиента сгенерировать ответ (sampling/createMessage). Новые реализации обращаются к API провайдеров моделей напрямую.
• Roots (устарел): клиент сообщает серверу, с какими каталогами можно работать. Теперь пути передают параметрами инструментов или в конфигурации сервера.
• Logging (устарел): сообщения журнала от сервера к клиенту. Заменён стандартным потоком ошибок для stdio-серверов и OpenTelemetry.

Устаревшая возможность продолжает работать не меньше двенадцати месяцев. Этот минимальный срок - часть формальной политики вывода функций из употребления, которую ввела версия 2026-07-28.

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

Как проходит запрос

Обнаружение возможностей

С версии 2026-07-28 MCP не хранит состояние (stateless): каждый запрос содержит всё, что нужно серверу для его обработки. Версия протокола, данные о клиенте и его возможности передаются в поле _meta каждого запроса.

Чтобы узнать, что поддерживает сервер, клиент может отправить server/discover. Этот метод обязан реализовать каждый сервер; клиент может его пропустить и сразу отправлять другие запросы.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

В ответе - поддерживаемые версии протокола и возможности сервера. Ответ можно кешировать:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": { "tools": { "listChanged": true }, "resources": {} },
    "_meta": {
      "io.modelcontextprotocol/serverInfo": { "name": "example-server", "version": "1.0.0" }
    },
    "ttlMs": 3600000,
    "cacheScope": "public"
  }
}

Если сервер не поддерживает запрошенную версию, он отклоняет запрос с ошибкой UnsupportedProtocolVersionError и списком версий, которые поддерживает. Клиент повторяет запрос с версией, которую поддерживают обе стороны.

Вызов инструмента

Типичный цикл выглядит так:

1. Хост запрашивает список инструментов у каждого подключённого сервера (tools/list) и добавляет их описания в контекст модели.
2. Пользователь задаёт вопрос. Модель решает, что нужен инструмент, и возвращает вызов с аргументами.
3. Хост проверяет разрешения, при необходимости спрашивает подтверждение у пользователя и отправляет tools/call через клиент нужного сервера.
4. Сервер выполняет действие и возвращает результат в виде массива content: текст, изображения, ссылки на ресурсы, структурированные данные.
5. Хост передаёт результат модели, и модель продолжает ответ.

Запрос и ответ шагов 3 и 4:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "San Francisco", "units": "imperial" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "resultType": "complete",
    "content": [
      { "type": "text", "text": "Current weather in San Francisco: 68°F, partly cloudy" }
    ]
  }
}

Ошибка, которая произошла во время работы инструмента, возвращается внутри результата с isError: true: модель её видит и может исправить вызов. Ошибки протокола, например неизвестный метод или неверные параметры, возвращаются как ошибки JSON-RPC.

Когда серверу нужны дополнительные данные

В прежних версиях сервер мог посреди обработки отправить запрос клиенту, например задать вопрос пользователю. Для этого требовалось долгоживущее соединение с одним и тем же экземпляром сервера.

Спецификация 2026-07-28 заменяет этот механизм на Multi Round-Trip Requests (MRTR), многоэтапные запросы. Сервер отвечает на tools/call, resources/read или prompts/get результатом типа input_required. В поле inputRequests перечислено, чего не хватает серверу, а в поле requestState может лежать непрозрачное для клиента состояние:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "github_login": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Please provide your GitHub username",
          "requestedSchema": {
            "type": "object",
            "properties": { "name": { "type": "string" } },
            "required": ["name"]
          }
        }
      }
    },
    "requestState": "AEAD-protected blob"
  }
}

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

Уведомления

Сервер может сообщить клиенту об изменениях, например о том, что изменился список инструментов (notifications/tools/list_changed). Уведомления клиент получает только по подписке: он открывает долгоживущий поток subscriptions/listen и перечисляет нужные типы уведомлений. Доставка не гарантирована, поэтому клиенты также периодически запрашивают списки заново.

Результаты tools/list, prompts/list, resources/list и resources/read содержат подсказки для кеширования: ttlMs (сколько результат остаётся актуальным) и cacheScope (кто может использовать его повторно). Спецификация рекомендует возвращать инструменты в детерминированном порядке, это сохраняет стабильность кеша промптов модели.

Транспорты

stdio

Хост запускает сервер как дочерний процесс. Сообщения JSON-RPC идут через стандартные потоки ввода и вывода, по одному сообщению на строку; стандартный поток ошибок используется для журнала. Этот транспорт применяют для локальных серверов: сети нет, учётные данные сервер берёт из окружения процесса, например из переменных окружения.

Streamable HTTP

Сервер - это HTTP-эндпоинт. Клиент отправляет каждое сообщение HTTP-запросом POST. Сервер отвечает JSON или открывает поток Server-Sent Events, когда ему нужно отправить несколько сообщений, например отчёты о прогрессе.

С версии 2026-07-28 запросы несут заголовки с методом и именем инструмента, ресурса или промпта. Шлюзы, ограничители частоты запросов и межсетевые экраны веб-приложений могут маршрутизировать и учитывать трафик, не разбирая тело JSON:

POST /mcp HTTP/1.1
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_issues

Сессии на уровне протокола и заголовка Mcp-Session-Id больше нет, поэтому удалённый сервер может работать за обычным балансировщиком нагрузки с распределением по кругу (round-robin), без привязки клиента к экземпляру и общего хранилища сессий, в том числе на бессерверных платформах.

Старый транспорт HTTP+SSE из первой версии спецификации объявлен устаревшим, вместо него используется Streamable HTTP. Оба транспорта, их заголовки и требования описаны в статье Транспорты MCP.

Спецификация 2026-07-28

Мейнтейнеры называют 2026-07-28 самой крупной редакцией протокола с момента запуска. Основные изменения по сравнению с 2025-11-25:

Версия также формализовала расширения (extensions): необязательные возможности, которые клиент и сервер должны явно поддержать и которые развиваются вне ядра протокола. Среди официальных расширений:

• Tasks: асинхронное выполнение длительных операций. Инструмент возвращает идентификатор задачи, клиент опрашивает её статус (tasks/get) и забирает результат позже.
• MCP Apps: интерактивные интерфейсы. Сервер связывает инструмент с ресурсом ui://, а хост отображает его в изолированном iframe. Хосты без поддержки расширения показывают текст или структурированные данные.
• Enterprise-Managed Authorization: доступ к серверам выдают администраторы через корпоративного провайдера учётных записей, и пользователи подключаются автоматически при входе.

Больше всего изменений при миграции требуют серверы, которые опирались на идентификатор сессии. Состояние, которое нужно приложению между вызовами, передаётся явно: например, инструмент возвращает идентификатор, а модель передаёт его аргументом следующего вызова. Изменения и миграция с 2025-11-25 описаны в статье MCP без состояния, механизм расширений и официальные расширения - в статье Расширения MCP.

Безопасность и авторизация

Авторизация в MCP необязательна. Для серверов на HTTP, которым она нужна, спецификация определяет авторизацию на основе OAuth 2.1. MCP-сервер выступает сервером ресурсов OAuth: клиент получает токен доступа у сервера авторизации и передаёт его в заголовке Authorization каждого запроса. Сервер принимает только токены, выданные для него. Спецификация 2026-07-28 добавила требования, которые закрывают известные пути атак:

• клиент обязан проверить издателя ответа авторизации (iss, RFC 9207), прежде чем обменять код авторизации на токен;
• учётные данные клиента привязаны к издателю, который их выдал, и не используются с другим сервером авторизации;
• динамическая регистрация клиентов (Dynamic Client Registration) объявлена устаревшей, вместо неё используются Client ID Metadata Documents.

Сервер не должен передавать токен, полученный от клиента, дальше в другие сервисы (token passthrough запрещён): для вызовов других API он получает собственные токены. Серверы на stdio не используют OAuth и берут учётные данные из окружения. Полная схема описана в статье Авторизация в MCP.

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

• Отравление инструментов (tool poisoning): инструкции, скрытые в описаниях инструментов. Модель их читает, а пользователь обычно не видит. Это разновидность prompt injection, публично описанная в апреле 2025 года.
• Prompt injection через данные: текст, который вернул инструмент или ресурс (веб-страница, письмо, задача в трекере), может содержать инструкции, адресованные модели.
• Confused deputy («запутавшийся заместитель»): прокси-сервер с широкими правами выполняет действие для пользователя, у которого не должно быть к нему доступа.
• Уязвимости реализаций: например, CVE-2025-6514 в пакете mcp-remote (CVSS 9.6) позволяла вредоносному серверу выполнять команды на машине пользователя, а CVE-2025-49596 в MCP Inspector возникла из-за отсутствия аутентификации по умолчанию.

Риски и меры защиты от них описаны в статье Безопасность MCP.

Экосистема

• SDK. SDK уровня Tier 1 (TypeScript, Python, Go и C#) поддержали 2026-07-28 к моменту выхода спецификации. Официальные SDK есть также для Java, Kotlin, Rust, Swift, PHP и других языков.
• MCP Inspector - инструмент разработчика: подключается к серверу, показывает его примитивы, вызывает инструменты и отображает сообщения. Его применение в тестировании описано в статье Тестирование MCP-серверов.
• MCP Registry (registry.modelcontextprotocol.io(откроется в новой вкладке)) - официальный каталог общедоступных серверов, предварительная версия запущена в сентябре 2025 года. Каталог хранит метаданные, а не код: каждая запись - файл server.json с уникальным именем в обратной DNS-нотации (например, io.github.user/server-name) и расположением пакета в npm, PyPI, Docker Hub или адресом удалённого сервера. API каталога открыт, поэтому компании могут держать собственные закрытые каталоги в том же формате. Публикация сервера описана в статье Публикация MCP-сервера в MCP Registry.
• Хосты. MCP поддерживают Claude, ChatGPT, Visual Studio Code, Cursor и многие другие ИИ-приложения и фреймворки для агентов.

MCP и смежные технологии

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

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

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

Термины

Источники

• Спецификация Model Context Protocol, версия 2026-07-28(откроется в новой вкладке) (на английском)
• Обзор архитектуры(откроется в новой вкладке) (на английском)
• Multi Round-Trip Requests(откроется в новой вкладке) (на английском)
• The 2026-07-28 Specification, блог MCP(откроется в новой вкладке) (на английском)
• Introducing the Model Context Protocol, Anthropic, 25 ноября 2024(откроется в новой вкладке) (на английском)
• Introducing the MCP Registry, блог MCP, 8 сентября 2025(откроется в новой вкладке) (на английском)