Agentic observability with Amazon OpenSearch Service MCP Apps

Observability brokers are quick. They question alerts, correlate logs with traces, and produce a root trigger speculation in minutes. The half that also takes time is verification. You learn the agent’s textual content abstract, open your observability instruments in a browser, navigate to the hint waterfall, test the service map to scope impression, and cross-reference what the agent informed you towards what you see on display screen. The agent saved you the question time. It didn’t prevent the tab-switching, context-carrying, manual-verification time. That’s nonetheless your job.

Amazon OpenSearch Service MCP Apps shut that hole. MCP Apps lengthen the Mannequin Context Protocol so that every device name responds with an interactive visualization — a hint waterfall, a service topology, a log sample view — rendered immediately in your AI assistant’s chat window alongside the textual content response. You ask the agent to research. The agent queries Amazon OpenSearch Service. The response arrives with each a textual content rationalization and the related dashboard widget. You confirm in the identical thread the place you requested the query, with out opening a separate browser tab or re-running a question.

On this publish, we clarify how MCP Apps change your observability workflow and stroll via setup step-by-step.

The issue: Verification nonetheless requires leaving the agent loop

The everyday investigation loop proceeds as follows. First, the engineer asks the agent and will get a text-based root trigger speculation. Subsequent, they go away the IDE to open a browser and log in to a separate observability UI. They then re-run queries manually to breed what the agent discovered, in a unique device. After verifying visually by evaluating the agent’s textual content output towards precise dashboards, they return to the agent and resume the dialog, having misplaced their place within the investigation.

The agent generates a response in seconds, however it’s essential to go away the agent’s atmosphere to confirm. This implies logging in to a separate observability expertise and navigating dashboards manually. This exterior verification loop is the bottleneck. It forces you right into a tool-switching position that undermines the pace benefit of agentic automation.

Organizations operating agentic observability regionally selected management and value effectivity over vendor-provided AI. However this alternative has traditionally include a trade-off: native agentic setups sacrifice ease of use and typically agent efficiency in comparison with vendor-hosted options that tightly couple AI with their providers. For these groups, the verification hole is the first operational burden. They optimized for autonomy, but verification nonetheless occurs at human pace, in a separate observability device.

The answer: MCP Apps deliver an observability UI into your IDE

Amazon OpenSearch Service now helps MCP Apps, a functionality that extends MCP with a twin response sample.

When your AI agent calls an MCP App device, the response comprises two elements. The primary is a textual content abstract with concise, structured knowledge. The second is an interactive visualization rendered in the identical dialog thread so that you can overview. OpenSearch MCP App generates the visualization by executing code towards the identical knowledge sources that energy your dashboards. Due to this, the outcomes are deterministic. You’re not trusting the AI’s interpretation. You’re seeing the precise question end result rendered as an interactive chart, hint waterfall, or service map.

The way it works

The MCP Apps functionality consists of an area MCP server, your IDE, and your OpenSearch UI utility working collectively. This part explains the structure, the protocol extension mechanism, and the end-to-end circulation of a single device name.

Structure

A native MCP server runs in your machine. It acts as a safe bridge between your agentic IDE and your OpenSearch UI utility. The server exposes observability instruments that your AI agent can name. Every device name goes via the MCP server to your OpenSearch UI endpoint, executes the question, and returns the twin response again to your IDE. OpenSearch UI is the serverless interface for unified observability that works with OpenSearch domains, serverless collections, CloudWatch, and Amazon Managed Service for Prometheus (study extra about OpenSearch UI).

The next diagram reveals the request circulation:

Your IDE or AI desktop consumer (Claude, VS Code, Cursor, and so forth.)
  ↓ device name
Native MCP server (runs in your machine)
  ↓ authenticated question
OpenSearch UI utility (linked along with your knowledge sources)
  ↓ twin response
Your IDE ← textual content abstract + interactive MCP App visualization

You preserve full management. The MCP server runs regionally. Your knowledge stays in your AWS account. Your credentials, your insurance policies, your domains.

How MCP Apps lengthen the MCP protocol

Commonplace MCP device calls return text-only responses. The agent sends a JSON-RPC request specifying the device identify and parameters, and the server returns a textual content end result that the agent incorporates into its reasoning. MCP Apps lengthen this sample by including a second response channel: a visualization payload that the IDE renders as an interactive widget alongside the textual content.

