mcp-agent-trace-inspector
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| db | No | Path to the SQLite database file used to store traces. Accepted as `--db` or `--db-path` in the command line. | ~/.mcp/traces.db |
| pricing-table | No | Path to a JSON file containing custom model pricing ($/1K tokens). Overrides the built-in table. | |
| no-token-count | No | Disable tiktoken-based token counting. Traces will omit token usage metrics. Accepted as `--no-token-count`. | false |
| retention-days | No | Automatically delete traces older than N days. Set to `0` to disable. | 0 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| logging | {} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| trace_startA | Begin a new agent workflow trace. Returns a trace_id to use with subsequent calls. Example: { "name": "My Search Workflow" }. Pass "auto" or leave name blank for an auto-generated name. |
| trace_stepB | Record a single step within a trace. Captures tool name, input, output, optional token count and latency. Example: { "trace_id": "abc-123", "tool_name": "web_search", "input": {"query": "hello"}, "output": {"results": ["a","b"]}, "token_count": 50, "latency_ms": 320 } |
| trace_endA | Mark a trace as completed. No further steps should be added after this call. Example: { "trace_id": "abc-123" } |
| get_trace_summaryA | Retrieve a summary of a trace including step count, total tokens, total latency, cost estimate, and reasoning chain detection. Example: { "trace_id": "abc-123", "model": "claude-sonnet-4-6" } |
| list_tracesA | List all stored traces with their names, statuses, and timestamps. Example: { "limit": 10 } to get the 10 most recent traces. |
| export_dashboardA | Generate a self-contained HTML dashboard for a trace with error highlighting and latency waterfall visualization. Returns the full HTML as a string. Example: { "trace_id": "abc-123" } |
| compare_tracesA | Compare two traces side by side: step counts, tokens, latency, and step-by-step differences. Example: { "trace_id_a": "abc-123", "trace_id_b": "def-456" } |
| extract_reasoning_chainA | Extract only the reasoning/thinking steps from a trace. Returns steps whose tool_name matches reasoning patterns (reason, think, plan, reflect, analyz, consider) or whose input/output content includes the word "think". Example: { "trace_id": "abc-123" } |
| export_otelA | Export trace(s) in OpenTelemetry OTLP JSON span format. Omit trace_id to export all traces. Example: { "format": "json" } or { "trace_id": "abc-123", "format": "json" } |
| configure_alertsC | Configure alert rules for latency, error rate, or cost thresholds. Example: { "rules": [{"type":"latency","threshold":1000}], "slack_webhook": "https://hooks.slack.com/..." } |
| set_retention_policyB | Set the trace retention policy (how many days to keep traces before archiving). Example: { "retention_days": 30 } |
| apply_retentionA | Apply the current retention policy: archives traces older than retention_days and deletes archived traces past 2× threshold. Example: {} |
| export_compliance_logB | Export the compliance audit log as JSON or CSV. Example: { "format": "json" } or { "format": "csv", "from_date": "2025-01-01", "to_date": "2025-12-31" } |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| analyze-trace | Guide an investigation of a completed agent trace — surfaces performance bottlenecks, errors, reasoning chains, and optimization opportunities. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
The core lifecycle tools (trace_start, trace_step, trace_end, get_trace_summary, list_traces) are clearly distinct, and the retention pair (set_retention_policy vs apply_retention) is differentiated by config-vs-execute semantics. The three export tools (export_compliance_log, export_dashboard, export_otel) are the only mild risk, but their descriptions and output formats clearly separate them.
Most tools follow a consistent verb_noun snake_case convention (configure_alerts, set_retention_policy, export_compliance_log, get_trace_summary, list_traces). The trace_start/trace_step/trace_end trio uses noun_verb ordering, a minor deviation but internally consistent.
13 tools is well-scoped for a trace inspector, covering lifecycle, analysis, export, and governance. Each tool earns its place with no redundant entries.
The trace lifecycle (start/step/end/summary/list), comparison, reasoning extraction, retention, alerts, compliance, and multiple export formats are all covered. Minor gaps exist such as no direct trace deletion or per-step retrieval/filtering, but agents can work around these.