MCP и будущее AI: что стоит знать сегодня, чтобы не отстать завтра

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

Model Context Protocol (MCP), представленный в ноябре 2024 года, привлек большое внимание в сообществе разработчиков и AI-энтузиастов как потенциальное решение этой проблемы. В этой статье мы разберем, что такое MCP, как он меняет способ взаимодействия AI с инструментами, что уже создают разработчики на его основе и какие задачи еще предстоит решить.

Поехали.

MCP (Model Context Protocol) — это открытый протокол, который позволяет системам предоставлять контекст моделям ИИ в универсальной форме, подходящей для различных интеграций. Протокол определяет, как модель может вызывать внешние инструменты, извлекать данные и взаимодействовать с сервисами. Для конкретного примера — ниже показано, как MCP-сервер Resend работает одновременно с несколькими MCP-клиентами.

Идея не нова: MCP вдохновлен LSP (Language Server Protocol). В LSP, когда пользователь набирает текст в редакторе, клиент запрашивает у language-сервера предложения автодополнения или диагностическую информацию.

Где MCP выходит за рамки LSP, так это в своей модели выполнения, ориентированной на агентов: LSP в основном является реактивным (отвечает на запросы от IDE на основе пользовательского ввода), тогда как MCP разработан для поддержки автономных AI-воркфлоу. На основе контекста, AI-агенты могут решать, какие инструменты использовать, в каком порядке и как их связывать для выполнения задачи. MCP также вводит возможности участия человека в цикле (human-in-the-loop), позволяя людям предоставлять дополнительные данные и одобрять выполнение.

С правильно настроенным набором MCP-серверов пользователь может превратить любой MCP-клиент в “приложение для всего”.

Возьмём Cursor в качестве примера. Несмотря на то что Cursor — это редактор кода, он также выступает в роли полнофункционального MCP-клиента. Пользователь может превратить его в клиент для Slack, подключив Slack MCP-сервер, в отправитель email-сообщений с помощью Resend MCP-сервера, а также в генератор изображений, используя Replicate MCP-сервер. Более мощный способ использования MCP — установка нескольких серверов на один клиент для организации новых сценариев взаимодействия: например, пользователь может установить сервер, генерирующий фронтенд-интерфейс из Cursor, и одновременно поручить агенту воспользоваться MCP-сервером генерации изображений, чтобы создать hero-изображение для сайта.

Помимо Cursor, большинство сегодняшних use-case’ов можно свести к двум категориям: dev-ориентированные local-first рабочие процессы и принципиально новые сценарии с использованием LLM-клиентов.

Для разработчиков, которые работают с кодом ежедневно, распространённый принцип — “я не хочу покидать IDE, чтобы сделать X”. MCP-серверы позволяют воплотить это в реальность.

Вместо переключения в Supabase для проверки состояния базы данных разработчик может использовать Postgres MCP-сервер для выполнения read-only SQL-запросов и Upstash MCP-сервер для создания и управления кеш-индексами — прямо из IDE. При итерациях над кодом можно подключить Browsertools MCP, предоставив кодовым агентам доступ к live-среде для фидбэка и отладки.

Помимо рабочих процессов, связанных с разработческими инструментами, MCP-серверы открывают еще одну важную возможность — добавление точного контекста кодовым агентам за счёт краулинга веб-страниц или авто-генерации MCP-серверов на основе документации. Вместо ручной настройки интеграций разработчики могут разворачивать MCP-серверы напрямую из существующей документации или API, делая инструменты мгновенно доступными для AI-агентов. Это означает меньше времени, потраченного на шаблонный код, и больше — на реальное использование инструментов: будь то подтягивание данных в реальном времени, выполнение команд или расширение возможностей AI-ассистента на лету.

IDE вроде Cursor — не единственные MCP-клиенты, хотя они и получили наибольшее внимание благодаря очевидной привлекательности MCP для технических пользователей. Для нетехнической аудитории хорошей точкой входа служит Claude Desktop, делающий MCP-инструменты более доступными и удобными для широкой аудитории. В ближайшем будущем, вероятно, появятся специализированные MCP-клиенты для задач, ориентированных на бизнес: техподдержка, копирайтинг для маркетинга, дизайн, редактирование изображений — все те области, где ИИ особенно силен благодаря способности к распознаванию паттернов и креативным операциям.

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

Примером может служить реализация @ command, с помощью которой можно вызывать любые MCP-серверы напрямую из клиента. Это формирует новый UX-паттерн, в рамках которого MCP-клиент может перенаправлять сгенерированный контент в любое downstream-приложение по выбору пользователя.

