Loading ToolBench
Client SDK for auditing source files against style rules and generating clean code refactors
This server has a single tool 'audit_and_refactor' with a name containing 'and' (violates verb_noun single-responsibility pattern). The tool description is present (67 chars) but lacks critical information about when/why to use it, what it returns structurally, and whether it modifies state. Input schema is visible with three parameters, but parameter descriptions are superficial (e.g. 'List of style rules to check against' does not explain format, valid values, or constraints). Output structure is inferred from example_usage.py (returns dict with 'issues_detected' and 'refactored_content') but NOT formally documented in the tool definition. No error handling, no validation guidance, no recovery paths. The implementation is a mock with hardcoded heuristics (only checks for 'import *' and basic naming patterns) rather than a real refactoring engine, which limits practical utility. No security considerations, no pagination (not applicable here), no idempotency guarantees documented.
Scans code content, identifies violations, and outputs refactored code
Tool name 'audit_and_refactor' violates single-responsibility principle by combining two actions (audit AND refactor). Should be split into separate tools: 'audit_code' and 'refactor_code'.
Tool description (67 chars) is too brief. Missing critical details: WHAT does it do exactly? WHEN should the LLM call it vs alternatives? WHAT structure is returned? Does it modify files or only analyze? Current description 'Scans code content, identifies violations, and outputs refactored code' does not guide LLM selection or explain return value structure.
Output schema is NOT documented in the tool definition. Example output inferred from example_usage.py shows a dict with 'issues_detected' (list of dicts with 'line_number', 'rule_violated', 'explanation') and 'refactored_content' (string), but this structure is nowhere in the tool schema or description. LLMs cannot plan downstream steps without knowing the output format.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 26 | 2026-07-28+ | v2 |
Parameter 'rules' is an array of strings with description 'List of style rules to check against' but lacks specification of valid values, format constraints, and examples. What rules are supported? Are they case-sensitive? Are they free-form strings or must they match a set of known rules? Current description is ambiguous and invites hallucinated rule names from the LLM.
No error handling or recovery guidance. If the tool fails (e.g. file not found, invalid rule), there is no documented error message, error category (retryable vs fatal), or recovery path. LLM has no guidance on what to do next.
Implementation is a mock with hardcoded heuristics checking only for 'import *' and basic naming patterns. Does not actually implement the rules passed in the 'rules' parameter, the rules list is ignored. For a production refactoring tool, this is a critical gap; the tool claims to audit against arbitrary style rules but only checks two specific patterns.
No idempotency guarantee documented. If an LLM retries with the same input after a transient failure, is the output identical? Can the tool be safely called multiple times? No guidance provided.