Amazon OpenSearch Puts Trace and Service-Map Widgets Into MCP Agent Chats

Amazon OpenSearch Service has added MCP Apps, a Model Context Protocol extension that places interactive observability views beside an AI agent’s text response. The design targets a workflow AWS says often requires engineers to leave the conversation to inspect the traces, logs, and service relationships behind an agent’s root-cause hypothesis.

The verification step moves closer to the diagnosis

The underlying protocol normally returns text from a tool call. MCP Apps add a second payload that a compatible AI assistant or IDE can render as an interactive widget in the conversation. Amazon says the widgets are generated server-side from the same data sources that power its dashboards, rather than being a model-created approximation of the results.

That distinction is central to the product’s pitch. A model can summarize a failing checkout service or suggest a root cause, while the engineer can inspect a trace waterfall or dependency graph in the same thread. Amazon describes the rendered result as deterministic: it is based on the underlying query result and intended to match the corresponding OpenSearch dashboard.

From alert triage to the trace itself

The available apps cover several stages of an investigation. They can surface alerts, search and cluster log patterns, investigate distributed traces, run metrics queries, and draw service topologies. The trace tool can return a span hierarchy, timing details, and error annotations; the service map shows dependencies alongside call volume and error rates.

OpenSearch UI can connect these tools to OpenSearch Service domains, OpenSearch Serverless collections, and Amazon Managed Service for Prometheus. Amazon also lists tools for tracing large language model calls and agent workflows, plus cluster-health and telemetry-quality checks. That makes the release broader than a single trace viewer, though all of the views remain tied to the data sources an organization has connected.

A local bridge is still the entry requirement

This is not a browserless connection with no setup. The documented architecture requires an OpenSearch UI application with an Observability workspace, a locally installed MCP server, Node.js 22 or later, and AWS credentials carrying es:ESHttpGet and es:ESHttpPost permissions. The server runs locally and connects the client to the OpenSearch UI endpoint.

Amazon’s setup guide names Claude Desktop, VS Code with GitHub Copilot, Goose, ChatGPT, and Cursor among compatible clients. The next operational question is how consistently those hosts render and support the interactive payload in day-to-day on-call work. For now, the release shifts the evidence-review interface into the agent conversation, while leaving the data, permissions, and local connection under the customer’s AWS configuration.