Что такое MCP? Model Context Protocol, JSON-RPC, ИИ-агенты и вызов инструментов

Сразу к делу: MCP (Model Context Protocol) — это не другое имя для Function Calling и не модель. Это открытый протокол между AI-приложением (Host) и внешними процессами инструментов (MCP Server). Сообщения — JSON-RPC 2.0. Модель по-прежнему говорит на Tool Calling / Function Calling своего вендора. Host переводит tools/list в массив tools модели, затем переводит tool_calls в tools/call. Эти три слоя вместе — так большинство агентов 2026 года вызывают инструменты.

Статья датирована 7 сентября 2026. Актуальная спецификация — 2026-07-28: нет протокольной сессии, нет рукопожатия initialize, каждый запрос несёт _meta, обнаружение возможностей идёт через server/discover. Наша августовская статья поток данных Agent JSON всё ещё показывает старый пример initialize; эту статью считайте актуальным чтением. Вопрос «нужно ли менять код Server?» — в гайде миграции MCP 2026.

Что такое MCP

Model Context Protocol — открытый стандарт того, как AI-приложения обнаруживают, читают и вызывают внешний контекст. Anthropic выпустил его в ноябре 2024; управление позже перешло к Agentic AI Foundation. Он задаёт, как обмениваться контекстом. Он не задаёт, какую модель вы берёте, как оркестрируете многошагового агента и как пишете бизнес-логику.

Думайте про USB-C: розетка стандартная; диск, монитор или блок питания за ней — вне скоупа. MCP стандартизирует розетку Host ↔ Server. Файловая система, GitHub, внутренний API заказов или JSON-валидатор вроде этого сайта — всё это просто Server.

Два слоя: слой данных — JSON-RPC 2.0 (методы, params, коды ошибок, уведомления); транспортный слой — как эти JSON-кадры едут: stdio на той же машине, Streamable HTTP удалённо. Меняете транспорт — форма сообщения остаётся. Поэтому отладка MCP начинается с разделения: «конверт — JSON-RPC; бизнес-полезная нагрузка часто тоже JSON».

Host, Client, Server

Треугольник спецификации легко спутать с бытовым «клиент / сервер»:

• Host: AI-приложение, которое открыл пользователь. Создаёт Client, скармливает модели схемы инструментов, авторизует и валидирует до исполнения, пишет результаты обратно в тред.
• Client: один объект соединения внутри Host. Один Server — один Client. VS Code, говорящий с файловой системой и с Sentry, в рантайме — это два Client.
• Server: программа, которая отдаёт контекст. Может делить машину с Host (stdio) или жить в другом месте (Streamable HTTP). «Server» — роль, не требование публичного hostname.

Модели в этом треугольнике нет. GPT-5.5, Claude 4.8 и Gemini 3.7 видят переведённый Host массив tools. Они не видят JSON-RPC и не видят Mcp-Session-Id (заголовок сессии убран в 2026-07-28). «Модель говорит на MCP» — маркетинг. В инженерии посередине всегда Host.

Как читать JSON-RPC 2.0

JSON-RPC — соглашение об удалённых вызовах процедур через JSON: ближе к «вызвать функцию», чем REST. MCP выбрал его, потому что имена методов стабильны (tools/list, tools/call), деление request / response / notification чистое, и весь конверт — дружелюбный для модели JSON.

Вызов tools/call по спецификации 2026-07-28 выглядит так. Заметьте: нет рукопожатия, нет заголовка сессии. Версия и идентичность клиента живут в _meta — любой экземпляр Server может обработать этот кадр.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "validate_json",
    "arguments": {
      "payload": {"orderId": "A-1001", "total": 42.5},
      "schemaId": "order.v1"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "json-toolbox-host",
        "version": "1.0.0"
      }
    }
  }
}

Успешный ответ — тот же конверт. Бизнес-результат лежит в result.content, часто type: "text", и этот текст сам может быть JSON-строкой — протокол снаружи, полезная нагрузка внутри. При отладке сначала сопоставьте id с запросом, затем проверьте внутренний объект по Schema.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "{\"valid\":true,\"schemaId\":\"order.v1\"}"
      }
    ]
  }
}

