One call, two outputs
The design puts a local MCP server between an agentic development environment and the OpenSearch UI application. The agent's tool call reaches that server, which authenticates with configured credentials and forwards the request over HTTP to the OpenSearch endpoint. OpenSearch runs the query against connected data sources and sends the result back along the same path.[1]
The result is prepared for two different readers. A structured text summary feeds the agent's next reasoning step, while an interactive view opens in the development environment for the human. AWS says the visualization is generated server-side against the customer's actual data and therefore matches the corresponding OpenSearch dashboard deterministically.[1]
Verification joins the workflow
In AWS's trace-investigation example, the agent sends a trace ID or a service name and time range. The text output carries the trace ID, total duration, span count, critical path, and an analysis of where the failure began. The visual side of the same response opens an interactive waterfall showing the span hierarchy, timing, and error annotations.[1]
This split moves the handoff between querying and human verification into one response object. The agent can continue looking for related logs while the person inspects the waterfall in the same thread. AWS provides no comparative timing measurement, however; if the embedded view lacks enough detail, the user may still open the full dashboard and the context-switching gain may disappear.[1]
The new boundary sits in the local bridge
Setup requires an OpenSearch UI application whose observability workspace is connected to at least one data source. The local server needs Node.js 22 or later and AWS credentials carrying the es:ESHttpGet and es:ESHttpPost permissions. AWS lists Claude Desktop, VS Code with GitHub Copilot, Goose, ChatGPT, and Cursor as compatible clients. The access boundary is therefore set by the local server's credentials and the OpenSearch application's permissions rather than by the model.[1]
The design fits work where the visual a human must verify and the text an agent must consume come from the same query. A team choosing it can track two numbers: time from a proposed root cause to a verified result, and the number of times an investigator leaves the thread. If neither measure improves against a text-only tool call, the in-chat chart has not created a new workflow; it has only moved the dashboard into a smaller frame.[1]