SpanHound

io.github.abhishekash由 GitHub 账号 abhishekash 发布v0.6.1更新于 Oct 29, 2026

Capture local agent traces and inspect failures, approvals, and run comparisons.

概览

AI 生成的概览

SpanHound 采集本地 AI 智能体追踪,并通过只读 MCP 工具查看失败、审批、token 用量与运行对比。

可以做什么
  • 列出并汇总已采集的运行,包括任务、模型、时长、成本与决策次数,并查看某次运行的嵌套 span 树。
  • 排查性能与失败:最慢 span、经过截断与脱敏的错误报告、按错误率/拒绝/延迟排序的工具统计,以及按工具名或路径搜索 span。
  • 审计人工审批与安全证据:含审批人及理由的审批日志,以及调用方、租户与来源相关发现。
  • 追踪成本与回归:跨运行或单次运行的 token 用量,以及针对不同模型或版本的选定追踪对比。
  • 在运行仍在写入时,用游标轮询新产生的 span。
适用场景
适合想通过 MCP 客户端了解本地智能体运行究竟做了什么、又不想搭建追踪后端的场景。可用于排查卡顿与失败、确认智能体在被拒绝后是否仍执行操作,以及对比运行以发现回归。
运行要求
通过 uvx 以 stdio 在本地运行,首次运行会安装 Python 依赖。需要一个存放 JSONL span 或已保存 OTLP JSON 导出的目录,或在与智能体相同的 Python 环境中安装可选自动埋点包。OTLP 接收器监听本机回环地址。未声明需要账号或 API 密钥。
安装前请注意
追踪文件在本地读取,但工具返回的证据会发送给所连接的 MCP 客户端。诊断信息会被截断且明显凭据会被脱敏,但追踪中仍可能包含敏感提示词、路径或工具输出。工具为只读;接收器在本机回环地址接受 OTLP,能访问该端口的程序都可写入追踪文件。

安装

在 SourceWeft 中

  1. 打开 控制台中的 SpanHound,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

[SpanHound logo]

SpanHound

[CI] [PyPI] [Downloads] [GitHub release] [GitHub stars] [MCP Registry] [Glama MCP server] [License: MIT] [Python 3.11+]

Capture local agent traces. Ask your MCP client what happened. SpanHound (formerly mcp-trace-inspector) captures supported Python agent calls, receives OpenTelemetry over local OTLP/HTTP, and exposes read-only MCP tools for failures, approval decisions, token usage, and run comparisons. It reads JSONL spans and OTLP JSON exports as described in the user guide, including traces from agent-harness.

[Animated demo: a blocked tool call becomes an inspectable trace]

Demo: Watch the full 48-second video · Read the reproducible story. This is a scripted regression trace, not a live-model benchmark.

The project's concrete origin was a shell-boundary regression: the harness blocked cat ../outside.txt, but the old trace recorded only that run_shell was called, not the returned diagnostic. SpanHound and the harness now preserve and query that bounded error.

Try it in one command

bash
uvx spanhound demo
text
SpanHound demo — recorded agent failureTool: run_shellFailure: error: shell path escapes workspace root: '../outside.txt'Approval: approve (auto)Trace: 563e779ee8fa2d7069fc63ed2cf9c8ec (6 spans)

The demo shows a recorded run_shell failure and its approval evidence from a bundled scripted regression trace. It needs no clone, account, trace backend, or MCP client. To inspect your own traces, point SpanHound at a directory of JSONL spans or saved OTLP JSON exports:

bash
uvx spanhound --trace-dir /path/to/traces --check

--check prints the runs it found and exits. Connect an MCP client with the configuration below to ask questions about those runs.

Explore the repository fixtures

bash
git clone https://github.com/abhishekash/spanhound.gitcd spanhounduvx --from . spanhound --trace-dir examples --check

--check also reports a missing directory or malformed complete JSONL or OTLP JSON record.

