feat(analytics): add anonymised usage telemetry via @elastic/ebt

[KDKHD]

Summary

Adds usage telemetry for the Elastic Security MCP app so we can understand which views and tools are being exercised.

Telemetry uses the Kibana telemetry opt-in setting from the default Kibana cluster. On startup, the app reads GET /api/telemetry/v2/config from that default cluster and only ships events when Kibana telemetry opt-in is enabled. If opt-in is disabled, unset, or the config fetch fails, the app stays opted out.

By default, telemetry is sent to production (telemetry.elastic.co). To test against staging, start the MCP server with:

MCP_APP_TELEMETRY_ENV=staging

claude_desktop_config.json

{
  "mcpServers": {
    "elastic-security": {
      "command": "node",
      "args": [
        "/Users/<BUILD PATH>/dist/main.js",
        "--stdio"
      ],
      "env": {
        "MCP_APP_TELEMETRY_ENV": "staging",
        "CLUSTERS_JSON": "[{\"name\":\"primary\",\"elasticsearchUrl\":\"https://my-deployment-782f0f.es.us-central1.gcp.cloud.es.io\",\"kibanaUrl\":\"https://my-deployment-782f0f.kb.us-central1.gcp.cloud.es.io\",\"elasticsearchApiKey\":\"<YOUR API KEY>\"}]"
      }
    }
  },
}

That routes events to telemetry-staging.elastic.co instead.

Test plan

• npm run test:run -- src/elastic/analytics/create-analytics-client.test.ts src/elastic/service/telemetryService.test.ts
• npm run typecheck

[KDKHD]

Question: license_id in telemetry context

The context block shipped with every event includes license_id (the Elasticsearch license UUID). For Elastic Cloud deployments this UUID is linkable to a specific customer in Elastic's internal systems — it's not user PII, but it is org-identifying information.

Can we get explicit product/privacy sign-off that collecting this is acceptable? @davethegut

| Field             | Source                              | Notes                                          |
|-------------------|-------------------------------------|------------------------------------------------|
| `cluster_uuid`    | Elasticsearch `GET /`               | Required by the V3 shipper; events do not ship without it |
| `cluster_version` | Elasticsearch `GET /` `version.number` | Stack version                              |
| `license_id`      | Elasticsearch `GET /_license`       | Optional                                       |
| `license_status`  | Elasticsearch `GET /_license`       | Optional                                       |
| `license_type`    | Elasticsearch `GET /_license`       | Optional                                       |
| `mcp_app_version` | `package.json` `version`            | Version of the MCP App that emitted the event  |

[davethegut]

@KDKHD - Smoke-tested this against staging from Claude Desktop — opt-in resolution, batching, and shipping all work cleanly, zero errors.

One thing worth flagging: execute-esql fired ~7,000 times in a single threat-hunt session because the Monaco editor live-validates on every keystroke. Each one emits a mcp_tool_called event. report-analytics-event is already excluded for the same reason — might be worth adding execute-esql to that list (or only emitting on explicit Run) before this starts drowning the dashboards.

Otherwise LGTM.

[davethegut]

Also, @KDKHD, noticed this weird bug when invoking a threat hunt? Dk if it is just my machine?

Clipboard-20260522-181337-405.mp4

[davethegut]

left a comment, but still approving this PR :)

[KDKHD]

@davethegut The UI bug and the repeated telemetry events bug were related and have been fixed now.

[davethegut]

Lgtm