Model Context Protocol: архитектура и основы

В предыдущем разделе мы разбирали механизмы расширения Claude Code — команды, навыки, субагенты, хуки. Все они работают внутри агентного цикла. MCP — это другой уровень: не расширение поведения агента, а стандартный канал связи между любым AI-приложением и внешним миром. Понять архитектуру протокола раз — значит уметь использовать любой MCP-сервер и писать собственные.

Откуда взялся MCP

Anthropіс анонсировал Model Context Protocol 25 ноября 2024 года как открытый стандарт с кодом на GitHub и готовыми SDK. Идея вышла из конкретной проблемы: каждая AI-интеграция требовала отдельной реализации под каждый инструмент. Хочешь подключить GitHub — пишешь адаптер под GitHub. Хочешь Postgres — пишешь другой. N инструментов × M AI-приложений = N×M пользовательских интеграций. Это не масштабируется.

MCP решает задачу так же, как USB-C решил проблему зарядных кабелей: один стандартный разъём — и любое устройство подходит к любому зарядному устройству. Написал MCP-сервер один раз — и он работает с Claude Code, VS Code Copilot, Cursor, ChatGPT и любым другим MCP-клиентом.

Важное следствие: MCP не принадлежит Claude Code. Anthropic создал спецификацию и первые SDK, но протокол открытый. VS Code, Cursor, OpenAI ChatGPT — всё это уже MCP-клиенты. Если вы напишете MCP-сервер для своей БД, он будет работать с любым из них без изменений.

Проверь себя

MCP создала Anthropic — значит, протокол привязан к Claude и работает только в Claude Code. Согласны? Почему да или нет?

Три роли в архитектуре

MCP разделяет участников на три роли:

MCP Host — AI-приложение целиком (Claude Code, Claude Desktop, VS Code). Координирует соединения, управляет жизненным циклом.

MCP Client — компонент внутри хоста, поддерживающий одно соединение с одним сервером. Хост создаёт отдельный клиент для каждого подключённого сервера. Claude Code с тремя подключёнными серверами — это один хост и три клиента.

MCP Server — программа, которая предоставляет инструменты, данные и шаблоны. Может работать локально (процесс на той же машине) или удалённо (на внешнем сервере).

graph TB subgraph Host["MCP Host (например, Claude Code)"] C1["MCP Client 1"] C2["MCP Client 2"] C3["MCP Client 3"] end S1["MCP Server\nФайловая система\n(локальный, stdio)"] S2["MCP Server\nPostgres\n(локальный, stdio)"] S3["MCP Server\nGitHub API\n(удалённый, HTTP)"] C1 -->|"выделенное соединение"| S1 C2 -->|"выделенное соединение"| S2 C3 -->|"выделенное соединение"| S3 style Host fill:#f0f4ff,stroke:#6b7cff

graph TB
    subgraph Host["MCP Host (например, Claude Code)"]
        C1["MCP Client 1"]
        C2["MCP Client 2"]
        C3["MCP Client 3"]
    end

    S1["MCP Server\nФайловая система\n(локальный, stdio)"]
    S2["MCP Server\nPostgres\n(локальный, stdio)"]
    S3["MCP Server\nGitHub API\n(удалённый, HTTP)"]

    C1 -->|"выделенное соединение"| S1
    C2 -->|"выделенное соединение"| S2
    C3 -->|"выделенное соединение"| S3

    style Host fill:#f0f4ff,stroke:#6b7cff

Хост создаёт отдельный клиент для каждого подключённого сервера; серверы могут быть локальными или удалёнными

Клиент и сервер общаются по протоколу JSON-RPC 2.0. Сначала происходит рукопожатие: клиент отправляет initialize с версией протокола и списком поддерживаемых возможностей, сервер отвечает своими. После этого клиент знает, чем сервер умеет торговать: инструменты, ресурсы, шаблоны — или только часть из них.

// Клиент → Сервер: инициализация
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "elicitation": {} },
    "clientInfo": { "name": "claude-code", "version": "1.0.0" }
  }
}

