[Feature]: Expose SPM metrics through MCP server #8409

Requirement

As an LLM agent using Jaeger's MCP server, I want to query service performance metrics (latency percentiles, call rates, error rates) so that I can assess service health without searching individual traces and inferring health from samples.

Problem

The MCP server provides trace-level tools (search, topology, critical path, span details). Jaeger's SPM feature computes RED metrics and serves them via /api/metrics/*, but there is no MCP tool to access this data.

For deployments with SPM configured, an agent must currently search for individual traces and infer health from samples, even when precomputed metrics exist. This is an unnecessary indirection.

Proposal

Add an MCP tool (e.g., get_service_metrics) that exposes the existing metricstore.Reader (latency percentiles, call rates, and error rates) through the MCP server. This would let an agent answer "what is the P95 latency for the frontend service?" in a single tool call.

SPM is optional and requires a configured metrics backend (e.g., Prometheus). The tool would need to degrade gracefully when metrics storage is not configured, either by not registering the tool or by returning a clear "metrics not configured" message.

Scope question: ADR-002 scopes the MCP server to trace-level progressive disclosure and does not mention SPM metrics. The proposed get_service_dependencies tool (#8403) would set a precedent for exposing non-trace aggregate data through the MCP server, but metrics may be a different category. I recognize this may be outside ADR-002's intended scope and would require a design amendment if approved.

Alternatives considered:

• Agent queries Prometheus directly: A separate Prometheus MCP server or HTTP tool for metrics. Keeps Jaeger's MCP server trace-focused but requires the agent to coordinate across two data sources.
• Derive health from traces only: Search recent traces, count errors, estimate latency from samples. Works without SPM but is less accurate and uses more context window.

Implementation notes:

• The metricstore.Reader uses the v1 storage API. There is no v2 equivalent. Flagging in case there are migration plans I'm not aware of.
• Wiring would require exposing the metrics reader through the jaegerquery.Extension interface. Happy to discuss approaches if the direction is approved.
• Multi-tenancy would need to be respected for metrics queries, consistent with existing tools.

Update 2026-04-24

#8425 removed GetMinStepDuration from metricstore.Reader. The remaining stable surface is three reader APIs: GetLatencies, GetCallRates, GetErrorRates. Scope for this feature is bounded to those three.

Open questions

1. Does exposing SPM data fit within the MCP server's charter, or should metrics remain a separate concern?
2. If yes, one tool (get_service_metrics with a metric_type parameter) or three separate tools?
3. Should the tool be omitted entirely when metrics storage isn't configured?