Your investigation agent finds the root cause in seconds. Then you open four browser tabs to check whether it is right. MCP Apps bring the evidence into the chat.
Your investigation agent can hand you a root-cause hypothesis about as fast as you can read the page. A hypothesis is not yet a fix, and before you act on one in the middle of an incident you need to see the evidence for yourself. That usually means opening the observability UI in a browser, finding the trace waterfall, pulling up the service map to scope the impact, and checking each view against what the agent said, ping-ponging between tabs while the pressure builds. The agent saved you the query time and left you the tab-switching. Amazon OpenSearch Service MCP Apps move that verification into the chat thread, so the evidence arrives next to the claim. This post builds on Implement Agent Observability: Extend Your OpenTelemetry Stack on Amazon OpenSearch Service, which covers how agent telemetry joins the OpenTelemetry stack you already run.
The proof arrives with the answer
A standard MCP tool call returns text. The agent reasons over it, and you go somewhere else to check it. MCP Apps extend the protocol with a second response channel. If a standard tool call is stdout only, an MCP App writes to two streams: a structured text summary for the agent, and an interactive visualization that your chat client renders in the conversation thread for you.
A trace investigation shows how the two halves divide the work. The agent passes a trace ID, or a service name and time range, and the tool returns a summary with the trace ID, total duration, span count, critical path, and where the failure started. The agent uses that text to choose its next step, such as pulling the log entries around the failing span. Meanwhile the same response renders a trace waterfall in the thread, and you can expand spans, inspect their attributes, and confirm the root cause yourself. OpenSearch UI builds that visualization server-side by running the query against your data, so the chart is deterministic. You are looking at the actual query result, not the model's description of it.
An MCP App renders a checkout trace waterfall in the chat thread, with the span hierarchy, span details, the AI analysis, and suggested next questions in one view. The chat client, Goose in this case, renders both the text and interactive graphic response.
When checkout errors spike, the whole investigation can start from one question about the cause. The agent queries the alerts, correlates logs with traces, and checks the service map, and its reply carries those views alongside its explanation. The waterfall above comes from exactly that kind of session. The analysis points at CartService/EmptyCart failing with a FailedPrecondition error after about 15 seconds, and the span hierarchy beneath it lets you trace the failure from the load generator through checkout to the cart service yourself. The suggested follow-ups at the bottom, such as showing the logs for this trace or checking cart service health, keep the next step in the same thread, whether that is digging deeper, drafting the incident summary, or starting the remediation.
Setting up the local server
The architecture is a local MCP server that sits between your chat client and an OpenSearch UI application. OpenSearch UI is the serverless interface for observability, and it already connects to your OpenSearch Service domains, OpenSearch Serverless collections, and Amazon Managed Service for Prometheus workspaces. Each tool call goes from your client to the local server, which signs the request with your AWS credentials and forwards it to the OpenSearch UI endpoint. The server runs on your machine, and your data stays in your AWS account. You need an OpenSearch UI application with an Observability workspace connected to at least one data source, Node.js 22 or later, and credentials that allow es:ESHttpGet and es:ESHttpPost on the application. Supported clients include Claude Desktop, VS Code with GitHub Copilot, Cursor, Goose, and ChatGPT.
Download and extract the server package, then add it to your client's MCP configuration:
{
"mcpServers": {
"opensearch-observability-stack-mcp": {
"command": "node",
"args": ["/path/to/opensearch-observability-stack-mcp/server/server.js"],
"env": {
"OS_UI_ENDPOINT": "application-abc123.us-west-2.opensearch.amazonaws.com",
"AWS_REGION": "us-west-2",
"AWS_PROFILE": "my-profile"
}
}
}
}
The endpoint is the Application URL on the Applications page of the Amazon OpenSearch Service console. Restart the client and ask it to list the available observability data sources. If your domains, collections, or Prometheus workspaces come back, the connection works. The setup creates no cloud resources, so removing it means deleting the configuration entry and the local directory. The launch post walks through each step.
The chat window becomes the console
The previous post made the case for bringing application and agent telemetry together, with logs and traces in OpenSearch Service and metrics in Amazon Managed Service for Prometheus. MCP Apps are where that unification pays off for the person on call. The signals still live in several stores, but the SRE no longer has to remember which store holds which signal or which UI shows it. The agent does that routing, and the chat thread becomes one surface over every source. In that sense the agent is the new user experience for observability: you describe what you need, and the right query against the right store comes back with the right view.
Behind that surface, each tool handles a different stage of an investigation and returns the view that suits it. Triage tools surface active alerts, correlate them across data sources, and break them down by severity so the agent knows where to start. Log tools search for error patterns and cluster similar entries into a failure signature. Trace tools find the distributed trace and draw the span hierarchy and latency breakdown. To size the impact, metric tools run PromQL with threshold analysis, service performance tools report rate, errors, and duration for each service, and topology tools draw the service map with call volume and error rate on every edge. Dynamic visualization tools build line, bar, area, and metric charts from queries you describe, and a set of specialized tools covers the agents themselves, tracing LLM calls and rendering agent trace maps, alongside cluster health reports and instrumentation scoring that finds gaps in your telemetry coverage.
With those tools behind it, the console stops being a wall of dashboards you navigate and becomes a conversation you drive. You ask what is wrong, and the waterfall that shows it arrives with the answer. You ask how far it spreads, and the service map renders with the failing edges marked. You ask for the error rate since the last deploy, and the chart is built for that window when you ask, rather than waiting on a dashboard someone had to anticipate.
Trust in that conversation depends on what sits underneath it. The agent works through your permissions, and every result reports its own status. An empty result means the query finished and found nothing, which is different from a timeout, a partial scan, or a permission denial, and that status carries through each step of the investigation. The same thread can also carry the response. A runbook for a known failure can live as a skill the agent runs, so the procedure and the data it depends on show up together instead of in a wiki tab.
This approach suits teams that run observability at scale and want to own the stack: large telemetry volumes, engineers who build their own tooling, and a preference for open, extensible components. If you already run OpenSearch for logs or search, the MCP server works against the same engine and the same data you already query.
Bringing it together
Agents made root-cause analysis fast, which left verification as the slow step. Amazon OpenSearch Service MCP Apps close that gap by returning each answer twice: as text the agent reasons over, and as a deterministic visualization you can inspect in the same thread. Setup takes a local server, your existing OpenSearch UI application, and your AWS credentials, and the tools cover an investigation from the first alert to the service map. For SREs working alongside agents that investigate at machine speed, the chat window is no longer a lighter view of the observability console. It is the console.
Top comments (0)