When the native MCP server receives a device name, it authenticates utilizing your configured AWS credentials and forwards the request to your OpenSearch UI utility endpoint as an HTTP API name. OpenSearch UI executes the question towards your linked knowledge sources and returns each a structured textual content abstract and a rendered visualization artifact. Supported knowledge sources embrace OpenSearch domains, serverless collections, and Amazon Managed Service for Prometheus. The MCP server packages these right into a single MCP response containing the textual content content material for the agent and the visualization content material for the IDE host to render.

The IDE host detects the visualization payload and renders it as an interactive widget within the dialog thread. OpenSearch MCP App generates the visualization server-side by executing code towards your precise knowledge. Subsequently, the rendered output is deterministic and matches what you’ll see in your OpenSearch dashboards.

A device name end-to-end

For example the twin response sample in follow, think about a hint investigation. The next walkthrough reveals what occurs when your agent calls the hint investigation MCP App device.

What the agent sends. Your agent points a device name to the hint investigation MCP App, passing parameters such because the hint ID or a filter like service identify and time vary. This name travels out of your IDE to the native MCP server over the usual MCP protocol.

How the server executes it. The native MCP server receives the device name, authenticates towards your AWS credentials, and forwards the request to your OpenSearch UI utility endpoint. OpenSearch UI executes the hint question towards your linked knowledge sources, retrieves the matching spans, and assembles the response.

What the twin response comprises. The MCP server returns two outputs in a single response. The textual content portion comprises a structured abstract. It consists of the hint ID, whole length, span depend, the important path, and an evaluation of the place the failure originated. The visualization portion comprises an interactive hint waterfall rendered as an MCP App inside your IDE, displaying the span hierarchy, timing, and error annotations.

How the agent and human every devour it. From the textual content abstract, your agent extracts context for its subsequent reasoning step, for instance correlating the failing span with associated log entries. In the meantime, you see the interactive hint waterfall in the identical dialog thread. You’ll be able to broaden particular person spans, examine attributes, and ensure the foundation trigger visually, with out opening a separate browser tab.

Out there MCP Apps

The MCP Apps help observability investigation throughout the lifecycle, with instruments that chain collectively throughout investigation phases.

Core investigation instruments

A typical investigation begins with triage and response instruments, which floor energetic alerts, correlate associated alerts throughout knowledge sources, and current severity breakdowns so your agent can prioritize the difficulty. After the agent identifies the affected service, log investigation instruments seek for error patterns and cluster comparable log entries to isolate the failure signature. From there, hint investigation instruments find the precise distributed hint, show the span hierarchy and latency breakdown, and pinpoint the place the failure originated.

Context and visualization instruments

To quantify the impression, metric investigation instruments execute PromQL queries and carry out threshold evaluation, whereas service efficiency instruments present RED metrics (price, errors, length) on the service degree. Topology instruments render the service map as a dependency graph. The graph reveals name quantity and error charges throughout edges so you may scope the impression. All through the investigation, dynamic visualization instruments generate line, bar, space, and metric charts from queries you specify, and datasets and correlations instruments help cross-signal joins and knowledge summaries.

Specialised instruments

Specialised instruments tackle rising wants. AI and agent observability instruments hint massive language mannequin (LLM) calls and render agent hint maps for groups constructing their very own AI workflows. Stack well being instruments report cluster standing and shard allocation. Instrumentation scoring instruments detect telemetry high quality gaps so groups can enhance their observability protection.

Determine 2: Hint investigation MCP App displaying span hierarchy, timeline, and failure origin evaluation contained in the IDE

Revisiting the on-call situation

With MCP Apps, the identical on-call investigation now appears like this.

The engineer asks the agent: “What’s inflicting the spike in checkout errors?” The agent investigates by querying logs, correlating with traces, and checking the service map. A twin response arrives containing each a textual content abstract and interactive visualizations (alert view, hint waterfall, and repair map) rendered in the identical thread. The engineer evaluations inline by scrolling via the MCP App visualizations and choosing span particulars to substantiate the scope of impression, with out leaving the IDE. Lastly, they instruct the agent to draft the difficulty abstract or set off a remediation.

