Хайп вокруг Model Context Protocol сейчас только набирает обороты. Все обсуждают, но толком мало кто понимает, как это работает под капотом. Я хочу поделиться тем, что сам знаю и использую, и начать серию заметок, где разберу протокол по слоям: от сервера до клиента. Без академического занудства, но с технической точностью.

Начнём с сервера. Это не просто API с ручками и базой. Это инфраструктура, которая хранит версии контрактов и управляет доступом к провайдерам через CQRS-подход. Только это не «чистый» CQRS, а своя интерпретация. У нас есть три ключевых блока: Tools — всё, что записывает (файлы, API вызовы, база), Resources — всё, что читается (ответы из API, файлы, БД), и Prompts — шаблоны и подсказки для взаимодействия. Вместе это даёт централизованный контроль и прозрачное управление контрактами.

Клиент, в отличие от классического сетевого «тупого» потребителя, выступает протокольным посредником. Он решает, что серверу можно, а что нельзя. Через Sampling клиент подтверждает вызовы к LLM, через Roots задаёт границы доступа к файловой системе, а через Elicitation уточняет недостающие данные у пользователя. Сервер может многое, но последнее слово всегда остаётся за клиентом.

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