Другой пример — использование Blender MCP-сервера: теперь даже непрофессиональные пользователи, с минимальными знаниями Blender, могут с помощью естественного языка описывать модель, которую они хотят создать. Мы наблюдаем, как text-to-3D-пайплайн реализуется в реальном времени по мере того, как сообщество создает MCP-серверы для других инструментов, таких как Unity и Unreal Engine.

Хотя мы в основном говорим о серверах и клиентах, экосистема MCP постепенно формируется по мере развития протокола. Эта карта рынка охватывает наиболее активные направления на сегодняшний день, хотя в ней всё ещё много пробелов. Учитывая, что MCP находится на ранней стадии развития, мы с интересом будем добавлять новых участников на карту по мере того, как рынок будет расти и созревать. (Некоторые из этих будущих возможностей мы рассмотрим в следующем разделе.)

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

Большинство MCP-серверов, представленных сегодня, работают по модели local-first и обслуживают одиночных пользователей. Это связано с тем, что MCP в текущей версии поддерживает только соединения на основе SSE и команд. Тем не менее, по мере того как экосистема перейдёт к полноценной поддержке удалённых MCP и внедрит Streamable HTTP как транспорт, мы ожидаем более широкого распространения MCP-серверов.

Также появляется новая волна решений в области MCP-маркетплейсов и хостинга серверов, которая делает возможным обнаружение MCP-сервисов. Платформы вроде mcpt от Mintlify, Smithery и OpenTools упрощают для разработчиков процесс поиска, публикации и совместной работы над новыми MCP-серверами — по аналогии с тем, как npm преобразовал пакетный менеджмент в JavaScript или как RapidAPI расширил возможности API-дискавери. Этот слой станет критически важным для стандартизации доступа к высококачественным MCP-серверам и позволит AI-агентам динамически выбирать и подключать нужные инструменты по требованию.

По мере роста MCP-экосистемы инфраструктура и туллинг будут играть ключевую роль в обеспечении масштабируемости, надежности и доступности решений. Инструменты генерации серверов, такие как Mintlify, Stainless и Speakeasy, снижают барьер входа при создании MCP-совместимых сервисов, а хостинг-решения вроде Cloudflare и Smithery решают задачи деплоя и масштабирования. Параллельно платформы управления соединениями, такие как Toolbase, начинают упрощать работу с key management и проксированием в local-first MCP-архитектурах.

Тем не менее, мы находимся лишь в начальной фазе развития agent-native архитектуры. Несмотря на высокий интерес к MCP сегодня, при разработке и поставке решений на основе MCP остается множество нерешенных задач.

В следующей итерации протокола необходимо реализовать следующие возможности:

Хостинг и мультиарендность

MCP изначально поддерживает модель "один ко многим", в которой один AI-агент может использовать множество инструментов. Однако мультиарендные архитектуры (например, SaaS-продукты) требуют поддержки параллельного доступа множества пользователей к общему MCP-серверу. Базовая поддержка удалённых серверов может стать краткосрочным решением для повышения доступности MCP, но корпоративные заказчики, скорее всего, предпочтут разворачивать MCP-серверы в изолированной среде с разделением data plane и control plane.

Следующий шаг к массовому внедрению — это создание унифицированной и эффективной toolchain для масштабируемого деплоя и сопровождения MCP-серверов.

Аутентификация

На данный момент MCP не определяет стандартный механизм аутентификации для взаимодействия клиентов с серверами и не предоставляет фреймворк для безопасного управления и делегирования аутентификации MCP-серверами при работе с внешними API. Аутентификация полностью отдана на откуп конкретным реализациям и сценариям развертывания. На практике, текущее использование MCP в основном ограничено локальными интеграциями, где явная аутентификация зачастую не требуется.

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

• Аутентификацию клиента: стандартные методы вроде OAuth или API-токенов для клиент-серверного взаимодействия
• Аутентификацию инструментов: вспомогательные функции или обёртки для аутентификации при обращении к сторонним API
• Мультипользовательскую аутентификацию: аутентификация с учётом тенантов для корпоративных развертываний

Авторизация

Даже если инструмент прошел аутентификацию, остаётся вопрос: кто имеет право его использовать и насколько детализированными должны быть права доступа? В MCP отсутствует встроенная модель разрешений, поэтому контроль доступа осуществляется на уровне сессии — инструмент либо доступен полностью, либо полностью запрещён. Хотя в будущем возможна реализация более тонких механизмов авторизации, текущий подход основан на потоках авторизации, соответствующих OAuth 2.1, при которых после аутентификации предоставляется доступ ко всей сессии. Это создает дополнительную сложность при увеличении количества агентов и инструментов — каждый агент, как правило, требует собственной сессии с уникальными авторизационными данными, что приводит к усложнению управления сессионным доступом.

Шлюз

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

Обнаружение и удобство использования MCP-серверов

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

