Loading ToolBench
MCP server for deep git file-level forensics, specializing in version tracking, diff analysis, and change investigation
This server defines 4 git forensics tools with reasonable naming and present schemas, but suffers from critical gaps in parameter descriptions, output schema documentation, and error handling. All tool descriptions are adequate (50-80 chars), but parameter descriptions are either missing or minimal. Input schemas are present and properly typed, but output schemas are never documented, LLMs cannot predict what these tools return. Error handling exists but provides no recovery guidance. The tools themselves are well-named (all verb_noun format: track_*, analyze_*), but the server does not meet production baseline for parameter clarity or output predictability.
Analyze broader context of file changes in a specific commit
Analyze specific changes between any two versions of a file
Analyze semantic changes and patterns in file history
Track complete version history of a specific file, including renames and moves
Output schemas are completely undocumented. No tool declares what it returns, what fields are in the response, or what structure the LLM should expect. This violates the fundamental requirement that tools must document return types so agents can plan downstream calls and extract data.
Input parameters have minimal or no descriptions. 'repoPath' is described as 'Path to git repository', but this does not explain format (absolute vs relative), whether it must exist, or how to resolve it. Similarly, 'file' lacks guidance on whether it is a relative path from the repo root, an absolute path, or a glob pattern. 'outputPath' never specifies what format the output takes or whether the file is created or appended.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
analyze_file_diff requires a 'versions' object with 'from' and 'to' fields, but these fields have no type or description. An LLM cannot tell whether they expect commit SHAs, branch names, tags, or version numbers. The schema shows {type:string} but the description is empty, violating the rule that every parameter must have a non-empty description.
Error handling exists (McpError thrown in code) but provides no recovery guidance. When an invalid repoPath is passed, the tool fails, but the error message tells the LLM nothing about what went wrong or what to try next. Per the rubric, errors must guide the agent: 'Repository not found at /path/to/repo. Provide an absolute path to a valid git repository.'
No indication in tool descriptions whether they modify state or are read-only. All four tools are marked Risk: READ_ONLY in the metadata provided, but this is not reflected in the tool descriptions themselves. Per the rubric, tools that modify state must declare so explicitly; here, the inverse is true, read-only tools should state this to signal to agents that calls are safe to retry.