Loading ToolBench
Model Context Protocol (MCP) server that exposes the 23 Gang of Four design patterns to AI coding agents — generation, canonical examples, AST-based detection and validation, anti-pattern refactoring.
Server has 7 well-named tools with clear descriptions and mostly complete schemas. Tool names follow verb_noun convention (detect_pattern, generate_pattern, list_patterns, etc.). Descriptions are substantive (100-250 chars typical), explaining WHAT the tool does and WHEN to use it. Input schemas are present with type definitions and parameter descriptions. However, output schemas are not documented in the visible code, LLMs cannot see what fields to expect from responses. The ping tool is deprecated in MCP 2026-07-28 spec. Error handling descriptions are minimal; tools do not guide recovery (e.g., 'if parse fails, check syntax'). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Parameter constraints are good (enums for pattern names, directory limits), but some descriptions lack format/range details.
Parse Java source(s) and report which GoF design patterns the contained classes / interfaces participate in. Returns per-instance confidence (0–1) and the structural signals that fired, with the originating file for every hit. Supports three input modes — pass exactly one of: 'source' (single inline string), 'paths' (list of .java files on disk), or 'directory' (recursive scan). Per-file parse failures are reported in 'errors' and do NOT abort the batch.
Generate a customised Java implementation of a design pattern, with the user's package name and main type name. Returns the rendered source code, ready to compile.
List the 23 Gang of Four design patterns with their intent, category, aliases and reference URL. Optional argument `category` filters the result: Creational, Structural, or Behavioral.
Return canonical, compilable Java example source(s) for a given Gang of Four design pattern. Accepts enum names, slugs, or display names (case-insensitive). When `includeSource` is false the file metadata is returned without the source bytes — useful for discovery.
Health-check tool. Returns server name, version, and the list of currently registered MCP tools. Takes no arguments.
Output schemas not documented. LLMs cannot see what fields detect_pattern, generate_pattern, validate_pattern, and refactor_to_pattern return. This forces LLMs to guess at response structure and risks failed downstream tool chaining.
ping tool is deprecated in MCP spec 2026-07-28 (removed from core protocol). Server should remove it or document that it is legacy.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). refactor_to_pattern is marked WRITE risk but has no destructiveHint annotation. detect_pattern and validate_pattern are READ_ONLY but lack readOnlyHint. Annotations help LLMs reason about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Apply a small, idempotent AST refactoring to a Java source. Returns the rewritten code plus a change log. Use validate_pattern first to discover which refactoring to apply.
Validate the implementation quality of design pattern instances in a Java source. Returns issues grouped by ERROR / WARNING / INFO, each with a concrete suggestion. Pass `pattern` to focus on one; omit to validate every supported pattern in the source.
Error handling lacks recovery guidance. Tools do not describe what to do if parsing fails, pattern not found, or refactoring is invalid. E.g., detect_pattern says 'parse failures reported in errors' but does not guide the LLM on next steps.
refactor_to_pattern parameter 'refactoring' lacks description detail. What are valid refactoring identifiers? Should LLM call validate_pattern first to discover them? Undocumented dependency.