Прекратите возвращать JSON: Отправляйте интерактивный интерфейс с приложениями MCP

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

Множество вопросов по-прежнему подходят под эту схему. Чтобы подсчитать количество успешных развертываний, не нужно ничего сложного: достаточно вызвать функцию get_deployments(), прочитать компактный объект вроде {"total": 12, "healthy": 10, "degraded": 2} и ответить одной строкой.

Ситуация меняется, когда люди хотят взаимодействовать с результатом. Дашборды, процедуры утверждения, таблицы с возможностью фильтрации, формы настройки, графики, панели развертывания, многоэтапные рабочие процессы и механизмы участия человека требуют не просто передачи данных в формате JSON. Долгое время MCP не предлагал стандарта для такого взаимодействия между хостами. Теперь же он существует под названием MCP Apps и расширяет возможности серверов MCP.

Серверы MCP в основном представляли собой интерфейсы для машин

Первая модель мышления была ориентирована на агентов. Серверы предоставляют такие инструменты, как search_projects(), create_ticket(), restart_service() и get_customer(). Модели находят их, вызывают, получают данные, а люди видят то, что модель решает показать. Это мощно, поскольку операции проходят через один протокол вместо отдельной интеграции для каждого агента. Ограничением является то, что функции были разработаны для машин, поэтому человек остается на шаг от сырых результатов.

Это нормально, пока взаимодействие не становится по своей природе визуальным. Запрос «Покажите мне все сервисы в производстве» может вернуть корректный JSON-объект с информацией о статусе, использовании CPU и памяти, однако компактная панель управления с полосками прогресса, индикаторами и элементами управления для логов, перезагрузки и масштабирования гораздо полезнее. MCP Apps призваны устранить этот разрыв.

Что же такое MCP Apps?

MCP Apps расширяет Model Context Protocol, позволяя серверам предоставлять интерактивные пользовательские интерфейсы вместе со своими инструментами — не скриншоты и не Markdown, имитирующие интерфейс, а настоящие приложения на HTML/JavaScript, отображаемые внутри хоста MCP. В документациях описывается, как инструменты объявляют ресурсы по адресу ui://, как хосты отображают эти ресурсы в изолированных iframe, а также как тот же хост одновременно вставляет данные инструментов в интерфейс и позволяет ему снова вызывать инструменты только через этот хост.

MCP App = MCP Tool + UI Resource + Host/View protocol

Инструмент по-прежнему вызывает API, запрашивает базы данных, выполняет бизнес-логику и возвращает структурированные данные. Кроме того, он может предоставлять интерфейс для отображения этих результатов. Этот интерфейс представляет собой ресурс MCP, такой как ui://services/dashboard, и может включать полноценный фронтенд — HTML, CSS, JavaScript, React, диаграммы, формы, кнопки. Таким образом, одна операция обеспечивает как возможности для взаимодействия с машиной, так и интерфейс для работы человека, стандартизированные на всех устройствах.

Откуда появились приложения MCP?

Это расширение является новым. Разработчики, выпускавшие серверы MCP до 2025 года, не упустили никаких скрытых функций; официального стандарта ещё не существовало.

В конце ноября 2025 года появился SEP-1865 — предложение по разработке приложений, созданное совместно с участниками проекта MCP-UI и администраторами крупных лабораторий по разработке моделей. Параллельные эксперименты (MCP-UI, Apps SDK) уже существовали; не хватало единого способа взаимодействия, позволяющего серверу предоставлять инструменты, данные и интерфейс, который мог бы отобразить любой совместимый хост. В статье блога MCP за ноябрь 2025 года, посвящённой предложению по приложениям, описано объявление об SEP-1865.

К концу января 2026 года та же группа объявила Apps первым официальным расширением, готовым к использованию в производстве, с более чёткими спецификациями, SDK и поддержкой со стороны хостов. ChatGPT, Claude, Goose и Visual Studio Code были названы первыми клиентами. В статье блога MCP за январь 2026 года Apps был объявлен первым официальным расширением.

