MCP-инструменты научились возвращать интерфейс: разбираем OpenSearch MCP Apps

Обычный MCP-инструмент возвращает агенту текст или структурированные данные. Агент анализирует результат и пишет тебе что-то вроде:

Ошибки оплаты вызваны ростом задержки в payment-service.

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

OpenSearch MCP Apps предлагает другой подход: один вызов инструмента возвращает сразу два результата:

• компактные данные для агента;

• интерактивный интерфейс для человека.

Вместе с текстовым выводом в чате появляется график, карта зависимостей или дерево трассировки. Агент продолжает расследование по структурированным данным, а ты проверяешь его вывод по первичным данным, не выходя из IDE.

Разберём, как это работает и что можно забрать в собственную архитектуру.

Почему обычного MCP-ответа недостаточно

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

Обычный сценарий выглядит так:

1. Агент получает активные предупреждения.

2. Ищет ошибки в логах.

3. Находит связанные трассировки.

4. Сравнивает задержки сервисов.

5. Формирует гипотезу о причине.

6. Возвращает текстовый отчёт.

Технически задача выполнена. Но ты видишь только пересказ результата:

За последние 15 минут доля ошибок checkout выросла до 8,2%.
Основной источник — payment-service.
Вероятная причина — увеличение времени ответа внешнего платёжного API.

Из этого ответа непонятно:

• какой именно запрос выполнялся;

• какие сервисы попали в выборку;

• насколько сильно выросла задержка;

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

• действительно ли ошибка начинается в payment-service.

Приходится открывать Grafana, OpenSearch Dashboards или другую панель и проверять всё вручную.

Получается странная автоматизация: агент исследует систему за секунды, а инженер после него ещё несколько минут воспроизводит исследование.

Что меняют MCP Apps

MCP Apps расширяют обычную модель вызова инструмента. Ответ теперь предназначен сразу двум потребителям.

Агент получает компактные структурированные данные:

{
  "service": "payment-service",
  "error_rate": 0.082,
  "baseline_error_rate": 0.004,
  "critical_span": "POST /payment/authorize",
  "p95_latency_ms": 4830,
  "suspected_dependency": "bank-gateway"
}

Человек получает интерактивное представление тех же результатов:

• дерево трассировки;

• временной график;

• карту сервисов;

• таблицу ошибок;

• распределение задержек;

• результат PromQL-запроса.

Это не картинка, нарисованная моделью по собственному пересказу. OpenSearch UI выполняет запрос по фактическим данным и строит виджет на стороне сервера. LLM может ошибиться в интерпретации, но сам график отражает результат выполненного запроса.

Именно здесь появляется нормальное разделение ответственности:

• агент ищет, сопоставляет и предлагает гипотезу;

• детерминированный код получает и визуализирует данные;

• человек проверяет вывод и принимает решение.

Как устроена архитектура

Схема состоит из трёх основных частей:

IDE или AI-клиент
        │
        │ MCP tool call
        ▼
Локальный MCP-сервер
        │
        │ HTTP + AWS credentials
        ▼
OpenSearch UI
        │
        ├── OpenSearch Domain
        ├── OpenSearch Serverless
        └── Amazon Managed Prometheus

Локальный MCP-сервер выступает мостом между агентом и OpenSearch UI.

Когда агент вызывает инструмент:

1. IDE отправляет MCP-запрос локальному серверу.

2. Сервер использует настроенные AWS-учётные данные.

3. OpenSearch UI выполняет запрос по логам, метрикам или трассировкам.

4. Сервер возвращает текстовую и визуальную части ответа.

5. Агент читает структурированный результат.

6. IDE отображает интерактивный виджет человеку.

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

Подключаем MCP-сервер

Для запуска потребуется:

• OpenSearch UI с рабочим пространством наблюдаемости;

• Node.js 22 или новее;

• AWS-профиль с нужными правами;

• клиент, поддерживающий MCP Apps.

После загрузки сервера его можно подключить к VS Code примерно так:

{
  "servers": {
    "opensearch-observability": {
      "type": "stdio",
      "command": "node",
      "args": [
        "/opt/opensearch-mcp/server/server.js"
      ],
      "env": {
        "OS_UI_ENDPOINT": "application-example.eu-central-1.opensearch.amazonaws.com",
        "AWS_REGION": "eu-central-1",
        "AWS_PROFILE": "production-readonly"
      }
    }
  }
}

Для других клиентов структура может немного отличаться, но параметры остаются теми же:

• путь к server.js;

• адрес OpenSearch UI;

• регион AWS;

• профиль доступа.

После перезапуска клиента можно проверить соединение простым запросом:

Покажи доступные источники данных для наблюдаемости.

Если всё настроено правильно, агент вернёт подключённые домены OpenSearch, коллекции Serverless или рабочие пространства Prometheus.

Ограничиваем права

Для расследования инцидентов агенту обычно не нужны права на изменение инфраструктуры. Достаточно разрешить чтение через OpenSearch UI.

Упрощённая политика может выглядеть так:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OpenSearchObservabilityRead",
      "Effect": "Allow",
      "Action": [
        "es:ESHttpGet",
        "es:ESHttpPost"
      ],
      "Resource": [
        "arn:aws:es:eu-central-1:123456789012:application/*"
      ]
    }
  ]
}

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

Но выдавать es:* всё равно не стоит. Лучше отдельно создать профиль вроде production-readonly и разрешить ему только необходимые приложения и источники.

AWS_PROFILE=production-readonly \
aws sts get-caller-identity

Также полезно:

• использовать краткоживущие учётные данные;

• разделять профили по окружениям;

• запретить агенту доступ к административным API;

• журналировать запросы;

• ограничивать доступ по конкретным ARN.

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

Пример расследования

