说到作者，来自 Elastic Jeffrey Rengifo

了解如何使用 Elastic Agent Builder MCP server 将 Cursor 连接到你的 Elastic APM 数据。这样你就可以在不离开编辑器的情况下调试生产错误，并基于真实使用数据做出 UI 决策。

前置条件

• Elasticsearch +
• Elasticsearch API KEY 和 Kibana URL
• 一个已接入 Elastic APM 的应用：用于前端交互的 RUM agent，还有用于后端错误的 APM agent
• 已安装 Cursor

两个世界的问题

应用日志和代码处于两个互不相通的世界。如果你想把日志洞察应用到代码中，你必须先分析日志。接下来回到编辑器手动应用你的发现。

Model Context Protocol改变了这一点。MCP 是一个开放标准，它允许 AI 客户端通过统一接口连接外部工具和数据源。你的 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 中。

在开发过程中会出现两个典型场景：

• 用例 : 产品团队希望简化搜索页面。老实说，目前有 个筛选条件，但我们不知道使用者实际点击了哪些。需要使用数据来决定哪些可以保留。怎么说呢，
• 用例 : 使用者报告搜索接口出现间歇性 错误。这些错误不是持续发生的，而且是从两天前开始出现的。需要错误详情来定位根本原因。

为了将这些数据引入 Cursor，我们将在 Kibana 中建立两个 Agent Builder 工具。并通过 Elastic Agent Builder MCP Server 进行连接：

• get_filter_usage: 查询 traces-apm-default 中的筛选点击事件，并按 filter name 返回使用情况统计。
• get_recent_errors: 查询 logs-apm.error-default 中最近的错误分组，包含异常信息和导致问题的 stack trace。说起来，

要更整体架构。可以查看 Agent Builder 参考教程。

设置 Elastic MCP Server

步骤 ：创建 Agent Builder 工具

我们通过 Kibana Agent Builder API 创建这两个工具。每个工具本质上是一个 ES|QL 查询，包含名称和描述。Cursor 会根据这些信息判断何时调用它们。工具的完整实现可以在以下 notebook 中查看。按理说，

工具 ：get_filter_usage

产品团队需要在决定删除哪些筛选条件之前。了解使用者实际点击了哪些筛选项。该查询会从 traces-apm-default 中读取 RUM 交互事件，并按 filter name 进行分组：

{
至于"id"，"get_filter_usage","type": "esql","description": "Returns usage count for each search filter in 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"
}
}
AI写代码

工具 ：get_recent_errors

针对错误调试场景，需要展示某个 service 中最近最常见的错误，并指出它们在代码中的来源位置。STATS ... BY 会按错误指纹对错误进行分组，提取异常信息还有导致错误的代码位置，并按出现频率进行排序：

{
至于"id"，"get_recent_errors","type": "esql","description": "Returns most frequent error groups for ecommerce-search-ui,ranked by occurrence count,with 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..message,error.culprit | SORT count DESC | LIMIT "
}
}
AI写代码

This 两个工具都是通过 POST /api/agent_builder/tools 创建的。老实说，你可以在这里了解更多关于 Elastic Agent Builder 的 Kibana API 端点。

步骤 ：连接到 Cursor

{
"mcpServers": {
"elastic-agent-builder": {
"command": "npx","args":
}
}
}
AI写代码
将  和  替换为你的实际值。

重启 Cursor。打开 Agent 面板，并确认 get_filter_usage 和 get_recent_errors 已出现在可用工具列表中。

用例 ：根据数据调整的 UI 调整

Based on this data。simplify SearchFilters component. Keep top filters visible,collapse ors under a 'More filters' toggle./根据这些数据，简化 SearchFilters 组件。保留使用率最高的 个筛选项，将其他筛选项折叠到一个 ‘More filters’开关中。”

从修改前来看，

再看修改后。

整个流程只用了一个聊天提示。这个决策是基于生产数据，而不是团队对 “使用者可能在意什么” 的主观讨论。怎么说呢，