作者：来自 Elastic Jeffrey Rengifo
了解如何使用 Elastic Agent Builder MCP server 将 Cursor 连接到你的 Elastic APM 数据，这样你就可以在不离开编辑器的情况下调试生产错误，并基于真实使用数据做出 UI 决策。
前置条件
- Elasticsearch 9.3+（或 Elastic Cloud Serverless）
- Elasticsearch API KEY 和 Kibana URL
- 一个已接入 Elastic APM 的应用：用于前端交互的 RUM agent（写入 traces-apm-_），_以及用于后端错误的 APM agent（写入 logs-apm.error-）
- 已安装 Cursor（版本 2.6+）
两个世界的问题
应用日志和代码处于两个互不相通的世界。如果你想把日志洞察应用到代码中，你必须先分析日志，然后回到编辑器手动应用你的发现。
Model Context Protocol（ MCP ）改变了这一点。 MCP 是一个开放标准，它允许 AI 客户端（例如 Cursor ）通过统一接口连接外部工具和数据源。你的 IDE 不再只能理解本地代码，它还可以连接你的 Elasticsearch 集群、查询 APM 数据，并将生产环境行为与源代码一起进行推理。
Elastic 在 Agent Builder中提供了内置的 MCP server。你可以在 Kibana 中定义工具，通过 MCP endpoint 暴露它们，然后任何支持 MCP 的客户端都可以调用这些工具。Cursor 原生支持 MCP，这意味着你可以在几分钟内完成配置。
我们正在构建的内容
我们使用一个已接入 Elastic APM 的电商搜索应用作为示例。RUM JS agent 会追踪浏览器中的筛选点击交互，并存储在 traces-apm-default 中。Node.js APM agent 会捕获后端错误，并存储在 logs-apm.error-default 中。
在开发过程中会出现两个典型场景：
- 用例 1：产品团队希望简化搜索页面。目前有 6 个筛选条件，但我们不知道用户实际点击了哪些。我们需要使用数据来决定哪些可以保留。
- 用例 2：用户报告搜索接口出现间歇性 500 错误。这些错误不是持续发生的，并且是从两天前开始出现的。我们需要错误详情来定位根本原因。
为了将这些数据引入 Cursor，我们将在 Kibana 中构建两个 Agent Builder 工具，并通过 Elastic Agent Builder MCP Server 进行连接：
- get_filter_usage：查询 traces-apm-default 中的筛选点击事件，并按 filter name 返回使用情况统计
- get_recent_errors：查询 logs-apm.error-default 中最近的错误分组（按 service），包含异常信息和导致问题的 stack trace
要更深入了解整体架构，可以查看 Agent Builder 参考指南。
设置 Elastic MCP Server
步骤 1：创建 Agent Builder 工具
我们通过 Kibana Agent Builder API 创建这两个工具。每个工具本质上是一个 ES|QL 查询，包含名称和描述，Cursor 会根据这些信息判断何时调用它们。工具的完整实现可以在以下 notebook 中查看。
工具 1：get_filter_usage
产品团队需要在决定删除哪些筛选条件之前，了解用户实际点击了哪些筛选项。该查询会从 traces-apm-default 中读取 RUM 交互事件，并按 filter name 进行分组：
`1. {
2. "id": "get_filter_usage",
3. "type": "esql",
4. "description": "Returns the usage count for each search filter in the ecommerce-search-ui service, sorted by most used first.",
5. "configuration": {
6. "query": "FROM traces-apm-default | WHERE service.name == \"ecommerce-search-ui\" | WHERE transaction.type == \"user-interaction\" | WHERE labels.filter_name IS NOT NULL | STATS count = COUNT(*) BY labels.filter_name | SORT count DESC"
7. }
8. }`AI写代码
工具 2：get_recent_errors
针对错误调试场景，我们需要展示某个 service 中最近最常见的错误，并指出它们在代码中的来源位置。 STATS ... BY 会按错误指纹（grouping_key）对错误进行分组，提取异常信息以及导致错误的代码位置（culprit），并按出现频率进行排序：
`1. {
2. "id": "get_recent_errors",
3. "type": "esql",
4. "description": "Returns the most frequent error groups for ecommerce-search-ui, ranked by occurrence count, with the exception message and code location.",
5. "configuration": {
6. "query": "FROM logs-apm.error-default | WHERE service.name == \"ecommerce-search-ui\" | WHERE processor.name == \"error\" | STATS count = COUNT(*) BY error.grouping_key, error.exception.0.message, error.culprit | SORT count DESC | LIMIT 5"
7. }
8. }`AI写代码
这两个工具都是通过 POST /api/agent_builder/tools 创建的。你可以在这里了解更多关于 Elastic Agent Builder 的 Kibana API 端点。
步骤 2：连接到 Cursor
打开 ~/.cursor/mcp.json 并添加 Elastic server。更多细节可以参考 Cursor 文档。Agent Builder MCP endpoint 使用 Server-Sent Events（ SSE ）传输，因此我们通过 mcp-remote 进行连接——这是一个轻量级桥接工具，由 Cursor 作为本地进程调用：
`1. {
2. "mcpServers": {
3. "elastic-agent-builder": {
4. "command": "npx",
5. "args": [
6. "-y",
7. "mcp-remote",
8. "https://YOUR_KIBANA_URL/api/agent_builder/mcp",
9. "--header",
10. "Authorization: ApiKey YOUR_API_KEY"
11. ]
12. }
13. }
14. }`AI写代码
将 YOUR_KIBANA_URL 和 YOUR_API_KEY 替换为你的实际值。
重启 Cursor，打开 Agent 面板，并确认 get_filter_usage 和 get_recent_errors 已出现在可用工具列表中。
用例 1：数据驱动的 UI 优化
电商搜索页面包含 6 个筛选条件：category（分类）、manufacturer（制造商）、price range（价格范围）、customer gender（用户性别）、day of week（星期几）、region（地区）。产品团队希望通过移除使用率较低的筛选项来简化 UI，但他们不想靠猜测，而是直接让 Cursor 来分析。
当你在 Cursor 的 Agent 面板中输入提示时，模型可以看到所有已连接 MCP 工具的名称和描述，并据此自动匹配最合适的工具并调用。这也是为什么我们在步骤 1 中设置的 description 字段非常重要——模型正是通过它来判断应该使用哪个工具来回答你的问题。如果你想了解更多关于 Cursor 的 MCP 工具管理，可以阅读相关文档。
打开 Cursor 聊天并提问：“Show me how often each search filter is used.” Cursor 会调用工具并返回类似如下结果：
category 和 manufacturer 筛选项获得最多点击。使用率最低的三个筛选项（ customer_gender、 day_of_week、 region ）几乎很少被使用。
让 Cursor 基于这些数据执行操作：“***Based on this data, simplify the SearchFilters component. Keep the top 3 filters visible, collapse the others under a 'More filters' toggle./***根据这些数据，简化 SearchFilters 组件。保留使用率最高的 3 个筛选项，将其他筛选项折叠到一个 ‘More filters’（更多筛选）开关中。”
Cursor 会打开 src/components/SearchFilters.jsx，读取当前实现，并提出修改建议。
修改前：
修改后：
整个流程只用了一个聊天提示。这个决策是基于生产数据，而不是团队对 “用户可能在意什么” 的主观讨论。
用例 2：生产错误调试
收到一个 bug 报告：search endpoint 出现间歇性 500 错误。这些错误从两天前开始出现，但并不是持续发生。开发者打开 Cursor 并提问：“Show me what errors ecommerce-search-ui is throwing.”
Cursor 调用工具并返回错误分组：
错误信息很明确：category 是一个 text 字段，不能用于 terms 聚合。正确的字段应该是 category.keyword。
当 APM 数据与代码一起可用时，调试过程就变成了一种“对话”：你描述现象，agent 拉取相关日志，然后你们在同一个上下文中一起分析问题。你可以继续追问、检查错误是否与最近一次部署相关，或者查看哪些 endpoint 受影响最严重，而所有这些都发生在你最终会进行修复的同一环境中。
如果你想更进一步，Elastic 也在 Agent Builder 中提供了预置的可观测性工具，可以和这里自定义的工具一起使用。关于 AI 驱动可观测性的补充方案，可以参考如何使用 OpenLIT 和 Elastic 监控 web AI agents。
结论
我们涵盖了：
- 如何在 Kibana 中创建 Agent Builder 工具来封装 APM 数据查询
- 如何通过三行 JSON 将 Elastic Agent Builder MCP Server 连接到 Cursor
- 如何使用生产环境遥测数据做出基于真实使用情况的 UI 决策
- 如何在修复问题的同一窗口中调试生产错误
这两个用例只是起点。同样的模式适用于你在 Elasticsearch 中的任何数据：性能指标、A/B 测试结果、审计日志、功能开关使用情况、用户会话数据。定义 Agent Builder 工具，通过 MCP 连接，它就会成为 Cursor 中开发上下文的一部分。更多示例可以参考使用 MCP 自动化合成监控，以及基于 agent 的 CI/CD 部署门禁。
