Amazon OpenSearch Service now offers MCP Apps, a capability that augments the Model Context Protocol so that each tool call returns a text explanation together with an interactive visualization rendered inside the AI‑assistant chat window. By delivering the dashboard widget alongside the summary, engineers no longer have to switch to a separate observability UI to verify an alert, keeping the entire investigation inside the IDE.
What Changed: Dual‑Response MCP Apps
Traditional MCP tool calls produce only a textual payload. MCP Apps add a second channel that carries a visualization payload – for example a trace waterfall, service topology, or log pattern view. The visualization is generated by executing the same query that powers the standard OpenSearch dashboards, ensuring the result is deterministic and directly tied to the underlying data.
Why It Matters to Engineers
Observability agents can formulate a root‑cause hypothesis in seconds, but the verification step has required opening a browser, navigating dashboards, and manually correlating results. This “tool‑switching” step erodes the speed advantage of agentic automation. With MCP Apps, the verification UI appears in the same conversation thread, eliminating the context‑switch and reducing the overall mean‑time‑to‑resolution for incidents.
Architecture and Implementation Details
The MCP Apps pattern consists of three components:
Local MCP server– runs on the engineer’s workstation and acts as a secure bridge between the AI‑enabled IDE (e.g., VS Code, Cursor) and the OpenSearch UI service.- IDE or AI desktop client – issues a tool call using the extended MCP protocol.
- OpenSearch UI application – receives the authenticated query, runs it against OpenSearch domains, serverless collections, CloudWatch, or Amazon Managed Service for Prometheus, and returns the dual response.
The request flow is linear: IDE → local MCP server → OpenSearch UI → dual response → IDE. Because the server runs locally, all credentials, policies, and data remain within the user’s AWS account, preserving existing security boundaries.
Operational and Security Considerations
Deploying MCP Apps introduces a lightweight runtime component that must be started on each developer machine. Practitioners need to ensure the local server is configured with appropriate IAM permissions to query the required OpenSearch resources. Since the server mediates authenticated calls, its exposure surface is limited to the developer’s environment, but standard best practices for local tooling – such as restricting network access and keeping the binary up‑to‑date – remain applicable.
From an operational standpoint, the dual response eliminates duplicate queries that would otherwise be issued manually from a dashboard. This can reduce load on OpenSearch clusters and lower cost associated with repeated ad‑hoc queries. However, teams should monitor the additional rendering workload in the IDE, especially when visualizations become complex.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Engineers should evaluate whether their primary IDE supports the MCP protocol extension and install the local MCP server provided by OpenSearch Service. Once in place, test a representative alert flow to confirm that the text summary and embedded widget appear as expected. Review IAM policies to grant the server only the permissions needed for the specific observability data sources. Finally, incorporate the new verification step into incident‑response runbooks, noting the reduced context‑switch and potential cost savings from fewer duplicate dashboard queries.
