Until recently, the moment an AI agent decided to call an outside tool was mostly a black box in observability setups. You could trace the call going to the model. If you had manually added instrumentation, you could sometimes trace the tool’s own execution too. What you usually could not do was see both of these connected together in one single trace, using a consistent set of fields that worked the same way no matter which agent framework or model provider was being used.
OpenTelemetry’s GenAI semantic conventions (a shared set of rules that define what names and fields should be used when recording data about AI systems) have now been extended to cover MCP, short for Model Context Protocol. MCP is the emerging standard for how AI agents discover and call outside tools and resources. In this article, I will explain what this addition actually gives you, why it matters if Elastic Observability, or any OpenTelemetry native backend, is already your tracing stack, and an important point about how settled this part of the specification actually is.
What MCP Tracing Actually Adds
MCP standardizes how a client, usually an AI agent powered by a language model, discovers and calls tools and resources exposed by an MCP server. Before this part of the specification existed, instrumentation of that exchange was inconsistent across different frameworks. Some agent libraries created their own custom spans (a span is simply one recorded unit of work in a trace, such as one function call or one network request). Some frameworks created no spans at all. Connecting a model’s decision to call a tool with that tool’s actual execution, especially across different vendors, was mostly manual work.
The MCP semantic conventions define a small set of dedicated fields for this layer.
mcp.method.name, the MCP method being calledmcp.protocol.version, the version of the MCP protocol being usedmcp.resource.uri, the resource being accessed, when there is onemcp.session.id, the identifier that ties multiple calls together as one agent session- Use an existing instrumentation library wherever one is available, instead of writing your own MCP span creation code from scratch. Since the field names are still changing, a well maintained library will track those changes for you automatically.
- Point your OTLP export at your existing Collector pipeline. If Elastic Observability is already your backend, these MCP spans will flow through the same ingestion path as the rest of your OpenTelemetry data. No separate agent or platform is needed.
- Pay close attention to
mcp.session.id. This is the field that lets you group every tool call an agent makes during one interaction into a single, connected view. That grouped view is usually the actual answer you are looking for when something goes wrong in production.
Rather than inventing a completely new set of fields, MCP tracing reuses fields that already exist in OpenTelemetry wherever they fit. This includes gen_ai.tool.name and gen_ai.prompt.name from the broader GenAI conventions, plus jsonrpc.request.id and rpc.response.status_code, since MCP itself is built on top of JSON-RPC, a simple, well established protocol for making remote calls. Span names follow a pattern of {mcp.method.name} {target}, where the target is the tool name or prompt name, used only when there is a meaningful, low cardinality one available.
One detail worth knowing if you plan to instrument this yourself. If your GenAI instrumentation is already creating a span for the tool’s execution, the specification says MCP instrumentation should add its attributes to that existing span rather than create a second, separate span for the same call. That may sound like a small detail, but it is the difference between a clean, readable trace and a confusing one showing two overlapping spans for a single tool call.
Why This Matters If You Are Already Using Elastic Observability
If your traces already flow into Elastic through OTLP (OpenTelemetry’s own standard data format for sending traces, metrics, and logs), whether that is through Elastic APM agents or direct OpenTelemetry ingestion, you do not need a separate, purpose built AI agent observability tool to get visibility into this layer. Once your MCP client or server starts emitting spans with these fields, the tool call shows up in the very same trace as the model call that triggered it, sitting right alongside your existing logs, metrics, and APM data inside Kibana.
In practical terms, this means you can start answering questions that were previously hard to trace from start to finish. You can find exactly which tool call caused a slow response from an agent. You can check whether an agent actually called the tool it claimed to call in its final answer. You can also see how many separate tool calls happened within a single mcp.session.id before the agent returned its answer to the user.
An Important Point: This Part of the Specification Is Not Stable Yet
It is worth being direct about this. OpenTelemetry’s GenAI semantic conventions, including the MCP specific fields, are still officially marked as under active development, not stable. This means the exact field names, the shape of the spans, and how MCP spans relate to GenAI spans can still change in future releases. If you build dashboards, alerts, or any other tooling on top of today’s field names, treat them as something you may need to revisit later, not as a fixed, permanent contract.
The practical takeaway is simple. Check the current state of the semantic-conventions-genai specification directly on GitHub before you commit to a long term integration built around these exact field names, rather than relying on any single article, including this one, as a permanent source of truth.
Getting Started
Frequently Asked Questions
Does OpenTelemetry support tracing MCP tool calls?
Yes. OpenTelemetry’s GenAI semantic conventions now include a dedicated set of fields for MCP, the Model Context Protocol. These fields cover the method, the protocol version, the resource, and the session identifiers involved in a tool call, and they are used alongside the existing gen_ai fields that are already used for model calls.
Is the OpenTelemetry MCP semantic convention stable?
Not yet. As of the current specification, GenAI semantic conventions, including the MCP specific fields, are officially marked as under active development. Field names and span structures may still change, so any integration built around them today should be treated as something to revisit later rather than a fixed, permanent contract.
Do I need a separate AI agent observability tool to trace MCP calls?
Not if you already have an OpenTelemetry native observability backend such as Elastic Observability. Once your MCP client or server sends spans using the standard fields over OTLP, they appear in the same traces as your existing logs, metrics, and APM data, without needing a separate, purpose built platform.
What does mcp.session.id actually let me do?
It ties multiple tool calls together as part of one single agent interaction. Instead of seeing isolated, disconnected tool call spans, you can view every tool call an agent made during one session as one connected sequence, which is usually exactly what you need when trying to understand an agent’s behavior.
You can also read this article on Medium.
Related Articles:
Elastic Observability AI Assistant: What It Does & How to Use It
OpenTelemetry Collector Configuration: Full Setup Guide
OpenAI’s AI Agents Broke Out of a Security Test and Hacked Hugging Face: What Actually Happened
Leave a Reply