OpenSearch 原生接入 MCP

全球所有兼容 MCP 的 Agent，都需要搜索后端提供同样三项能力：发现有哪些数据可用、对数据执行查询，以及获取结构化结果。如今，Claude、Amazon Q、Cursor、Kiro、Strands Agents，以及越来越多的开源框架，都已经原生支持 MCP。协议这一端的问题已经解决，现在，你的搜索基础设施也能用同一种协议回应它们了。

Amazon OpenSearch Service 现在已经支持这一能力。你的 domain 会暴露一个原生 MCP endpoint，Agent 可以直接连接。无需自定义 connector，无需 middleware，也不必为每个 Agent 编写集成代码。本文将介绍它在实际使用中的工作方式：这个 endpoint 暴露了哪些能力、如何保护它，以及当数据源使用 Agent 已经理解的同一种协议时，为什么 M×N 集成难题会随之消失。

Model Context Protocol（MCP）是一套标准的 JSON-RPC 接口，允许 AI Agent 发现并调用外部系统上的工具。MCP server 会声明自己能做什么，例如搜索 index、检查 cluster health、执行 aggregation；任何兼容 MCP 的 Agent 都可以调用这些工具，无需编写自定义集成代码。一套协议就能取代所有专门定制的 connector。

MCP 解决的是一个组合复杂度问题。如果有 M 个 Agent 需要连接 N 个数据源，采用自定义集成意味着要构建和维护 M×N 个 connector。三个 Agent 与五个 OpenSearch Service domain 通信，就需要十五个 connector。每个 connector 都要用自己的方式处理身份验证、查询格式化和响应解析。再增加第六个 domain 或第四个 Agent，整个集成周期就得重新开始。MCP 将复杂度压缩为 M+N：每个 Agent 只需使用一种协议，每个数据源只需暴露一个 server，任意 Agent 都能与任意 server 通信，不需要额外代码。

可以把它想象成 USB。在 USB 出现之前，每种外设都需要自己的线缆和驱动程序。USB 出现之后，插上就能用。MCP 就是把这种标准化应用到了 AI 集成层。你的 Agent 是外设，你的数据源是计算机，而 MCP 就是接口。

MCP Server 暴露了什么

你的 OpenSearch Service domain 会通过 ML Commons plugin，在 /_plugins/_ml/mcp 路径暴露 MCP endpoint，Agent 可以直接连接。这个 endpoint 会声明三类组件。Resources 提供来自 index 的数据上下文。Prompts 是可复用的指令模板，适合反复执行的分析任务。Tools 则是可执行函数，例如搜索 index、检查 cluster health、分析性能指标以及执行 aggregation。

下面是一次工具调用的示例。一个使用 fastmcp 连接的 Python Agent：

from fastmcp import Client

async with Client("https://your-domain.us-east-1.es.amazonaws.com/_plugins/_ml/mcp") as client:
    # discover what the domain exposes
    tools = await client.list_tools()
    print([t.name for t in tools])  # ['SearchIndexTool', 'ListIndexTool', 'ClusterHealthTool', ...]

    # call a tool by name
    result = await client.call_tool("SearchIndexTool", {
        "index": "products",
        "query": {"match": {"category": "electronics"}}
    })

Agent 会发现可用工具，按名称调用它们，并获得结构化结果。无需自定义 SDK，也不用编写 REST client 的样板代码。任何兼容 MCP 的 Agent，例如 Amazon Q CLI、Claude、Cursor 和 Strands Agents，都以相同方式连接。

配置过程（有趣的部分来了）

对于内置 endpoint，server 端不需要配置任何东西。你的 domain 已经暴露了 MCP endpoint。真正重要的是正确配置身份验证：IAM role 和 backend role mapping 决定每个 Agent 能看到什么。一旦这些配置就位，连接新的 Agent 就只是一次配置变更。我创建了一个 domain，启用 MCP，注册工具，然后使用 SearchIndexTool 查询 OpenSearch Service 中的数据。Agent 通过协议的 capability negotiation 发现可用工具，并在没有任何自定义集成代码的情况下执行查询。

访问控制需要两层配置。第一层是 IAM resource-based policy，允许 Agent role 访问 domain：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789012:role/ai-agent-role"
    },
    "Action": ["es:ESHttpGet", "es:ESHttpPost"],
    "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/*"
  }]
}

第二层是在启用 fine-grained access control 的情况下，将 IAM role 映射到一个 OpenSearch backend role。这个 backend role 需要拥有访问 ML Commons API，以及搜索 Agent 所需 index 的权限。在 OpenSearch Dashboards 中，进入 Security > Roles，创建或选择一个拥有 ml_full_access cluster permission 的 role（也可以使用权限范围更窄的自定义 permission set），为目标 index 添加 index permission，然后在 Mapped users 中，把 Agent 的 IAM role ARN 映射到这个 backend role。所有采用同一个 IAM role 的 Agent 都会继承相同的访问权限。这样只需维护一个安全边界，而不是为每个 connector 分别维护一个。

无需重建即可扩展

内置 MCP endpoint 会随 OpenSearch Service domain 一起扩展。只要你的 domain 能够承受查询负载，MCP endpoint 也能处理这些负载。不必再操心单独的扩展层。对于使用 AgentCore 托管方案的团队，AgentCore 会独立处理自动扩缩容。

添加新的 AI Agent 时，server 端什么都不用做。Agent 连接到 domain 的 MCP endpoint，并通过协议内置的 capability negotiation 自动发现可用工具。这就是 M+N 特性在实际场景中的体现：每增加一个 Agent，只需要 O(1) 的工作量，而不是 O(N)。

假设一个团队有四个 AI Agent，需要连接三个 OpenSearch Service domain。按照旧模式，需要十二套自定义集成。使用 MCP 后，每个 Agent 只需指向 domain 的 endpoint，就能自动发现工具。增加第五个 Agent，只是新增一条配置，而不是开启一个开发迭代。增加第四个 domain，现有 Agent 也能立即访问它。复杂度始终保持线性增长。

开源的 OpenSearch MCP server 是 OpenSearch 项目的一部分。由社区推动的功能改进和安全更新，意味着你不必再维护专有的集成代码。由于 OpenSearch Service domain 内置的 MCP endpoint 使用相同协议，无论 Agent 使用哪一种接入方式，都能与另一种方式兼容，无需修改代码。

如果你的 Agent 已经支持 MCP，那么 OpenSearch Service domain 已经做好了响应准备。启用 ML Commons plugin（将 plugins.ml_commons.mcp_server_enabled 设置为 true），注册希望 Agent 访问的工具，配置 IAM 和 backend role mapping，然后让 Agent 连接到 /_plugins/_ml/mcp endpoint。接入第二个 Agent 不会产生额外成本，接入第十个 Agent 也一样。协议实现了协议本该实现的目标：让下一次连接无需额外代价。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。