Что такое MCP сервер. Как работает киллер-фича современности под капотом

Помните время, когда искусственный интеллект был простой говорящей головой? 

Мы все через это проходили: открываешь чат, просишь ИИ написать кусок кода, копируешь его, вставляешь в IDE, ловишь ошибку компиляции, копируешь текст ошибки, вставляешь обратно в чат. Рутина. Сплошная, выматывающая рутина. 

Хочешь, чтобы ИИ прочитал лог-файл? Пиши кастомный плагин. Хочешь, чтобы он сделал простой запрос в базу данных? Садись и пиши очередной адаптер. Каждая новая интеграция требовала написания отдельного, уникального кода. По сути, приходилось соединять зоопарк различных ИИ-моделей с бесконечным множеством баз данных, API и сервисов, собирая костыльные решения на ходу.

И так продолжалось бы еще долго, если бы не одно событие.

Но 25 ноября 2024 года компания Anthropic представила Model Context Protocol (MCP). И, честно говоря, это событие полностью изменило правила игры.

ИИ получает USB-порт

MCP часто называют «USB-стандартом» для систем искусственного интеллекта. Аналогия весьма точная. Раньше взаимодействие пользователя с LLM происходило лишь через чат. То есть все, что ИИ мог сделать — это отправить текст. Взаимодействие с системой, сервисами и приложениями оставалось за пользователем.

MCP это открытый протокол, который позволяет любым ИИ-моделям подключаться к внешним инструментам и данным. С помощью этого ИИ может взаимодействовать с вашим Google календарем, базой знаний в Obsidian или Notion, создать дизайн в Figma или даже создать 3D модель в Blender.

Протокол работает по принципу «plug and play». Это значит, что любой MCP-совместимый клиент без проблем общается с любым MCP-совместимым сервером. И теперь, спустя полтора года после релиза, запуск MCP-сервера стал такой же обыденностью, как запуск обычного веб-сервера.

Чтобы понять, как именно ИИ обрел способность взаимодействовать с реальным миром, давайте разберем архитектуру MCP. Она на самом деле довольно проста и следует классической клиент-серверной модели. Есть несколько ключевых компонентов:

Хост (MCP Host): Это приложение, в котором вы общаетесь с ИИ. Это могут быть, например, Claude Desktop, Cursor или Visual Studio Code с GitHub Copilot.

Его задача — координировать работу и управлять одним или несколькими MCP-клиентами.

Хост отвечает за пользовательский интерфейс, управляет разрешениями и решает, каким именно серверам можно доверять.

Клиент (MCP Client): Этот компонент располагается внутри хоста.

Его главная задача переводить запросы ИИ в протокол MCP. Клиент поддерживает 1:1 соединение с MCP-сервером и запрашивает у него контекст для MCP-хоста. Если у вас подключено три сервера, внутри хоста параллельно работают ровно три клиента.

Сервер (MCP Server): Это отдельная, легковесная программа, которая предоставляет доступ к конкретному инструменту или сервису. Она может быть локальная или удаленная. Один сервер, к примеру, может давать доступ к файлам на вашем компьютере (локальный источник данных), а другой — к внешнему API вроде GitHub (удаленные сервисы).

Взгляните на наглядную схему:

1. Хост MCP (MCP Host) — программы, использующие LLM в своей основе, которым нужен доступ к данным через MCP.

2. Клиент MCP (MCP Client) — клиенты, поддерживающие соединение 1:1 с серверами.

3. Сервер MCP (MCP Server) — легковесные программы, каждая из которых предоставляет доступ к инструментам.

4. Локальные источники данных (Local Data Sources) — файлы на вашем компьютере, базы данных и сервисы, к которым серверы MCP могут безопасно получать доступ.

5. Удаленные источники данных (Remote Data Sources) — внешние системы, доступные через интернет, к которым могут подключаться серверы MCP.

Вся эта система работает на базе двух слоев:

Уровень данных(Data layer): определяет протокол взаимодействия между клиентом и сервером на базе JSON-RPC 2.0, включая управление жизненным циклом и такие основные примитивы, как Инструменты (tools), Ресурсы (resources) и Промпты (prompts).

Транспортный уровень(Transport layer): определяет механизмы и каналы связи, обеспечивающие обмен данными между клиентами и серверами. Устанавливает соединения, фрейминг сообщений и авторизацию.

Он поддерживает два механизма: stdio (стандартный ввод/вывод для локальных процессов без сетевых задержек) и Streamable HTTP (использует HTTP POST и Server-Sent Events для удаленного взаимодействия). 
По сути, уровень данных — внутренний, а транспортный — внешний.

Инструменты, Ресурсы и Промпты – три кита данных MCP

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

