- Connect MCP tool spans to the downstream service that determines the result.
- Use low-cardinality MCP dimensions for filtering and metrics.
- Keep payloads minimized, redacted, sampled, and fail-open.
OpenTelemetry can connect an MCP tool call to the downstream APIs, databases, queues, and services that determine its result. The useful design is to keep standard traces, metrics, and logs while adding MCP context such as client, tool, method, transport, outcome class, and correlation identity.
What belongs in a trace
- A server or transport span for the MCP request.
- A tool execution span with method, tool name, and outcome class.
- Child spans for downstream HTTP, database, queue, or model calls.
- A trace or workflow identity that lets operators reconstruct the path.
- Deployment, environment, service version, and protocol version.
Recommended MCP dimensions
Use low-cardinality attributes for filtering and dashboards. Client name, tool name, method, transport, environment, outcome class, and server version are usually more useful than putting raw arguments into every span.
Keep high-cardinality data out of default metrics
User IDs, URLs, document IDs, free-form queries, and raw arguments can create cardinality and privacy problems. Keep them out of default metric labels. If a debugging trace needs a redacted identifier, put it behind access controls and retention limits.
Metrics to start with
- Tool calls by tool, client, environment, and outcome class.
- Tool duration as a histogram by tool and outcome class.
- Active workflows or sessions where the application has a meaningful lifecycle.
- Retries by tool and client.
- Workflow completions by workflow and outcome.
Logs still matter
Traces answer where time went. Metrics answer how often a condition occurs. Structured logs preserve the detailed event needed to inspect a failure. Link logs to traces with a correlation ID, redact sensitive values before emission, and record tool-level error state rather than only HTTP status.
Sampling and fail-open behavior
Sample routine success traces when volume is high, but retain enough errors and incomplete workflows to investigate regressions. Bound queues and export timeouts. Observability must not block the tool call or turn an analytics outage into an MCP outage.
Connect the trace to the outcome
A tool span is not the same as a useful result. When the application knows that a ticket was created, a deployment was verified, or a report was delivered, emit an explicit workflow outcome and link it to the trace. That is how infrastructure telemetry becomes product insight.
Frequently asked questions
Does OpenTelemetry replace MCP analytics?
OpenTelemetry provides a strong foundation for traces, metrics, and logs. MCP analytics adds protocol- and product-specific views such as client mix, tool adoption, retries, sessions, and workflow outcomes.
Should MCP arguments be stored in spans?
Not by default. Prefer minimized metadata and redact sensitive fields locally. Store payload details only when there is a documented debugging need, access policy, and retention limit.
What is the most useful MCP trace attribute?
Tool name is usually the first useful dimension, followed by client, method, environment, outcome class, protocol or server version, and a correlation identity.
See this on your own server
TrackMCP turns your MCP server's calls into adoption, workflows, and outcomes. One line to install.