Основы MCP: хосты, клиенты, серверы и формат передачи данных JSON-RPC
Узнайте, почему существует протокол Model Context Protocol, как хосты, клиенты и серверы делят работу между собой, как выглядят сообщения JSON-RPC и в чём различия между транспортами stdio и HTTP.
Источники: Beyond the Noise: How MCP Unlocks the Real Value of LLMs
Языковые модели стали по-настоящему полезными для бизнеса в тот момент, когда они смогли выполнять действия, а не просто отвечать. Сама модель никогда не была сложной частью; проблема заключалась в подключении её к базам данных, API и внутренним инструментам, где фактически происходит работа, причём это подключение должно было осуществляться один раз, а не каждый раз при использовании отдельного приложения или у поставщика модели. Протокол контекста модели (MCP) представляет собой попытку стандартизировать такое подключение. В этой статье объясняется проблема, которую решает MCP, функции его компонентов, что передаётся по каналу связи, а также в чём различия между двумя стандартными способами передачи данных, чтобы вы могли определить, какое место займёт сервер MCP в вашей собственной архитектуре.
Где большие языковые модели создают ценность: выполнение действий
Раньше большая часть автоматизации была недоступна просто потому, что программное обеспечение не могло интерпретировать запросы с размытой структурой. Модели языка устраняют этот барьер, и после подключения к инструментам они могут управлять многоэтапными рабочими процессами, которые ранее требовали вмешательства человека для перехода между системами.
Возьмем в пример ассистента, которому нужно найти и забронировать поезд из Касабланки в Рабат. Понимание запроса — это лишь первый шаг. Ассистент должен найти информацию о расписании поездов, выбрать время отправления, вызвать API для бронирования и подтвердить результат. Каждый из этих шагов представляет собой вызов инструмента. Когда инструменты предоставляются через сервер MCP, любой совместимый агент может выполнить весь процесс.
Практическая польза очевидна: меньшее количество ручных операций за задачу приводит к снижению операционных затрат и ускорению выполнения работ. Есть также аргументы, связанные с пользовательским опытом. Сотрудники постоянно работают с множеством панелей управления и интерфейсов, каждый из которых имеет собственную логику. Беседующий интерфейс, связанный с этими внутренними системами, может скрыть большую часть этой сложности за одним интерфейсом.
Проблема интеграции, которую решает MCP
Использование инструментов — не новость. Все крупные SDK для LLM поддерживают их, но каждое делает это с собственными правилами объявления инструмента, описания параметров и возврата результатов. Практический результат заключается в том, что один и тот же инструмент реализуется несколько раз, по одному разу для каждого поставщика моделей. Смена моделей или одновременная поддержка нескольких моделей требует переноса кода интеграции, что замедляет работу команд и затрудняет масштабирование продуктов.
Игнорирование SDK не решает эту проблему полностью. Вы можете написать собственный слой интеграции, который будет соотносить намерения с действиями, вызывать конечные точки, собирать параметры, обрабатывать ошибки и вести аналитику. Это добавляет сложности, но с этим можно справиться. Более глубокая проблема заключается в том, что такой слой обычно находится внутри одного приложения. Когда другому приложению нужны те же инструменты, команда снова создает этот слой заново. Логика интеграции связана с конкретным приложением-потребителем, а не с системой, обладающей соответствующими возможностями.
Что такое MCP
MCP — это открытый стандарт, который предоставляет ИИ-приложениям единый способ подключения к источникам данных и инструментам. Он не позволяет делать того, что раньше было абсолютно невозможно; он делает такие подключения проще и более последовательными. Официальным источником информации является документация протокола на modelcontextprotocol.io.
Ключевое изменение касается местоположения логики инструментов. С помощью MCP сервис бэкенда, такой как база данных, API или внутренний инструмент, публикует свои возможности через сервер MCP. Часто используется аналогия с портом USB-C: сервис предоставляет стандартный разъем, в который может подключаться любое совместимое приложение. Приложение ИИ больше не содержит информации о том, как использовать каждый инструмент; ему достаточно просто соблюдать протокол.
Архитектура: хосты, клиенты и серверы
MCP использует архитектуру клиент-сервер с тремя ролями, которые легко путать:
- Хост: само приложение ИИ, например чат-ассистент, IDE с агентом или ваш собственный сервис агента. Именно с ним взаимодействует пользователь, и оно подключается к внешнему миру через один или несколько серверов MCP.
Хост никогда не общается напрямую с сервером. Он создает по одному клиенту на каждый сервер и передаёт ему всю коммуникацию; каждый клиент поддерживает отдельное однонародное соединение. Такое разделение полезно на практике: хост, подключённый к серверу файловой системы, серверу обработки тикетов и серверу CRM, запускает три независимых клиента, поэтому сбой или ограничение прав на одном соединении не влияет на остальные.
Три примитива сервера
Примитивы определяют, что может предложить каждая сторона. Сервер предоставляет три основных вида примитивов:
- Инструменты: операции, которые может выполнять модель, такие как вызов API или запись данных.
- Ресурсы: данные, которые модель может читать и использовать в качестве контекста, такие как строки базы данных или документы.
- Инструкции: заранее определенные шаблоны команд, которые направляют действия модели; по сути они аналогичны многократно используемым системным инструкциям.
Различие между инструментами и ресурсами имеет значение с точки зрения безопасности и проектирования. Чтение ресурса не должно вызывать побочных эффектов, тогда как использование инструмента может изменить ситуацию в окружении, поэтому хосты часто применяют разные правила одобрения к каждому из них.
JSON и JSON-RPC: формат сообщений
JSON (JavaScript Object Notation) представляет структурированные данные в виде текста, состоящего из пар ключ-значение, массивов и вложенных объектов. Благодаря простоте формата и его универсальной поддержке отправитель и получатель, написанные на разных языках, могут договориться о значении сообщения.
JSON-RPC развивает эту концепцию, определяя фиксированную структуру сообщений для удаленных вызовов процедур. Запрос содержит название метода, параметры и идентификатор; если обе стороны соблюдают эту структуру, клиент может попросить сервер выполнить метод и получить результат или сообщение об ошибке в таком же предсказуемом формате. Приведенный ниже пример — запрос JSON-RPC 2.0 с просьбой к серверу выполнить поиск погоды для Касабланки. Обратите внимание на четыре поля: версию протокола, идентификатор запроса id, используемый для сопоставления с ответом, название method и объект params.
{
"jsonrpc": "2.0",
"id": 1,
"method": "get_weather",
"params": {
"city": "Casablanca"
}
}
Этот пример иллюстрирует простой формат JSON-RPC. В самом MCP инструменты не вызываются как методы верхнего уровня, названные в соответствии с именем инструмента. Вместо этого клиент отправляет запрос с методом tools/call, в котором имя инструмента и его аргументы указываются в поле params. Именно такая косвенность позволяет MCP определять фиксированный набор методов протокола, в то время как серверы могут свободно предоставлять любые инструменты, которые им нужны.
Отсутствующим элементом является механизм обнаружения
JSON-RPC сам по себе оставляет одну проблему нерешенной: клиент должен заранее знать, какие методы предлагает сервер. MCP устраняет этот недостаток, стандартизируя способы, с помощью которых клиенты обнаруживают возможности сервера. Клиент может попросить сервер перечислить его инструменты, ресурсы и шаблоны ввода, получить их названия, описания и схемы входных данных, а затем передать эти описания модели. MCP также определяет, как инициализируется соединение и какие механизмы передачи данных используются для передачи сообщений.
Механизмы передачи данных: как передаются сообщения
JSON-RPC определяет словарный запас; механизм передачи данных определяет, как байты перемещаются между клиентом и сервером. На момент написания документации MCP определяет два стандартных механизма передачи данных. Перед тем как полагаться на конкретные детали, проверьте актуальную спецификацию, поскольку протокол продолжает развиваться.
stdio для локальных инструментов
При использовании транспорта stdio клиент запускает сервер MCP в качестве дочернего процесса. Сервер считывает входящие сообщения из своего стандартного ввода и записывает ответы в свой стандартный вывод. Каждый процесс автоматически получает эти трубопроводы от операционной системы, поэтому не требуются сетевые сокеты или порты.
Это делает stdio подходящим решением для инструментов, работающих на том же компьютере, что и хост, например для сервера, создающего папки в локальной файловой системе. Дополнительным преимуществом является изоляция: сервер существует только до тех пор, пока хост его запущен, и к нему невозможно получить доступ из сети.
Streamable HTTP для общедоступных удаленных серверов
При использовании Streamable HTTP сервер представляет собой независимый процесс, работающий в качестве HTTP-сервиса, и может обслуживать множество клиентов одновременно. Сообщения обмениваются с помощью обычных HTTP-запросов.
Этот способ передачи данных позволяет использовать стриминг. Вместо ожидания полного ответа сервер может постепенно отправлять данные, что особенно полезно для длительных запросов к инструментам. Стриминг реализуется с помощью Server-Sent Events (SSE) — однонаправленного канала, в котором один длительный HTTP-ответ содержит последовательность событий, отправляемых сервером. Трафик в обратном направлении по-прежнему передается в виде обычных HTTP-запросов от клиента. Конкретная работа этого механизма зависит от реализации и используемой версии HTTP.
Практическое правило: выбирайте stdio, когда инструмент работает на компьютере одного пользователя, а Streamable HTTP — когда необходимо делиться функционалом между пользователями или командами, с учетом механизмов аутентификации и сетевого контроля, требуемых для общедоступных сервисов.
Почему протокол важнее, чем другой SDK
Протоколы существуют для того, чтобы системы, созданные разными командами на разных языках и с разными графиками выпуска, могли всё равно предсказуемо взаимодействовать. Протокол — это согласованный набор правил, определяющих, как независимые компоненты обмениваются сообщениями, интерпретируют их и устанавливают взаимное доверие.
Ценность стандартизации доступа к инструментам в основном экономическая. Когда стоимость интеграции новой модели или приложения снижается почти до нуля, экспериментирование становится дешевым, а дешёвые эксперименты способствуют более быстрой итерации. Команда, управляющая системой, может опубликовать один сервер MCP, и каждое текущее и будущее ИИ-приложение в организации сможет им пользоваться без специально написанного кода-связки. Чтобы узнать, как это работает в рамках фреймворка агентов, прочитайте нашу статью о стандартизации интеграции инструментов в LangGraph с использованием MCP.
Основные выводы
- LLM приносят наибольшую пользу, когда могут взаимодействовать с реальными системами, причем узким местом является интеграция, а не уровень интеллекта.
- Без стандарта один и тот же инструмент приходится переимплементировать для каждого SDK модели и каждого приложения; MCP переносит эту логику на сервер, принадлежащий системе, обеспечивающей соответствующие возможности.
- На одном хосте запускается по одному клиенту на каждый сервер, причем каждый клиент поддерживает отдельное соединение; серверы предоставляют инструменты, ресурсы и команды.
- JSON-RPC определяет формат сообщений, в то время как MCP добавляет фиксированный набор методов, таких как
tools/call, а также механизм обнаружения возможностей. - Для локальных инструментов с одним пользователем используйте stdio, а для общедоступных удаленных сервисов — Streamable HTTP; проверяйте детали транспортировки в соответствии с текущей спецификацией.