Loading ToolBench
MCP server for WordPress Gutenberg development with GeneratePress, GenerateBlocks, and WPCodebox integration
This WordPress/Gutenberg MCP server has solid foundational structure with 15 clearly defined tools spanning block generation, styling, PHP utilities, and WPCodebox integration. All tools have names, descriptions, and input schemas. However, the server exhibits several moderate quality gaps: (1) Output schemas are completely undocumented, tools return results but their response structure is not specified anywhere in the code or docs; (2) Parameter descriptions, while present, are often minimal (5-20 chars) and lack actionable detail about constraints, formats, or dependencies; (3) Error handling is generic, the main server catches exceptions and returns error text, but individual tools provide no guidance for recovery; (4) Descriptions average ~80-120 chars, which is acceptable but could be more LLM-optimized with WHEN/WHY context; (5) Several tools like 'generate_gb_block', 'generate_block', and 'generate_php_function' accept complex nested objects (attributes, innerBlocks, hooks) but parameter descriptions don't explain the expected structure; (6) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite the fact that most tools are read-only code generators. The server is functional and domain-competent, but lacks the rigor and LLM-optimization details expected of production tools.
Format a code snippet for WPCodebox plugin with proper structure and metadata
Generate complete Gutenberg block code
Generate block pattern
Generate block variation
Generate GenerateBlocks-compatible block code
Generate GenerateBlocks-specific SCSS
Generate GenerateBlocks template code
Output schemas completely undocumented. Tool handlers return results (lines 68-72 in index.ts show 'JSON.stringify(result, null, 2)') but no tool documents what fields are in the response. LLMs cannot plan downstream steps without knowing the response structure.
Parameter descriptions severely lack actionable constraint details. For example, 'generate_gb_block' has 'Block attributes' and 'Inner blocks' as descriptions (generic, under 20 chars). LLMs need explicit format details: what fields are valid? What structure is expected for 'attributes'? Are there required sub-fields?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Generate WordPress action or filter hook implementation
Generate WordPress PHP function following coding standards
Generate WordPress REST API endpoint
Generate WordPress shortcode implementation
Get GenerateBlocks development guide
Get Gutenberg block development standards reference
Get WPCodebox usage guidelines and best practices
Validate a snippet structure against WPCodebox requirements
No tool annotations present. All code-generation tools are read-only and likely idempotent, but readOnlyHint and idempotentHint are absent. Tool registration in index.ts (lines 58-84) does not include capability hints, making it harder for clients to determine which tools are safe to call repeatedly.
Error handling is generic and non-actionable. The server catches exceptions (lines 70-75 in index.ts) and returns 'Error: {message}' as plain text. Tools do not classify errors (retryable vs. user-fixable vs. fatal) or suggest recovery steps. An LLM receiving 'Error: Invalid input' has no idea what to try next.
Complex nested parameters (attributes object in generate_gb_block, hooks array in generate_php_function) lack structural documentation. Parameter schema shows type='object' but does not enumerate expected keys, types, or constraints. LLMs must guess valid JSON structure.
Tool descriptions lack WHEN/WHY guidance. For example, 'Generate GenerateBlocks-compatible block code' tells WHAT but not WHEN to use it vs. generate_block or generate_gb_template, and does not hint at prerequisites or relationships.