Loading ToolBench
MCP server for analyzing Git repository hotspots, code complexity, risk assessment, and refactoring priorities using git history analysis
Server has 11 well-named tools with consistent verb_noun patterns (get_*, compare_*, run_*). All tools have descriptions (50-200 chars, meeting baseline). Input schemas are present and typed for all tools. However, output schemas are NOT documented, critical gap for LLM planning. Parameters lack descriptions in several tools (e.g., 'analyses' in run_batch_analysis is described only as 'List of analysis configurations' with no field-level detail). Error handling and recovery guidance are absent. Tool descriptions are functional but generic; they don't explain WHEN to use each tool vs. alternatives or what downstream tools expect. No pagination guidance despite tools returning lists. Missing idempotency and retry semantics.
Compare hotspots between two Git references (e.g., branches, tags, or commits).
Compare hotspots between two Git references (e.g., branches, tags, or commits) aggregated by folder.
Analyze file co-change patterns to identify the blast radius of changes and understand coupling between files.
Analyze git history to find code hotspots at the file level.
Analyze git history to find code hotspots aggregated by folder.
Analyze git history and return an interactive SVG heatmap visualization of code hotspots.
Analyze the evolution of code hotspots across release transitions to understand how risk and complexity change over time.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., does get_files_hotspots return file_id, file_path, risk_score?). This forces agents to guess structure and wastes tokens on parsing.
run_batch_analysis 'analyses' parameter lacks field-level schema. Described only as 'List of analysis configurations' with no detail on required/optional fields, types, or structure. LLM cannot construct valid payloads.
No error handling or recovery guidance. Tools lack descriptions of failure modes, retryability, or what the LLM should do if a call fails (e.g., 'repo not found, try run_check first').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | <=2025-11-25 | v2 |
Recommended first step. Analyzes repository shape via a lightweight aggregation pass and returns a recommended configuration preset (small, large, or infra) to be used with other tools.
Analyze git history to generate a time series of hotspot metrics over a specified period.
Run multiple analyses in batch mode for efficiency.
Run a validation check on the repository configuration and git setup.
No pagination or result-limiting guidance. Tools accept 'limit' but descriptions don't state default, max, or whether results are paginated. Large result sets risk context window exhaustion.
Tool descriptions lack WHEN-to-use guidance. E.g., get_files_hotspots vs get_folders_hotspots vs get_blast_radius are similar; descriptions don't explain which to call for different analysis goals. LLMs conflate similar tools.