MCP Apps extend the Model Context Protocol so AI agents return both text explanations and interactive visualizations from OpenSearch in the same IDE thread, removing the manual tool-switching step in verification.
MCP Apps provide dual responses: a structured text summary plus an interactive visualization rendered inside the agent’s conversation window.
The new flow reduces context switching: ask the agent, see the trace or dashboard widget inline, verify results without opening a separate observability UI.
MCP Apps work with OpenSearch UI and the same data sources behind your dashboards (OpenSearch domains, serverless collections, CloudWatch, Amazon Managed Service for Prometheus).
# What changed Amazon OpenSearch Service now supports MCP Apps, an extension to the Model Context Protocol (MCP). When an AI agent calls an OpenSearch MCP App, the tool returns two things: a concise text summary and an interactive visualization rendered directly inside the agent's chat or IDE. That visualization can be a trace waterfall, service topology, error-count chart, or other dashboard widget produced by the same queries that power your OpenSearch dashboards.
# Why it matters Agentic observability speeds up hypothesis generation but verification has remained manual. Engineers typically copy the agent's diagnosis, open a browser, navigate dashboards, re-run queries, and visually confirm results. That tool-switching slows investigations and breaks conversational flow. MCP Apps eliminate that extra step by delivering the visual evidence inline with the agent's explanation, so you can verify results without leaving the conversation.
# How it works, at a glance A local MCP server runs on the engineer's machine and acts as an authenticated bridge between the AI client (IDE or desktop AI) and OpenSearch UI. The server forwards tool calls to OpenSearch UI, which runs the same queries used for dashboards and returns a deterministic result. The MCP server assembles a dual response: structured text for the agent's reasoning and a visualization payload the IDE renders as an interactive widget beside the text.
# Security and data control The MCP server runs locally, so credentials, domains, and policies remain under your AWS account. OpenSearch UI continues to work with OpenSearch domains, serverless collections, CloudWatch, and Amazon Managed Service for Prometheus. The design preserves local control and determinism while surfacing visuals in the agent thread.
# Practical impacts on workflow Before: agent produces a root-cause hypothesis quickly, but verification required leaving the IDE and re-running queries in a separate UI. That breaks the conversational state and adds manual steps.
After: the agent returns a hypothesis plus an embedded chart or trace. You can inspect the trace waterfall or service map inline, ask follow-up questions, and keep the investigation in a single conversation.
# When teams will prefer this Teams running agentic observability locally—choosing control and cost efficiency over vendor-hosted, tightly coupled experiences—gain the most immediate benefit. MCP Apps reduce the main operational burden those teams face: manual, external verification that negates some of the agent's time savings.
# What remains the same
# Next practical steps If you want to try this pattern, set up the local MCP server, connect it to your IDE or AI client, and ensure OpenSearch UI is configured to access the data sources you use for observability. The OpenSearch MCP App will then be available as a tool the agent can call, returning both text and interactive visualizations during investigations.
Learn how to observe and evaluate production AI agents by combining an agent running on AWS with OpenSearch Agent Health. This post walks through deploying an agent and its observability pipeline to AWS, then using Agent Health to explore traces and run evaluations that measure and improve agent quality over time.
This post builds an enterprise agentic retrieval solution on the Amazon Bedrock Managed Knowledge Base and Amazon Bedrock AgentCore. An agent reasons, routes across multiple knowledge bases, and returns cited answers, with seven layers of observability and both on-demand and continuous evaluation, all deployed with a s
Build a multi-account architecture that keeps each team's data in its own AWS account while giving AI agents a unified way to query across them. A central platform account runs the agent using Amazon Bedrock AgentCore Gateway and MCP, while line-of-business accounts expose their data as MCP servers with secure cross-ac
In this post, you will learn how to deploy and host your MCP server in AgentCore Runtime and integrate it with Amazon Quick, along with the prerequisites. With this pattern, you promote reusability and avoid duplication of AI tools, so clients can reuse commonly used tools and agents exposed through an MCP server inste
Learn how to build and deploy an MCP App with interactive HTML widgets on Amazon Bedrock AgentCore. Because MCP Apps is a host-agnostic standard, the same server delivers the same rich experience across AI hosts like ChatGPT and Claude that support the extension.
Most teams struggle to answer a deceptively simple question: is my search returning relevant results? This post shows how to capture User Behavior Insights (UBI) data on Amazon OpenSearch Service and use Search Relevance Workbench (SRW) to turn those signals into relevance judgments and evaluate search quality.
Loading more related stories...
Open the app view to save this story, compare related coverage, and continue from the same source.
