Loading ToolBench
A read-only MCP server that lets Claude answer questions about your own Claude Code sessions
Three well-named, read-only tools with clear descriptions and proper input schemas using Zod. All tools have descriptions (194 - 250 chars, within baseline 34 - 392 range). Parameters are typed and described. Tool annotations (readOnlyHint, openWorldHint) present. Main gaps: output schemas are not formally documented in the tool definitions (only in descriptions), error handling is minimal (session_stats returns a bare error object rather than actionable guidance), and no pagination support despite list_sessions accepting a limit parameter.
List past Claude Code sessions, newest first, with the project, time span, number of turns and prompts, per-model token usage and a tally of which tools were called. Use it to answer questions like which projects were worked on last week or which session was the long one. Returns counts only, never the text of any message.
Full counts for a single session id: duration in seconds, turns, prompts, subagent turns, damaged lines, per-model token usage and the combined totals. Take the id from list_sessions. Returns counts only, never the text of any message.
Count how often each Claude Code tool (Read, Edit, Bash, Grep and the rest) was called across the sessions matching the filters, most used first. Use it to answer questions about working habits, such as how much of a week was reading versus editing. Returns tool names and counts, never tool arguments.
Output schemas not formally documented. Tool descriptions mention what is returned (counts, token usage, tool names) but the actual response structure is not declared in inputSchema or a separate outputSchema field. LLMs cannot reliably plan downstream operations without knowing the exact fields returned.
Error handling lacks recovery guidance. session_stats returns {error: 'no session with that id', session_id, root} but does not suggest what the LLM should do next (e.g., 'Call list_sessions to find valid session IDs'). Bare error objects force the agent to guess.
Pagination not fully implemented. list_sessions accepts a limit parameter but does not return a total count or next_cursor, making it impossible for an agent to know if results are truncated or to fetch the next batch. Large result sets could exhaust context.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Parameter descriptions lack format constraints. 'since' and 'until' accept YYYY-MM-DD strings but do not specify validation rules (e.g., 'ISO 8601 date format, must be valid calendar date'). LLMs may pass malformed dates.
No batch operation support. If an agent needs stats for multiple sessions, it must call session_stats N times sequentially. A batch_session_stats(session_ids: string[]) would reduce token waste and latency.