Loading ToolBench
Analyzes code repositories for architectural debt, code smells, cyclomatic complexity, and provides refactoring recommendations
This server presents a single tool with a reasonable name but critical deficiencies in schema visibility, parameter documentation, and output specification. The tool definition is inferred from a mock client implementation rather than from explicit MCP server registration code. No MCP framework, transport mechanism, or tool registration infrastructure is visible in the provided source. The tool name follows verb-noun convention (analyze_architectural_debt), but the implementation is a hardcoded mock that returns static data regardless of input, making it non-functional for real use. The input schema is partially visible (repository_path, complexity_threshold) but lacks proper JSON Schema type declarations and detailed parameter descriptions. No output schema is documented. Critical security concern: the tool accepts repository_path as a string parameter, which invites path traversal attacks and command injection, but no validation is mentioned. The mock implementation does not actually analyze any repository.
Analyzes a code repository for architectural debt, detecting code smells and recommending refactorings. Returns a technical debt score, list of detected code smells with cyclomatic complexity metrics, and recommended refactoring strategies.
No explicit MCP server registration visible. Tool definition is inferred from a mock Python client class, not from MCP tool_list or server initialization code. Cannot verify actual tool registration, schema, or transport mechanism.
Input schema lacks proper JSON Schema type declarations. Parameters are documented in Python type hints (repository_path: str, complexity_threshold: int = 15) but no formal JSON Schema with 'type', 'properties', 'required' fields is visible.
Output schema is not documented. The tool returns a dict with 'tech_debt_score', 'code_smells_detected', 'recommended_refactorings' but no formal output schema is provided. LLMs cannot plan downstream tool usage or extract fields without documented return structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | 2026-07-28+ | v2 |
repository_path parameter accepts untrusted user input as a file system path with no validation. This invites path traversal (e.g. '../../../etc/passwd') and command injection if the path is used in shell commands. No input sanitization or error handling for invalid paths is documented.
Parameter descriptions are minimal or missing detail. 'complexity_threshold' is described as 'Cyclomatic complexity threshold for flagging problematic code (default: 15)' which lacks constraint information (min/max range, valid values). The description does not explain what happens when the threshold is exceeded or how it affects the analysis.
Tool implementation is a static mock that ignores all inputs and returns hardcoded results. The method does not actually read the repository_path or use complexity_threshold. This is not a functional tool; it is a placeholder stub.
No error handling or error recovery guidance. If repository_path is invalid, does not exist, or is inaccessible, the tool provides no error message or suggestion for the LLM to recover. The description lacks guidance on prerequisites (e.g. 'Repository must be a valid Python project path').
No pagination or result limits. The tool returns code_smells_detected as a list with no limit. A real analysis could return hundreds of smells, which would inflate the LLM context window. No total count, limit parameter, or next_cursor is provided.