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

Если смотреть на схемы выше, то картина получается парадоксальная. Уровень связности высокий: запросы к LLM проксируются через хост, а MCP-сервера сидят как отдельные острова, каждый тянет свои данные — базы, файлы, API. На первый взгляд хочется спросить: «зачем такие сложности?». Ответ простой — тарификация и контроль. Если бы сервер напрямую ходил к LLM, владелец MCP оказывался бы заложником чужой экономики. А так запрос идёт через клиента/хост, и именно пользователь контролирует, когда и какой токен уходит в модель.

Важно понимать: MCP-сервер всегда на стороне провайдера данных. Это он готовит промпты, пишет функции, агрегирует источники. Ваша задача — не изобретать велосипеды, а собрать этих провайдеров, подключить через MCP и дальше использовать уже в своих оркестраторах (хоть LangChain, хоть самописные пайплайны).

Почему MCP имеет значение? Всё зависит от того, где вы стоите:
– Разработчику MCP сокращает время интеграции и даёт готовый слой абстракций.
– ИИ-приложениям MCP открывает экосистему источников и тулзов.
– Пользователю MCP гарантирует, что его данные не уходят вслепую, а действия согласованы.

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

В следующей части разберём, какие паттерны интеграции MCP-серверов с LLM-оркестраторами реально просто работают

Ссылки, как обычно, в моём канале

——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура