← Back to all announcements
★★★★☆ 10/06/2026

Amazon OpenSearch Service launches MCP Apps for agentic observability

Investigate incidents with AI agents inside VS Code or Claude Desktop, with interactive OpenSearch visualizations rendered inline—no browser switching needed.

View original announcement →

Visual Summary

graph TD A{{OpenSearch MCP Apps}}:::announced B((Developer IDE)):::external C(Amazon OpenSearch Service):::storage D(Amazon Managed Prometheus):::storage E([Dual Response Engine]):::feature F([Interactive Visualizations]):::feature G([Cross-Signal Correlation]):::feature H(OpenSearch UI):::compute B ==>|"MCP tool calls"| A A -->|"queries logs/traces"| C A -->|"queries metrics"| D A -->|"returns"| E E -->|"text summary"| B E -->|"renders"| F A -.->|"correlates signals"| G A -->|"built on"| H H -->|"connects to"| C classDef announced fill:#ff9900,stroke:#ec7211,color:#fff,font-weight:bold classDef compute fill:#e3f2fd,stroke:#1565c0,color:#1565c0 classDef storage fill:#e8f5e9,stroke:#2e7d32,color:#2e7d32 classDef feature fill:#fff3e0,stroke:#e65100,color:#e65100 classDef external fill:#f5f5f5,stroke:#616161,color:#616161

What's New

Amazon OpenSearch Service now supports MCP Apps, enabling AI agents running in local agentic IDEs such as Claude Desktop and VS Code to perform observability workflows—including incident investigation, root cause analysis, and distributed trace exploration—directly against OpenSearch domains, serverless collections, and Amazon Managed Service for Prometheus. Each MCP tool call returns a dual response: a concise text summary for the agent to reason over and an interactive visualization rendered inline in the conversation thread. This brings the full observability signal set (logs, traces, metrics, and alerts) into a single, agent-driven conversational workflow without requiring engineers to switch contexts.

How It Works

  • MCP Server Setup: Users configure an MCP server that connects their local agentic IDE (Claude Desktop, VS Code, or any MCP-compatible client) to their OpenSearch domains, serverless collections, and Amazon Managed Service for Prometheus endpoints via an .mcpb configuration file.
  • Dual-Response Tool Calls: Every MCP App tool invocation returns two artifacts simultaneously—a structured text summary the AI agent uses for reasoning and chaining next steps, and an interactive visualization rendered directly in the conversation thread for human review.
  • Available Tool Categories: The MCP App toolset covers log investigation, metrics analysis, trace investigation, service performance, topology/service maps, dynamic visualizations, agent health, cluster health, and instrumentation scoring.
  • Signal Correlation: The agent can correlate across multiple observability signals (logs, traces, metrics, alerts) within a single conversation, enabling end-to-end incident workflows from alert triage through root cause analysis.
  • Visualization Types: Interactive outputs include firing alert timelines with severity breakdowns, distributed trace span hierarchies, service dependency call graphs (with edge width for call volume and color for error rate), and PromQL metric charts (line, bar, area, or metric formats).
  • Underlying Platform: The experience is built on OpenSearch UI, a cloud-hosted, multi-source operational analytics layer that supports OpenSearch domains, serverless collections, CloudWatch, Security Lake, and S3 as data sources.

Why It's Important

  • Eliminates Context Switching: Engineers can investigate production incidents entirely within their local IDE, removing the need to jump between dashboards, terminal windows, and separate observability consoles during high-pressure incidents.
  • Accelerates Root Cause Analysis: By combining AI-driven reasoning with interactive visualizations in a single thread, teams can move from alert firing to root cause identification faster than traditional manual workflows.
  • Human-in-the-Loop Verification: The dual-response model ensures that AI-generated conclusions are always paired with verifiable visual evidence, reducing the risk of acting on incorrect agent inferences.
  • Unified Observability Signal Coverage: Covering logs, metrics, traces, and alerts in one conversational workflow addresses the fragmentation problem that has historically made cross-signal correlation slow and error-prone.
  • Lowers the Observability Skill Floor: Natural language–driven investigation via an AI agent makes deep observability analysis more accessible to developers who are not expert in query languages like PPL, PromQL, or Lucene.
  • Extensible to Managed Prometheus: Native integration with Amazon Managed Service for Prometheus means teams using Prometheus-based metrics stacks get the same agentic experience without additional instrumentation changes.

How It's Different

  • Versus Traditional OpenSearch Dashboards: OpenSearch Dashboards requires users to manually build and navigate dashboards within a browser; MCP Apps bring the data to the developer's existing IDE via conversational AI, with no manual dashboard construction required.
  • Versus OpenSearch UI Alone: OpenSearch UI is a cloud-hosted web interface; MCP Apps extend that observability capability into local agentic environments, enabling programmatic, agent-driven investigation rather than point-and-click exploration.
  • Versus Generic LLM + Observability Integrations: Rather than sending raw data to an LLM and receiving only text, MCP Apps produce structured interactive visualizations alongside text, giving engineers a verifiable artifact rather than just an AI narrative.
  • Versus Standalone Prometheus/Grafana Workflows: PromQL metric charts, service maps, and trace views are all surfaced within the same conversation thread, eliminating the need to context-switch to Grafana or Jaeger for different signal types.
  • Dual-Response Architecture: The explicit separation of "text for agent reasoning" and "visualization for human review" is a deliberate design choice that most observability integrations do not implement, making the human-AI collaboration more structured and auditable.

