Loading ToolBench
MCP server for analyzing and converting Git repositories to text files for LLM context
The server provides two tools with complete parameter schemas and reasonable descriptions, but has significant gaps in output schema documentation, error handling guidance, and parameter optimization. Tool names follow verb_noun conventions. Descriptions exist but are relatively generic (139-151 chars, near the p10 baseline of 34 chars but underdeveloped for production). Parameter schemas are properly typed with JSON Schema, but lack several critical elements: no enums for constrained inputs, missing validation descriptions, and incomplete composition patterns. Error handling is minimal, tools return HTTPException with generic detail strings rather than recovery guidance. Output schemas are only partially documented (mentioned in code but not in tool registration metadata). The 'personal_token' parameter violates secret injection patterns by being exposed as a tool parameter. Parameter count is reasonable (11 and 1 respectively, within the p10-p90 band of 1 - 8). Overall Definition Quality is fair, basic structure is sound, but falls short of production-grade patterns in descriptions, error handling, and security.
Get the content of a generated output file
Convert a Git repository or local folder to a text file for LLM context
Secret injection violation: 'personal_token' parameter exposed as tool input. Credentials must be server-side injected via environment variables or vault. Agent traces log all parameters, token will leak into logs.
No output schema documented in tool registration. repo_to_txt returns {output_file, session_folder, character_count, token_count}, and get_output_content returns {content, character_count, token_count}, but neither is declared in the MCP tool definitions. LLMs cannot plan downstream operations without knowing response structure.
Error handling does not guide recovery. Tools raise HTTPException with generic detail strings like 'Failed to analyze repository' or 'Output file not found'. No recovery guidance (e.g. 'Try with a different source URL' or 'Check the file path'). Errors must categorize as retryable/user-fixable/fatal and suggest next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Parameter descriptions lack validation rules. 'exclude' and 'include' accept arrays of file extensions but do not specify format (e.g. '.py' vs 'py' vs '*.py'). 'output_dir' accepts a string but no format/path validation rules stated. Descriptions must specify constraints: length, regex patterns, enums, ranges.
No enums for constrained inputs. 'exclude' and 'include' parameters are free-form arrays inviting invalid values (wrong extension format, invalid characters). Should declare allowed file extension patterns or provide discovery endpoint listing supported extensions.
Tool descriptions are generic (139 - 151 chars). 'Convert a Git repository or local folder to a text file for LLM context' and 'Get the content of a generated output file' lack context on WHEN to use them, prerequisites, or expected behavior differences between local vs remote sources. Descriptions should be 50 - 200 chars with clear differentiation from related tools.
No pagination support. If a repository has thousands of files, concatenate=true will return unbounded content. Large results blow context windows. Tools must accept limit/page parameters and return total_count or next_cursor.
Composition concern: repo_to_txt writes to disk and get_output_content reads from disk. If the agent calls repo_to_txt and then get_output_content, the design requires the agent to pass the output_file path from the first call to the second. Consider returning content directly from repo_to_txt when return_file=true (as the FastAPI endpoint does) to enable single-call workflows.
Confusing parameter naming across endpoints. FastAPI endpoint has 'include_only' but MCP tool has 'include'. Both are passed to analyze_repo as 'include'. This inconsistency will confuse LLMs and cause silent failures if they pass the wrong name.
No idempotency hints. repo_to_txt writes files to disk, repeated calls with the same parameters may create new session folders or overwrite existing files. This behavior is not documented. Tool should either declare idempotentHint=true (if it safely returns cached results) or describe the overwrite behavior to prevent accidental duplicates.