[v2] Per-tool call and log history in the web UI
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- typescript
调研方向
Start by reading the v2 UX spec and issue #2607 to understand the existing counts work and the web UI’s Tools, Server Console, and Protocol panels. Decide where per-tool history should live before implementation; then trace how tool calls, results, notifications/message logs, progress notifications, and request IDs reach those panels. Done means recent calls show arguments, results, and duration alongside associated logs and progress, with best-effort stderr correlation clearly identified.
由索引模型根据 Issue 内容生成。
描述
Split out of #2607, whose PR covers only the tool/prompt/resource counts (the part the v2 UX spec already describes). This tracks the second half of that report.
The problem
After running a tool several times there is no way to see that tool's history in the web UI:
- Console tab (Server Console): a tool call shows only
Processing request of type CallToolRequest. The tool name is not shown and the line is not linked to the matchingtools/callentry in the Protocol panel. - Tools screen: only the latest result is shown — no record of previous calls, their arguments, results or logs.
- Protocol panel: searching by tool name finds entries, but nothing groups a tool's calls together with the server logs and notifications they produced.
What's wanted
For each tool, its recent calls — arguments, result, duration — together with the notifications/message log lines and progress notifications each call produced.
Notes
- There is no spec wireframe for this yet, so it needs a design pass (where it lives: a Tools-screen history panel vs. a Protocol-panel grouping) before implementation.
- Correlating server log lines to a call is only exact where the server tags them (e.g. a
related-request-id); stderr lines on stdio carry no request id, so a time-window heuristic would be a best-effort association, and the UI should say so.
- 主要语言
- TypeScript
- 星标
- 11.1k
- 派生
- 1.5k
- 平均合并
- 4 小时 14 分钟
- 30 天内合并 PR
- 162
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
modelcontextprotocol/inspector 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
modelcontextprotocol/inspector#2723 ·
维护者通常 1 天内回复
-
Modern subscriptions: a subscriptions/listen refused with HTTP 403 is retried eight times in silence未关闭bug v2
难度 4/5 3-5 天 新手友好度 30/100
modelcontextprotocol/inspector#2722 · 1 条评论 ·
维护者通常 1 天内回复
-
bug v2
难度 3/5 1-2 天 新手友好度 50/100
modelcontextprotocol/inspector#2721 · 2 条评论 ·
维护者通常 1 天内回复
-
bug v2
难度 3/5 半天 新手友好度 62/100
modelcontextprotocol/inspector#2719 ·
维护者通常 1 天内回复
-
chore v2
难度 4/5 3-5 天 新手友好度 48/100
modelcontextprotocol/inspector#2715 ·
维护者通常 1 天内回复
查看 modelcontextprotocol/inspector 的全部 Issue
相似的 Issue
-
enhancement good first issue help wanted
难度 2/5 1-3 小时 新手友好度 78/100
OWASP/cve-lite-cli#1335 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 66/100
code-yeongyu/senpi#3353 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
Channels status: needs triage
难度 2/5 1-3 小时 新手友好度 70/100
mastra-ai/mastra#27093 · 1 条评论 ·
维护者通常 1 天内回复
-
enhancement needs-triage ui
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复