Кандидат на выпуск в июле 2026 года улучшил функционал расширений в целом: стабильные идентификаторы, возможность переговоров о функциях, отдельные репозитории, независимая версионирование, а также раздел «Extensions Track», в котором перечисляются приложения. В нем также подчеркивалось, что вызовы через кнопки по-прежнему проходят через механизм JSON-RPC хоста, что позволяет держать схемы Agent → Tool и Human → Button → Tool в рамках одной плоскости управления. Статья о кандидате на выпуск в июле 2026 года на блоге MCP посвящена разделу «Extensions Track».

В сентябре 2026 года статья AWS Bedrock AgentCore показала конкретную схему хостинга, не ограничиваясь использованием только сервисов AWS: хост → шлюз → среда выполнения → сервер MCP (инструменты + ресурсы интерфейса) → Lambda/DynamoDB. В демонстрации использовался ChatGPT, и отмечалось, что хосты приложений Claude и другие работают аналогичным образом. Подробное руководство можно найти в статье на блоге AWS Machine Learning о интерактивных приложениях MCP с использованием Bedrock AgentCore.

Кто на самом деле поддерживает приложения MCP?

Поддержка MCP не является тем же, что и поддержка приложений MCP. Клиент может работать с обычными инструментами и ресурсами без внедрения расширения Apps. В объявлении от января 2026 года упоминались ChatGPT, Claude, Goose и VS Code; в текущей документации описывается встроенная отрисовка в Claude, ChatGPT и других совместимых клиентах, при этом отмечается, что поддержка хостами варьируется. Проектируйте с учётом этой реальности: не предполагайте, что каждый клиент понимает концепцию Apps. Полезная формула звучит так: Сервер поддерживает приложения MCP + Хост поддерживает приложения MCP = Интерактивный интерфейс, и ответственный сервер должен переходить на текстовую или структурированную форму представления контента, если хост не может отрисовать приложение.

Единственный вопрос, который действительно имеет значение

Если ресурс интерфейса — это статический HTML, как тогда изменения данных инструмента до него доходят? Загрузка процессора может составлять 21% сейчас и 87% через десять секунд; полная перегенерация веб-интерфейса при каждом вызове инструмента была бы абсурдной. Решение заключается в разделении: интерфейс и данные — это разные компоненты. Считайте инструмент производителем данных, ресурс — оболочкой для их отображения, а хост — связующим звеном. Инструмент возвращает динамические данные; ресурс — приложение, которое знает, как отобразить эти данные; хост соединяет их во время выполнения программы.

Как на самом деле работают приложения MCP

Рассмотрим функцию get_servers(), которая возвращает объекты серверов с полями id, name, status, CPU и memory, причем метаданные этих объектов указывают на путь ui://servers/dashboard. Жизненный цикл:

Модель вызывает функцию get_servers(). Сервер выполняет свою логику — работу с базой данных, обращение к облачным API, управление Kubernetes и внутренними сервисами — и возвращает структурированные данные. Хост получает метаданные интерфейса для ui://servers/dashboard и отправляет запрос resources/read. Сервер возвращает пакет кода фронтенда (React, Vue или обычный JavaScript). Текущие строки данных сервера не включаются непосредственно в HTML; интерфейс знает только ожидаемый формат данных (servers[].id, servers[].status и т. д.).

Хост отображает приложение в изолированном iframe, так что код интерфейса с сервера MCP не может свободно влиять на DOM хоста, сессию или учетные данные. Затем хост передает результат работы инструмента в отображаемый интерфейс, обычно через JSON-RPC с использованием метода postMessage между хостом и изолированным окном отображения.

Фронтенд получает данные так же, как и любой SPA, и отображает их соответственно. Один сервер генерирует одну карточку; пятьдесят серверов генерируют пятьдесят карточек. Приложение остается неизменным; меняются только данные.

По сравнению с классическим веб-приложением, где React вызывает GET /api/servers, в MCP Apps агент запускает tools/call, инструмент возвращает JSON, а хост вставляет этот JSON в React-приложение внутри iframe. Интерфейс не всегда загружает данные самостоятельно; хост может передать результаты напрямую.

Но MCP Apps — это не просто более красивые результаты работы инструментов

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

