Все уроки · 44
MCP: USB-порт для ИИ
Model Context Protocol — открытый стандарт, который соединяет модели с инструментами и данными, и почему он понадобился индустрии.
USB-порт для ИИ
Вы подключаете мышь к любому ноутбуку, и она работает. Вам не нужно покупать мышь, сделанную под одну конкретную модель ноутбука, а производитель мыши не пишет отдельный драйвер для каждого компьютера на свете. Так было не всегда: у клавиатур был свой круглый разъём, у принтеров — широкий, у мышей — третий, и ни один не подходил ни к чему другому. Потом все договорились об одном порте, один раз заплатили за переход — и неразбериха исчезла.
У ИИ-приложений такого порта не было. До MCP подключение ИИ-приложения к инструменту было штучной работой: редактору понадобилось читать файлы — пишем интеграцию вручную; чату понадобился ваш календарь — ещё одна интеграция вручную. При M приложениях и N инструментах требовалось до M × N соединителей, каждый хрупкий и каждый поддерживался отдельно.
В ноябре 2024 года компания Anthropic опубликовала Model Context Protocol (MCP) — USB-порт для ИИ: открытый стандарт подключения моделей к инструментам и данным. Его быстро приняли OpenAI, Google, Microsoft и десятки производителей инструментов. Сегодня об ИИ-программе принято спрашивать: «Она поддерживает MCP?»
Один протокол вместо M × N соединителей
С MCP автор инструмента пишет один MCP-сервер, и им может пользоваться любое MCP-совместимое приложение. Автор приложения реализует протокол один раз, и внутри него работает любой MCP-сервер. M × N превращается в M + N.
Что вообще такое протокол?
Разберёмся с нуля: это слово здесь несёт большую нагрузку.
Протокол — это всего лишь согласованный набор правил о том, как общаются две стороны. Он определяет, какие бывают сообщения, какой они формы, кто говорит первым и что происходит, когда что-то идёт не так.
Самый простой бытовой пример — телефонный звонок. Обе стороны следуют сценарию, который никто не записывал: звонящий здоровается, снявший трубку отвечает, они говорят по очереди, один из них прощается, и разговор заканчивается. Если бы одна сторона начала выкрикивать названия товаров без приветствия, разговор формально всё равно остался бы звуковыми волнами — но не работал бы. Этот сценарий и есть протокол.
У компьютеров всё то же самое, только записано точно. Веб работает на HTTP —
протоколе, который говорит: клиент отправляет запрос с методом (GET) и адресом, а
сервер отвечает кодом состояния (200, 404) и телом ответа. Только благодаря
этому соглашению браузер, написанный одной компанией, может прочитать страницу,
которую отдаёт совсем другая.
MCP — соглашение такого же рода для одной узкой задачи: как ИИ-приложение и поставщик инструментов общаются друг с другом. Оно закрепляет четыре вещи:
- Рукопожатие (handshake) — приложение спрашивает «кто вы и что предлагаете?», а сервер отвечает списком инструментов, ресурсов и промптов.
- Формат сообщений — каждое сообщение — это «конверт» JSON-RPC 2.0, поэтому обе стороны знают, где находятся имя метода, параметры и идентификатор.
- Вызов — «запусти этот инструмент с такими аргументами» и «вот результат» (или «вот ошибка»).
- Транспорт — как байты физически передаются: через локальный канал или по HTTP.
Вот и вся идея: две программы договорились об одних и тех же четырёх правилах и теперь могут работать вместе, ни разу не встречавшись и не заглядывая друг другу внутрь. Три роли ниже — это просто названия, которые MCP даёт участникам этого разговора.
Три роли
У MCP намеренно небольшой словарь. Три чётко разделённые роли:
- MCP-хост (host) — приложение, которым пользуется человек: редактор вроде Cursor или VS Code, чат-приложение вроде Claude Desktop, фреймворк для агентов.
- MCP-клиент (client) — соединитель, живущий внутри хоста. Он поддерживает соединение с одним MCP-сервером и общается по протоколу от имени хоста. Обычно один хост запускает несколько клиентов — по одному на каждый подключённый сервер.
- MCP-сервер (server) — небольшая программа, которая предоставляет возможности: инструменты для вызова, ресурсы для чтения, промпты для повторного использования. Сервер может оборачивать что угодно: файловую систему, базу данных, GitHub, Slack, внутренний API вашей компании.
Простая картинка: хост — это компьютер, клиент — USB-порт, сервер — устройство, которое вы подключаете.
Два уровня: транспорт и данные
MCP описан в двух уровнях, и если держать их раздельно, всё встаёт на свои места.
Транспортный уровень отвечает на вопрос «как передаются байты?»
- stdio — сервер работает как локальный процесс, а сообщения идут через стандартный ввод и вывод. Просто, быстро, приватно. Это вариант по умолчанию для локальных конфигураций вроде Claude Desktop.
- HTTP (Streamable HTTP, а для сообщений от сервера к клиенту — SSE) — сервер работает удалённо, поэтому команда может разместить один общий сервер с полноценной аутентификацией. Так инструменты открывают для целой организации.
Уровень данных отвечает на вопрос «что мы говорим?» Все сообщения — это JSON-RPC 2.0: запросы, ответы и уведомления в стандартном «конверте». Поверх него расположены три типа возможностей:
- инструменты (tools) — действия, которые может вызывать модель: сделать запрос к базе данных, отправить сообщение, создать заявку. Когда их использовать, решает модель.
- ресурсы (resources) — данные, которые приложение может прочитать и подставить в контекст: файлы, схемы, документы. Ими управляет приложение, а не модель.
- промпты (prompts) — повторно используемые шаблоны промптов с параметрами, которые предлагает сервер; в интерфейсе они часто выглядят как слеш-команды.
Как запрос проходит через весь стек
Вот полный путь одного запроса пользователя:
«Что у меня в календаре на завтра?» — набрано в приложении-хосте.
Итак, полный круг такой: вы — хосту, хост — модели, модель — обратно хосту, хост — клиенту, клиент — серверу, сервер — обратно клиенту, клиент — хосту, хост — снова модели и, наконец, ответ — вам. Модель и сервер никогда не разговаривают напрямую — хост всегда посередине.
Та же форма, которую вы уже знаете по вызову функций, — но теперь инструмент живёт в отдельном процессе, возможно, на другой машине, и им может пользоваться любое MCP-совместимое приложение.
Как инструменты попадают к модели
Модель никогда ни к чему не «подключается». Хост собирает определения инструментов со всех подключённых серверов и помещает их схемы — имя, описание, JSON Schema параметров — в контекст модели. Модель читает эти описания как меню и выбирает, что вызвать. Поэтому описание инструмента — это вся его «презентация» для модели. Напишете небрежно — и модель выберет не тот инструмент или не выберет никакого.
Посмотрите в разговоре
Вот обмен репликами, в котором виден шаг с инструментом:
Проверьте себя
В аналогии с USB: что такое MCP-сервер?
Кто разговаривает с моделью во время вызова инструмента MCP?
Откуда модель знает, какие инструменты существуют?
Куда идти дальше
Теперь вы знаете, что такое MCP и как запрос проходит через хост, клиент и сервер. Дальше на дорожной карте — мультимодальный ИИ: модели, которые работают с изображениями, звуком и видео, а не только с текстом. А если хотите увидеть, откуда пошёл вызов инструментов, урок Инструменты и вызов функций — именно на нём построен MCP.