Виджет в чате нужен, когда человек должен сам смотреть, фильтровать, сравнивать или пройти шаги, не открывая новый запрос на каждое движение. Обычного инструмента хватает, когда ответ — цифра, короткий список или вывод, который модель может пересказать словами. MCP Apps — не отдельная программа и не «ещё один метод». Это способ показать заранее объявленный экран внутри разговора.

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

Экран вместо пересказа. Фильтр остаётся у человека

Что такое MCP Apps

По текущей документации MCP Apps сервер может отдать интерактивный HTML, а хост показывает его в чате: график, форму, панель, просмотр файла. Обычный инструмент на этом месте возвращает текст, картинку, ресурс или структурированные данные, и хост показывает их как часть разговора. Модель может свернуть это в пересказ: анонс как раз описывает сводку там, где человеку нужно самому покрутить данные. Виджет человек видит сам.

Связка короткая, и это факт документации, не схема внедрения. Инструмент в описании указывает _meta.ui.resourceUri на ресурс со схемой ui://. Хост забирает HTML. Веб-хосты обычно рисуют его в sandboxed iframe внутри разговора. Виджет и хост говорят по JSON-RPC поверх postMessage. Один пример ссылки, не рецепт сборки: ui://charts/interactive. Так в анонсе от 26 января 2026 года показан ресурс для интерактивного графика.

Первый тип содержимого в SEP-1865 — HTML text/html;profile=mcp-app. Предложение создано 21 ноября 2025 года, статус Final, дорожка Extensions. Страница сама называет текст исторической записью принятого дизайна, не живой спецификацией, и отсылает к текущим требованиям. Живые формулировки я беру из обзора, дату «это стало официальным расширением» — из анонса.

26 января 2026 года MCP Core Maintainers написали, что MCP Apps вышли как официальное расширение и что это первое официальное расширение протокола. Это их слова про протокол. Не «первый в России» и не мой продукт.

Чем ответ инструмента отличается от экрана

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

Обычный ответ человек читает в пересказе модели. Другой срез — новое сообщение: «только Москва», «отсортируй по выручке», «что в этой строке». Для одного числа это нормальный режим.

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

Как автор разбора на Хабре разводит поля ответа. DreamShaded, компания Сбер, заголовок «30 лет красивых интерфейсов — и вот снова текст». Страницу я читала 2 октября 2026 года. В шапке была относительная метка времени, календарной даты публикации извлечённый текст не содержал, поэтому дату выхода я не ставлю. В его формулировке content — текст для модели и для хоста, который виджет не рисует, а structuredContent — данные для виджета. Это слова автора разбора. На обзорной странице MCP Apps этих имён полей я не нашла и обзору их не приписываю.

Вывод, не свойство протокола. Виджет не умнее инструмента. Он показывает то, что текстом человек будет переспрашивать.

Обычный инструмент Виджет ui://
Что приходит Текст, картинка, ресурс или структурированные данные Заранее объявленный HTML, на который ссылается инструмент
Кто смотрит Модель пересказывает Человек видит и нажимает
Если хост экран не умеет Ответ и так текст Расширение необязательное: клиент продолжает работать. Текст на месте, если сервер отдал его в content
Когда лишнее Редко: это базовый слой Когда ответ укладывается в одну реплику

Когда я прошу виджет

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

Много цифр, которые надо крутить. «Продажи по регионам» списком модель отдаст. Карта или таблица, где человек сам открывает регион и переключает метрику, снимает следующий запрос.

Форма со связанными полями. Десяток зависимых выборов в чате превращается в допрос. На экране видны поля сразу, значения по умолчанию и ошибка рядом с полем.

Документ или картинка, которые надо смотреть, а не описывать. PDF, превью, объект, который крутят. Фраза «на третьей странице абзац» — не просмотр.

Живой статус. Если человек раз за разом спрашивает «ну что сейчас», экран может обновляться без нового вопроса. Это не правило «любой дашборд переносим в чат».

Цепочка шагов: сравнить, отметить, согласовать, перейти дальше. Состояние остаётся на экране, а не в четвёртой реплике.

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

Рядом жёсткая оговорка обзора. Если сценарию эти свойства не нужны, обычное веб-приложение может быть проще. Я не тащу в чат каждый отчёт только потому, что протокол умеет экран.

Когда хватает обычного инструмента

Один ответ. Один показатель за вчера, проверка факта, короткий список, который никто не фильтрует руками. Модель пересказывает. Экран здесь лишняя сложность: его надо объявить заранее, хост должен уметь его нарисовать, человеку надо понять, куда нажать.

Разовое действие, которое и так спрашивает подтверждение, тоже не повод рисовать панель ради одной кнопки.

Инструмент в этих случаях не «хуже». Он приносит данные. Виджету без этого слоя нечего показывать.

Где экран живёт и почему это не страница сайта

Виджет живёт внутри чата конкретного хоста. Это не страница на сайте и не программа, которую читателю надо ставить отдельно. Поддержка — свойство клиента. Протокол сам по себе экран не гарантирует.

На обзорной странице в день чтения, 2 октября 2026 года, названы Claude, Claude Desktop, VS Code с GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam и Archestra.AI. Страница отсылает к матрице клиентов, так что перечень я не считаю вечным.

Январский анонс — другая дата и другой список. 26 января 2026 года там были Claude, Goose, Visual Studio Code Insiders и ChatGPT с оговоркой «starting this week». Для текущего списка я беру обзор, не январский пост. В обзоре от 2 октября ChatGPT в перечне нет. На Хабре в тот же день написано, что ChatGPT подключился в числе первых. Эти два предложения я не склеиваю. Пока обзор ChatGPT не называет, я не пишу, что виджет там откроется.

