作者来自 Elastic Jeffrey Rengifo了解如何使用 Elastic Agent Builder MCP server 将 Cursor 连接到你的 Elastic APM 数据这样你就可以在不离开编辑器的情况下调试生产错误并基于真实使用数据做出 UI 决策。前置条件Elasticsearch 9.3或 Elastic Cloud ServerlessElasticsearch 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 中查看。工具 1get_filter_usage产品团队需要在决定删除哪些筛选条件之前了解用户实际点击了哪些筛选项。该查询会从 traces-apm-default 中读取 RUM 交互事件并按 filter name 进行分组{ id: get_filter_usage, type: esql, description: Returns the usage count for each search filter in the ecommerce-search-ui service, sorted by most used first., configuration: { 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 } }工具 2get_recent_errors针对错误调试场景我们需要展示某个 service 中最近最常见的错误并指出它们在代码中的来源位置。 STATS ... BY 会按错误指纹grouping_key对错误进行分组提取异常信息以及导致错误的代码位置culprit并按出现频率进行排序{ id: get_recent_errors, type: esql, description: Returns the most frequent error groups for ecommerce-search-ui, ranked by occurrence count, with the exception message and code location., configuration: { 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 } }这两个工具都是通过 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 作为本地进程调用{ mcpServers: { elastic-agent-builder: { command: npx, args: [ -y, mcp-remote, https://YOUR_KIBANA_URL/api/agent_builder/mcp, --header, Authorization: ApiKey YOUR_API_KEY ] } } }将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 部署门禁。后续步骤Elastic Agent Builder MCP server 文档Model Context Protocol 规范Elastic Agent Builder 概览原文https://www.elastic.co/observability-labs/blog/elastic-mcp-server-cursor-production-logs