Loading ToolBench
Git line-level staging via MCP - Stage individual changes and partial untracked files with precision
git-polite provides 4 well-named Git tools with functional schemas, but lacks depth in descriptions and error guidance. All tools follow verb_noun naming (list_changes, apply_changes, unstack, get_diff), which is excellent for LLM parsing. However, descriptions are terse (most under 100 chars) and lack situational context about when to use each tool vs. others. Parameter descriptions are present but minimal, many lack format constraints or usage guidance. Output schemas are not explicitly documented in the source. Error handling is not visible in the provided code snippet. No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinctions. Pagination support exists for list_changes but lacks documentation of result limits and next_cursor semantics. The server uses fastmcp (good framework choice) but provides minimal evidence of production-grade error recovery or validation logic.
Stage specific line ranges from a file to the git index.
Get detailed diff for specific changes with configurable context width.
List all changes in the working directory with optional filtering by paths and pagination support.
Unstack a linear series of commits into parallel independent branches.
Descriptions lack situational context and usage guidance. 'Stage specific line ranges from a file to the git index' tells WHAT but not WHEN (vs. apply_all_changes or get_diff first) or WHY. Per pattern:tool-description baseline of 194 chars avg, these are 50-90 chars with minimal context.
No documented output schemas. Source shows input parameters but does not specify return types, field names, or structure. LLMs cannot plan downstream tool chains or extract results reliably without knowing 'Does list_changes return an array of objects? Does each object have path, status, hunks?'
Missing tool annotations despite clear intent. apply_changes and unstack are WRITE operations (destructive); list_changes and get_diff are READ-ONLY. No destructiveHint or readOnlyHint annotations visible. This prevents clients from warning users or applying rate limits appropriately.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Parameter descriptions lack format constraints and validation guidance. 'hunk_selections' expects 'comma-separated hunk and line range selections (e.g. 0001,0004,0010-0015)' but the description does not clarify: are line numbers 0-indexed or 1-indexed? Does '0001' mean hunk 1 or line 1? What is the max range? What happens if you pass an invalid hunk?
No error handling or recovery guidance documented. What happens if apply_changes hits a merge conflict? If unstack fails because commits are non-linear? If a file path in list_changes does not exist? LLMs need 'error: conflict detected; call resolve_conflict() first' not raw exceptions.
Pagination semantics for list_changes undocumented. Schema includes page_token and page_size_files, but source does not clarify: what is the default page_size? What is the max (description says max 1000, but is that enforced or advisory)? Does page_token come from a previous response's next_page_token field? Undocumented pagination breaks LLM chaining.
Parameter 'unified' context width defaults are mentioned (20 for list_changes, 3 for get_diff) but rationale is missing. Why different defaults? When would an LLM pick one over the other? Why is list_changes max 1000 but get_diff has no stated limit?
Tool composition guidance is missing. An LLM discovering these tools may not know the intended workflow. Should it call list_changes first, then apply_changes, then get_diff? Or are they independent? The descriptions do not hint at tool chains.