Что такое MCP? Полное руководство 2026: Model Context Protocol, JSON-RPC, AI-агенты и вызов инструментов

Что такое MCP: не модель — протокол для инструментов

Минимум — три стороны: Host (редактор или процесс агента), Client (сторона в Host, которая говорит с серверами), Server (процесс или HTTPS-эндпоинт с инструментами, ресурсами и промптами). Client запрашивает каталог, вставляет name, description и inputSchema в контекст и после решения модели шлёт tools/call. MCP правит обнаружением и формой вызова. Не тем, как модель думает.

«ИИ-плагин» верно лишь наполовину. Плагин браузера висит на одном хозяине; MCP Server могут переиспользовать много клиентов — один поиск счетов отдаёт Cursor, Claude Desktop или вашему оркестратору. Разница не в «можно ли вызвать функцию», а в том, стандартизированы ли каталог и конверт вызова. Самодельный адаптер OpenAPI уже бьёт HTTP; второй Client значит писать адаптер снова. MCP складывает этот слой в протокол. Официальные понятия и спецификация:документация Model Context Protocol.

На линии времени: Anthropic открыл MCP в 2024; к концу 2025 протокол оказался под Agentic AI Foundation (AAIF) Linux Foundation. В 2026 хосты держат его как канал удалённых инструментов по умолчанию, не как демо. Версия протокола живёт в _meta запроса — 2026-07-28 значит «стороны согласны с этой семантикой», не «модель стала умнее». Чем это не чат-бот и не cron-workflow — вЧто такое AI Agent: нет цикла и нет проверяемой формы arguments — это просто чат; цикл по локальным функциям всё ещё может быть агентом — просто без стандартного удалённого каталога.

JSON-RPC 2.0: зачем этот конверт

MCP не изобрёл новый RPC. Каждое действие протокола сидит в конверте JSON-RPC 2.0: jsonrpc, id, method, params или error. Запрос и ответ делят id; уведомления могут его не нести. Шлюзам и логам так проще резать, чем свой потоковый кадр: сначала method, потом бизнес. Поля — вспецификации JSON-RPC 2.0.

method — глагол протокола, не имя вашей бизнес-функции. tools/list перечисляет, tools/call вызывает, resources/read читает. Бизнес-имя живёт в params.name, аргументы — в params.arguments. Писать searchInvoices как method — частая ошибка чтения: это ваш JSON-RPC-сервис, не MCP. Стандартный запрос каталога выглядит так:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

Конверт решает три вещи: мультиплекс (несколько id в полёте), классифицируемые ошибки (parse, нет метода, отказ бизнеса) и сменный транспорт (stdio-потомок или Streamable HTTP несут один и тот же JSON). Он не решает, верны ли arguments. Законный конверт JSON-RPC всё равно может отдать Server объект arguments без полей. Server сам парсит и проверяет по inputSchema.

Как AI-агент использует MCP: найти → выбрать → вызвать

Снимите демо-видео: цикл агента на MCP по-прежнему из пяти шагов. Меняется то, что шаги 2 и 4 больше не приклеены к локальным функциям:

1. Цель пользователя попадает в контекст (естественный язык + опциональные системные ограничения).
2. Client шлёт tools/list каждому подключённому MCP Server и превращает каталог в tools / functions, которые модель умеет читать.
3. Модель возвращает tool_calls (функция + arguments) или финальный текст / Structured Output.
4. Runtime делает JSON.parse arguments, шлёт MCP tools/call и пишет result в сообщения.
5. Модель читает результат и выбирает следующий инструмент или стоп. maxSteps, отмена или провал Schema тоже останавливают.