Однако, согласно презентации Anthropic на AI Engineer Conference в прошлом месяце, ожидается внедрение реестра MCP-серверов и протокола обнаружения, что может стать следующим этапом в развитии MCP-инфраструктуры.

Среда исполнения

Большинство AI-воркфлоу требует последовательного вызова нескольких инструментов — однако в MCP отсутствует встроенная концепция воркфлоу для управления такими шагами. Неэффективно требовать от каждого клиента реализации резюмируемости и возможности повторного выполнения. Хотя сейчас разработчики исследуют решения вроде Inngest, выведение состояния исполнения (stateful execution) в статус концепции первого класса значительно упростит модель выполнения задач для большинства разработчиков.

Стандартизированный клиентский опыт

Один из часто задаваемых вопросов в сообществе разработчиков — как реализовывать выбор инструментов в MCP-клиентах: всем ли нужно писать свою реализацию RAG для инструментов, или есть слой, который должен быть стандартизирован?

Кроме выбора инструментов, не существует единого UX/UI-паттерна для их вызова (встречаются реализации от слэш-команд до полностью естественного языка). Стандартизированный клиентский слой для обнаружения, ранжирования и вызова инструментов может сделать опыт взаимодействия предсказуемым как для разработчиков, так и для конечных пользователей.

Отладка

Разработчики MCP-серверов часто сталкиваются с тем, что один и тот же сервер сложно стабильно запустить с разными клиентами. Обычно каждый MCP-клиент имеет свои особенности, а клиентские трейсы либо отсутствуют, либо труднодоступны, что делает отладку MCP-серверов крайне сложной задачей. По мере того как появляются удаленные MCP-серверы, необходимо создавать новый стек инструментов, обеспечивающий консистентный и управляемый разработческий опыт (dev experience) как для локальных, так и для удаленных сред.

Разработческий опыт с MCP напоминает мне разработку API в 2010-х. Парадигма новая и захватывающая, но тулчейны пока находятся в зачаточном состоянии. Если мысленно перенестись на несколько лет вперед — что будет, если MCP станет стандартом де-факто для AI-ориентированных воркфлоу? Вот несколько прогнозов:

• Конкурентное преимущество компаний, ориентированных на разработчиков, будет эволюционировать: от лучшего дизайна API — к лучшей коллекции инструментов, пригодных для использования агентами. Если MCP действительно позволит агентам автономно обнаруживать инструменты, поставщики API и SDK будут вынуждены обеспечивать удобство поиска своих решений и достаточно чёткую дифференциацию, чтобы агент выбрал именно их для выполнения конкретной задачи. Требования агентов будут гораздо более специфичными и детализированными, чем у людей-разработчиков.
• Появится новая модель монетизации, если каждая программа станет MCP-клиентом, а каждый API — MCP-сервером: агенты будут выбирать инструменты более динамично, основываясь на сочетании скорости, стоимости и релевантности. Это приведёт к более рыночной модели принятия решений, при которой предпочтение будет отдаваться самым производительным и модульным инструментам, а не самым распространённым.
• Документация станет критическим элементом MCP-инфраструктуры, поскольку компаниям придётся проектировать инструменты и API с четкими, машиночитаемыми описаниями (например, llms.txt) и превращать MCP-серверы в полноценные артефакты, основанные на существующей документации.
• API перестанут быть самодостаточными, хотя по-прежнему будут хорошей точкой входа. Разработчики поймут, что маппинг API на инструменты редко бывает 1:1. Инструменты — это более высокоуровневая абстракция, которая больше подходит для агентов на момент выполнения задачи. Вместо прямого вызова send_email(), агент может предпочесть функцию draft_email_and_send(), объединяющую несколько API-вызовов с целью минимизации задержек. Проектирование MCP-серверов будет ориентировано не на API, а на сценарии использования.
• Появится новый подход к хостингу, если по умолчанию всё ПО станет MCP-клиентом, поскольку характер нагрузки будет отличаться от традиционного веб-хостинга. Каждый клиентский запрос будет состоять из нескольких шагов и потребует гарантий исполнения: поддержка резюмируемости, повторных попыток, управление долгоживущими задачами. Провайдерам хостинга придётся реализовать real-time балансировку нагрузки между различными MCP-серверами с учетом стоимости, задержек и производительности — чтобы агенты могли выбирать наиболее эффективный инструмент в каждый момент времени.

MCP уже трансформирует экосистему AI-агентов, но следующий этап развития будет определяться тем, как мы решим фундаментальные проблемы. Если всё сделать правильно, MCP может стать дефолтным интерфейсом для AI-to-tool-взаимодействия и открыть дорогу новому поколению автономных, мультимодальных и глубоко интегрированных AI-решений.

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