MCP App → call tool → Host → tools/call → MCP Server → restart_server()

Например, элемент управления «Перезагрузить» в панели управления может вызвать restart_server через хоста, вместо того чтобы создавать дополнительный канал связи:

async function restartServer(serverId) {
  return app.callServerTool({
    name: "restart_server",
    arguments: { server_id: serverId }
  });
}

Хост остается контролером разрешений, логирования и правил.

Одна функциональность, два интерфейса

Таким образом, одна и та же операция на стороне сервера может иметь два вида представления: инструмент, к которому обращается модель во время диалога, и приложение, с которым работает человек визуально. Одно не заменяет другое. Агенты остаются сильными в решении открытых задач; приложения проявляют себя лучше, когда важны структура, плотность информации или повторяющиеся действия.

Пример из практики: утверждение человеком в рамках рабочего процесса агента

Представьте, что агент составляет историю пользователя, которая должна быть одобрена перед тем, как её сохранить. Без приложений модель просто вставляет черновик в чат и надеется, что человек введёт «одобрить» или «отклонить с причинами». С помощью приложений такой инструмент, как present_user_story_for_approval, может вернуть черновик вместе с ресурсом интерфейса, содержащим элементы управления «Принять», «Попросить изменения» и «Отклонить». Нажатие на «Отклонить» открывает поле для ввода причин; отправка данных может вызвать инструмент, который записывает решение и при необходимости обновляет контекст модели, чтобы в следующем этапе она уже знала, почему версия 1 не прошла проверку.

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

Не каждая кнопка должна быть инструментом, видимым для модели

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

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

MCP Apps — это не новая базовая примитивная структура

Несмотря на название, Apps не является четвертым элементом рядом с инструментами/ресурсами/промптами. Это расширение, стандартизирующее взаимосвязь между инструментом и ресурсом интерфейса, а также протоколом хоста/представления. Если инструменты и ресурсы уже знакомы, Apps представляет собой интерактивный слой вокруг них, а не отдельный протокол, добавленный сверху.

Что изменится, если у вас будет собственное приложение чата

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

Существуют три участника — сервер MCP, хост MCP и интерфейс приложения MCP — а официальный SDK разделяет разработчиков интерфейса, хоста и сервера. Вспомогательные пакеты находятся в директории @modelcontextprotocol/ext-apps в TypeScript, что не заставляет переносить бизнес-логику в Node. MCP на уровне соединений по-прежнему использует метаданные инструментов, ресурсы, структурированный контент и запросы MCP, поэтому сервер на Python/FastMCP будет работать, если он предоставляет то, что ожидают хосты с поддержкой приложений. Интерфейс основан на веб-технологиях; существующие бэкенды могут оставаться без изменений.

Безопасность не может быть второстепенной

Выполняемый интерфейс пользователя повышает уровень риска. Использование изолированных фреймов и вызовов через хост помогает, однако каждое приложение следует рассматривать как ненадежный интерфейс — особенно когда оно может запустить restart_service(), delete_resource(), approve_payment() или deploy_to_production(). Диалоговые окна подтверждения полезны, но недостаточны. Аутентификация, авторизация, валидация, правила работы, журналы аудита, идемпотентность, проверка версий и ограничения скорости по-прежнему должны находиться на стороне бэкенда. Интерфейс пользователя не является границей доверия.

Где приложения MCP действительно имеют смысл

Не оборачивайте каждый инструмент в приложение. Для возврата кода 42 или строки с версией не требуется React. Приложения оправдывают себя тогда, когда взаимодействие имеет определенную структуру:

Панели управления операциями — сервисы, развертывания, инфраструктура, журналы, метрики, задачи, очереди: анализ и последующие действия.

Процессы утверждения — одобрение/отклонение, принятие/запрос изменений, развертывание/отмена, публикация/сохранение в черновике. Часто являются наилучшим решением для крупных предприятий.

RAG и поиск знаний в корпоративной среде — фильтры, галочки и функция «Сравнить выбранные» превосходят двадцать результатов поиска в чистом тексте, при этом агент продолжает выполнять логические операции.