When to Prefer It

  • Active Incident Response: When an on-call engineer needs to triage a firing alert, correlate it with traces and logs, and identify root cause quickly without leaving their IDE.
  • Distributed System Debugging: When investigating latency or error spikes in microservices architectures where understanding service topology and trace span hierarchies is essential.
  • AI-Augmented SRE Workflows: When teams want to use AI agents to automate the initial investigation steps (alert review, log pattern detection, metric anomaly identification) while retaining human oversight via inline visualizations.
  • Multi-Signal Correlation: When an incident requires correlating Prometheus metrics, OpenSearch logs, and distributed traces simultaneously—a workflow that is cumbersome across separate tools.
  • Developer-Led Observability: When application developers (not dedicated SREs) need to investigate production issues from their primary development environment (VS Code) without learning a separate observability platform.
  • Instrumentation Auditing: When teams want to assess the completeness and quality of their observability instrumentation using the instrumentation scoring tool before or after a deployment.

Availability

  • GA Status: Generally available as of June 10, 2026.
  • Regional Availability: Available in all AWS Regions where Amazon OpenSearch UI is offered; no specific region exclusions were called out in the announcement.
  • Supported IDEs: Compatible with any MCP-compatible agentic IDE, with Claude Desktop and VS Code explicitly cited as supported clients.
  • Data Source Support: Works with Amazon OpenSearch Service domains, OpenSearch Serverless collections, and Amazon Managed Service for Prometheus.
  • Pricing: No separate pricing was announced for MCP Apps; costs are expected to follow standard Amazon OpenSearch Service and Amazon Managed Service for Prometheus pricing for the underlying data queries and storage.
  • Prerequisites: Requires an existing OpenSearch domain or serverless collection, a configured MCP server, and a compatible agentic IDE; setup is documented in the OpenSearch Agentic Observability with MCP Apps developer guide.

Tags

Servicesopensearch
Typenew-featureintegration
Conceptsagentic-aigenai
Use Casesobservabilitydeveloper-tools
Providersanthropic
GeographyGlobal

Related Resources

AI Radar AWS

AWS AI/ML news — curated, researched, explained

An automated intelligence platform that curates, researches, and analyzes AWS AI/ML/GenAI announcements daily. Every report is backed by real research — the system reads linked blog posts and documentation to provide accurate, in-depth analysis.

How Each Report Is Generated

  1. Collection — Daily monitoring of the AWS "What's New" RSS feed
  2. Filtering — AI-powered relevance detection for AI/ML/GenAI topics
  3. Taxonomy Tagging — LLM-based classification across 6 dimensions
  4. Importance Scoring — Point-based system with tag bonuses (1-5 stars)
  5. Research Phase — Follows links to blog posts and documentation
  6. Report Generation — Claude Sonnet produces structured 6-section analysis
  7. Visual Summary — Claude Opus generates Mermaid diagrams for key items
  8. Publishing — Static website rebuilt and deployed via CloudFront

Features

  • Faceted filtering by service, type, concept, and more
  • Multi-dimensional taxonomy with 80+ tags across 6 dimensions
  • Geographic availability badges (Global, APJ, EMEA, AMER) with filtering
  • Timeline visualization of announcement volume
  • PDF export for offline reading
  • Mermaid visual summaries for key announcements
  • Daily automated updates — no manual curation
What makes this different: Each report involves a dedicated research phase where the system reads linked blog posts and AWS documentation pages. This produces analysis that goes beyond the original announcement text.

Technology

Built with Python, AWS Lambda, Amazon Bedrock (Claude Sonnet 4.6, Opus 4.6, Haiku 4.5), S3, CloudFront, WAF, EventBridge, and CDK.

Open Source

This project is open source. Fork it, customize it for your needs, and deploy your own instance.
📦 github.com/bbonik/ai-radar-aws

How Importance Scoring Works

Each announcement receives a point score based on multiple factors. The total score maps to a 1-5 star rating:

1★ < 2 pts 2★ ≥ 2 pts 3★ ≥ 3.5 pts 4★ ≥ 5 pts 5★ ≥ 6.5 pts

Point Breakdown

FactorPointsWhen
Core AI service (Bedrock, AgentCore, SageMaker AI)+4Service named in title
Key AI service (SageMaker, Kiro, QuickSight)+2Service named in title
Other AI-related service+1Default
Blog post link+3Link to aws.amazon.com/blogs/
GitHub samples link+2Link to github.com/aws*
Documentation link+1Link to docs.aws.amazon.com/
New model+1.5Tagged as "new-model"
New service+1Tagged as "new-service"
New feature+0.5Tagged as "new-feature"
Anthropic / OpenAI provider+2Provider explicitly mentioned
Instance / notebook announcement-2Hardware/capacity, not feature
Performance / pricing / security-0.5Incremental updates
Region expansion to APJ+1Expands to Asia Pacific
Region expansion (non-APJ only)-1.5Only expands to other regions

Geographic Relevance Badges

Each announcement card shows a small badge indicating whether the feature is available in your region:

🌐 Global Available in all regions
🌏 APJ Asia Pacific
🌍 EMEA Europe / Middle East / Africa
🌎 AMER Americas (US, Canada, South America)
No badge Geography unknown
How geography is detected: The system detects ALL geographies mentioned in each announcement. If the text mentions specific regions (Tokyo, Frankfurt, Oregon, etc.), the corresponding geography badges are shown. If it says "all regions" or is a new feature with no region specified, it gets the Global badge. Geography is also filterable — click a geo chip to see only announcements available in that region.