To try an OTLP JSON export, run the same command with --trace-dir tests/fixtures. The sample export includes a model call, token usage, a tool call, and an exception.

Capture your own traces

For a Python agent, install SpanHound's optional auto instrumentation in the same environment as the agent, then run it through SpanHound:

bash
python -m pip install 'spanhound[auto]'spanhound run --trace-dir ./traces -- python agent.py

The command starts and stops a local receiver, configures OTLP export, and captures supported library calls without changes to agent.py. The optional package includes instrumentation for OpenAI, Anthropic, OpenAI Agents, HTTPX, and Requests. It reports when no spans were produced. Your Python agent and SpanHound must share one environment; for a uv project, use uv add 'spanhound[auto]' and uv run spanhound run -- python agent.py. See the Python capture guide.

For other runtimes, or agents that already export OpenTelemetry traces, start the receiver in one terminal:

bash
uvx spanhound collect --trace-dir ./traces

Point an agent that already uses an OpenTelemetry trace exporter at the receiver, then run the agent:

bash
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://127.0.0.1:4318/v1/tracesexport OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf# Start your instrumented agent here.

SpanHound stores each accepted OTLP/HTTP trace request as a local JSON file. Run uvx spanhound --trace-dir ./traces --check to see the captured runs, then connect your MCP client to that folder. The receiver accepts OTLP/HTTP JSON or protobuf on loopback; it does not add instrumentation to an agent. See the capture guide for limits and privacy.

Where it fits

For a live terminal and browser view of local Codex/Claude Code sessions and received OTLP telemetry, try Agent Observatory. SpanHound provides trace investigation through MCP using JSONL and OTLP JSON files.

Use this when you want a local trace view through MCP without setting up a trace backend. Capture supported Python library calls in one command, receive OTLP/HTTP from another runtime, or read the supported JSONL or OTLP JSON formats. Focused queries include recorded approval decisions, bounded failure diagnostics, and run comparisons.

MCP Agent Trace Inspector records steps into a local SQLite database and provides a dashboard and exports. SpanHound auto-instruments supported Python libraries or receives OTLP/HTTP traces, then queries the captured files through MCP. It does not automatically trace arbitrary agent functions or approvals.

For traces stored in Jaeger, Tempo, or Traceloop, use a backend-connected tool such as OpenTelemetry MCP Server. For a trace UI, instrumentation, and evaluations, see Phoenix. SpanHound does not read backend-specific JSON exports.

AI-native use cases

Question during an agent runMCP toolEvidence returned
"Why did yesterday's run stall?"list_runs → slowest_spansRun IDs and the longest model or tool spans.
"Did the agent act after I denied the write?"approval_log → span_treeThe recorded decision and subsequent execution path.
"How many model tokens did this run use?"token_usage → span_treeRun-level usage totals and the span tree for context.
"Which tool is failing or timing out?"failure_report / tool_statsRedacted diagnostics, error rates, denials, and p95 latency.
"Who/what was allowed to act?"security_auditCaller, tenant, server provenance, risk, and missing-evidence findings.
"What is happening in the run right now?"recent_activityCursor-based polling of newly written spans.
"Did this model/version regress?"compare_runsCost, latency, tokens, tool calls, and failure deltas.

The tools read stored traces and can poll files being written, but they do not push events or infer intent from the final answer. Start with the installation and user guide, then see the real trace fixture and the tool descriptions for the query contract.

Install & run

bash
uvx spanhound --trace-dir ./traces# or, for local development:git clone https://github.com/abhishekash/spanhoundcd spanhounduvx --from . spanhound --trace-dir ./traces

For a desktop client that accepts MCP Bundles, download the .mcpb asset from the latest release and install the downloaded file in the client; the download link does not open a web page. In Claude Desktop, use Settings → Extensions → Advanced settings → Install Extension… and select the .mcpb file. The bundle asks you to choose a local trace folder. It uses UV to install its Python dependencies on first run. SpanHound reads the folder locally; the connected client receives the evidence returned by its MCP tools.

