Мой дэйли дайджест

одно техническое понятие в день

MCP (Model Context Protocol)

30 мая 2026 · ~14 мин чтения

протокол ai llm интеграции стандарт

MCP (Model Context Protocol)

Открытый протокол, по которому большая языковая модель (LLM) общается с внешними источниками данных и инструментами — файлами, базами, API, серверами — через стандартный «разъём», не зная заранее, какой именно сервис на другом конце.

История

MCP анонсировала компания Anthropic 25 ноября 2024 года. Сразу — с открытой спецификацией, референсной реализацией на TypeScript и Python и каталогом готовых серверов на GitHub. Идея вызревала весь 2024 год: к тому моменту у каждого AI-IDE и каждого AI-ассистента был свой формат «плагинов» — у ChatGPT свой, у LangChain свой, у Cursor свой, у Continue свой, и подключить одну и ту же базу данных к разным ассистентам означало написать четыре несовместимые обёртки.

На момент мая 2026 в публичном реестре modelcontextprotocol/servers лежит порядка нескольких тысяч серверов, написанных сообществом: от обёрток к Postgres и GitHub до интеграций с домашними «умными» розетками. Владелец и шеф-архитектор протокола — по-прежнему Anthropic, но участвуют все крупные AI-лаборатории и независимые контрибьюторы.

Что это такое

MCP — это формальное соглашение о том, как клиент (например, Claude Code или Cursor) разговаривает с сервером, который умеет показать модели данные и дать ей выполнить функции. Соглашение состоит из четырёх вещей:

  1. Транспорт. Как байты идут от клиента к серверу. Сейчас поддерживается два варианта: stdio (сервер — отдельный процесс, клиент пишет ему в stdin и читает stdout) и HTTP + Server-Sent Events (сервер — удалённый веб-сервис).
  2. Формат сообщений. JSON-RPC 2.0. Это значит: каждое сообщение — это JSON-объект с полями jsonrpc: "2.0", method, params, id. Ответ — JSON-объект с тем же id и полем result или error. Это та же самая схема, что лежит под LSP (Language Server Protocol — стандартом, по которому редакторы общаются с языковыми анализаторами; именно из мира LSP вдохновение и выросло).
  3. Семантика сущностей. Что именно сервер может предоставить. Их три типа:
    - Resources (ресурсы) — данные, на которые модель может «посмотреть»: содержимое файла, строка из базы, статья из вики. Идентифицируются URI.
    - Tools (инструменты) — функции, которые модель может вызвать с аргументами: «прочитай файл», «отправь сообщение», «выполни SQL-запрос». У каждого инструмента есть JSON-Schema описание входов и выходов.
    - Prompts (промпт-шаблоны) — заготовки текстов, которые сервер предлагает использовать как шаблоны для диалога.
  4. Сценарий жизненного цикла. Как клиент и сервер договариваются о версиях, обмениваются capability (что каждый из них умеет), и как обрабатываются ошибки и отключения.

Чем MCP отличается от соседних понятий:

Аналогии из жизни

Аналогия 1: USB-разъём. До USB у каждого периферийного устройства был свой кабель и свой разъём: мышь по PS/2, клавиатура по DIN, принтер по LPT, сканер по SCSI, модем по COM. Чтобы добавить новое устройство, нужно было докупать карту расширения. USB решил это: один разъём, любое устройство, операционка сама разбирается. MCP — это USB для контекста: один протокол, любой источник данных, любой ассистент сам разбирается.

Где ломается: USB перестаёт быть невидимым, как только устройство требует большой мощности или гарантированной задержки — для камер и аудио всё равно нужны специальные классы и драйверы. У MCP так же: тривиальные кейсы (файлы, БД) — просто, а как только нужна потоковая запись или гарантия порядка событий, начинаются нюансы транспорта и сессионности, поверх которых приходится строить надстройки.

Аналогия 2: Шведский шведский стол в отеле. Вместо того чтобы тащить с собой свою еду, готовить её и подавать, ты приходишь к большому столу, где сервер «отеля» уже разложил блюда (resources), повара готовы по запросу пожарить тебе омлет (tools), и есть карточки с рекомендованными комбинациями (prompts). Ты выбираешь сам, повар не знает, кто ты и что ты с этим сделаешь.

Где ломается: шведский стол подразумевает, что ты сам видишь все блюда и не задаёшь повару вопросов в реальном времени. MCP-клиент же ведёт диалог: модель может спросить сервер, изменилось ли содержимое ресурса, попросить более новую версию, отказаться от ответа. Аналогия не передаёт эту интерактивность.

Аналогия 3: Стандарт грузового контейнера TEU. До 1956 года каждый порт грузил корабль по-своему, каждое судно строилось под свой груз, и любая пересадка превращалась в перепаковку. Стандартный 20-футовый контейнер сделал так, что внутри может лежать что угодно — кофе, телевизоры, машины — а снаружи он одинаков: один кран, одна перевалка, один поезд. MCP — стандартный контейнер для контекста: внутри может быть что угодно (база, файлы, API, личные заметки), снаружи — единая JSON-RPC обёртка.