Запрос MCP на шаге 4 выглядит так. params.arguments уже объект, не строка. Версию протокола можно повесить на _meta, чтобы stateless-маршрутизация могла читать:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "searchInvoices",
    "arguments": {
      "startDate": "2026-01-01",
      "endDate": "2026-01-31",
      "status": "paid"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

Агент не зависит от MCP. Локальные функции, OpenAPI и свой HTTP годятся как инструменты. Ценность MCP: один Server находят многие Hosts, с тем же каталогом и формой вызова удалённо. Критерий внедрения — «второй Client переиспользует этот набор», не «похоже на 2026». Инженерное определение цикла — вкак работает AI Agent.

Вызов инструментов модели: tool_calls и tools/call

Инженерно tool calling и function calling — один механизм: модель не трогает базу; она шлёт структурированную просьбу «вызовите эту функцию с этими arguments». MCP — следующий hop: runtime переводит это в JSON-RPC tools/call. Имена полей двух hops постоянно смешивают:

Когда модель вызывает, типичный tool_calls выглядит так. arguments всё ещё строка. Runtime сначала парсит, потом кладёт объект в MCP params.arguments. Не пихайте строку сырьём в JSON-RPC — получится «строковое поле с именем arguments», и Schema Server упадёт сразу.

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "arguments": "{\"startDate\":\"2026-01-01\",\"endDate\":\"2026-01-31\",\"status\":\"paid\"}"
  }
}

Оболочки вендоров разные: OpenAI tools[].function.parameters, Anthropic input_schema, Gemini function_declarations. MCP — Tool.inputSchema. Имена разные; каноническая Schema должна быть одним файлом. Как поля стыкуются и почему в strict каждое property должно быть в required — вMCP и JSON Schema. Финальный ответ идёт через Structured Output — не делите этот файл с входами инструмента.

Карта 2026: локально, удалённо, без состояния, A2A

Два главных транспорта. Локальный stdio: Host поднимает дочерний процесс, JSON-RPC едет по stdin/stdout — локальная ФС или локальная БД. Удалённый Streamable HTTP: Client POSTит тот же конверт на HTTPS-эндпоинт — общие счета, тикеты, внутренние API. Удалённость больше не значит «рукопожатие, потом Session ID». Около 2026-07-28 запросы стараются быть самоописываемыми, чтобы шлюз лимитировал по method.

Без состояния — слой протокола: любой инстанс берёт любой запрос. У приложения по-прежнему БД, ключи идемпотентности и личность. Читать «протокол без состояния» как «инструменты не надо проверять» — наоборот: без кэша сессии нельзя считать живым tools/list прошлого хода. Протухший каталог пишет неверную форму в tools/call. Детали:stateless MCP и JSON-RPC.

MCP также не протокол нескольких агентов. Планировщик, который отдаёт ценообразованию, комплаенсу и логистике, идёт через A2A message/send, не tools/call. Каждый специалист внутри может по-прежнему звать MCP к своей базе. «Война протоколов» обычно неверный кадр: один слой к инструментам, другой к агентам. СравнениеA2A vs MCP. Спека и реализации — вMCP GitHub; версии смотрите в репозитории спецификации, не в блоге одного Host.

Проверка на земле и JSONVue

Каждый hop: parse → Schema → бизнес-правила. Законный конверт MCP не делает arguments законными. Умная модель эти три шага не заменяет.

1. Строка arguments модели: JSON.parse; при провале записать raw + tool_call id и вернуть retryable конверт — downstream ещё не бить.
2. Проверить по inputSchema / parameters (Draft 2020-12); выдать path и keyword.
3. Бизнес-ворота: диапазон дат, enum vs права, внешние ключи. Только потом Server бьёт downstream API.

Поставьте рядом три JSON: arguments модели, params.arguments в MCP, объект, который Server реально использовал. Расхождение почти всегда в адаптере. В браузере:форматтер JSON для parse;Валидатор JSON Schema для arguments vs файла Schema;JSON Diff для arguments модели vs body MCP / HTTP. Фикстуры valid / missing-field / wrong-enum — общие для CI и ручной отладки.

Дальше: Что такое AI Agent, MCP и JSON Schema, Stateless MCP, A2A vs MCP.

FAQ

Итог и следующие шаги

MCP в 2026: находить и вызывать инструменты по JSON-RPC, писать результаты обратно в контекст модели. Это не модель, не агент и не A2A. Tool calling правит выбором функции; MCP — поиском и удалённым вызовом; JSON Schema — формой каждого hop.

Дальше: перечислите три JSON (arguments модели, MCP params.arguments, downstream body) и проверьте общую Schema; прогоните valid / нет поля / неверный enum в JSONVue. Протокол — в статье stateless MCP; поля — в статье Schema; несколько агентов — в сравнении A2A.