Loading ToolBench
Find and resume AI coding sessions (Claude Code, Codex, Pi). Provides full-text search and MCP tools for agent access to session history.
This server exposes 8 read-only tools for searching and retrieving AI coding sessions. While tool names are clear and follow verb_noun conventions (search_sessions, get_session, list_sessions), the implementation has significant gaps in schema documentation, parameter descriptions, and output schema clarity. All tools are READ_ONLY and low-risk, but the lack of visible, explicit input/output schema definitions in the provided source code, combined with minimal parameter documentation, places this in the 'fair' range. The regex-based tool extraction (site/src/lib/mcp-tools.ts) indicates tool names and titles come from src/mcp.ts, but the actual schema definitions are not visible in the provided snippet, making it impossible to verify JSON Schema completeness. Based on the tools shown in the specification (with at least some parameters visible: e.g., search_sessions has 'query', get_session has 'sessionId' and 'tool'), we can infer schemas exist but cannot fully validate them from the code sample.
Get details of a specific session by ID
Get conversation context from a session
Get a summary of a session's contents
List all available sessions
List all supported AI coding tools
Search sessions from a specific tool
Search past AI coding sessions
Search sessions within a specific project directory
Input schemas not fully visible in provided source code. Tool definitions appear to be in src/mcp.ts but the actual registerTool() calls with full JSON Schema details are not shown. Cannot verify parameter types, enums, required fields, or constraints.
Parameter descriptions are minimal (10-30 chars). e.g., 'query' described as 'Search query to find relevant sessions' lacks context about format, examples, or what fields are searched. Descriptions should be 50-150 chars, explaining WHAT is searched, WHEN to use it, and any prerequisites.
Output schemas not documented in visible code. Tools return session data (list_sessions, search_sessions) but there is no visible schema describing the structure of returned session objects, fields like 'id', 'tool', 'timestamp', 'messages', etc. LLMs need to know what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Parameters lack enum constraints where appropriate. 'tool' parameter in get_session and search_by_tool accepts one of {claude, codex, pi, opencode} but there is no visible enum definition. Should use JSON Schema enum to prevent hallucinated tool names.
Pagination support not clearly documented. list_sessions accepts 'limit' and 'offset' but there is no visible documentation of the pagination contract (max limit, whether offset is zero-indexed, what happens if offset > total). Should include total_count and next_offset in response.
Tool descriptions are generic and do not explain differentiation. 'Get details of a specific session by ID' (get_session) vs 'Get conversation context from a session' (get_session_context), unclear what each returns. Why would an LLM choose one over the other? Descriptions should state: this returns metadata/summary vs this returns full conversation history.
Numeric parameters (limit, offset, maxMessages) lack constraints. No visible min/max bounds. What is the maximum limit? Can offset be negative? What happens if maxMessages > session message count? JSON Schema should declare minimum and maximum; descriptions should explain sensible defaults and bounds.
Error handling and recovery guidance not visible. If a session is not found, what does the tool return? A 404? A structured error message? Tools should return actionable error responses (e.g., 'Session not found. Try search_sessions() to browse available sessions.') to guide LLM recovery.