Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

io.github.mcpsmiths/tracehub-mcp

PYPI · TRACEHUB-MCP · SCANNED SEP 20

Query OpenTelemetry traces from LLM apps across Jaeger, Tempo, Traceloop, Datadog, Sentry, X-Ray.

Available components

+18 this week 73 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security100
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
  • 4 of 59 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency48
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
  • Clear OSI-approved license (Apache-2.0).Pass
  • Actively maintained (last published 0 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability67
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 3578 tokens (~188/item across 19 items; 19 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management23
  • Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 19 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 19 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a current MCP spec version (2026-07-28).Pass
Install

How do I install the io.github.mcpsmiths/tracehub-mcp server?

io.github.mcpsmiths/tracehub-mcp runs locally as a PyPI package, launched with uvx tracehub-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

pypi · tracehub-mcp

# add to Claude Code
claude mcp add mcpsmiths-tracehub-mcp -- uvx tracehub-mcp
// .cursor/mcp.json
{
  "mcpServers": {
    "mcpsmiths-tracehub-mcp": {
      "command": "uvx",
      "args": [
        "tracehub-mcp"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "mcpsmiths-tracehub-mcp": {
      "command": "uvx",
      "args": [
        "tracehub-mcp"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add mcpsmiths-tracehub-mcp -- uvx tracehub-mcp
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "mcpsmiths-tracehub-mcp": {
      "type": "local",
      "command": [
        "uvx",
        "tracehub-mcp"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add mcpsmiths-tracehub-mcp --command uvx --arg tracehub-mcp
# ~/.hermes/config.yaml
mcp_servers:
  mcpsmiths-tracehub-mcp:
    command: "uvx"
    args: ["tracehub-mcp"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "mcpsmiths-tracehub-mcp": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "tracehub-mcp"
      ]
    }
  }
}
# add to Vellum
assistant mcp add mcpsmiths-tracehub-mcp -t stdio -c uvx -a tracehub-mcp
// mcp.json
{
  "mcpServers": {
    "mcpsmiths-tracehub-mcp": {
      "command": "uvx",
      "args": [
        "tracehub-mcp"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 20 Sept 26 +1
    • Stability: 0.20 → unverified security
    • Tool safety: pass → unverified security
    • Malware scan: pass → unverified security
    • Schema quality: 3125 → 3578 functional
    • Capabilities: pass → unverified functional
    • Tool coverage: 100 → unverified functional
    • First check of Schema quality: unverified functional
    • Package version: 0.11.0 → 0.12.1 functional
    • Package version: 0.11.0 → 0.12.0 functional
  • 19 Sept 26 +15
    • Tool safety: pass → unverified security
    • Stability: 0.17 → unverified security
    • Malware scan: unverified → pass security
    • Capabilities: pass → unverified functional
    • Tool coverage: 100 → unverified functional
    • First check of Schema quality: unverified functional
    • MCP protocol: Implements a current MCP spec version (2026-07-28). functional
    • Package version: 0.10.0 → 0.11.0 functional
  • 18 Sept 26 −14
    • Malware scan: pass → unverified security
    • Package version: 0.9.0 → 0.10.0 functional
  • 17 Sept 26 0
    • Tool safety: pass → unverified security
    • Stability: 0.10 → unverified security
    • Malware scan: pass → unverified security
    • Capabilities: pass → unverified functional
    • Tool coverage: 100 → unverified functional
    • First check of Schema quality: unverified functional
    • Package version: 0.8.1 → 0.9.0 functional
    • Package version: 0.8.1 → 0.8.2 functional
  • 16 Sept 26 +15
    • Stability: 0.07 → unverified security
    • Tool safety: pass → unverified security
    • Malware scan: unverified → pass security
    • Schema quality: 2468 → 3050 functional
    • Capabilities: pass → unverified functional
    • Tool coverage: 100 → unverified functional
    • First check of Schema quality: unverified functional
    • Package version: 0.6.0 → 0.8.1 functional
    • Package version: 0.6.0 → 0.8.0 functional
    • Package version: 0.6.0 → 0.7.0 functional
  • 15 Sept 26 +1
    • Security disclosure: fail → pass functional
    • Package version: 0.5.0 → 0.6.0 functional
  • 14 Sept 26 0
    • Schema quality: 1765 → 2468 functional
    • Stability: unverified → 0.03 functional
    • Package version: 0.4.0 → 0.5.0 functional
  • 13 Sept 26 55

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 20 Sept 2026 · Analysed pypi/tracehub-mcp@0.12.1

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem pypi

Background: How many MCP packages publish verified provenance →

Install scripts 1 script
Hook Tier Command
build_backend allowlisted hatchling.build

Background: Why install scripts are a supply-chain risk →

Dependencies 59 packages
Packages resolved 59
Stale 2
No linked repository 2
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 19 exposed · ~3,578 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
compare_time_windows ~221

Compare aggregated LLM usage metrics between two time windows. Runs the same usage aggregation for both ranges and returns the delta - useful for "this week vs last week" or "before/after a deploy" style comparisons of request/token counts.

NameTypeReqDescription
gen_ai_request_modelFilter by requested model name (applied to both ranges)
gen_ai_response_modelFilter by actual model used (applied to both ranges)
gen_ai_systemFilter by LLM provider (applied to both ranges)
limitintegerMaximum number of traces to analyze per range (default: 1000)
range_a_endRange A end time in ISO 8601 format
range_a_startRange A start time in ISO 8601 format
range_b_endRange B end time in ISO 8601 format
range_b_startRange B start time in ISO 8601 format
service_nameFilter by service name (applied to both ranges)
NameTypeReqDescription
resultstringyes

No examples provided.

correlate_trace ~180

Try to find the corresponding trace in a second, independently- configured backend (e.g. a Datadog trace and its downstream Sentry error, joined) - given a trace_id known to the primary backend. Tries a direct trace_id match in the secondary backend first (confidence "high"); if that fails, falls back to a time-window + service-name-overlap heuristic search (confidence "low"). This is a best-effort correlation, not a guaranteed join - see the always-present `limitations` in the result for why. Requires a secondary backend to be configured via SECONDARY_BACKEND_TYPE/SECONDARY_BACKEND_URL (and any backend-specific fields) environment variables; raises a clear error otherwise.

NameTypeReqDescription
trace_idstringyesTrace identifier, as known to the primary (already configured) backend.
NameTypeReqDescription
limitationsarrayyes
matchesarrayyes
primary_trace_idstringyes

No examples provided.

find_errors ~83

Find traces with errors. Including detailed error messages, stack traces, and LLM-specific error information.

NameTypeReqDescription
end_timeEnd time in ISO 8601 format
limitintegerMaximum error traces to return (default: 100)
service_nameFilter by service name
start_timeStart time in ISO 8601 format
NameTypeReqDescription
resultstringyes

No examples provided.

get_llm_expensive_traces ~168

Find traces with highest LLM token usage. Useful for cost optimization and identifying inefficient prompts.

NameTypeReqDescription
end_timeEnd time in ISO 8601 format
gen_ai_request_modelFilter by requested model name (e.g., "gpt-4")
gen_ai_response_modelFilter by actual model used (e.g., "gpt-4-0613")
limitintegerMaximum number of traces to return (default: 10)
min_tokensMinimum token count threshold (only return traces above this)
service_nameFilter by service name
start_timeStart time in ISO 8601 format (e.g., 2024-01-01T00:00:00Z)
NameTypeReqDescription
resultstringyes

No examples provided.

get_llm_model_stats ~147

Get detailed performance statistics for a specific LLM model. Analyzes request count, latency percentiles (p50, p95, p99), token usage statistics, error rates, and finish reason distributions.

NameTypeReqDescription
end_timeEnd time in ISO 8601 format
model_namestringyesModel name to analyze (e.g., "gpt-4", "claude-3-opus", "gpt-3.5-turbo")
service_nameFilter by service name
start_timeStart time in ISO 8601 format (e.g., 2024-01-01T00:00:00Z)
NameTypeReqDescription
resultstringyes

No examples provided.

get_llm_slow_traces ~172

Find slowest LLM traces by duration. Useful for performance optimization and identifying latency bottlenecks.

NameTypeReqDescription
end_timeEnd time in ISO 8601 format
gen_ai_request_modelFilter by requested model name (e.g., "gpt-4")
gen_ai_response_modelFilter by actual model used (e.g., "gpt-4-0613")
limitintegerMaximum number of traces to return (default: 10)
min_duration_msMinimum duration threshold in milliseconds (only return traces above this)
service_nameFilter by service name
start_timeStart time in ISO 8601 format (e.g., 2024-01-01T00:00:00Z)
NameTypeReqDescription
resultstringyes

No examples provided.

get_llm_usage ~126

Get aggregated LLM usage metrics (token counts) for a time period. Provides breakdowns by model and service.

NameTypeReqDescription
end_timeEnd time in ISO 8601 format
gen_ai_request_modelFilter by requested model name
gen_ai_response_modelFilter by actual model used
gen_ai_systemFilter by LLM provider
limitintegerMaximum traces to analyze (default: 1000)
service_nameFilter by service name
start_timeStart time in ISO 8601 format
NameTypeReqDescription
resultstringyes

No examples provided.

get_prompt_version_stats ~170

Get aggregated performance stats grouped by prompt name and version. Groups spans by gen_ai.prompt.name + gen_ai.prompt.version, mirroring Langfuse's shipped per-prompt Metrics tab. Real-world adoption of these two attributes is still thin, so this tool may often return an empty list until more instrumentations populate them.

NameTypeReqDescription
end_timeEnd time in ISO 8601 format
gen_ai_systemFilter by LLM provider (openai, anthropic, etc.)
limitintegerMaximum spans to analyze (default: 1000)
service_nameFilter by service name
start_timeStart time in ISO 8601 format (e.g., 2024-01-01T00:00:00Z)
NameTypeReqDescription
resultstringyes

No examples provided.

get_session_stats ~147

Get detailed statistics for a single conversation/session. Analyzes span count, distinct services, time bounds, LLM request/success/ error counts, latency percentiles, and token usage for every span sharing the given gen_ai.conversation.id.

NameTypeReqDescription
conversation_idstringyesThe gen_ai.conversation.id to analyze
end_timeEnd time in ISO 8601 format
limitintegerMaximum spans to analyze (default: 1000)
service_nameFilter by service name
start_timeStart time in ISO 8601 format (e.g., 2024-01-01T00:00:00Z)
NameTypeReqDescription
resultstringyes

No examples provided.

get_trace ~119

Get complete trace details by trace ID. Returns all spans with attributes, including parsed Opentelemetry data for LLM operations.

NameTypeReqDescription
detail_levelstring"full" (default) returns every attribute/event value in full, unchanged from this tool's original behavior. "summary" elides known-large gen_ai.* fields (input/output messages, system instructions, r…
trace_idstringyesTrace identifier
NameTypeReqDescription
detail_levelstringyes
duration_msnumberyes
has_errorsbooleanyes
llm_summary
root_operationstringyes
service_namestringyes
span_countintegeryes
spansarrayyes
start_timestringyes
statusstringyes
trace_idstringyes

No examples provided.

investigate_cost_spike ~297

Investigate an LLM cost spike: compare a recent window against a baseline and rank which models/services contributed most to the change. On-request/pull-based analysis, not a push alert - mirrors SigNoz's own "investigate telemetry cost" skill. Call this when you suspect (or want to check for) a cost increase, rather than polling get_llm_usage by hand.

NameTypeReqDescription
baseline_endBaseline window end (ISO 8601)
baseline_startBaseline window start (ISO 8601). If omitted along with baseline_end, auto-computed as the same duration immediately preceding recent_start.
gen_ai_request_modelFilter by requested model name (applied to both windows)
gen_ai_response_modelFilter by actual model used (applied to both windows)
gen_ai_systemFilter by LLM provider (applied to both windows)
limitintegerMaximum number of traces to analyze per window (default: 1000)
recent_endstringyesRecent window end time in ISO 8601 format
recent_startstringyesRecent window start time in ISO 8601 format
service_nameFilter by service name (applied to both windows)
top_nintegerMaximum ranked contributors to return per breakdown (default: 5, max: 50)
NameTypeReqDescription
resultstringyes

No examples provided.

investigate_error_spike ~285

Investigate an error-rate spike: compare a recent window against a baseline and rank which services/models/error types contributed most. is_spike requires both an absolute error-count floor and a relative rate-multiplier to hold, so a tiny sample (e.g. 1 error becoming 2) doesn't read as a spike.

NameTypeReqDescription
baseline_endBaseline window end (ISO 8601)
baseline_startBaseline window start (ISO 8601). If omitted along with baseline_end, auto-computed as the same duration immediately preceding recent_start.
limitintegerMaximum number of traces to analyze per window (default: 1000)
min_error_count_increaseintegerMinimum absolute error-count increase to count as a spike (default: 3)
rate_multiplier_thresholdnumberMinimum error-rate multiplier (recent / baseline) to count as a spike (default: 2.0)
recent_endstringyesRecent window end time in ISO 8601 format
recent_startstringyesRecent window start time in ISO 8601 format
service_nameFilter by service name (applied to both windows)
top_nintegerMaximum ranked contributors to return per breakdown (default: 5, max: 50)
NameTypeReqDescription
resultstringyes

No examples provided.

list_llm_models ~133

List all LLM models being used with usage statistics. Discovers what models are deployed and tracks their usage patterns.

NameTypeReqDescription
end_timeEnd time in ISO 8601 format
gen_ai_systemFilter by LLM provider (e.g., openai, anthropic, cohere)
limitintegerMaximum traces to analyze for model discovery (default: 1000)
service_nameFilter by service name
start_timeStart time in ISO 8601 format (e.g., 2024-01-01T00:00:00Z)
NameTypeReqDescription
resultstringyes

No examples provided.

list_llm_tools_tool ~141

List all LLM tools being used by identifying traceloop.span.kind == tool. Discovers which tools/functions LLM applications are calling, grouped by tool name with usage statistics.

NameTypeReqDescription
end_timeEnd time in ISO 8601 format
gen_ai_systemFilter by LLM provider (openai, anthropic, etc.)
limitintegerMaximum spans to analyze (default: 1000)
service_nameFilter by service name
start_timeStart time in ISO 8601 format (e.g., 2024-01-01T00:00:00Z)
NameTypeReqDescription
resultstringyes

No examples provided.

list_services ~28

List all available services in the OpenTelemetry backend. Returns: JSON string with list of services

Input schema present but exposes no named parameters.

NameTypeReqDescription
resultstringyes

No examples provided.

list_sessions ~165

List conversations/sessions grouped by gen_ai.conversation.id. Groups spans that carry the gen_ai.conversation.id attribute (a real, cross-industry OTel semantic convention for session/conversation grouping) to surface per-conversation span counts, token usage, and time bounds - useful for understanding multi-turn conversation activity.

NameTypeReqDescription
end_timeEnd time in ISO 8601 format
gen_ai_systemFilter by LLM provider (openai, anthropic, etc.)
limitintegerMaximum spans to analyze (default: 1000)
service_nameFilter by service name
start_timeStart time in ISO 8601 format (e.g., 2024-01-01T00:00:00Z)
NameTypeReqDescription
countintegeryes
message
sessionsarrayyes

No examples provided.

search_spans_tool ~358

Search for individual OpenTelemetry spans with optional filters. Unlike search_traces, this returns individual spans rather than grouped traces, which is useful for analyzing specific operations or finding spans with certain characteristics (e.g., LLM tool calls with traceloop.span.kind == tool).

NameTypeReqDescription
end_timeEnd time in ISO 8601 format
filtersGeneric filter conditions - list of filter objects with: - field: Field name in dotted notation (e.g., "traceloop.span.kind") - operator: Comparison operator - value: Single value for most operators…
gen_ai_request_modelFilter by requested model name (e.g., "gpt-4")
gen_ai_response_modelFilter by actual model used (e.g., "gpt-4-0613")
gen_ai_systemFilter by LLM provider (e.g., openai, anthropic)
has_errorFilter spans with errors
limitintegerMaximum number of spans to return (1-1000, default: 100)
max_duration_msMaximum span duration in milliseconds
min_duration_msMinimum span duration in milliseconds
operation_nameFilter by operation/span name
service_nameFilter by service name
start_timeStart time in ISO 8601 format (e.g., 2024-01-01T00:00:00Z)
tagsAdditional tag filters as key-value pairs
NameTypeReqDescription
countintegeryes
spansarrayyes

No examples provided.

search_traces ~365

Search for OpenTelemetry traces with filters. Supports both simple parameters and advanced generic filter system.

NameTypeReqDescription
end_timeEnd time in ISO 8601 format
filtersGeneric filter conditions (advanced) - list of filter objects with: - field: Field name in dotted notation (e.g., "gen_ai.usage.prompt_tokens") - operator: Comparison operator (equals, not_equals, gt…
gen_ai_request_modelFilter by requested model name (e.g., gpt-4)
gen_ai_response_modelFilter by actual model used (e.g., gpt-4-0613)
gen_ai_systemFilter by LLM provider (e.g., openai, anthropic)
has_errorFilter traces with errors
limitintegerMaximum number of traces to return (1-1000, default: 100)
max_duration_msMaximum trace duration in milliseconds
min_duration_msMinimum trace duration in milliseconds
operation_nameFilter by operation/span name
service_nameFilter by service name (use filters for advanced queries)
start_timeStart time in ISO 8601 format (e.g., 2024-01-01T00:00:00Z)
tagsAdditional tag filters as key-value pairs
NameTypeReqDescription
countintegeryes
tracesarrayyes

No examples provided.

triage_trace ~273

Synthesize a likely-root-cause diagnosis for a trace, instead of returning raw trace data for the caller to re-derive one from every time. Computes a critical path (the "Last Finishing Child" chain actually responsible for the trace's total latency), ranks spans by self-time (latency contribution net of children, top 10), and - when the trace contains an error anywhere under any root span - identifies the deepest error span in the trace's error chain as the likely root cause. Falls back to the highest self-time span as a pure-latency diagnosis when no error is present. Deterministic (no LLM call); works against any configured backend.

NameTypeReqDescription
detail_levelstring"summary" (default) returns a compact diagnosis only - this differs from get_trace's own "full"-by-default, since a triage result is already a small synthesized diagnosis rather than a raw data dump,…
trace_idstringyesTrace identifier
NameTypeReqDescription
critical_patharrayyes
error_chainyes
top_latency_contributorsarrayyesTop spans by self-time (latency contribution net of children) across the whole trace, capped at 10 entries.
trace_idstringyes
verdictobjectyesThe synthesized root-cause diagnosis triage_trace produces. likely_root_cause is None only when the trace has no spans at all (a backend returned an empty TraceData) - every non-empty trace always f…

No examples provided.

Common questions

What is the io.github.mcpsmiths/tracehub-mcp server?

io.github.mcpsmiths/tracehub-mcp is listed in the public MCP registry as io.github.mcpsmiths/tracehub-mcp. Query OpenTelemetry traces from LLM apps across Jaeger, Tempo, Traceloop, Datadog, Sentry, X-Ray. This page covers its PyPI package (tracehub-mcp).

Is the io.github.mcpsmiths/tracehub-mcp server safe to use?

io.github.mcpsmiths/tracehub-mcp scores 73 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the io.github.mcpsmiths/tracehub-mcp server expose?

io.github.mcpsmiths/tracehub-mcp exposes 19 tools: search_traces, get_trace, triage_trace, correlate_trace, get_llm_usage, and 14 more. Their descriptions and schemas cost roughly 3,578 tokens of context every time the server is loaded.

Is the io.github.mcpsmiths/tracehub-mcp server still maintained?

io.github.mcpsmiths/tracehub-mcp is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the io.github.mcpsmiths/tracehub-mcp server under?

io.github.mcpsmiths/tracehub-mcp declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.