Перейти к содержанию

Model Context Protocol

Материал из Викижурнал

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

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

Протокол был представлен компанией Anthropic 25 ноября 2024 года как открытый проект. В декабре 2025 года MCP был передан в Agentic AI Foundation — фонд под управлением Linux Foundation, созданный Anthropic, Block и OpenAI при поддержке других участников отрасли.[2][3]

Зачем нужен MCP

Архитектура MCP: приложение управляет отдельным клиентом для каждого подключённого сервера

Языковая модель обрабатывает сведения, переданные ей во входном контексте, но не имеет универсального доступа к файлам, базам данных, рабочим приложениям и действиям пользователя. До появления общего протокола каждая пара «ИИ-приложение — внешний сервис» требовала собственной интеграции. Разработчик описывал доступные функции, формат параметров, способ авторизации и обработку ответа отдельно для каждого продукта.

MCP отделяет интеграцию с внешней системой от конкретной модели. Разработчик сервиса создаёт MCP-сервер, который публикует свои возможности по общей схеме. Разработчик ИИ-приложения реализует MCP-клиент один раз и может подключать совместимые серверы. Такой подход напоминает принцип Language Server Protocol, позволившего редакторам кода использовать языковые серверы через стандартный интерфейс.[1]

Протокол решает три основные задачи:

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

Архитектура

MCP использует архитектуру «хост — клиент — сервер». Сообщения кодируются в формате JSON-RPC 2.0. В актуальной версии протокола каждый запрос сам содержит сведения о версии и возможностях клиента, поэтому сервер может обработать его независимо от предыдущих запросов.[4]

Хост

Хост — ИИ-приложение, в котором работает пользователь: настольный ассистент, редактор кода, исследовательский агент или собственная корпоративная система. Хост создаёт клиентов, объединяет полученный контекст, обращается к языковой модели и показывает пользователю запросы на разрешение.

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

Клиент

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

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

Сервер

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

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

Основные возможности

Возможность Кто предоставляет Назначение Пример
Инструменты (tools) Сервер Функции, которые модель может выбрать и вызвать Найти задачу, создать запись, выполнить вычисление
Ресурсы (resources) Сервер Данные, которые приложение добавляет в контекст Файл, схема базы данных, документ, состояние проекта
Шаблоны (prompts) Сервер Подготовленные сообщения и последовательности для типовых операций Проверка кода, анализ отчёта, подготовка сводки
Запрос данных (elicitation) Клиент Получение недостающей информации или подтверждения от пользователя Выбор проекта, заполнение формы, согласование действия

Инструменты

Инструмент имеет уникальное имя, текстовое описание и JSON Schema с допустимыми параметрами. Клиент получает каталог через запрос tools/list, а вызывает выбранную функцию методом tools/call. Сервер возвращает текст, структурированные данные, изображения, ссылки на ресурсы или сообщение об ошибке.[5]

Упрощённый вызов инструмента выглядит так: 

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "Бишкек" }
  }
}

Описание инструмента помогает модели решить, когда его применять, но не должно считаться доверенным только потому, что оно получено по MCP. Хост может показывать пользователю название операции, параметры и ожидаемые последствия перед выполнением.

Ресурсы

Ресурс представляет данные, доступные по URI: текстовый файл, изображение, схему, документ или объект прикладной системы. Приложение может предложить пользователю выбрать ресурс, автоматически подобрать его по запросу или получить содержимое через resources/read. Для наборов однотипных объектов используются параметризованные шаблоны URI.[6]

Ресурсы отличаются от инструментов направлением работы. Ресурс описывает данные, которые приложение читает и включает в контекст; инструмент выполняет операцию и может изменить внешнюю систему. На практике одна интеграция способна предоставлять оба типа возможностей.

Шаблоны

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

Расширения

Версия 2026-07-28 ввела формальную систему необязательных расширений. К ним относятся Tasks для длительных асинхронных операций, MCP Apps для интерактивных элементов интерфейса внутри разговора и Skills over MCP для передачи структурированных инструкций агентам. Расширение действует только при явной поддержке обеих сторон и не изменяет минимальное ядро протокола.[7]

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

Типичная операция состоит из нескольких этапов:

  1. Хост создаёт клиент для выбранного сервера.
  2. Клиент при необходимости запрашивает описание возможностей сервера.
  3. Сервер возвращает доступный текущему пользователю каталог инструментов, ресурсов и шаблонов.
  4. Хост передаёт модели только те описания и данные, которые нужны для задачи.
  5. Модель выбирает инструмент и формирует его параметры либо приложение выбирает ресурс.
  6. Клиент отправляет JSON-RPC-запрос серверу.
  7. Сервер проверяет авторизацию и параметры, выполняет операцию и возвращает результат.
  8. Хост показывает результат пользователю или передаёт его модели как новое наблюдение агентного цикла.

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

Транспорт

