← Все статьи

MCP: зачем агенту отдельный протокол для инструментов

Разбор · август 2026

Model Context Protocol появился из очень скучной проблемы. Каждый агент умеет вызывать инструменты — прочитать файл, сходить в базу, дёрнуть API. Но описание этих инструментов каждый раз пишется заново под конкретного агента: свой формат, свой способ передать параметры, свои правила ошибок. Десять агентов и десять сервисов — это сто интеграций.

MCP предлагает то же, что когда-то сделал LSP для редакторов: один протокол между тем, кто умеет думать, и тем, кто умеет действовать. Сервер объявляет свои инструменты, клиент их подхватывает — и любой агент, говорящий на MCP, получает их без отдельной интеграции.

Что внутри

Общение идёт по JSON-RPC: локально через стандартный ввод-вывод, по сети — через HTTP. Разница важна на практике: локальный сервер запускается как обычный процесс и живёт в вашей же машине, сетевой требует аутентификации и всего, что положено публичному сервису.

Где он реально помогает

Там, где инструмент нужен нескольким агентам сразу или переживёт смену агента. Написали MCP-сервер к своей базе задач — и он одинаково работает и в терминале, и в редакторе, и в чате. Поменяли агента — сервер остался.

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

Когда без него проще

Если инструмент нужен ровно одному агенту и только вам — MCP это лишний слой. Скрипт в PATH или пара строк в конфигурации агента решают задачу быстрее и отлаживаются понятнее. Протокол окупается при повторном использовании, а не при первом.

Второй случай — когда важна цена контекста. Каждый подключённый сервер занимает место в окне: описания инструментов уезжают в промпт целиком. Десяток серверов «на всякий случай» — это заметная доля контекста, потраченная впустую.

На что смотреть при подключении