В прошлой заметке я писал про сервер и клиент, а теперь хочу копнуть глубже и пройтись по составу протокола. Это будет чуть упрощённая версия, чтобы не утонуть в спеке, но картинка станет понятнее.

На самом дне MCP — транспорт. Тут нет никакой магии: JSONRPC. Его работа — просто донести пакет от клиента до сервера и обратно. Запросы, ответы, нотификации, ошибки — всё аккуратно упаковано, но без бизнес-смысла.

Дальше идут данные. Со стороны сервера это Resources, Prompts, Tools. Resources управляют файлами, базой, API-ответами и прочим контекстом, который нужен ИИ-приложениям. Внутри этого — Content: текст, картинки, аудио, бинарь, блоки. Prompts описывают доступные подсказки и параметры. Tools — это исполняемые функции, которыми сервер делится с клиентом, от файловых операций до API вызовов.

Со стороны клиента данные другие. Sampling.Complete позволяет серверу дёрнуть LLM клиента без встроенного SDK. Elicit даёт возможность уточнить что-то у пользователя: параметры, подтверждения, ввод. Logging отправляет обратно логи и диагностику.

Есть и служебный слой: Initialize для рукопожатия, Capabilities для описания возможностей сторон, плюс сервисные штуки вроде уведомлений о прогрессе, подписок/отписок и отмен операций.

В итоге MCP — это не просто «реестр» инструментов, а полноценный протокольный шлюз. Сервер экспонирует ресурсы и инструменты, клиент решает, что из этого реально использовать. Баланс тот же: удобство для разработчиков серверов и полный контроль у пользователя.

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

Ну а чтобы вам не было скучно, я приложу сравнение протоколов, дабы можно было понять роль MCP относительно других