Где ломается: контейнер — статичный объект, его погрузили один раз и больше не открывают до прибытия. Внутри MCP-сервера, наоборот, идёт постоянный обмен — модель снова и снова что-то спрашивает, сервер отвечает. Аналогия передаёт идею стандартизации интерфейса, но не передаёт постоянный диалог.

Как это работает

Представь, что у тебя на ноутбуке запущен Claude Code и ты хочешь, чтобы он умел читать твою локальную базу данных DuckDB. Шаги:

  1. Запуск сервера. Ты в ~/.claude/settings.json прописываешь блок mcpServers, где для имени clients указано: «запусти команду mcp-duckdb --db /Users/pasha/clients.duckdb». Claude Code при старте запускает этот процесс.
  2. Handshake (рукопожатие). Клиент посылает серверу первое сообщение — initialize — с указанием версии протокола, своих capabilities (умеет ли он отображать прогресс, поддерживает ли streaming) и информации о клиенте. Сервер отвечает своими capabilities и списком: «я предоставляю tools, resources и prompts».
  3. Discovery (опись). Клиент шлёт tools/list и получает массив описаний инструментов. Например: «есть инструмент sql_query с параметром query: string, возвращает строки результата». Аналогично для resources/list и prompts/list. Эти описания попадают в системный промт модели — теперь модель знает, что у неё есть руки.
  4. Решение модели. Пользователь спрашивает: «сколько строк в таблице records?». Модель видит в своём системном промте, что есть инструмент sql_query, и решает его вызвать. Это решение — формально tool-use в формате нативного API LLM (это всё ещё function calling): модель отвечает не текстом, а JSON-объектом {"tool": "sql_query", "input": {"query": "SELECT COUNT(*) FROM records"}}.
  5. Маршрутизация. Клиент видит, что инструмент sql_query принадлежит серверу clients, и шлёт ему tools/call сообщение с этими параметрами. JSON-RPC сообщение по stdio выглядит так (упрощённо):
    json {"jsonrpc":"2.0","id":42,"method":"tools/call", "params":{"name":"sql_query","arguments":{"query":"SELECT COUNT(*) FROM records"}}}
  6. Исполнение. Сервер парсит сообщение, выполняет SQL по DuckDB, заворачивает результат:
    json {"jsonrpc":"2.0","id":42, "result":{"content":[{"type":"text","text":"4935747"}]}}
  7. Возврат модели. Клиент кладёт ответ в контекст модели как «результат tool-call с id 42». Модель видит число и формулирует человеческий ответ: «В таблице 4 935 747 записей».

Параллельно идёт и поток ресурсов. Модель может попросить «подпишись на изменения ресурса file:///Users/pasha/notes.md» — и сервер будет слать notifications/resources/updated, когда файл меняется. Это уже асинхронные нотификации поверх того же JSON-RPC канала.

Ещё одна важная штука — sampling (выборка): сервер может попросить клиента вызвать LLM от своего имени. Например, MCP-сервер для перевода говорит: «эй, клиент, переведи мне эту строку через свою модель». Это переворачивает обычную картину «клиент зовёт сервер» — иногда сервер тоже может звать клиента. Так строятся sub-agents и иерархические сценарии.

Главный сдвиг мышления

MCP — это не про «как сделать AI умнее», а про «как один AI умеет работать с любым контекстом без переписывания». Ценность не в одном сервере, а в комбинаторике: имея 10 клиентов и 100 серверов, ты получаешь 1000 готовых интеграций без линейного роста кода.

Где встречается в обычной жизни

Где встречается в IT и бизнесе

Кто пользуется

В моём собственном чате прямо сейчас, например, подключён MCP-сервер clients с инструментами sql_query, phone_lookup, inn_lookup — это типичная корпоративная интеграция к внутренней БД.

Альтернативы и конкуренты

Когда НЕ стоит использовать

Связанные понятия

Грабли, на которые наступают новички

Подключив MCP-сервер с большим набором tools, легко переполнить контекст модели описаниями инструментов — каждое описание занимает токены, и при тридцати инструментах на сервере у тебя десятки тысяч токенов уходит впустую. Хорошие клиенты позволяют включать/выключать конкретные tools и группы; используй это.

Литература и источники

Где встретилось у меня

В пятницу 29 мая я через Claude Code лез в боевую DuckDB-базу клиентов, подключённую к Claude как MCP-сервер clients. Часть данных лежала в DuckDB (cold), часть — в отдельной SQLite (hot), и второй разъём MCP к hot ещё не был сделан коллегой. Это типичная ситуация «один источник через MCP уже виден модели, второй — пока нет, и модель чувствует слепое пятно». В тот же день параллельный subagent тоже шёл по MCP-тулзам к веб-поиску и веб-фетчу — без всякого моего участия, по тому же самому протоколу.

Краткое резюме