OpenTelemetry Powers End‑to‑End Observability for Model Context Protocol Agents

The Model Context Protocol (MCP) has become the backbone of modern agentic systems, enabling large language models (LLMs) to call external tools in a standardized way. Yet as agents grow more sophisticated, their internal choreography—LLM decision points, context management, and tool execution—remains opaque. OpenTelemetry (OTel), the open‑source instrumentation standard, steps in as the unifying layer that turns this opacity into actionable insight.

Article illustration 1

Two Sides of MCP Analytics

MCP analytics split naturally into producer and consumer perspectives:

  • Server‑Side Observability (Producer) – Tool execution latency, error distribution, usage breakdown, and server health.
  • Client‑Side Observability (Consumer) – Token usage, context efficiency, and model consumption.

Both sides must expose the same semantic conventions so that a single trace can span the entire agent journey.

Distributed Tracing: The Glue

OTel’s distributed tracing model is a perfect fit for MCP’s dual‑path architecture. A trace begins when a user submits a query to the agent (client side), proceeds through the LLM call, and continues into the tool execution on a remote MCP server. Each hop is represented by a span:

Span Layer Key Data
Agent Request Client Session ID, user ID
LLM Call Client/Proxy Input/Output tokens, model name
Tool Call Request Client Tool name, arguments
Tool Execution Server Execution time, success/failure

By propagating the Trace ID across the proxy and the MCP server, developers can visualize the full path and correlate token costs with tool performance.

"The push to leverage OpenTelemetry for Model Context Protocol analytics marks a professional and sustainable step forward for the agent ecosystem. – Om‑Shree‑0709, MCP Developers Summit

Practical Implementation: TypeScript SDK

Below is a minimal, production‑ready snippet that instruments an MCP server written in TypeScript. The @shinzolabs/instrumentation-mcp package automatically configures OTel, wraps tool handlers, and exports data via OTLP.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { instrumentServer } from "@shinzolabs/instrumentation-mcp";

// 1. Create your MCP server
const server = new McpServer({
    name: "my-mcp-server",
    version: "1.0.0",
    description: "My instrumented MCP server"
});

// 2. Add telemetry instrumentation
const telemetry = instrumentServer(server, {
    serverName: "my-mcp-server",
    serverVersion: "1.0.0",
    exporterEndpoint: "https://api.app.shinzo.ai/telemetry/ingest_http", // OTLP endpoint
    exporterAuth: {
        type: "bearer",
        token: "your-ingest-token-here"
    }
});

// 3. Define a simple tool – execution is automatically traced
server.tool("hello", {
    description: "Say hello",
    inputSchema: {
        type: "object",
        properties: { name: { type: "string" } }
    }
}, async (args) => {
    return { content: `Hello, ${args.name}!` };
});

The instrumentation layer captures span boundaries around the tool handler, emits metrics on latency and error rates, and forwards the data to the configured collector.

Dual‑Path Telemetry Architecture

  1. Decentralized MCP Server Instrumentation – Directly instruments each tool server, exporting tool‑level metrics and traces.
  2. Centralized Token & Context Interception – A proxy between the agent and LLM provider captures token counts and model metadata, then forwards the request.

The challenge is to stitch these paths together. Standardized context propagation (e.g., W3C Trace Context headers) is mandatory, and both client and server must honor the same semantic conventions.

Why Vendor‑Neutral Matters

Adopting OTel ensures that observability data can flow to any backend—Grafana, Prometheus, or a cloud‑native analytics platform—without vendor lock‑in. It also encourages a shared vocabulary for generative‑AI telemetry, making cross‑project comparisons possible.

The Road Ahead

Full end‑to‑end tracing across client‑side LLM calls and decentralized server‑side tool execution remains a complex engineering problem. However, the community is already producing standardized semantic conventions (e.g., mcp.tool_name, agent.session_id, llm.cached_tokens). As instrumentation libraries mature, the barrier to entry will drop, allowing developers to focus on building smarter agents rather than plumbing observability.

Source: "Building MCP Analytics with OpenTelemetry — Deep Dive with Shinzo Labs’ CEO", MCP Developers Summit, 2025.