Metrics

opentel-mcp emits six OpenTelemetry metrics instruments through @opentelemetry/api's Metrics API: mcp.tool.calls, mcp.tool.errors, mcp.tool.silent_failures, mcp.tool.duration, and — new in v0.5.0 — mcp.tool.tokens.total and mcp.tool.cost.total. All six come from src/metrics.js's setupMeter(). The first four are recorded from the same isToolResultError() check that marks spans ERROR, so the metric and the trace never disagree about whether a call failed; the two cost/token counters are recorded from Cost & Token Attribution's applyCostAttribution() instead, independently of call outcome.

What are the six instruments?

mcp.tool.duration's mcp.tool.outcome attribute is one of success, error, or silent_failure — the same three-way split as the instrument names, but on a single histogram so you can compare call latency across all three outcomes without joining against error.type (which silent failures don't set on the duration metric).

Why is mcp.tool.silent_failures a separate counter from mcp.tool.errors?

Because they're different failure modes and mixing them into one counter would hide which one is happening. mcp.tool.errors counts handlers that threw or rejected — a JavaScript-level exception. mcp.tool.silent_failures counts handlers that returned normally with CallToolResult.isError: true — see Silent Failures for why that case is easy to miss entirely without this counter. A tool that's failing by throwing and a tool that's failing by returning isError: true usually point at different bugs; a single alert on both would tell you that something's wrong but not what.

Do I need to configure anything to get these?

No setup beyond registering a MeterProvider somewhere in your application — instrumentMcpServer() doesn't create one for you (unlike its tracing side, which can optionally create its own NodeTracerProvider via setupNodeSdk: true). Set enableMetrics: false in instrumentMcpServer()'s options to opt out of metrics specifically while keeping tracing; tracing has no equivalent metrics-only switch since it isn't one.

How do I query these in SigNoz?

Wiring a MeterProvider that exports to SigNoz's default local OTLP/HTTP endpoint:

import { metrics } from '@opentelemetry/api';
import { MeterProvider, PeriodicExportingMetricReader } from '@opentelemetry/sdk-metrics';
import { OTLPMetricExporter } from '@opentelemetry/exporter-metrics-otlp-http';
import { resourceFromAttributes } from '@opentelemetry/resources';
 
const meterProvider = new MeterProvider({
  resource: resourceFromAttributes({ 'service.name': 'my-mcp-server' }),
  readers: [
    new PeriodicExportingMetricReader({
      exporter: new OTLPMetricExporter({ url: 'http://localhost:4318/v1/metrics' }),
    }),
  ],
});
metrics.setGlobalMeterProvider(meterProvider);

With that registered before instrumentMcpServer() runs, a SigNoz dashboard panel querying mcp.tool.silent_failures grouped by gen_ai.tool.name shows which tools are failing silently, and how often, without opening a single trace.

How do I query cost per tool in SigNoz?

With the same MeterProvider registered, a SigNoz dashboard panel summing mcp.tool.cost.total grouped by gen_ai.tool.name over a time range shows which tools are actually driving LLM spend:

sum(mcp.tool.cost.total) by (gen_ai.tool.name)

That only reflects calls where Cost & Token Attribution detected a model and that model resolved in the configured pricingTable — see that page for what happens when it doesn't.

How do I query token spend by model?

Group the same counter — or mcp.tool.tokens.total for raw token volume instead of dollars — by mcp.tool.model (or the co-emitted gen_ai.response.model, for dashboards already built around the OTel GenAI semantic conventions) instead of tool name:

sum(mcp.tool.tokens.total) by (mcp.tool.model)

Useful for answering "which model is actually consuming the tokens," independent of which tool called it — a tool that calls multiple models conditionally would otherwise hide that split behind a single gen_ai.tool.name grouping.

How do I export these to Prometheus?

Register a Prometheus exporter as the MeterProvider's reader instead of an OTLP one — nothing about instrumentMcpServer() changes. Verified against @opentelemetry/exporter-prometheus current stable — pin your version and check the package README if you upgrade:

import { metrics } from '@opentelemetry/api';
import { MeterProvider } from '@opentelemetry/sdk-metrics';
import { PrometheusExporter } from '@opentelemetry/exporter-prometheus';
 
const meterProvider = new MeterProvider({
  readers: [new PrometheusExporter({ port: 9464 })],
});
metrics.setGlobalMeterProvider(meterProvider);

OpenTelemetry's Prometheus exporter converts metric names by replacing . with _ and appending _total to counters, so mcp.tool.silent_failures becomes mcp_tool_silent_failures_total in PromQL:

sum(rate(mcp_tool_silent_failures_total[5m])) by (gen_ai_tool_name)

That gives a per-tool silent-failure rate over a 5-minute window — a reasonable starting alert query, tune the window and threshold to your own traffic.

Where do I go from here?

• Silent Failures — what isError: true means and why mcp.tool.silent_failures exists at all.
• Deep Failure Fingerprinting — the mcp.failure.category attribute these metrics carry when fingerprinting classifies a failure.
• Cost & Token Attribution — how mcp.tool.tokens.total and mcp.tool.cost.total get populated, and the span attributes that go with them.
• API Reference — enableMetrics and the rest of instrumentMcpServer()'s options.