MCP

Этот блок объясняет, как инструмент другой команды попадает к вашему агенту через Model Context Protocol (MCP), как выглядит текущая версия протокола и что он оставляет на вас с точки зрения безопасности.

Два одинаковых бланка на все отделы

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

Потом все отделы договариваются о двух бланках. Один спрашивает «что вы умеете?», другой говорит «сделайте, пожалуйста, вот это». Первый бланк каждый отдел заполняет сам, а вы зачитываете ответы коллеге.

У Northwind три агента, и всем нужны одни и те же три сервиса. Без общего формата на каждую пару нужен свой адаптер.

MCP — это такая пара бланков, записанная сообщениями JSON-RPC 2.0. API сервиса остаётся на месте. Здесь сервер MCP — это адаптер перед ним, и любое приложение, которое говорит по MCP, может им пользоваться без кода под этот сервер.

Кто что делает

• Хост (host) — это ваше приложение. Оно ведёт разговор и обращается к модели.
• Клиент (client) — это соединитель внутри хоста. Он держит одно соединение с одним сервером, поэтому у хоста с четырьмя серверами четыре объекта клиента, и все из одного кода.
• Сервер (server) — это программа, которая предлагает возможности. Она может работать на той же машине или удалённо.

Модель в протоколе не участвует и соединений не открывает. Вот один запрос статуса посылки:

1. Ваше приложение отправляет tools/list, и сервер доставки отвечает своими определениями.
2. Приложение копирует их в поле tools запроса к модели. В MCP схема называется inputSchema, а в API Anthropic — input_schema, поэтому приложение её переименовывает.
3. Модель отвечает блоком tool_use для track_parcel.
4. Приложение проводит свои проверки и отправляет tools/call.
5. Сервер делает работу и возвращает результат. Приложение заворачивает его в tool_result, и цикл из прошлых блоков продолжается.

На шаге 2 нужна осторожность с именами. Имя инструмента уникально только внутри одного сервера, так что у двух серверов может быть по search, и спецификация говорит, что клиентам следует различать их, например приставкой с именем сервера. Приставку лучше задавать в самом хосте: спецификация предупреждает, что собственное name сервера не обязано быть уникальным. Ещё MCP разрешает точку в имени, а API Anthropic нет. Поэтому хост Northwind показывает модели shipping__track_parcel, заменяет точки на подчёркивания и убирает приставку перед вызовом сервера.

Шаг 4 в текущей редакции выглядит так:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "track_parcel",
    "arguments": {
      "order_id": "4417"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

И ответ:

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "4417: курьер в пути"
      }
    ],
    "isError": false
  }
}

Кроме инструментов, у серверов есть и другое. Инструменты (tools) — это функции, которые запускает модель, ресурсы (resources) — данные для пользователя или модели, а промпты (prompts) — шаблоны сообщений для пользователя. В обратную сторону клиент может предложить elicitation: сервер спрашивает у пользователя нужные сведения.

Сообщения идут по одному из двух стандартных транспортов. В stdio клиент запускает сервер как дочерний процесс, и они обмениваются строками через его стандартные потоки. В Streamable HTTP каждое сообщение — это POST на один адрес. Более старый транспорт HTTP+SSE объявлен устаревшим.

О какой версии вы читаете

На 2026-11-10 текущая редакция — 2026-07-28, и она изменила основу протокола. Статьи и примеры SDK, написанные раньше, описывают рукопожатие слева.

Устаревший не значит удалённый, но новым реализациям брать эти функции не следует. Вместо Roots спецификация предлагает параметры инструмента, URI ресурсов или настройки сервера. Elicitation остаётся в силе, а Roots, Sampling и Logging могут исчезнуть не раньше первой редакции, вышедшей 2027-07-28 или позже.

Сами по себе эти две эпохи не совмещаются. Клиент, который знает только новую редакцию, не сможет работать с сервером, знающим только рукопожатие, и наоборот. Реализация, которой нужны обе, поддерживает обе, и спецификация называет это dual-era.

Что MCP оставляет вам

Спецификация прямо говорит, что MCP не может обеспечить свои принципы безопасности на уровне протокола. Эта работа лежит на вашем хосте и на сервисе.

• Описания инструментов — это текст от сервера, и он попадает к модели. Об этом следующий блок.
• Сервер — это чужой код. Сервер на stdio — это локальная программа, и сам по себе stdio не ограничивает, что она читает и куда отправляет.
• Длинные списки инструментов съедают окно контекста. В примере Anthropic пять серверов и 58 инструментов занимают около 55 000 токенов ещё до начала разговора.

Правило из блока про возвраты остаётся в силе: customer_id не попадает в arguments. Авторизация в MCP необязательна. Если сервер на Streamable HTTP её использует, токен идёт с каждым запросом, и сервер берёт личность из него.

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

Вывод

• Сервер MCP — это адаптер перед сервисом: tools/list, чтобы узнать, что есть, tools/call, чтобы запустить, а между моделью и сервером стоит ваше приложение.
• Проверяйте редакцию. В 2026-07-28 рукопожатия нет, и каждый запрос несёт свою версию и возможности клиента.
• Протокол не делает сервер безопасным. Это задача вашего хоста и сервиса.

Глубже