// Сервер → Клиент: ответ
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": {}
    },
    "serverInfo": { "name": "my-postgres-server", "version": "0.3.0" }
  }
}

Здесь "tools": { "listChanged": true } означает: «у меня есть инструменты, и я буду уведомлять тебя, если они изменятся». Клиент сохраняет эти возможности и использует только то, что сервер объявил.

Три примитива: tools, resources, prompts

Примитивы — главное понятие в MCP. Они определяют, чем сервер может поделиться с клиентом.

Tools (инструменты) — исполняемые функции. Клиент вызывает их через tools/call, сервер выполняет код и возвращает результат. Примеры: запрос к базе данных, вызов внешнего API, поиск в файловой системе. Это самый часто используемый примитив — именно он позволяет Claude Code «действовать» в реальном мире.

// Вызов инструмента
{ "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": { "sql": "SELECT * FROM users LIMIT 10" }
  }
}

Resources (ресурсы) — источники данных только для чтения. Это контекст: схема БД, содержимое файла, список задач из трекера. Ресурсы не выполняют действий — они отдают данные, которые AI использует для понимания ситуации. Идентифицируются через URI, перечисляются через resources/list, читаются через resources/read.

Prompts (шаблоны) — готовые шаблоны взаимодействия: системные промпты, few-shot примеры, заготовки для частых задач. Сервер может предложить их клиенту через prompts/list. Реже используются в Claude Code, но полезны для стандартизации обращений к специфическим инструментам.

Проверь себя

У вас есть MCP-сервер для Postgres. Claude Code хочет узнать, какие инструменты доступны. Что происходит первым — и какой метод используется?

Каждый примитив следует одному паттерну: */list для обнаружения, */get или */read для получения содержимого, tools/call для выполнения. Клиент всегда сначала спрашивает «что у тебя есть?», потом использует.

Два транспорта

Протокол не диктует, как именно клиент и сервер обмениваются байтами. Это дело транспортного слоя, и MCP поддерживает два варианта:

Stdio — стандартные потоки ввода-вывода. Хост запускает сервер как дочерний процесс и общается через stdin/stdout. Нет сетевого оверхеда, максимальная скорость, прямая изоляция процессов. Подходит для локальных серверов: файловая система, локальная БД, утилиты.

Streamable HTTP — HTTP POST для запросов от клиента, опционально Server-Sent Events для потоковых ответов от сервера. Поддерживает стандартные HTTP-механизмы аутентификации (bearer tokens, API keys). Для удалённых серверов MCP рекомендует OAuth. Подходит для облачных интеграций: SaaS-API, корпоративные системы, публичные сервисы.

Большинство серверов в официальном реестре используют stdio для локальной установки. Удалённые MCP-серверы (Sentry, GitHub Cloud API и им подобные) — Streamable HTTP.

# Локальный сервер через stdio (в конфиге Claude Code)
claude mcp add my-db -- node /path/to/db-server/index.js

# Удалённый сервер через HTTP (с OAuth)
claude mcp add sentry --url https://mcp.sentry.io/

Место в экосистеме

К середине 2026 года MCP поддерживают Visual Studio Code (Copilot), Cursor, ChatGPT, JetBrains, Zed и десятки других инструментов. Реестр официальных серверов на GitHub содержит готовые интеграции: GitHub, Postgres, SQLite, Slack, Google Drive, Puppeteer, Brave Search и другие.

Это значит: если в вашей компании уже поднят MCP-сервер для внутренней базы знаний, им могут пользоваться все члены команды — через Claude Code, через Cursor или через любой другой совместимый клиент — без переписывания интеграции.

Проверь себя

Ваш коллега написал MCP-сервер для внутренней CRM компании. Кто сможет им воспользоваться?

В контексте Claude Code MCP — это тот самый «шестой механизм», который не попал в таблицу предыдущей статьи. Команды, навыки, субагенты и хуки расширяют поведение агента изнутри. MCP-сервер — это внешняя система, которую агент вызывает как инструмент. Ни навык, ни команда не дадут Claude Code живого соединения с базой данных. MCP — единственный способ это сделать.

Быстрое повторение

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