Model Context Protocol: как устроен протокол, дающий ИИ доступ к инструментам

Про MCP есть объяснение на пальцах, и для большинства этого достаточно. Но если хочется понять, как протокол устроен внутри — из чего состоит, как общаются стороны и почему он вообще решил проблему, которую не решали до него, — стоит копнуть глубже. Этим и займёмся.

Какую проблему решает протокол

Начать проще с боли, которую MCP устранил. До него каждую интеграцию нейросети с внешним инструментом писали отдельно и под конкретную связку. Хочешь подключить модель к базе — пишешь интеграцию. Другую модель к той же базе — пишешь заново, потому что интерфейсы разные.

Математически это выглядело как N×M: каждый из N клиентов надо было отдельно подружить с каждым из M инструментов. С ростом обоих чисел это превращалось в комбинаторный ад.

MCP свёл задачу к N+M. Клиент реализует протокол один раз, сервер реализует протокол один раз — и дальше любой клиент работает с любым сервером. Именно поэтому инструмент, написанный однажды, подходит к разным агентам без переделки. Протокол придумали в Anthropic и открыли всем, и за счёт этого он быстро стал общим стандартом.

Клиенты и серверы

В основе — простое разделение ролей. Есть клиент (он же хост) — это приложение с нейросетью, например десктопный агент. И есть серверы — отдельные программы, каждая из которых даёт доступ к какому-то ресурсу или инструменту: к файловой системе, базе, трекеру, API.

Клиент подключается к серверам, узнаёт, что они умеют, и даёт модели этим пользоваться. Один клиент может держать несколько серверов сразу — тогда у модели просто расширяется набор доступных инструментов.

Что сервер предоставляет

Сервер отдаёт клиенту не что попало, а три чётко определённых типа возможностей.

Инструменты — это действия, которые модель может выполнить: сделать запрос, отправить сообщение, изменить данные. Именно инструменты чаще всего имеют в виду, когда говорят про MCP.

Ресурсы — это данные для чтения, которые сервер может отдать модели как контекст: содержимое файла, запись из базы, документ.

Промпты — заготовленные шаблоны и сценарии, которые сервер предлагает, чтобы типовые задачи выполнялись единообразно.

Такое разделение неслучайно: оно позволяет серверу аккуратно очертить, что модели можно читать, а что — делать, вместо одного размытого «доступа ко всему».

Транспорты: локально и удалённо

Дальше вопрос, как физически общаются клиент и сервер. В протоколе для этого есть два основных транспорта.

Первый — stdio: сервер запускается как дочерний процесс на той же машине, и общение идёт через стандартные потоки ввода-вывода. Это вариант для локальных серверов, и он же самый приватный — ничего не выходит за пределы компьютера.

Второй — HTTP: сервер работает как удалённый эндпоинт, доступный по сети. Это нужно, когда сервер живёт не на твоей машине, а где-то ещё.

Выбор транспорта — это во многом выбор про приватность и топологию. Локальный stdio-сервер держит всё у тебя; удалённый HTTP-сервер удобнее для общих сервисов, но данные уже идут по сети.

Как это выглядит в реальном агенте

Теория становится понятнее на живом примере. В Доке MCP-серверы подключаются локально, через stdio: ты указываешь команду запуска и параметры, а при каждом запуске задачи приложение поднимает включённые серверы, собирает их инструменты и регистрирует под понятными именами. Модель вызывает их наравне со встроенными, а вызовы уходят обратно в нужный сервер.

То есть весь этот протокол на практике сводится для пользователя к паре полей в настройках — а как заполнить их правильно, разобрано в статье про подключение MCP-сервера.

Почему это важно за пределами хайпа

MCP часто подают как модную аббревиатуру, но ценность у него вполне приземлённая. Общий стандарт означает, что экосистема инструментов растёт независимо от того, какой именно моделью ты пользуешься. Сервер, написанный сегодня под один агент, завтра заработает с другим. Для пользователя это значит, что возможности его агента расширяются не силами одного вендора, а всей экосистемой сразу.

Если подытожить

Model Context Protocol — это способ стандартизировать, как нейросеть получает доступ к внешнему миру: клиент и сервер, инструменты-ресурсы-промпты, локальный или удалённый транспорт. За внешней сложностью стоит простая цель — чтобы инструмент писали один раз, а работал он везде. Как пощупать это на практике — скачай Доку, MCP уже внутри.