提交 MCP 连接器：Anthropic 需要什么

我们从 Claude 的提交文档中得知，需要向 Anthropic 的审核人员提供一个测试实例的访问权限：

测试账户的设置和访问说明必须足够详细，以便审核人员能够连接到你的服务器并运行其中的工具……

当 Elastic 的 Claude Enterprise 账户需要将一个自定义 MCP 服务器连接到一个名为“Anthropic MCP Test”的 Elastic Cloud Serverless 项目时，这种体验就变得有些尴尬。同样，我们需要与 IT 管理员合作，既要搭建这个 MCP 服务器，又要避免将其暴露给整个企业。

这可能不是普遍的经历，因为 Elastic Agent Builder MCP 服务器属于较为罕见的 MCP 服务器类型，每个客户部署都拥有自己内嵌的服务器。

MCP 连接器审核实际检查什么

上面的内容暗示 Anthropic 会自行对我们提交的 MCP 服务器进行一些测试，这一点在提交连接器文档中得到了进一步确认：

Anthropic 会自动扫描你的提交内容以检查是否符合政策……

事实证明，这种说法过于轻描淡写了。

Claude 的提交流程并不要求提供评估数据集或深入的测试脚本。它只要求提供一个沙箱环境、一个文档链接和三个示例提示用例。基于这些材料，Anthropic 团队对我们 MCP 服务器中的每一个工具进行了逐一审查，并对其中许多工具给出了（正面和负面的）反馈。他们检查了工具的规范符合性和安全性（这是预料之中的），但还进一步审视了：

• 工具和参数描述中使用的语言。
• 工具响应值中嵌入的元数据的影响。
• 每个工具的词元效率。
• 预期错误消息的有效性。
• 在特定许可证或产品版本中功能不可用的情况下，列出这些工具的价值。

Verified 徽章审核会增加什么

有趣的是，在起草这篇博客时，一个自主审阅者批评我此前没有仔细阅读 Claude 的验证文档，尤其是以下内容：

Anthropic 可能会将被标记为对 Claude 用户高度有用的条目升级为 Verified 审核，该审核流程更加深入且耗时更久，审核人员会对每个工具进行功能测试。该升级是自动评估的，无需单独申请 Verified 标签，也不需要你采取任何行动。

尽管如此，由于这让我们颇感意外，我认为有必要在此强调：如果你希望提交到 Claude 连接器目录并获得验证徽章，请做好接受高度严格审查的心理准备。

虽然这种级别的审查并非预料之中，但平心而论，它确实非常有帮助。它不仅让我们获得了 Verified 徽章，还发现了几个真实存在的 bug [1][2][3][4]，促使我们改变了对所有工具定义更好地自动化质量标准的方式 [5]，并迫使我们正视一个事实：并非每个工具都需要发布到 MCP 服务器中 [6][7][8][9][10][11][12][13]。

用数据来量化一下调整的规模：我们的 Elasticsearch 项目最初发布了 36 个工具。截至撰写本文时，一个项目默认暴露 22 个工具。

开发之后：批准与发布

我们勇敢的开发者们克服了重重障碍。他们更新了 MCP 规范符合性，重新审视了每个工具的设计意图以确认其合理性和粒度。描述被反复润色，指令语气被软化，文档链接被嵌入，错误提示信息被精细化。终于，Anthropic 团队授予了令人垂涎的批准…….

而连接器立刻就对公众可见了。没有最终的发布按钮，没有确认提示，甚至没有任何通知。我们某天打开目录管理页面，就看到了：

Anthropic 目录管理页面显示 Elastic Cloud Serverless MCP 连接器已标记为已发布

这本应值得庆祝——如果每个早期用户没有看到以下错误的话：

Claude 错误提示用户添加 OAuth Client ID，因为 Elastic Cloud Serverless 缺少自动客户端注册功能

还记得我前面说过客户特定配置这个话题还会再出现吗？