Cursor в этом обзоре тоже не назван. Одинакового экрана в Claude, ChatGPT и Cursor из этих страниц не следует.

Песочница — ограничение, не лозунг. По обзору виджет в iframe не читает страницу хоста, не забирает куки и не выходит из контейнера. Канал — postMessage. В SEP-1865 iframe-песочница названа обязательной частью принятой модели. В текущем обзоре формулировка мягче: веб-хосты обычно рисуют так. Я не додумываю, как устроен хост, которого нет в списке.

Вызов из виджета — не самостоятельный поход в чужой сервис. В анонсе прямо сказано: хост может потребовать явное согласие человека на вызов инструмента, который инициировал интерфейс. Виджет не «сам открывает» Метрику, Директ или CRM. Данные приносит инструмент сервера, если такой инструмент есть. Виджет просит хост, хост решает.

Если хост расширение не согласовал, старый клиент не обязан рисовать экран. SEP-1865 описывает расширение как необязательное: его надо явно согласовать, существующие реализации продолжают работать без изменений. Чтобы на таком клиенте не осталась пустота, в разборе на Хабре нужен текстовый content. Это вывод из двух источников, не обещание любого чата. Я бы закладывала текст всегда, даже когда виджет есть.

Что это не значит для работы с клиентом

Я не продаю готовый виджет и не прошу поставить его из коробки.

На странице каталога MCP Panel, текст которой я читала 2 октября 2026 года, в коробке семь коннекторов: Яндекс Метрика, Roistat, Яндекс Директ, Wordstat, Яндекс Вебмастер, amoCRM и UniSender. Коннектора MCP Apps в этом списке нет. Карточки описывают доступ к данным сервиса. Строки ui:// на прочитанной странице нет. Коннектор отдаёт данные. Виджет показывает экран в чате. Смешивать их в одну кнопку установки нечего. Каталог — контур cheremisina.ru. Здесь я решаю, нужен ли экран, а не ставлю платформу.

Навык — не виджет. Навык — инструкция для модели. Виджет — экран для человека. Дальше эту тему я здесь не разбираю.

Отдельная страница иногда честнее чата. Обзор называет то, чего нет у чужой вкладки: разговор не рвётся; виджет может вызвать инструмент своего MCP-сервера, а хост — прислать свежий результат; действие можно попросить у возможностей, которые уже подключены в хосте, и только с согласия человека; чужой HTML сидит в песочнице. Если ни одно из этого не нужно, я оставляю обычную страницу. Это оговорка документации, не вкус.

Один вопрос перед виджетом

Уберите экран мысленно. Если человек всё равно получит ответ словами, виджет не нужен. Если без экрана начнётся серия «покажи ещё раз, но только вот это», экран стоит обсудить. Это рекомендация к решению, не результат замера.

Второе условие обязательное. Хост, которым человек реально пользуется, должен уметь рисовать расширение. Не умеет — остаётся текст, и это нормальный исход, не сломанный сценарий.

Как проверить, не на глаз. На одном повторяющемся вопросе посчитайте уточняющие реплики до решения: отдельно без виджета и отдельно на том клиенте, где экран реально рисуется. Меньше реплик, и решение не уехало в соседнюю вкладку — пилот есть смысл продолжать. Столько же реплик — остановитесь на инструменте. Срок и порог я не беру из исследования. Их надо задать до пилота, иначе «стало удобнее» ничего не докажет.

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

Вопросы, которые мне задают

MCP Apps — это отдельная программа, которую надо ставить?

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

Чем виджет в чате отличается от обычного инструмента MCP?

Инструмент приносит текст или данные, модель их пересказывает. Виджет — экран в том же чате. Инструмент при этом остаётся.

Если мой чат виджеты не умеет, ответ пропадёт?

Не должен, если сервер отдал текст в content. Расширение необязательное. Не любой чат нарисует экран. Пустой ответ без текста — дыра сервера, не свойство протокола.

Это то же самое, что коннектор в MCP Panel?

Нет. В каталоге семь коннекторов, MCP Apps среди них нет. Коннектор даёт данные. Виджет показывает экран.

Можно ли так показать Метрику или Директ панелью прямо в чате?

Страница каталога описывает доступ к данным, не ресурс ui://. Панель в чате — отдельная работа, и только если без неё цифры не читаются. Готовым коннектором я её не продаю.

Навыки и MCP Apps — это одно и то же?

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

Источники

Проверено 2 октября 2026 года.

  1. Обзор MCP Apps, текущая документация. https://modelcontextprotocol.io/extensions/apps/overview
  2. Анонс MCP Core Maintainers, 26 января 2026. https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/
  3. SEP-1865, статус Final, историческая запись, создан 21 ноября 2025. https://modelcontextprotocol.io/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp
  4. DreamShaded, «30 лет красивых интерфейсов — и вот снова текст», Хабр, компания Сбер. Календарной даты в извлечённом тексте нет. https://habr.com/ru/companies/sberbank/articles/1089106/
  5. Каталог коннекторов MCP Panel. https://cheremisina.ru/connectors/
Любовь Черемисина
Стратегический маркетолог · Fractional CMO · AI-интегратор
20 лет в digital-маркетинге. Более 100 компаний в работе как директор по маркетингу на аутсорсе. Строит AI-нативные команды и внедряет ИИ-агентов в бизнес-процессы по собственной методологии. Основатель Gettalent и Proenter, сооснователь Reffocus.