Протокол определяет смысл сообщений отдельно от способа их доставки. Стандартная спецификация 2026-07-28 предусматривает два транспорта:[8]

  • stdio — клиент запускает локальный сервер как дочерний процесс и обменивается с ним строками JSON-RPC через стандартные потоки ввода и вывода;
  • Streamable HTTP — клиент отправляет каждое сообщение методом HTTP POST на единый адрес, а ответ получает как JSON либо как ограниченный данным запросом поток Server-Sent Events.

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

В ранних версиях MCP соединение начиналось с обмена initialize и могло хранить идентификатор сессии. Версия 2026-07-28 перешла к независимым запросам: сведения о версии, клиенте и возможностях помещаются в каждый запрос. Совместимые реализации могут распознавать старую сторону и переходить в режим предыдущей спецификации.[7]

MCP, API, вызов функций и RAG

MCP и API

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

MCP и вызов функций

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

MCP и RAG

RAG — архитектура поиска сведений и добавления найденных фрагментов в запрос к модели. MCP может предоставить ресурсы или поисковый инструмент для такого конвейера, но не определяет способ разбиения документов, построения индекса, ранжирования и генерации ответа. Одно приложение способно использовать MCP без RAG, RAG без MCP либо сочетать оба подхода.

Пример использования

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

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

Версии и развитие

Версия MCP обозначается датой выпуска спецификации. Первая публичная редакция появилась в ноябре 2024 года. В 2025 году протокол получил удалённый HTTP-транспорт, стандартизованную авторизацию, асинхронные операции и официальный реестр серверов. Редакция 2026-07-28, актуальная на ноябрь 2026 года, заменила сессионное ядро независимыми запросами, добавила маршрутизационные HTTP-заголовки, кэширование каталогов, формальную систему расширений и усиленную схему авторизации.[7]

Изменения 2026 года несовместимы с частью прежней модели обмена, поэтому экосистема поддерживает переходный период. Клиенты и серверы указывают версию протокола и могут реализовывать совместимость с редакцией 2025-11-25. Версия SDK и версия протокола при этом не равнозначны: библиотека может поддерживать несколько редакций спецификации.

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

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

Спецификация требует сохранять контроль за пользователем: приложение должно ясно показывать, какие серверы и инструменты подключены, какие данные передаются и какое действие будет выполнено. Описания инструментов и аннотации считаются недоверенными, пока сервер не признан доверенным. Для операций с последствиями интерфейс должен позволять отклонить вызов.[1]

Для удалённых HTTP-серверов предусмотрена авторизация на основе OAuth 2.1. Сервер действует как защищённый ресурс, клиент запрашивает только необходимые области доступа, а выдачей токена занимается сервер авторизации. Передача серверу токена, выпущенного для другого ресурса, запрещена: такой подход нарушает границы доверия и затрудняет аудит.[9]

Основные меры защиты включают:

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

Документация MCP отдельно рассматривает атаки «запутавшегося посредника», подмену адресов авторизации, SSRF, перехват состояния, небезопасную передачу токенов и компрометацию локального сервера.[10]

Распространённые вопросы

MCP работает только с Claude?

Нет. Протокол создан в Anthropic, но опубликован как открытый стандарт и передан в независимый фонд. Совместимый клиент или сервер можно реализовать для любого ИИ-приложения и любой модели.

MCP-сервер обязательно находится в интернете?

Нет. Локальные серверы обычно запускаются через stdio как дочерние процессы. Удалённые серверы используют Streamable HTTP.

MCP даёт модели прямой доступ ко всем данным?

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

Нужно ли создавать отдельный MCP-сервер для каждого сервиса?

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

См. также

Примечания

  1. ↑ 1,0 1,1 1,2 Model Context Protocol Specification 2026-07-28 (англ.). Model Context Protocol (28 июля 2026). Дата обращения: 13 ноября 2026.
  2. ↑ Introducing the Model Context Protocol (англ.). Anthropic (25 ноября 2024). Дата обращения: 13 ноября 2026.
  3. ↑ Donating the Model Context Protocol and establishing the Agentic AI Foundation (англ.). Anthropic (9 декабря 2025). Дата обращения: 13 ноября 2026.
  4. ↑ Architecture (англ.). Model Context Protocol (28 июля 2026). Дата обращения: 13 ноября 2026.
  5. ↑ Tools (англ.). Model Context Protocol (28 июля 2026). Дата обращения: 13 ноября 2026.
  6. ↑ Resources (англ.). Model Context Protocol (28 июля 2026). Дата обращения: 13 ноября 2026.
  7. ↑ 7,0 7,1 7,2 The 2026-07-28 Specification (англ.). Model Context Protocol Blog (28 июля 2026). Дата обращения: 13 ноября 2026.
  8. ↑ Transports overview (англ.). Model Context Protocol (28 июля 2026). Дата обращения: 13 ноября 2026.
  9. ↑ Authorization (англ.). Model Context Protocol (28 июля 2026). Дата обращения: 13 ноября 2026.
  10. ↑ Security Best Practices (англ.). Model Context Protocol (28 июля 2026). Дата обращения: 13 ноября 2026.

Ссылки

Источник — https://ru.wikijournal.org/w-wiki/index.php?title=Model_Context_Protocol&oldid=16740