If you previously ran uvx mcp-trace-inspector, change that command to uvx spanhound to receive this release. The old PyPI distribution stays at 0.3.1; the new package retains its Python import paths and command aliases for clients that install spanhound explicitly.

Client configuration

Claude Desktop (claude_desktop_config.json):

json
{  "mcpServers": {    "agent-traces": {      "command": "uvx",      "args": ["spanhound", "--trace-dir", "/path/to/traces"]    }  }}

pi (~/.pi/agent/settings.json):

json
{  "mcpServers": {    "agent-traces": {      "command": "uvx",      "args": ["spanhound", "--trace-dir", "/path/to/traces"]    }  }}

agent-harness (mounted as gated tools):

bash
harness run "Why was my last run slow?" --mcp "uvx spanhound --trace-dir ./traces"

Tools

ToolUse it when
list_runsStarting out — recent runs with task, model, duration, cost, decision counts
run_summaryOne run at a glance (accepts trace-id prefix)
span_tree"What did the agent actually do?" — nested shape of the run
slowest_spans"Why was it slow?" — top-k spans by duration
approval_logHITL audit — every approve/deny/edit, who decided, and the rationale
token_usageCost questions — aggregated across runs or per-run
search_spansFind spans by tool name, file path, "denied", …
failure_reportFind actionable, bounded, redacted errors and failed tool calls.
tool_statsRank tools by volume, error rate, denials, and latency.
security_auditAudit caller identity, tenant, server provenance, risk, and approval evidence.
recent_activityPoll new spans with a cursor while a run is active.
compare_runsCompare selected traces for regressions across models or versions.

Tool descriptions are written as prompts (when-to-use, not just what-it-does) — descriptions are the interface for agent-called tools.

Example session (real fixture trace)

> list_runs[{ "trace_id": "f920798dd2558fcb84f9977736432a8b", "task": "Summarize the workspace's notes…",   "tool_calls": 4, "human_decisions": 2, "stopped_reason": "completed" }]
> approval_log[{ "tool": "write_file", "decision": "approve", "approver": "auto", … }, { "tool": "run_shell",  "decision": "approve", "approver": "auto", … }]

Design

traces/*.jsonl ──┐traces/*.json  ──┴─▶ mcp_trace.core (local query functions)                          │                   mcp_trace.server (MCP adapter)                          │                    stdio (JSON-RPC)
  • core/server split: all logic is pure functions over parsed spans; the MCP layer only parses args and JSON-encodes results. Tests hit both layers.
  • trace_id prefixes: agents fumble full 32-char hex ids; every tool accepts prefixes.
  • bounded output: diagnostics are truncated and obvious credentials are redacted before query results leave the server.
  • honest cost totals: token_usage returns cost_known: false and a null cost when any model span lacks a cost or marks pricing as unavailable; unknown pricing is never presented as $0.
  • cursor polling: recent_activity makes the snapshot reader useful while a run is still writing spans.
  • The demo fixture (examples/example_trace.jsonl) is a real agent-harness run, not hand-written.

Honest limitations

  • MCP stdio transport only (Streamable HTTP plus authenticated remote access is the next transport boundary)
  • live polling re-reads snapshots; it is not a push subscription
  • security audit can only report identity/provenance that the trace producer records
  • read-only tools; trace mutation (annotations) is roadmap
  • The Python query and server modules are available as mcp_trace; older import and command aliases remain for existing clients.

First-run feedback

Tell us what happened when you tried it: your MCP client or trace producer, the question you were trying to answer, and any missing evidence. Share a redacted excerpt when a file fails to load.

License

MIT

来源:README.md,提交 5991bda

工具

0
SourceWeft 尚未在沙箱中启动过该软件包,因此其工具未知。

版本历史

3
  1. v0.6.1最新Oct 15, 2026
  2. v0.6.0Oct 13, 2026
  3. v0.4.1Oct 13, 2026

评分

已满足适用检查项的 50%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分

    请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。

  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分