提交表单曾询问每个客户是否需要提供自己的 URL，我们提供了一组明确的 OAuth 凭据供测试使用。然而，我们没有澄清或确认客户特定配置表单会提示用户输入 client_id 和 client_secret 对（这两者需要从 Kibana 获取）。这第一个发布的版本只显示了：

首个发布的 MCP 连接器设置表单仅提示输入服务器 URL，没有 OAuth client ID 或 secret 字段

我们提到这一点，是为了给其他连接器发布者提供一个警示：如果你的 MCP 服务器像 Agent Builder 和 Snowflake 一样，属于少数拥有非静态 URL 并要求单独配置 OAuth 的类型，请务必在提交说明中提前注明这一需求。值得高兴的是，Anthropic 团队迅速为我们修复了这个问题。几天后，表单变成了：

修复后的 MCP 连接器表单提示输入服务器 URL、OAuth client ID 和 secret，并带有指向 Elastic OAuth 文档的链接

在 Claude Enterprise 中连接多个 MCP 服务器实例

使用这个连接器时我们遇到的另一个问题是，Claude Enterprise 账户只能从目录中连接一个连接器实例。这对于那些针对不同用例具有不同配置（实例）的 MCP 服务器来说并不理想。

虽然这类 MCP 服务器通常被描述为“面向客户”，但这并不一定意味着“面向账户”或“面向企业”。例如，一家企业可能有三个合理的 Elastic Cloud Serverless 项目：

1. Dev（开发环境）
2. QA（测试环境）
3. Prod（生产环境）

每个项目都有自己独立的 Agent Builder MCP 服务器，并需要各自的 OAuth 配置。这意味着你无法将这三个都作为目录连接器进行连接，因为一旦连接了一个，就没有选项可以添加另一个了：

Claude 连接器目录显示已验证的 Elastic Cloud Serverless MCP 连接器和 Elastic 插件

Claude 中已连接的 Elastic Cloud Serverless MCP 连接器，仅提供查看详情、刷新工具和移除选项

为了额外连接到你的 Elastic 资源，你（或管理员）必须添加一个自定义连接器：

Claude 连接器的添加菜单已打开，显示“添加自定义连接器”是连接第二个 Elastic MCP 服务器的途径

这样一来，你额外的连接会显示为：

Claude 连接器列表显示 Elastic Cloud Serverless 以及第二个作为自定义连接器添加的 Elastic MCP 服务器

如果你的 MCP 服务器使用静态 URL，以上这些内容几乎都不适用于你。

下一步：在 mcp.elastic.co 提供单一 MCP 服务器 URL

如果你不熟悉的话，"Progress, SIMPLE Perfection" 是 Elastic 公司价值观的一部分。特别摘录其中的两句话：

完美不是一个终点。……不断前进的 Elastic 才能生存、繁荣并经受住时间的考验。

我们清楚地认识到，Agent Builder MCP 服务器及其工具目录并不是我们智能体接口的最终形态。因此，我们没有固守过去的决策，而是积极从这次经验中学习并改进我们的架构。

我很高兴能在这篇博客中提前透露：一个集中、通用的 mcp.elastic.co MCP 服务器即将到来。目前还没有确定的具体日期，但请持续关注，随着日历翻到 '27 年。我们希望借此机会，改进这次 Claude 连接器集成所暴露出的几个结构性问题：

• 一个 MCP 服务器 URL（mcp.elastic.co），可以内置到插件、目录和市场中，且无需显式配置。
• 在我们的 OAuth 流程中支持 Client ID Metadata Document（CIMD），这样 client_id 和 client_secret 对也无需显式配置。
• 一个全新的工具目录，同时实现以下目标：
  • 避免工具泛滥。
  • 提供清晰的工具标注和职责分离。
  • 暴露更多功能（Elastic Cloud API，我们来了！）。

Agent Builder MCP 服务器会被移除吗？

对于目前正在使用 Agent Builder MCP 服务器的用户：请放心，它不会消失。虽然一路上有些波折，但我们仍然非常高兴为 Elastic 的智能体接口做出了这一增量改进。现在，我们的 MCP 服务器离你——我们的用户——更近了一步。