Loading ToolBench
The server provides 13 git-related tools with basic structure but significant quality gaps. All tools are explicitly defined with @mcp.tool() decorators in main.py. Naming follows verb_noun convention (git_status, git_add, etc.), which is positive. However, descriptions are minimal (10-50 chars), parameter descriptions lack depth, and output schemas are not documented. Error handling returns plain strings rather than structured error objects. No tool annotations (readOnlyHint/destructiveHint) despite clear risk distinctions. The server relies on GitPython and subprocess without comprehensive validation. Schemas show only basic type info (string, integer, array) without format constraints, ranges, or examples. Output documentation is absent, tools return str or List[str] but expected field structures are not described.
Stage the given files.
Switch to <branch_name>.
Record changes with a commit (redirect to git_commit_direct).
Record changes with a commit.
Create a new branch (optionally from <base_branch>).
Show differences between HEAD and <target>.
Show changes that are staged for commit.
Missing output schema documentation. Tools return str or List[str], but expected output structure (fields, types, format) is undocumented. LLMs cannot plan downstream tool chaining or extract structured data.
Parameter descriptions are generic or absent. Example: 'repo_path' described only as 'Path to the git repository', no guidance on relative vs absolute paths, tilde expansion, validation behavior. LLMs cannot infer error cases or edge conditions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Show changes in the working directory that are not yet staged.
Initialize a new Git repository at <repo_path>.
Show the last <max_count> commits.
Unstage all staged changes.
Show the contents (metadata and diff) of <revision>.
Show the working tree status.
Tool descriptions lack state-change declarations. git_add, git_reset, git_commit_direct, git_checkout, git_create_branch, and git_init are all WRITE or IRREVERSIBLE operations, but descriptions do not warn that these modify the repository. LLMs may invoke them without planning for side effects.
No tool annotations. Risk declarations are provided in the rubric (READ_ONLY, WRITE, REVERSIBLE, IRREVERSIBLE) but not exposed via MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint). Clients cannot determine which tools are safe to invoke speculatively.
Error handling returns plain strings (e.g., 'Error: ...') rather than structured error objects with classification. No actionable recovery guidance. LLMs cannot distinguish retryable errors from user-fixable or fatal ones.
Duplicate tools: git_commit and git_commit_direct are identical in function (second calls first). Confusing naming violates single-responsibility. LLMs waste reasoning cycles deciding which to call.
git_diff parameter 'target' description is vague ('Target revision/branch to diff against'). Does not clarify format (branch name, commit hash, tag, range?). LLMs may pass invalid revisions.
git_commit_direct and git_commit require message to start with '[agent]'. This is a hard constraint but the description does not emphasize it as non-negotiable. Error message will likely be clear, but the parameter description should warn upfront.
git_log returns List[str], not a structured list of commit objects. LLMs cannot extract specific fields (hash, author, date, message) for downstream processing. Parsing unstructured strings is error-prone.
No pagination or result limits. git_log defaults to 10 commits and accepts max_count, but other tools (git_diff, git_show, git_status) have no limits. Large diffs or repositories could produce massive responses, exhausting context windows.