Управление агентами — с помощью естественного языка можно определить, кто имеет доступ к рабочей среде Salesforce; вид реестра удобнее для проверки и утверждения изменений в правах доступа.

Формы и настройки — указание таких параметров, как «CPU 2, память 4GB, регион us-east-1, копии 3», хуже, чем использование формы, которую агент может открыть по мере необходимости.

Не создавайте отдельное приложение для каждого инструмента

Избегайте распространения конструкции tool_1 → app_1. Предпочитайте приложения, работающие в рамках домена. Приложение «Управление развертыванием» может объединять операции по получению данных, логированию, перезапуску, масштабированию и отката в единый набор. Один инструмент позволяет открыть приложение; после этого интерфейс может напрямую вызывать соответствующие операции. Интерфейс остается целостным, а структура MCP остаётся более упорядоченной.

Более значительное архитектурное изменение

Интересным изменением является не сам iframe. Операции, разработанные для агентов, теперь могут предоставлять стандартизированный интерфейс для людей:

OPERATION → Machine Interface (MCP Tool) + Human Interface (MCP App)

Если функции упакованы в плагины для агентов, пакет Salesforce может содержать инструкции, инструменты (search_accounts, create_opportunity, update_lead), разрешения, элементы оценки и приложения (браузер счетов, форма для описания возможностей, панель управления процессами). Таким образом, эта функция превращается в полноценный интерфейс взаимодействия как для агентов, так и для людей.

Агенту не обязательно знать о существовании React или iframes. Он вызывает get_services(...) или present_user_story_for_approval(...); метаданные сообщают хосту о наличии интерфейса. Интерфейс остается в слое UI, обмениваясь данными с агентом, а бизнес-логика — в бэкенде.

Как я бы внедрил это в существующую систему

На платформе, уже имеющей пользовательский чат, агентов и сервер FastMCP, избегайте полной переработки. Начните с одной функции только для чтения, такой как get_agents(), вместе с минимальным виджетом (ui://agents/list), отображающим имена, статусы и количество инструментов — без кнопок. Проверьте работу цикла: агент вызывает инструмент, хост обнаруживает интерфейс, считывает ресурс, отображает iframe, а результат работы инструмента поступает в виджет.

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

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

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

Наконец, обеспечивайте версионирование схематических контрактов. Приложение и инструмент должны соглашаться относительно названий и типов полей. Разделение поля servers[].cpu на вложенные объекты без обновления контракта интерфейса приведет к отображению пустых элементов, в то время как агент будет продолжать получать корректный JSON. Рассматривайте ожидаемый объем данных от приложения как общедоступный API, принадлежащий той же команде, что и сам инструмент.

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

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

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

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

В документации к вашему серверу необходимо четко указать варианты замены: какие инструменты объявляют ресурсы интерфейса, какие хосты способны их отображать, а также как выглядит текстовый/структурированный вариант замены при недоступности приложений. Такая документация помогает избежать заявок на поддержку вида «MCP не работает», когда на самом деле проблема заключается в хосте без включенного расширения.

Дополнительная литература

Основная документация по расширению Apps опубликована на сайте apps.extensions.modelcontextprotocol.io (разделы обзора и API). Описания сроков реализации публикуются на блоге modelcontextprotocol.io: для предложения 2025 года, объявления о внедрении в 2026 году и для версий расширений, находящихся в стадии тестирования. Блог AWS Machine Learning позже представил шаблон хостинга Bedrock AgentCore, который остается независимым от конкретного хоста.

Если сегодня у вас есть несколько серверов MCP, сдерживайте желание создавать отдельные мини-фреймворки для каждой команды. Лучше использовать общие инструменты хостинга для управления жизненным циклом iframe, общие типы TypeScript для данных инструментов, которые используют приложения, а также краткий чек-лист для проверки дизайна: нужен ли этому инструменту интерфейс? Существует ли уже приложение, которое могло бы его включить? Какова альтернатива, если хост не может отрисовать приложение? Кто отвечает за авторизацию вызовов, инициируемых кнопками? Эти четыре вопроса помогают избежать чрезмерного распространения приложений.

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

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