Every prompt you send to an LLM costs money—but most teams have no idea where those tokens are actually going. A new case study published on DEV.to this week demonstrates how to instrument a Go AI service with OpenTelemetry to track token usage at scale, then leverage MCP (Model Context Protocol) to query and analyze the resulting telemetry data.

The Visibility Problem in Production AI

The core challenge is straightforward: when you're calling GPT-4o, Claude, or any other hosted model, you get back a bill but little insight into consumption patterns. Which endpoints are burning through tokens fastest? Are retries duplicating requests unnecessarily? Is your prompt engineering adding hundreds of unnecessary tokens per call? Without instrumentation, these questions remain unanswered until month-end sticker shock hits. The author (bhavesh_az) approached this by integrating OpenTelemetry directly into their existing Go AI service rather than wrapping it in a proxy layer. This gives them distributed tracing context—tying token usage back to specific requests, users, and upstream services that triggered the LLM call.

Instrumenting Token Tracking With OTel

The implementation captures both input and output token counts as span attributes within OpenTelemetry's trace model. By standardizing on OTLP (OpenTelemetry Protocol), this telemetry flows into any compatible backend: Jaeger for visualization, Prometheus for metrics, or a purpose-built observability platform like Honeycomb or Grafana Tempo. What makes this approach powerful is that token consumption becomes queryable alongside traditional infrastructure signals—latency, error rates, database queries. You can finally answer questions like "are high-latency responses correlated with longer output tokens?" without stitching together disparate monitoring systems.

MCP as the Analysis Layer

The Model Context Protocol comes into play when it's time to dig through the telemetry. Rather than writing raw SQL against a traces table or fighting with dashboard GUIs, MCP provides a structured way to query and explore the OpenTelemetry data programmatically. The author demonstrates using MCP to surface patterns that wouldn't be visible in aggregated metrics alone—individual request traces revealing prompt bloat, inefficient few-shot examples, or unexpected tokenization behaviors across different content types.

Key Takeaways

  • OpenTelemetry's trace model is a natural fit for AI observability since LLM calls are inherently span-like operations with rich metadata
  • Capturing both input and output tokens as attributes enables cost attribution back to specific features, users, or API endpoints
  • MCP transforms raw telemetry into actionable insights by providing a query interface that understands the structure of distributed traces
  • Without instrumentation, AI costs remain opaque until billing cycles reveal the damage retroactively

The Bottom Line

If you're running AI services in production without token-level observability, you're essentially flying blind on one of your biggest line items. OpenTelemetry plus MCP gives you the visibility to optimize prompts, catch regressions early, and actually understand where your LLM spend is going—not just react to invoices.