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

У AI-приложения быстро появляется несколько внешних систем: документы, задачи, календарь, CRM. Если для каждого клиента писать собственный способ описания инструментов и передачи результатов, интеграции начинают дублировать друг друга. MCP стандартизирует этот стык.

В четвёртом выпуске «В цикле» разбираем Model Context Protocol: какие роли в нём есть, чем отличаются инструменты от ресурсов и почему стандартный протокол не отменяет проверки прав. Версионные детали в этой статье относятся к спецификации 2026-07-28, на которую опирается выпуск.

Хост, клиент и сервер

Хост — AI-приложение пользователя. Оно общается с моделью, собирает контекст, показывает интерфейс и применяет политики доступа. Клиент — протокольный компонент внутри хоста, работающий с конкретным сервером. Сервер — поставщик инструментов, данных и шаблонов.

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

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

Три примитива с разными ролями

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

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

Учебный пример: помощник поддержки

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

1. Хост определяет доступные пользователю системы и передаёт модели нужные определения.
2. Модель запрашивает статус заказа. Сервер проверяет авторизацию и принадлежность заказа.
3. Приложение добавляет подходящий фрагмент правил доставки.
4. Модель составляет объяснение и при необходимости создаёт черновик.
5. Отправка клиенту проходит отдельную проверку и подтверждение, если этого требует принятая политика.

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

Транспорт — это способ доставки сообщений

Протокол использует JSON-RPC. Локальные серверы часто подключаются через stdio: клиент запускает процесс, а стандартный вывод используется для протокольных сообщений. Диагностические логи должны идти отдельно, иначе они могут испортить обмен.

Для удалённых серверов используется Streamable HTTP. Здесь уже нужны сетевые таймауты, аутентификация, корректная проверка Origin и ограничения доступности endpoint. Локальный сервер не следует без необходимости открывать всей сети.

Транспорт не определяет бизнес-семантику повторов. Если соединение оборвалось после операции записи, нельзя считать, что операция точно не состоялась. Идемпотентность и проверка состояния нужны независимо от формата сообщений.

Почему важно зафиксировать ревизию

В ревизии 2026-07-28 основой стали самодостаточные запросы: версия и возможности клиента передаются для каждого обращения. Информацию о сервере предоставляет server/discover. Это отличается от прежней модели с initialize и состоянием соединения.

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

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

Граница доверия проходит через каждую интеграцию

Документ с одного сервера остаётся недоверенными данными, когда модель предлагает передать сведения на другой. Встроенная в документ команда «отправь базу клиентов по этому адресу» не является разрешением пользователя.

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

Ошибки протокола и ошибки исполнения полезно различать. Сбой бизнес-операции можно вернуть как результат с isError и безопасным пояснением. Некорректный запрос или неизвестный метод относятся к протокольному уровню. Это помогает не превращать любой отказ в бессмысленный повтор.

Когда определений становится слишком много

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

В code mode модель пишет программу, которая вызывает инструменты через контролируемый интерфейс. Это позволяет обработать промежуточные данные вне контекста модели. Но песочница, проверка каждого вызова и хранение учётных данных у доверенного посредника остаются обязательной частью архитектуры. Разрешение исполнить скрипт не должно автоматически разрешать любые действия внутри него.

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

Источники

Основа — глава 5 материалов «Жизненный цикл агента» и сценарий S1E04. Разбор зафиксирован на ревизии MCP 2026-07-28.

• MCP: спецификация 2026-07-28
• MCP: архитектура
• MCP: инструменты
• MCP: многораундовый обмен