Loading ToolBench
A secure and scalable Git MCP server enabling AI agents to perform comprehensive Git version control operations via STDIO and Streamable HTTP.
Git MCP Server demonstrates solid definition quality with consistent naming, comprehensive parameter descriptions, and explicit input/output schemas. All 9 tools follow verb_noun naming convention and include detailed descriptions (average ~180 chars). Parameter schemas are well-structured with type definitions, enums, and constraints. However, several tools lack output schema documentation in the visible code, and error handling/recovery guidance is not evident. Tool compositions are appropriate for git operations, though some complex operations (cherry-pick, rebase) could benefit from explicit dry-run/confirmation patterns. The server uses tool annotations (destructiveHint for git_clean, git_reset, etc.) which is current MCP practice.
Stage files for commit. Add file contents to the staging area (index) to prepare for the next commit.
Show line-by-line authorship information for a file, displaying who last modified each line and when. For large files, use startLine/endLine to limit output.
Manage branches: list all branches, show current branch, create a new branch, delete a branch, or rename a branch.
Gather git history context (commits, tags) and structured review instructions to support LLM-driven changelog analysis. Changelog file should be read separately; this tool provides the supporting git data and analysis framework. Pass one or more review types to control what kind of analysis to perform.
Switch branches or restore working tree files. Can checkout an existing branch, create a new branch, or restore specific files.
Output schemas not visible in source code for most tools. While tool definitions show detailed input schemas (OutputSchema objects exist for git_add), the complete output documentation for all 9 tools is not fully visible in the provided code sample, making it difficult to verify consistency of return types across the toolkit.
Error handling and recovery guidance not documented. Tools like git_cherry_pick, git_rebase (mentioned in keywords but not in provided list), and git_merge lack explicit error messages or recovery suggestions. An LLM encountering a merge conflict or cherry-pick failure has no guidance on next steps.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Cherry-pick commits from other branches. Apply specific commits to the current branch without merging entire branches.
Remove untracked files from the working directory. Requires force flag for safety. Use dry-run to preview files that would be removed.
Clear the session working directory setting. This resets the context without restarting the server. Subsequent git operations will require an explicit path parameter unless git_set_working_dir is called again.
Clone a repository from a remote URL or local path. Accepts HTTP(S), SSH, git://, file://, and bare filesystem paths, with optional shallow cloning.
Confirmation/dry-run pattern missing for destructive operations. git_clean and git_reset (inferred) are marked destructive but do not explicitly expose a --dry-run or confirmation step in the parameter schema. Agents should preview changes before destructive git clean -fd.
Inconsistent parameter naming for path resolution. git_add accepts 'path' for repository root but also 'paths' array. git_clear_working_dir has no 'path' parameter. Documentation states path 'can be inferred from prior git_set_working_dir call', but this stateful behavior is not idiomatic for stateless MCP. Each request should be self-contained.
Parameter constraint documentation relies on free-form text. git_branch limit parameter says 'cap the number of branches returned' but specifies no explicit maximum. git_changelog_analyze maxCommits is bounded (1-1000) correctly. Inconsistent constraint documentation across tools.