Amazon OpenSearch Service Introduces Support for MCP Apps

According to a publication by Arthur Hang Zuo, Joshua Li, and Pratik Gurudatt Shenoy from Amazon OpenSearch Service, Amazon OpenSearch Service now supports a new capability called MCP Apps, which extends the Model Context Protocol to enable rendering interactive visualizations directly in the IDE chat window alongside the AI agent's text response.

The Problem: Verification Requires Leaving the Agent Loop

According to the authors of the post, observability agents query alerts, correlate logs with traces, and produce a root cause hypothesis within minutes. However, the verification phase still consumes time from engineers. After reading the agent's text summary, the engineer is required to leave the integrated development environment (IDE), open a browser, log in to a separate observability UI, manually re-run queries in a different tool, and compare the agent's text output against the actual dashboards. Afterwards, the engineer returns to the agent to resume the conversation.

The authors note that this external verification loop serves as a bottleneck because it forces switching between tools and slows down the speed advantage of agentic automation. In addition, organizations that chose to run agentic observability locally for reasons of control and cost efficiency have historically sacrificed ease of use and sometimes agent performance compared to vendor solutions that tightly couple AI to their services. For these teams, the verification gap represents the primary operational burden.

The Solution: Bringing an Observability UI into the IDE

Amazon OpenSearch Service introduces support for MCP Apps, which add a dual response pattern to the MCP protocol. When an AI agent executes a tool call to an MCP App, the response contains two parts: a textual summary containing concise, structured data, and an interactive visualization rendered within the same conversation thread.

The visualization is generated by executing code server-side against the same data sources that power OpenSearch dashboards. As a result, the results are deterministic and display the actual query result in the form of an interactive chart, a trace waterfall view, or a service map.

Architecture and How the Protocol Works

The capability consists of a local MCP server, the IDE, and the OpenSearch UI application (referred to as OpenSearch UI).

The workflow operates as follows:

1. A local MCP server runs on the user's machine and acts as a secure bridge between the IDE and the OpenSearch UI application.
2. The server exposes observability tools that the AI agent can invoke.
3. Each tool call is routed through the local MCP server to the OpenSearch UI application endpoint, authenticated using AWS credentials, and executes a query.
4. The OpenSearch UI application, which serves as a serverless interface for OpenSearch domains, Serverless collections, the CloudWatch service, and Amazon Managed Service for Prometheus, returns both a structured text summary and a rendered visualization artifact.
5. The MCP server packages both parts into a single MCP response that is sent back to the IDE, which detects the visualization and renders it as an interactive widget.

The data remains in the user's AWS account, and the server runs locally under the credentials and policies configured on it.

An End-to-End Tool Call Example in a Trace Investigation

To illustrate the pattern, the authors describe a trace investigation scenario:

• The agent sends a tool call with a trace ID or filters such as service name and time range to the local MCP server using standard MCP protocol.
• The local server authenticates the request and forwards it via HTTP API to the OpenSearch UI application, which retrieves the matching spans and generates the response.
• The dual response includes in its text portion a structured summary with the trace ID, total duration, span count, critical path, and failure origin analysis. The visual portion presents an interactive trace waterfall displaying span hierarchy, timing, and error annotations.
• The agent uses the text for its next analytical step (such as correlating the failing span with logs), while the engineer views the trace waterfall in the same window, expands spans, inspects attributes, and confirms the root cause without opening a browser tab.

MCP Tools Available in the System

The authors detail the available tools, which are divided into three categories:

1. Core investigation tools:

   • Triage and response tools that surface active alerts, correlate related alerts, and display severity breakdowns.
   • Log investigation tools to search for error patterns and cluster similar log entries.
   • Trace investigation tools to locate distributed traces, display span hierarchy, and identify the failure origin.

2. Context and visualization tools:

   • Metric investigation tools to execute PromQL queries and analyze thresholds.
   • Service performance tools that provide RED metrics (rate, errors, duration).
   • Topology tools that display a service map as a dependency graph with call volume and error rates.
   • Dynamic visualization tools to generate line, bar, area, and metric charts.
   • Datasets and correlations tools to execute cross-signal data joins.

3. Specialized tools:

   • AI and agent observability tools to trace large language model (LLM) calls and display agent trace maps.
   • Stack health tools reporting cluster status and shard allocation.
   • Instrumentation scoring tools to identify gaps in telemetry coverage.

Installation and Setup Steps

To get started, the authors outline the prerequisites and setup steps:

Prerequisites:

• An OpenSearch UI application with an Observability workspace connected to at least one data source (OpenSearch Service domains, Serverless collections, or Amazon Managed Service for Prometheus workspaces).
• A compatible IDE: Claude Desktop, VS Code GitHub Copilot, Goose, ChatGPT, or Cursor.
• A local installation of Node.js version 22 or later.
• AWS credentials with es:ESHttpGet and es:ESHttpPost permissions.

Installation steps:

1. Download the MCP server ZIP file from the download page and extract it. The extracted folder contains server/server.js.
2. Add the MCP server definition to the relevant configuration file in the IDE with the execution command (node), the path to the server file, and environment variables including the OpenSearch UI endpoint (found under Applications in the OpenSearch console), AWS Region, and AWS profile.
3. Verify the connection by restarting the IDE and entering the prompt: "List available observability data sources". A response listing the connected data sources indicates a proper setup.

The authors note that to test without production data, the OpenTelemetry demo application can be deployed. To remove the setup, delete the entry from the IDE's MCP settings and delete the local folder, with no cloud cleanup required on the AWS side.