MCP UI для интерактивной карточки в чате агента сегодня строят через официальное расширение MCP Apps: инструмент связывают с UI resource, хост показывает форму в изолированном iframe, а запись подтверждают через сервер. Поисковый запрос также ведёт к прежнему проекту MCP-UI, из идей которого выросло расширение. Для рабочего процесса пригодность решения зависит от поддержки MCP Apps конкретным хостом и от серверной проверки прав.
Где проходит граница
MCP Apps — официальное расширение MCP для интерфейса внутри разговора; базовые вызовы инструментов остаются отдельным механизмом. Проект MCP-UI предшествовал расширению и продолжает жить как самостоятельная разработка.
Статья про инструменты MCP-сервера объясняет, как агент вызывает действие и получает текст либо структурированный результат. Интерактивная карточка добавляет человеку поля, выбор и явное подтверждение прямо в беседе. Согласно блогу сопровождающих MCP, MCP Apps стало официальным расширением, выросшим из работы MCP-UI и других проектов интерфейса. Поэтому название старого проекта полезно для поиска истории и совместимости, но наличие базового MCP само по себе UI хосту обещать нельзя.
| Слой | Задача | Результат для пользователя |
|---|---|---|
| MCP tool | Вызвать действие на сервере | Текст или структурированный ответ |
| UI resource | Описать шаблон карточки | Поля и состояние формы |
| Хост с MCP Apps | Показать изолированное представление | Карточка в разговоре |
| Бизнес-сервер | Проверить право и подтвердить запись | Проверенный статус заявки |
В спецификации MCP Apps интерфейс обозначен ресурсом с адресом ui://, а инструмент ссылается на него через _meta.ui.resourceUri. Клиент и сервер объявляют поддержку расширения при соединении. Если хост поддерживает только обычные инструменты, тот же сценарий должен возвращать понятный текстовый результат. Это практический тест выбора хоста, а также защита от ситуации, когда красивая карточка видна лишь автору демонстрации.
Заявка внутри чата
Для проектной схемы возьмём форму согласования внутренней заявки на закупку. Сотрудник описывает потребность агенту, а карточка показывает выбранную позицию из разрешённого каталога, количество, назначение, ответственного и состояние заявки. Агент помогает составить пояснение из сообщения сотрудника, но исходные поля пользователь просматривает сам. Карточка показывает источник каждого поля и даёт исправить значение перед отправкой. Такой пример служит описанием будущего пилота, без рассказа о работающем внедрении.
Сервер сначала отдаёт черновик с идентификатором, допустимыми вариантами выбора и статусом. UI resource задаёт внешний вид формы, а результат инструмента несёт содержимое для отображения. Разделение шаблона и содержимого следует официальному обзору MCP Apps. Кнопка «Проверить» может вызвать инструмент через хост; кнопка «Подтвердить» направляет отдельный запрос на сервер. Сервер повторно читает состояние заявки, проверяет роль пользователя и валидность полей, затем возвращает новый статус.
Форма показывает человеку границу между предложением агента и записью в системе. Если каталог изменился или заявка уже закрыта, сервер отвечает ошибкой состояния и предлагает обновить карточку. Текст агента поясняет причину, а интерфейс сохраняет исправляемые поля. Такой порядок особенно важен для действий с последствиями. Статус «подтверждено» берут из ответа серверной системы. Уверенный текст языковой модели остаётся пояснением. Для архитектуры самого сервера полезен разбор инструментов собственного MCP-сервера.
Вопрос для проектирования здесь конкретный: какое решение сотрудник должен увидеть и принять в карточке? Если ответ ограничен чтением статуса, достаточно текстового инструмента. Если требуется выбор из вариантов, исправление полей и подтверждение, интерактивная форма получает ясную рабочую роль.
Сборка карточки
Процесс начинается с описания бизнес-действия на сервере: получить черновик, проверить ввод, подтвердить запись и прочитать статус. Для каждого действия задайте входные поля и результат. Подготовьте также текстовое представление, чтобы агент и хост без расширения могли объяснить состояние заявки. В документе приёмки отделите отображаемые поля от полей, которые сервер вычисляет из учётной системы: пользователь должен понимать, что именно он вправе исправлять.
- Зарегистрируйте инструмент чтения заявки и UI resource с адресом ui://. Укажите связь в метаданных инструмента через _meta.ui.resourceUri.
- Проверьте объявленную поддержку io.modelcontextprotocol/ui у хоста. Для неподдерживающего хоста сохраните текстовый ответ и обычный порядок подтверждения.
- Передайте карточке результат чтения и покажите черновик, ошибки полей и текущий статус. Для полного списка позиций примените парсер или скрипт; ИИ лишь объясняет выбор и возможные расхождения.
- Свяжите действие подтверждения с отдельным инструментом сервера. Перед записью сервер проверяет роль, допустимость полей и актуальное состояние заявки.
По спецификации хост считывает ресурс через resources/read и помещает представление в iframe. Представление обменивается сообщениями с хостом, а обращение к серверным инструментам проходит через хост. Для команды это означает отдельные проверки шаблона, результата инструмента и серверного действия. Рабочая карточка должна сохранять понятное поведение при ошибке чтения, отмене подтверждения и повторном открытии заявки.
Если в проекте уже есть средства отображения MCP-UI, сравните их возможности с требованиями официального расширения, прежде чем менять код. При похожем назначении протокол обмена сообщениями и порядок согласования возможностей хоста могут различаться.
Изоляция и подтверждение
MCP Apps требует изолированного iframe для представления. Хост управляет загрузкой интерфейса и ограничениями на внешние источники через правила безопасности содержимого. Изоляция снижает риск прямого доступа карточки к окружению чата. Право на бизнес-операцию определяет сервер. Перед запуском формы команда проверяет, какие адреса она запрашивает и какие полномочия ей действительно нужны. Обращения к инструментам проходят через хост; сервер решает, разрешать ли чтение и запись конкретному пользователю.
Для заявки полезно разделить кнопки «Проверить» и «Подтвердить». Первая показывает ошибки, конфликты каталога и последствия выбранных полей. Вторая явно спрашивает согласие человека и передаёт действие серверу. Сервер сверяет роль, состояние записи и разрешённые значения, сохраняет событие аудита и отвечает новым статусом. Если модель повторит старый текст подтверждения, запись всё равно опирается на текущие серверные проверки. Механизм прав и секретов ИИ-агента раскрыт отдельно; здесь он применён к конкретной карточке.
Карточка может выглядеть убедительно даже при устаревшем статусе. Перед отправкой покажите пользователю значения, которые сервер собирается сохранить, и понятный результат проверки. Ошибка сервера возвращает форму в состояние редактирования с причиной, а успешное действие получает новый статус из системы учёта.
Такой контроль помогает превратить нажатие в проверяемое решение. В пилоте полезно заранее записать, какое поле требует ручного выбора и какая ошибка блокирует запись. По этим условиям оценивают надёжность формы; внешний вид проверяют отдельно.
Хотите проверить карточку заявки для вашего агента?
Приёмка рабочего сценария
Предложите пилот на обезличенной заявке и согласованном каталоге тестовых позиций. Сначала откройте форму в хосте с объявленной поддержкой MCP Apps, затем вызовите тот же инструмент в хосте с текстовым режимом. Оба пути должны сообщать одинаковый статус заявки и одинаковые причины отказа. Такая проверка измеряет пригодность сценария для разных клиентов без обещания универсальной совместимости каждого продукта. Факт поддержки конкретного хоста сверяйте по его текущей документации и тесту соединения.
- Проверьте загрузку UI resource, отображение полей и передачу результата инструмента в изолированное представление.
- Убедитесь, что карточка показывает источник значений и предоставляет пользователю возможность исправить разрешённые поля.
- Откройте заявку с закрытым статусом и проверьте, что сервер отклоняет попытку записи с понятной причиной.
- Повторите отправку после изменения каталога и убедитесь, что итоговый статус приходит из серверной системы.
- Проверьте текстовый путь для хоста без расширения и соответствие сообщения реальному статусу заявки.
После предложенного испытания владелец процесса сможет утвердить поля и правила подтверждения. Разработчик проверит инструмент и ресурс, специалист по безопасности проверит права и изоляцию. ИИ объясняет сотруднику ошибки и предлагает исправление формулировки, человек сверяет содержимое заявки. Для массовых выгрузок и расчётных полей оставьте парсер или скрипт: языковая модель подходит для объяснения, но итоговые значения нужно проверять по источнику.
Стоимость такого проекта зависит от готовности серверных действий, состава формы, требований к хосту и объёма проверок. Если нужен агент с карточкой внутри рабочего процесса, обсудите состав работ на странице разработки ИИ-агентов. Для разговора подготовьте схему статусов, список полей, правила доступа и описание действия, которое требует явного подтверждения сотрудника.