Инструменты (Tools): Это исполняемые функции, которые ИИ может вызывать для выполнения действий. Инструменты спроектированы так, чтобы ими управляла сама модель.

Например, когда вы просите ИИ «создай репозиторий на GitHub», модель получает от сервера список доступных инструментов (с их описаниями и inputSchema в формате JSON Schema), сама выбирает нужный инструмент и передает ему правильные аргументы.

Ресурсы (Resources): Это любые данные(содержимое файлов, схемы баз данных) которые обеспечивают необходимый контекст для ИИ-приложения

В отличие от инструментов, ресурсы контролируются приложением, и именно разработчик в ответе за то, как эта информация будет использоваться.

Промпты (Prompts): Готовые шаблоны взаимодействия, которые оптимизированы для конкретных задач. Спроектированы так, чтобы контролироваться пользователем.

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

Для начала посмотрим на схему работы ИИ-агента, потому что именно он работает с MCP. В самом простом высокоуровневом определении, ИИ-агент — это приложение, которое использует LLM в качестве основного механизма рассуждений для принятия решений о шагах, необходимых для выполнения запроса пользователя.

Схема работы агента обычно выглядит так и состоит из следующих блоков:

• Планирование (Planning) — способность планировать последовательность действий, которые приложение должно выполнить для реализации заданного намерения. Для этого существует множество стратегий.

• Память (Memory) — краткосрочная и долгосрочная память, содержащая любую информацию, которая может понадобиться агенту для обдумывания своих дальнейших действий. Эта информация обычно передается в LLM через системный промпт как часть ядра.

• Инструменты (Tools) — любая функция, которую приложение может вызвать для расширения своих способностей к рассуждению. Инструментом может быть буквально что угодно:

  • Простые функции, определенные в коде.

  • Векторные базы данных (VectorDB) и другие хранилища данных, содержащие контекст.

  • API обычных моделей машинного обучения.

  • Другие Агенты!

Топология того, как происходят взаимодействия, определяется в коде, а не планируется самой LLM.

За связь нашего приложения с внешней средой отвечают Инструменты. Сервер MCP предоставляет эндпоинт, который может вывести список всех доступных Инструментов с их описаниями и требуемыми аргументами. Приложение может передать этот список в LLM, чтобы та могла решить, какие инструменты нужны для текущей задачи и как именно их следует вызывать.

Архитектура ИИ-агента, если мы внедряем MCP:

Мы можем внедрить серверы MCP в качестве интерфейса для всех источников данных, имеющих отношение к процедуре извлечения информации. Сервер MCP управляет логикой извлечения с помощью Инструментов, поскольку LLM будет выбирать, какие источники данных будут релевантны для системы. Вот некоторые преимущества такого подхода:

Мы отделяем логику извлечения данных от топологии агентной системы.

Благодаря этому мы можем развивать компонент извлечения отдельно:

• Внедрять дополнительные инструменты.

• Внедрять дополнительные источники данных.

• Версионировать, развивать и откатывать существующие инструменты и источники данных.

• Управлять безопасностью и доступом к данным через сервер MCP.

• Независимо работать над данными.

Про безопасность

Есть в нашей бочке меда заметная ложка дегтя. Конечно, наделять большую языковую модель способностью выполнять SQL-запросы к вашей базе или писать файлы на ваш жесткий диск звучит… ну, слегка пугающе. Безопасность это пока самое слабое звено молодого протокола.

Уже в апреле 2025 года аналитики по кибербезопасности из компании Invariant опубликовали отчеты. Выяснилось, что архитектура MCP подвержена нескольким серьезным угрозам:

Во-первых, классический prompt injection (внедрение промпта) никуда не делся. Через вредоносный ответ сервера можно заставить модель выполнить нежелательные действия.

Во-вторых, исследователи обнаружили проблему «отравления инструментов» (Tool Poisoning) и использование похожих названий. Злоумышленник может подсунуть ИИ фальшивый инструмент, который тихо подменяет доверенный. Вредоносные инструкции прекрасно считываются и исполняются языковыми моделями. В результате ИИ-агент может начать выполнять несанкционированные действия, о которых владелец даже не будет подозревать.

Повсеместные разрешения для агента позволяют комбинировать эти методы для скрытой эксфильтрации данных.

Поэтому базовые правила того, как не сесть лужу с MCP звучат так:

1. Ограничивайте доступ к файловой системе только теми директориями, которые не страшно показать ИИ (помните, сервер работает с правами вашего локального пользователя!).

2. Никогда не хардкодьте пароли в конфигурационном JSON, используйте переменные окружения.

3. Используйте серверы только из проверенных источников (например, из официального репозитория Anthropic) и всегда проверяйте исходный код кастомных решений.