Loading ToolBench
Smart checkpoint-based version control MCP server for Claude Code with automatic deduplication
The server implements 5 tools with basic schemas and descriptions, but falls short on several critical quality dimensions. All tools ARE explicitly registered with names and inputSchemas visible in src/index.ts. However, descriptions, while present, are often generic or overly verbose without clear parameter guidance. Parameter descriptions are minimal or absent. The 'checkpoint' tool has verbose, redundant description text rather than concise action statements. Most read-only tools lack detail about what they return. Output schemas are not documented, LLMs have no formal specification of response structure. Error handling provides generic text responses but no actionable recovery guidance or error classification. The server uses STDIO transport (hard cap 50), making it non-remotely-accessible. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite several tools being clearly destructive or read-only. Parameter constraints are missing, no enums, ranges, or type enforcement beyond basic JSON Schema. Overall, the server is functional but lacks the polish and clarity expected of production-grade agent tools.
MANDATORY: ALWAYS call this function FIRST before making ANY file modifications, deletions, or creations. This creates a checkpoint to enable undo functionality. This must be called before every single file operation - no exceptions. Never modify files without calling checkpoint first.
Clear all undo checkpoints from the stack
List all undo checkpoints in the stack
Get current status of the undo system (checkpoint count, number of checkpoints in the stack, and whether undo is possible)
Undo the last checkpoint (pops from stack and restores files). Each call removes the latest checkpoint from the stack. To undo multiple changes, call this function repeatedly until the desired state is reached.
STDIO transport: server is not remotely accessible and cannot be tested/used by hosted MCP clients. This is a fundamental architectural limitation.
No output schemas documented. Tools return text content without formal specification of return structure (e.g., list_undos and status return unstructured strings). LLMs cannot reliably parse or chain results.
No tool annotations. Tools like 'cleanup' and 'undo' are clearly destructive/reversible, but no readOnlyHint, destructiveHint, or idempotentHint annotations are present. LLMs cannot automatically classify tool safety.
Checkpoint description is 338 chars and highly repetitive ('MANDATORY: ALWAYS... This must be called... Never modify...'). This is an anti-pattern that wastes tokens and confuses LLM instruction-following. Should be concise and prescriptive, not imperative.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Parameter descriptions are minimal or absent. 'files' parameter in checkpoint has description, but many tools have empty property objects with no descriptions. LLMs cannot understand parameter purpose.
No error classification or recovery guidance. Handler catches errors and returns generic text ('Error: ...'). LLMs do not know if an error is retryable, user-fixable, or fatal.
Destructive tools (cleanup, undo) lack confirmation or dry-run pattern. An agent could inadvertently clear all checkpoints or undo critical changes without safeguard.
No input validation or constraint documentation. 'files' array accepts any strings with no path validation, file existence checks, or sanitization. No enums or min/max constraints on counts or strings.