Как протокол Model Context Protocol помогает агентам ИИ находить и вызывать инструменты.

Попросите ИИ-ассистента «создать минимальную лендинг-страницу в Figma для SaaS-сервиса на базе ИИ под названием FlowAI с тёмным фоном, одним заголовком, кнопкой с призывом к действию и тремя карточками с функциями», — хорошо настроенный ассистент сможет это сделать: он создаст структуру в Figma без необходимости открывать приложение или писать собственную интеграцию в Figma. Первый результат служит отправной точкой, и вы можете продолжать работу, запрашивая новые экраны, изменения в типографике или шрифтах. Тот же подход применим к многим другим приложениям.

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

Что такое MCP

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

Figma — это лишь один пример. С помощью того же протокола ИИ-приложение может получить доступ к базам данных, Slack, GitHub и практически любой другой системе, имеющей сервер MCP.

В этом контексте «инструмент» просто означает функцию, которую сервис предоставляет для вызова моделью, такую как «создать рамку», «найти сообщения» или «запустить запрос». MCP придает этим функциям единый формат, что позволяет любому совместимому ИИ-приложению находить и использовать их.

Проблема интеграции, которую решает MCP

Без общего протокола каждая пара приложения ИИ и инструмента требует собственного специально написанного кода. Подключение одного ассистента к Figma — это одна интеграция. Подключение второго ассистента к Figma — ещё одна. Добавление Slack означает новую интеграцию, а база данных — ещё одну. Количество интеграций растёт с умножением количества приложений на количество инструментов, и их обслуживание быстро становится неконтролируемым.

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

Является ли MCP заменой API?

Нет. API не исчезнут. U Figma, Stripe и Slack по-прежнему существуют их API, а ваша база данных PostgreSQL по-прежнему присутствует в основе всего, что вы над ней создаёте. На практике многие серверы MCP представляют собой тонкий слой поверх существующих API.

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

С помощью MCP приложение ИИ может за время выполнения запросить у сервера, какие инструменты он предлагает. Сервер онлайн-магазина может ответить с такими инструментами, как:

• поиск товаров
• загрузка заказа
• создание возврата средств

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

Три основных компонента: хост, клиент и сервер

MCP организован вокруг трех ролей.

Хост

Хост — это приложение ИИ, с которым фактически взаимодействует пользователь: чат-ассистент, инструмент для программирования с ИИ или любое приложение, в основе которого лежит языковая модель. Оно контролирует разговор и модель, а также определяет, какие серверы может использовать модель.

Клиент MCP

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

Сервер MCP

Сервер предоставляет инструменты для приложения ИИ и связывает их с реальными системами. Когда вызывается инструмент, именно сервер взаимодействует с API Figma, выполняет запросы к базе данных или отправляет сообщения в Slack.

Что происходит при вызове инструмента

Если объединить эти три роли, логика работы становится понятной. Клиент позволяет хосту обнаруживать инструменты, предлагаемые сервером, и вызывать их с правильно структурированными параметрами, когда модель считает их необходимыми.

Это не просто однократный запрос, после которого всё забывается. Это диалог между клиентом и сервером. Сначала они устанавливают сессию и договариваются о возможностях, затем клиент запрашивает список инструментов, а позже отправляет запросы к этим инструментам и получает результаты. По сути, для передачи сообщений используется формат JSON-RPC — либо через стандартный ввод-вывод для локально работающих серверов, либо через HTTP для удалённых.

Именно языковая модель отличает этот подход от традиционных способов интеграции. Здесь нет жёстко заданных последовательностей запросов; модель читает описания инструментов, определяет, какие из них помогут достичь цели пользователя, и запрашивает их в том порядке, который требуется ходу диалога.

Пример работы вспомогательного агента для электронной коммерции

Рассмотрим вспомогательного агента для интернет-магазина, сервер MCP которого предоставляет три инструмента:

• get_order

search_products

create_refund

Клиент пишет: «Где мой заказ?» Модель распознаёт намерение, замечает наличие инструмента get_order и решает использовать его с идентификатором заказа клиента. Запрос передаётся от клиента на сервер, который запрашивает базу данных заказов или внутренний API заказов и возвращает структурированные данные о заказе. Затем модель преобразует эти данные в естественный ответ, например: «Ваш заказ был отправлен вчера и должен прибыть в четверг».

Клиент пишет в ответ: «На самом деле, верните деньги». Поскольку у модели всё ещё сохраняется контекст разговора, она знает, к какому заказу относится «это». Она видит, что функция create_refund доступна, и вызывает её с теми же данными заказа. Если сервер также предоставляет инструмент вроде notify_finance, модель может включить и этот шаг в процесс обработки.

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

Что даёт MCP

Выделяются три преимущества.

1. Стандартизация: приложения ИИ взаимодействуют с внешними инструментами одинаковым способом, без необходимости использования разных схем для каждой интеграции.
2. Гибкость: модель сама находит доступные инструменты и считывает их схемы напрямую, поэтому больше не требуется вручную описывать каждую функцию в длинном промпте системы.
3. Повторное использование: сервер MCP создается один раз и может обслуживать множество совместимых приложений ИИ.

Чего не делает MCP

Важно четко понимать его ограничения, так как ажиотаж вокруг протокола может их затуманить.

• MCP — это не волшебство, и он не делает основной API более мощным, чем тот, кем он уже является.

Это не делает систему ИИ надежной. Модель по-прежнему может выбрать неправильный инструмент или передать неверные аргументы, поэтому проверка и разумная обработка ошибок на сервере остаются крайне важными.

Это не устраняет проблем с аутентификацией и безопасностью. Серверам по-прежнему требуются учетные данные, контроль доступа и аудит, а результаты работы инструментов могут содержать ненадежный контент, пытающийся повлиять на модель.

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

Использование ИИ для вызова API — не новость; разработчики уже много лет подключают модели к API. MCP добавляет стандартизированный интерфейс, через который модель может находить и использовать множество различных инструментов без необходимости создания отдельной интеграции для каждого из них.

Основные выводы

• MCP — это протокол для подключения ИИ-приложений к инструментам. Он работает поверх API, а не заменяет их.
• Серверы предоставляют инструменты вместе с описаниями и схемами входных данных; хост и его клиенты отвечают за обнаружение инструментов и взаимодействие с ними.
• Модель выбирает, какой инструмент вызвать и с какими аргументами; реальная операция выполняется на сервере.
• Стандартизация превращает растущую сеть единичных интеграций в компоненты, которые создаются один раз и могут использоваться повторно.
• Надежность, аутентификация, принцип минимальных привилегий и подтверждение рискованных действий остаются вашей ответственностью.

Если вы только начинаете, сначала подключите существующие серверы MCP, такие как те, что используются GitHub, Slack или Figma, к ассистенту, которым вы уже пользуетесь, и посмотрите, как модель выбирает инструменты. Как только ценность этого станет очевидной, создание собственного сервера для внутренней базы данных или сервиса станет логичным следующим шагом. Чтобы узнать, как MCP вписывается в более крупные фреймворки агентов, прочитайте нашу статью о стандартизации интеграции инструментов в LangGraph с помощью MCP.