Loading ToolBench
MCP server that teaches and applies software-design guidance: SOLID/OOP/DRY principles, the 23 GoF design patterns, pattern scaffolding, and heuristic code-smell detection.
Four well-named tools with clear, actionable descriptions (avg 180 chars). All tools have input schemas with type definitions and parameter descriptions. Output schemas are documented via Zod. Naming follows verb_noun convention (list_, explain_, scaffold_, check_). Parameters are well-constrained (enums, descriptions). Error handling is present but minimal, no recovery guidance or categorization. No tool annotations (readOnlyHint, destructiveHint). Security is solid (no secrets in params). Composition is clean, each tool has one responsibility. Main gaps: error responses lack actionable recovery hints, and output schemas could be more explicit in descriptions.
Scan a code snippet for heuristic code smells: long methods, large classes, too many parameters, deep nesting, duplication, and large files. Returns findings mapped to design principles and refactoring hints. All thresholds are overridable.
Return an authoritative explanation of one design principle or GoF pattern: intent, when to use it, trade-offs, participants, and related concepts. Accepts a slug, full name, or alias (e.g. "SRP", "factory").
List the catalog of software-design concepts, optionally filtered by kind. Returns each concept's slug, name, category, and one-line summary.
Generate a language-agnostic pseudo-code skeleton for a GoF pattern, showing its participants and how they collaborate. Optionally rename roles to your domain (e.g. Product -> Notification). Translate the result into your target language.
Error responses lack recovery guidance. Tools return errors but do not tell the LLM what to do next (e.g., 'Concept not found. Try list_catalog() to see available concepts.').
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All four tools are read-only and idempotent, but this is not declared in the schema. LLMs cannot infer safety properties without explicit hints.
Output schema for explain_concept and scaffold_pattern not visible in source. Zod schemas are inferred but not explicitly documented in descriptions. Users cannot predict response structure without reading implementation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
check_smells accepts numeric thresholds but does not validate ranges. LLMs could pass negative or absurdly large values (e.g., longMethod: -1 or 999999). Add min/max constraints to parameter descriptions.
scaffold_pattern 'names' parameter uses additionalProperties but lacks guidance on valid role names. LLMs may pass arbitrary keys. Document expected role names (e.g., 'Product', 'Creator', 'Observer') in the description.