OpenTelemetry Powers End‑to‑End Observability for Model Context Protocol Agents
Share this article
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.
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
- Decentralized MCP Server Instrumentation – Directly instruments each tool server, exporting tool‑level metrics and traces.
- 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.