Ошибки идут через объект JSON-RPC error: code, message, опционально data. 2026-07-28 сменил «ресурс не найден» с MCP-специфичного -32002 на стандартный -32602 (Invalid Params). Клиенты, которые сравнивают со старым литералом, промахнутся. У уведомлений нет id, ответа они не ждут — например, смена списка инструментов.

Tools, Resources, Prompts

Server может открыть три примитива. Агенты живут на Tools; остальные два легко пропустить — и часто экономят раунд гадания модели.

Инструмент — это name, description и inputSchema. inputSchema — JSON Schema (2020-12 с 2026-07-28; корень по-прежнему должен быть type: "object"; oneOf / $ref / $defs разрешены). Опциональный outputSchema ограничивает форму возврата. Host почти 1:1 копирует inputSchema в parameters / input_schema API модели.

{
  "name": "validate_json",
  "title": "Validate JSON",
  "description": "Check a JSON payload against a named schema. Returns valid and errors.",
  "inputSchema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "payload": { "type": "object", "description": "Already parsed JSON object, not a raw string" },
      "schemaId": { "type": "string", "description": "Stable schema id such as order.v1" }
    },
    "required": ["payload", "schemaId"]
  }
}

Resources подходят для схемы «прочитай, потом думай»: загрузить schema://order.v1 дешевле, чем заставлять модель запоминать 200-строчную схему в треде. Prompts — для заготовленных зачинов команды. Roots, Sampling и Logging объявлены deprecated в 2026-07-28: пути рабочей области передавайте как аргументы инструмента или URI ресурса; Server не должен просить у Host completion; логи — в stderr или OpenTelemetry.

Как это стыкуется с Tool Calling

Три имени сплющивают в одно. Это не один слой — статья о потоке данных Agent JSON проходит каждый хоп. Здесь только маппинг:

Function Calling — раннее имя OpenAI; Tool Calling — более позднее общее (Claude tools, Gemini Function Calling, OpenAI Tools API). Для разработчика это один поток: Host шлёт Schema, модель возвращает вызов с JSON-аргументами, Host исполняет, затем засовывает JSON-результат обратно в тред.

MCP этот слой не заменяет. Host, который вызывает функции в том же процессе только через Tool Calling, по-прежнему валиден. MCP делает инструменты обнаруживаемыми, межпроцессными и переиспользуемыми между Host. Корпоративные агенты почти всегда кладут оба слоя; скрипты и демо часто обходятся без MCP.

Две ловушки маппинга: API моделей часто отдают arguments строкой; MCP params.arguments — это объект. И name из tools/list должен дойти до модели и tools/call без изменений — не выдумывайте «более дружелюбный» алиас посередине. Валидируйте до настоящего tools/call; см. Tool Calling и валидация JSON Schema.

Один полный вызов инструмента

Пользователь говорит: «Проверь этот JSON заказа по order.v1.» По 2026-07-28 путь такой:

1. Host → Server: server/discover (кэшируемо), чтобы подтвердить tools; или шлите следующий запрос и повторите при ошибке версии.
2. Host → Server: tools/list возвращает элементы с inputSchema; результат может нести ttlMs / cacheScope.
3. Host → модель: смапьте список в tools[].parameters (всё ещё JSON Schema).
4. Модель → Host: tool_calls с name validate_json; arguments часто — сериализованный JSON.
5. Host валидирует: JSON.parse, затем проверка inputSchema. При провале запишите ошибку как результат инструмента — настоящий Server не трогайте.
6. Host → Server: tools/call с объектными arguments и версией протокола в _meta.
7. Server → Host: result.content; Host может ещё раз проверить outputSchema.
8. Host → модель: JSON-строка с role: tool; модель отвечает пользователю или начинает следующий ход инструмента.

User natural language
    │
    ▼
Host ──JSON Schema──► LLM Tool Calling
    │                      │
    │                      ▼
    │                 arguments JSON
    ▼                      │
MCP JSON-RPC ◄──── tools/call only after validation
    │
    ▼
result JSON ──► tool message ──► model’s final answer

