Loading ToolBench
MCP server for deep git repository analysis and investigation, providing insights into branch relationships, merge strategies, and development patterns
The server defines 4 tools with explicit schemas and descriptions visible in src/index.ts. All tools have verb_noun naming (get_*, analyze_*) which is good. However, descriptions are functional but brief (9-20 chars; baseline ideal is 10-1024 chars, median 194 chars). Input schemas are present with type declarations and basic descriptions. Critical gaps: (1) No input validation beyond null checks, LLMs can pass invalid values that will fail at runtime; (2) No output schema documentation, callers don't know what fields to expect from the analysis; (3) timeRange.start and timeRange.end lack format hints (ISO 8601? Unix timestamp? Natural language?); (4) No error recovery guidance, failures return generic error text without hints on what to do next; (5) Parameter descriptions lack format/constraint details (e.g., what constitutes a valid repoPath? Absolute or relative? Must exist? What about Windows vs Unix paths?); (6) Tools write to outputPath but no schema documents what gets written or how agents should interpret it.
Analyze changes to specific files across branches
Analyze detailed development activity in a specific time period
Get high-level overview of branch states and relationships
Get detailed merge strategy recommendations
Missing output schema documentation. All 4 tools write analysis to outputPath but return type is never documented. LLMs don't know what fields to expect or how to chain calls. The response appears to be {content: [{type: 'text', text: ...}]} but downstream processing is opaque.
Parameter descriptions lack actionable constraints. 'repoPath: Path to git repository' doesn't specify: absolute vs relative path? Must the repo exist? How should Windows paths be formatted? What happens if path is invalid? Current description is 23 chars; should be 50-100 chars with format, constraints, and failure modes.
timeRange.start and timeRange.end lack format specification. Are they ISO 8601 strings (2024-01-15)? Unix timestamps? Natural language ('last week')? This ambiguity will cause parsing errors. Should be enum or regex pattern with description like 'ISO 8601 date string, e.g. 2024-01-15 or 2024-01-15T14:30:00Z'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 20 | - | v1 |
Error handling is generic and non-actionable. All errors return 'Git analysis error: {message}' with isError=true. LLMs get no recovery guidance. Pattern guidance: 'User not found. Try search_users() with a partial name.' This server never suggests next steps. See pattern:recovery-guide.
No input validation beyond null checks. Code checks 'if (!args?.repoPath)' but doesn't validate: branch names exist in repo, files exist in repo, outputPath is writable, date range is valid (start before end). Invalid inputs silently fail at exec() time with unhelpful error messages.
Tool descriptions are under 50 chars; baseline good description is 10-1024 chars (median 194). Examples: 'Get high-level overview of branch states and relationships' (58 chars) is minimal. Should expand: what relationships? How detailed? What is a 'state'? When should I call this vs analyze_file_changes? When is the output ready?
Command injection risk: repoPath, branch names, and file names are interpolated into execSync() calls without sanitization. An agent could pass repoPath='.' && rm -rf / or branches containing shell metacharacters. Must use child_process with argv array, not string interpolation.
No pagination or limits on results. A large repo with 1000s of branches or commits will return massive output blowing context window. Pattern guidance: cap results at 20-50, add limit and offset params, document the cap in description. No such limit visible here.