Loading ToolBench
This Git MCP server has 12 tools with consistent basic structure: all are named with the git_ prefix and verb-noun pattern (git_status, git_commit, etc.). All tools have descriptions and input schemas visible in the source code. However, quality is hindered by several critical gaps: (1) Descriptions are uniformly terse (10-50 chars), well below the 50-200 char optimal range for LLM-driven tool selection. For example, 'Shows the working tree status' lacks context on WHEN to use git_status vs alternatives, or WHAT the output contains. (2) Parameter descriptions are minimal and generic, most just repeat the parameter name or say 'Path to Git repository' without explaining format, constraints, or dependencies. (3) Output schemas are completely undocumented, there are no descriptions of what fields the handlers return, forcing LLMs to guess structure. (4) Error handling is present in code (handlers check for repo open failures) but error messages are generic strings, not structured recovery guidance. (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification (git_commit is irreversible, git_add is write, git_status is read-only). (6) No idempotency guidance for retryable operations. Tool names are clear and follow verb_noun convention well, but descriptions fail the LLM-optimization bar significantly.
Adds file contents to the staging area
Lists Git branches
Switches branches
Records changes to the repository
Creates a new branch
Shows differences between branches or commits
Shows changes that are staged for commit
Descriptions are uniformly terse (10-50 chars), far below the 50-200 char LLM-optimal range. Example: git_status = 'Shows the working tree status' lacks WHEN/WHY context, expected output fields, and relation to similar tools (git_diff_unstaged). LLMs cannot reliably select between similar tools with such minimal docstrings.
Output schemas are completely undocumented. Handlers return unstructured strings (from go-git library) with no schema declaration visible. LLMs cannot plan downstream tool calls or extract structured fields without knowing return types. Example: git_log returns commit history but the response format is not specified.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Shows changes in working directory not yet staged
Shows the commit logs
Unstages all staged changes
Shows the contents of a commit
Shows the working tree status
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification visible in tool names and behavior. git_commit is IRREVERSIBLE and should declare destructiveHint=true; git_add and git_checkout are WRITE and should be marked; git_status, git_diff, etc. are READ_ONLY and should be marked. Agents cannot reliably reason about retry safety or user confirmation needs without these hints.
Parameter descriptions are minimal and generic. Most params are described only as 'Path to Git repository' without format constraints, examples, or dependencies. Example: git_diff's 'target' param is described as 'Target branch or commit to compare with' but doesn't explain whether it accepts branch names, commit hashes, tags, or remote refs. git_log's 'max_count' lacks min/max bounds (e.g. 1-1000) and default behavior.
Error messages in handlers are generic strings without recovery guidance. Example: handleGitStatus returns 'failed to open repository: %v', an LLM sees this error and has no instruction on what to do next (check path exists? try a different repo? call git_init?). Error handling should categorize failures (retryable vs user-fixable) and suggest recovery steps.
No idempotency guidance for tools that might be retried. git_add, git_commit, git_create_branch, and git_checkout can be retried, but the server does not document whether repeated calls with the same input produce the same result (idempotent) or have side effects (non-idempotent). This forces agents to reason about retry safety themselves.
No pagination support for git_log. If a repository has thousands of commits, git_log will return all of them (or be capped silently in the handler). The visible schema does not declare whether results are paginated or capped. Large unbounded results waste tokens and risk context window exhaustion.
Inconsistent parameter naming conventions. Most params are repo_path (snake_case), but git_add uses 'files' (plural array). git_diff uses 'target' (generic noun) instead of 'compare_branch' or 'compare_ref'. These inconsistencies force LLMs to re-read each tool's schema, increasing reasoning overhead.