На удалённом транспорте HTTP-заголовки должны включать MCP-Protocol-Version, Mcp-Method и Mcp-Name, и должны совпадать с телом, иначе Server должен отклонить. Балансировщики могут маршрутизировать по заголовкам, не разбирая JSON. У локального stdio этих заголовков нет; имена методов JSON-RPC те же.

Что запомнить из 2026-07-28

Июльская спецификация — крупнейшая ревизия с запуска, и 28 июля 2026 — дата финальной публикации. Для «что такое MCP» держите список ниже. Нужны ли правки кода Server — по-прежнему дерево решений из статьи о миграции.

• Нет рукопожатия, нет протокольной сессии: initialize / initialized и Mcp-Session-Id убраны. Каждый запрос самодостаточен. Состояние приложения сшивайте явным basket_id (или аналогом) как обычным аргументом. Не ждите, что транспорт вас запомнит.
• Обнаружение — server/discover: опционально, но один вызов возвращает поддерживаемые версии, capabilities и serverInfo. Результаты списков несут ttlMs; длинный SSE-поток больше не единственный способ узнать, что инструменты изменились.
• Схемы — JSON Schema 2020-12: корень входа остаётся object; композиция и refs разрешены; не разыменовывайте внешние $ref автоматически. Выходные схемы больше не только object.
• Roots / Sampling / Logging объявлены deprecated: методы ещё работают в годовом окне. Новые Server не должны реализовывать Sampling, чтобы просить у Host completion.
• Extensions: Tasks и MCP Apps — официальные расширения, не обязательное ядро. Долгая работа — через task handle + tasks/get. Не изобретайте свою сессию.

Host и Server, которые ещё на 2025-11-25, продолжают использовать initialize. Когда версии смешаны, берите согласованный protocolVersion. Не отправляйте бессессионные кадры из этой статьи старому Server. Что ставить — см. рейтинг MCP Server 2026.

Что делать сейчас

1. Нарисуйте три слоя до кода: Tool Calling API модели, оркестрация Host, MCP Server. Скрипты могут остановиться на первых двух. Переиспользование между IDE — момент писать Server.
2. Берите официальный SDK; не собирайте кадры JSON-RPC руками: @modelcontextprotocol/sdk и остальные официальные пакеты уже закрывают обнаружение, транспорт и коды ошибок. Рукописный SSE или приватные поля — типичный кейс «надо менять код» в гайде миграции.
3. Пишите inputSchema как контракт, который можно валидировать отдельно: additionalProperties: false, required, enum, лимиты длины. Модели пропускают поля и превращают числа в строки. Заблокируйте один раз той же схемой до исполнения.
4. stdio локально, Streamable HTTP удалённо: личная отладка не требует HTTP. Общий доступ команды, много клиентов или шлюз — тогда уходите на удалённый транспорт, плюс OAuth и минимальные привилегии.
5. Кэшируйте списки, обрезайте результаты: соблюдайте ttlMs. Не заливайте сырые стеки обратно в модель. Большее окно не делает грязный JSON безопасным — см. окна контекста на 1M токенов.
6. Проверьте фикстуры в браузере до живого Server: сохраните inputSchema, хорошие / плохие arguments и образцы ответов Server как JSON; проверьте и Diff на этом сайте. Ничего не загружается. Та же привычка, что тестировать REST-контракт.

FAQ

Итоги

MCP — розетка инструментов агента 2026: JSON-RPC 2.0 возит обнаружение и вызов между Host и Server; на стороне модели по-прежнему Tool Calling; JSON Schema — общий контракт. Это не модель, не фреймворк и не замена OpenAPI. Спецификация 2026-07-28 убрала сессии из протокола, поэтому запросы должны быть самодостаточными. Три примитива — Tools, Resources, Prompts — не изменились.

Этот гайд — только про слои. Форма байтов на каждом хопе — в статье о потоке данных; нужно ли менять код старого Server — в статье о миграции; какие Server ставить — в рейтинге. Прежде чем подключать живое, проверьте Schema и образцы JSON локально — модели можно менять; имена полей и required двигаться не должны.