The engineer by no means leaves the IDE. Investigation, verification, and determination occur in a single dialog thread. For on-call engineers, this implies quicker decision and a extra simple expertise to collaborate with AI brokers.

Determine 3: Service map MCP App displaying dependency graph with error price shade coding and name quantity edge widths

Getting began: Arrange the MCP server

Comply with these steps to attach your agentic IDE to your OpenSearch UI utility.

Stipulations

Earlier than you start, test that you’ve the next:

• An OpenSearch UI utility with an Observability workspace linked to at the least one knowledge supply (Amazon OpenSearch Service domains, serverless collections, or Amazon Managed Service for Prometheus).
• A appropriate agentic IDE (Claude Desktop, VS Code GitHub Copilot, Goose, ChatGPT, or Cursor).
• Node.js 22 or later put in regionally.
• AWS credentials configured with es:ESHttpGet and es:ESHttpPost permissions.

Step-by-step setup

The next process walks via downloading the server, configuring your IDE, and verifying the connection.

Step 1: Obtain and extract the MCP server

Obtain and put together the MCP server package deal:

1. Navigate to the OpenSearch observability MCP server obtain web page.
2. Obtain the MCP server .zip file.
3. Extract the archive. The extracted listing comprises a server/server.js file. Be aware the complete path to this file.

Step 2: Add the MCP server to your IDE

Every supported IDE has an MCP configuration file. The next listing reveals the place to search out it:

• Claude Desktop: Settings → Developer → Edit Config.
• VS Code GitHub Copilot: .vscode/mcp.json in your workspace, or Person Settings → MCP Servers.
• Cursor: Settings → MCP → Add Server.
• Goose: ~/.config/goose/mcp.json (via extensions).
• ChatGPT: Settings → MCP Plugins → Add.

Open the configuration in your IDE and add the next:

{
  "mcpServers": {
    "opensearch-observability-stack-mcp": {
      "command": "node",
      "args": ["/path/to/opensearch-observability-stack-mcp/server/server.js"],
      "env": {
        "OS_UI_ENDPOINT": "application-foo-bar.us-west-2.opensearch.amazonaws.com",
        "AWS_REGION": "us-west-2",
        "AWS_PROFILE": "my-profile"
      }
    }
  }
}

Substitute the placeholder values along with your OpenSearch UI endpoint, AWS Area, and profile.

To seek out your OpenSearch UI endpoint:

1. Open the Amazon OpenSearch Service console.
2. Within the navigation pane, select Purposes.
3. Choose your OpenSearch UI utility.
4. Copy the Utility URL (for instance, application-abc123.us-west-2.opensearch.amazonaws.com).

Step 3: Confirm the connection

After saving the configuration, restart your IDE or reload the MCP server listing. Then enter the next immediate in your IDE:

“Record accessible observability knowledge sources”

If the agent returns your linked knowledge sources (Amazon OpenSearch Service domains, serverless collections, or Amazon Managed Service for Prometheus workspaces), the MCP server is configured appropriately.

In the event you obtain an error, test that your AWS credentials are energetic and that your AWS Id and Entry Administration (IAM) coverage consists of the es:ESHttpGet and es:ESHttpPost actions in your OpenSearch UI utility ARN.

Tip: To check with out manufacturing knowledge, deploy the OpenTelemetry Demo utility to generate pattern traces, logs, and metrics in your Amazon OpenSearch Service area.

Clear up

To take away the MCP server configuration, open your IDE’s MCP settings and delete the opensearch-observability-stack-mcp entry. Then delete the extracted MCP server listing out of your native machine. This setup provisions no cloud sources, so that you don’t want AWS aspect cleanup.

Why this issues

The next desk summarizes how MCP Apps change the on-call workflow:

Conclusion

With MCP Apps, Amazon OpenSearch Service closes the verification hole in agentic observability. Your AI agent investigates, and the interactive proof arrives in the identical thread: no context-switching, no separate logins, no re-running queries. For on-call engineers, this may imply quicker decision. For organizations operating agentic observability regionally, this supplies the operational simplicity you needed with out sacrificing accuracy.

Get began at this time: For setup directions, see Agentic observability with MCP Apps within the Amazon OpenSearch Service Developer Information.

In regards to the authors