Loading ToolBench
An MCP server providing stateful Gemini access with autonomous codebase exploration
Single tool 'git' has a well-structured schema with proper enum constraints and reasonable parameter descriptions. However, the tool description is terse (67 chars), and several parameters lack detailed guidance on format/constraints. Output schema is not documented. Error handling returns plain strings rather than structured objects with recovery guidance. The tool is read-only and validates inputs defensively, which is good, but LLM-facing descriptions could be more explicit about when to use each subcommand.
Read-only git operations for codebase exploration. Subcommands: status, diff, log, show.
Tool description is too brief (67 chars). Should explain WHEN to use each subcommand (status for repo state, diff for changes, log for history, show for commit details) and what the LLM should expect from each.
Output schema not documented. LLMs cannot plan downstream operations or parse results without knowing the structure. Document what each subcommand returns (e.g., status returns porcelain v2 format, log returns lines of 'hash date author subject').
Parameter 'ref' description lacks format guidance. Should state: 'Git ref (branch, tag, commit SHA, or HEAD). Must be 1-256 chars, alphanumeric + ._/~^@{}- only. No leading dash or shell metacharacters.'
Error responses are unstructured strings (e.g., 'Error: ref too long...'). Should return JSON with error code, message, and recovery hint (e.g., 'Try a shorter ref or use git log to find the commit SHA').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
Parameter 'max_count' description does not explain the capping behavior. Should state: 'Max commits to return (1-100, default 20). Values above 100 are silently capped.'