Amazon OpenSearch Service now supports the Agent Toolkit for AWS with a curated skill
Describe your OpenSearch goal in plain English and let AI coding agents handle provisioning, search, logs, and traces — no infra changes needed.
View original announcement →Visual Summary
What's New
Amazon OpenSearch Service now integrates with the Agent Toolkit for AWS, allowing developers to build, manage, and query OpenSearch Service domains and OpenSearch Serverless collections directly through AI coding agents like Claude Code, Kiro, and Cursor. The integration is powered by the AWS MCP (Model Context Protocol) server and a curated amazon-opensearch-service skill that translates natural-language requests into the correct AWS API calls across five capability areas: migration, operations, search, log analytics, and trace analytics. The feature requires no infrastructure changes and is available at no additional charge in all regions where OpenSearch Service and OpenSearch Serverless are offered.
How It Works
- The AWS MCP (Model Context Protocol) Server acts as an authenticated bridge between the AI coding agent and AWS, executing AWS API calls on the developer's behalf in a sandboxed environment using locally configured AWS credentials.
- The
amazon-opensearch-serviceskill is a curated package of instructions, scripts, and reference material that the agent loads on demand when a request is OpenSearch-related, routing it to one of five specialized capability modules without slowing the agent on unrelated tasks. - The skill is delivered via the
aws-data-analyticsplugin, which bundles both the MCP Server configuration and the OpenSearch skill in a single installation step for supported agents (Claude Code, Codex, Kiro, Cursor). - For agents that do not support plugins, the AWS MCP Server can be configured directly, after which the agent discovers the
amazon-opensearch-serviceskill at runtime through the server. - The five capability areas are: Migration (compatibility assessment, schema/query translation, cutover planning from Solr, Elasticsearch, or self-managed OpenSearch), Operations (domain/collection lifecycle, version upgrades, UltraWarm/OR1 storage tiers, fine-grained access control), Search (BM25 keyword, vector, semantic, hybrid, and RAG search with FAISS/Lucene k-NN and Bedrock connectors), Log analytics (PPL queries, OpenSearch Ingestion pipelines, anomaly detection, Dashboards), and Trace analytics (OpenTelemetry span investigation, service maps, Data Prepper ingestion).
- The integration works with both managed OpenSearch Service domains and OpenSearch Serverless collections across all supported versions, with no changes required to existing infrastructure.
- A notable limitation: the AWS MCP Server connects only to public endpoints and does not support VPC-deployed domains or collections; VPC users must use the open-source
opensearch-mcp-server-pyinstead.
Why It's Important
- Reduces the expertise barrier for OpenSearch: developers can describe goals in plain language and the agent handles complex, multi-step workflows like shard sizing, k-NN engine selection, or OTel trace investigation without requiring deep OpenSearch domain knowledge.
- Accelerates development cycles by eliminating trial-and-error API calls; the curated skill provides tested procedures and up-to-date service knowledge, reducing token waste and debugging time.
- Bridges the model training cutoff gap: foundation models may lack knowledge of recent OpenSearch features, but the skill provides real-time, accurate guidance on current capabilities and best practices.
- Enables agentic infrastructure management end-to-end — from provisioning a production domain with multi-AZ to building a hybrid RAG search pipeline — all within the developer's existing coding agent workflow.
- Improves auditability and governance: agent actions flow through the AWS MCP Server, enabling CloudWatch monitoring, IAM-based access controls, and enterprise guardrails that differentiate agent actions from human actions.
- Lowers migration friction for teams moving from self-managed Elasticsearch, Solr, or OpenSearch by providing automated compatibility assessment and cutover planning directly in the agent.
How It's Different
- Unlike generic LLM knowledge of AWS, the curated skill provides current, tested, OpenSearch-specific procedures rather than relying on potentially outdated training data, resulting in higher first-attempt success rates.
- Unlike raw API access via a terminal or CLI, the MCP Server provides an auditable, IAM-governed interface that distinguishes agent actions from human actions and supports enterprise policy enforcement.
- Unlike community or open-source MCP integrations, this is an officially curated AWS skill that encapsulates AWS Well-Architected best practices, instance sizing guidance, and shard math recommendations specific to OpenSearch Service.
- The single-plugin installation (
aws-data-analytics) bundles both the MCP Server and the skill, whereas other integrations typically require separate configuration of the protocol server and domain knowledge sources. - The skill is lazily loaded only for OpenSearch-related requests, meaning it adds capability without adding latency or context overhead for unrelated agent tasks — a design choice not common in always-on MCP tool configurations.
- Unlike the open-source
opensearch-mcp-server-py, the AWS MCP Server is a fully managed service with no local server process to maintain, though it trades VPC connectivity support for this convenience.
When to Prefer It
- When migrating from self-managed Elasticsearch, Solr, or OpenSearch to managed OpenSearch Service or Serverless and needing automated compatibility assessment, schema translation, and cutover planning without manual research.
- When building RAG, hybrid, or semantic search applications that require coordinating index configuration, k-NN engine selection, and Amazon Bedrock embedding connectors — tasks that benefit from guided, multi-step agent workflows.
- When your team uses AI coding agents (Claude Code, Kiro, Cursor, Codex) as a primary development interface and wants OpenSearch management to fit naturally into that workflow rather than context-switching to the console or CLI.
- When operating OpenSearch Service domains with public endpoints and wanting governed, auditable agent access with IAM controls and CloudWatch monitoring.
- When performing log analytics or trace investigations using PPL or OpenTelemetry and wanting the agent to help construct queries, set up ingestion pipelines, or identify latency regressions without manual DSL authoring.
- When your organization requires enterprise guardrails on AI agent activity, such as differentiating what agents can do versus what humans can do, and auditing all AWS API calls made by agents.
- Avoid this integration if your OpenSearch Service domains or Serverless collections are deployed inside a VPC — use
opensearch-mcp-server-pyinstead for VPC connectivity.
Availability
- GA Status: Generally available as of July 15, 2026.
- Regional availability: Available in all AWS Regions where Amazon OpenSearch Service and Amazon OpenSearch Serverless are offered.
- Pricing: Available at no additional charge; standard OpenSearch Service and Serverless pricing applies for any resources provisioned or queried through the agent.
- Supported agents: Claude Code, Kiro, Cursor, Codex, and any other MCP-compatible AI coding agent.
- Supported resources: Works with both managed OpenSearch Service domains (all versions) and OpenSearch Serverless collections; no infrastructure changes required.
- Limitation — VPC: The AWS MCP Server supports public endpoints only; domains and collections deployed in a VPC are not supported and require the open-source
opensearch-mcp-server-pyalternative. - Getting started: Install the
aws-data-analyticsplugin in your agent (e.g.,/plugin install aws-data-analytics@claude-plugins-officialin Claude Code) and ensure AWS credentials are configured locally with appropriate IAM permissions.