Представим, что после выпуска новой версии выросло число ошибок оформления заказа.

Ты пишешь агенту:

Разберись, почему за последние 30 минут выросло число ошибок checkout.
Сначала проверь предупреждения, затем логи, трассировки и карту зависимостей.
Ничего не изменяй.

Агент может построить такую цепочку:

list_alerts
    ↓
investigate_service_logs
    ↓
find_related_traces
    ↓
inspect_trace
    ↓
render_service_topology

Для проверки метрик он может выполнить PromQL-запрос:

sum(
  rate(
    http_server_requests_total{
      service="checkout-service",
      status=~"5.."
    }[5m]
  )
)
/
sum(
  rate(
    http_server_requests_total{
      service="checkout-service"
    }[5m]
  )
)

В ответе ты увидишь не только фразу «ошибки выросли», но и график изменения доли ошибок.

Следом агент изучит трассировки и получит, например, такую цепочку:

checkout-service        5.1 s
└── order-service       4.9 s
    └── payment-service 4.8 s
        └── bank-api    4.6 s ERROR

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

После этого агент формирует проверяемый вывод:

После выпуска checkout-service число ошибок выросло с 0,4% до 8,2%.

Новая версия checkout-service сама по себе не является источником ошибки.
96% неуспешных трассировок останавливаются на вызове
payment-service -> bank-api.

У bank-api p95 вырос с 410 мс до 4,6 с.
Рекомендую проверить состояние внешнего шлюза и временно снизить
тайм-аут повторных попыток. Изменения не выполнялись.

Инженер проверяет трассировку и график прямо в том же диалоге. Если доказательства подтверждают вывод, можно попросить агента подготовить тикет или план исправления.

Какие инструменты уже доступны

OpenSearch MCP Apps покрывают основные этапы расследования:

• поиск и группировка активных предупреждений;

• анализ шаблонов в логах;

• поиск распределённых трассировок;

• просмотр дерева участков и критического пути;

• выполнение PromQL-запросов;

• анализ RED-метрик: частота, ошибки, длительность;

• построение карты сервисов;

• сопоставление логов, метрик и трассировок;

• проверка состояния кластера и распределения сегментов;

• трассировка вызовов LLM и самих агентов;

• поиск пробелов в телеметрии.

Особенно интересна наблюдаемость за агентами. Вместо одной длинной трассировки HTTP-запроса можно увидеть:

user_request
└── planner
    ├── search_logs
    ├── inspect_trace
    ├── query_metrics
    └── root_cause_analysis

Так проще понять:

• какой инструмент выбрал агент;

• какие аргументы передал;

• сколько занял каждый шаг;

• где произошла ошибка;

• почему выросла стоимость;

• не зациклился ли агент на повторных вызовах.

Что здесь действительно нового

Главная идея не в том, что график переехал из браузера в IDE. Важнее изменение контракта между инструментом, агентом и человеком.

Раньше MCP-инструмент фактически отвечал только агенту:

tool → data → agent → text → human

Теперь инструмент может отвечать им обоим:

                 ┌─ structured data → agent
tool execution ──┤
                 └─ interactive UI → human

Эту схему можно применять далеко за пределами наблюдаемости.

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

• агенту — список таблиц, столбцов и связей;

• человеку — интерактивный граф происхождения данных.

Инструмент развёртывания может вернуть:

• агенту — состояние выпуска и результаты проверок;

• человеку — различия конфигурации и кнопку подтверждения.

Инструмент управления доступом может вернуть:

• агенту — результат проверки политики;

• человеку — форму согласования с перечнем выдаваемых прав.

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

Ограничения и риски

Нужна поддержка со стороны клиента

Обычный MCP-клиент прочитает текстовую часть, но может не показать интерфейс. Перед внедрением нужно проверить поддержку MCP Apps в конкретной версии IDE или приложения.

Виджет не доказывает правильность гипотезы

График показывает фактический результат запроса. Но агент всё ещё может:

• выбрать неправильный интервал;

• отфильтровать не тот сервис;

• перепутать причину и следствие;

• проигнорировать альтернативную гипотезу.

Поэтому вместе с визуализацией стоит показывать параметры исходного запроса.

Локальный сервер получает чувствительный доступ

MCP-сервер работает с AWS-учётными данными. Его нужно рассматривать как обычный производственный клиент:

• проверять источник пакета;

• проверять подпись загруженного файла;

• фиксировать версию;

• ограничивать права;

• контролировать обновления;

• не передавать секреты через аргументы командной строки.

Интерфейс тоже является входными данными

Если MCP App строится сторонним сервером, его содержимое нельзя автоматически считать доверенным. В общем случае виджет может содержать ссылки, формы и действия.

Для собственных MCP Apps нужны:

• изоляция отображаемого интерфейса;

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

• строгая схема сообщений между виджетом и клиентом;

• явное подтверждение изменяющих операций;

• защита от внедрения команд через данные.

Что стоит забрать в собственную систему

Даже если ты не используешь OpenSearch, из этой архитектуры можно вынести несколько практических правил.

Первое: инструмент должен возвращать первичные данные, а не только готовый вывод.

Второе: результат для модели и результат для человека могут отличаться. Агенту нужен компактный JSON, человеку — удобное представление и возможность проверить детали.

Третье: действия и доказательства нужно разделять. Поиск логов можно выполнять автоматически, а перезапуск сервиса — только после подтверждения.

Четвёртое: безопасность должна обеспечиваться правами среды выполнения. Промпт не заменяет IAM, песочницу и журнал аудита.

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

Итог

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

Агент получает структурированные данные и продолжает рассуждение. Ты получаешь интерактивное представление фактического результата и проверяешь вывод в том же диалоге.

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

Ссылки:

• Технический разбор OpenSearch MCP Apps

• Официальная документация AWS

• tg