The read tools are layered the way an investigation actually runs: get_summary to see what exists, list_traces to narrow by service or error, get_trace for the span tree, and query_spans when the pattern across requests matters more than any single one. Traces live in memory and clear_traces empties them, so what you are reading is a running collector's working set rather than a long-term trace store — which is what makes it good for a test run and wrong for last week's incident.
A front end over the traces held in a collector's memory, with five tools covering overview, drill-down, cross-trace search and clearing.
- A trace listing narrowed by service, error presence, minimum duration or a time window, each row carrying duration, span count and error count
- The full span tree for one trace_id, with timing and optionally span attributes, showing where a request spent its time
- Span-level search across every trace by name, service, attribute or a where clause, for patterns such as slow database queries or failed HTTP calls
- get_summary as a starting point: total traces and spans, the services seen, and recent errors
- clear_traces to empty the collected set between runs, returning how many it removed
An OpenTelemetry collector this server can read from, and applications reporting traces into it. No account, no key and no environment variables. GPL-3.0 licensed.
One command — npx -y otel-mcp