Loading ToolBench
Session explorer for Claude Code - find, search, and resume all your past sessions
The server defines 8 well-named, read-only tools with complete input schemas and reasonable descriptions. All tool names follow verb_noun patterns (search_*, get_*) and are clear in intent. Descriptions are present and mostly adequate (ranging 58 - 190 chars), though several lack actionable context about when to use them. All input schemas are properly typed with required fields and parameter descriptions. However, output schemas are entirely undocumented, the code returns JSON text without specifying structure, making it hard for LLMs to parse results. Error handling is minimal: only get_session and get_project_context validate required params, while others silently accept invalid input. No pagination despite tools returning multiple results (search_sessions, search_decisions, search_knowledge default to 10-20 results but no cursor/next support). No recovery guidance in error messages.
Get the history of changes to a specific file across sessions
Get all pending/incomplete todos across sessions, optionally filtered by project
Get rich context for a project including recent sessions, decisions, todos, and accumulated knowledge
Get a summary of recent coding activity across all projects
Get detailed information about a specific session by ID
Search through past decisions made in sessions. Useful for "why did we choose X?" questions.
Search through accumulated knowledge from past sessions. Useful for finding solutions to similar problems.
Output schemas are completely undocumented. Tools return JSON text via content[0].text but provide no schema documentation of the structure, field types, or what fields agents should expect. This forces LLMs to guess at response structure and prevents proper downstream tool chaining.
No pagination support despite multiple tools returning lists with configurable limits (search_sessions, search_decisions, search_knowledge default 10-20 results). No cursor, offset, next_token, or total_count fields documented. Large result sets will blow context windows without pagination mechanism.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Search across all Claude Code sessions by query text. Searches summaries, file names, project names, and enriched data.
Inconsistent error handling. get_session and get_project_context validate required params and return isError=true responses. But search_sessions, get_pending_todos, search_decisions, search_knowledge, get_file_history, get_recent_activity do not validate, they silently accept missing required query params or return unhelpful results. Error messages lack recovery guidance (e.g., 'Session not found: X' does not suggest next steps).
Parameter descriptions could be more detailed about expected format and constraints. For example, 'query' params (in search_sessions, search_decisions, search_knowledge) lack detail about case sensitivity, boolean operators, or field coverage. 'days' in get_recent_activity has no range guidance (1-365? 1-30?).
Tool descriptions lack context about when to use each tool and how they differ. For example, 'search_sessions' vs 'search_knowledge' vs 'search_decisions' overlap conceptually (all search across sessions). The descriptions should clarify: search_sessions finds by project/filename/summary, search_decisions finds architectural choices, search_knowledge finds solutions/patterns. Without this, LLMs may pick wrong tools.
Optional parameters lack clear defaults. 'limit' is documented as '(default: X)' in descriptions but not in the schema itself (no default keyword in JSON Schema). 'project' is optional but no guidance on what happens if omitted (searches all projects? returns error?). This ambiguity makes LLM behavior unpredictable.