Loading ToolBench
Stonewright exposes WordPress building primitives to MCP clients through a WordPress plugin with a Node.js companion server for WP-CLI, health checks, and optional MCP HTTP proxy.
Stonewright WordPress MCP server exhibits significant definition quality gaps. While 12 tools are registered, most suffer from missing or severely incomplete parameter descriptions, weak input schemas lacking constraint validation, and output schemas that are not documented. Tool naming follows verb-first conventions but descriptions are often vague or generic. The server's primary value proposition (WordPress/WP-CLI integration) is undermined by tools that lack actionable error guidance, constrained inputs, and clear composition paths. Only 2 of 12 tools have descriptions exceeding the 20-char minimum threshold for actionable guidance. Most parameters lack type information or are empty objects, triggering hard scoring penalties.
Run related nested editor calls with aliases, mandatory mutation readback, and rollback on failure.
Checks MCP client surface compatibility and capabilities
Setup and configuration profile initialization tool for Stonewright
Returns WordPress MCP server status and health information
Executes multiple WP-CLI commands in a batch
Discovers available WP-CLI commands and their metadata
Empty input schemas (6 tools): stonewright-setup-profile, stonewright-wordpress-mcp-status, stonewright-client-surface-check, stonewright-wp-cli-status, stonewright-wp-cli-discover, stonewright-wp-cli-install all define input as {"type":"object","properties":{},"required":[]}. This violates pattern:constrained-input and provides zero guidance to LLMs about what inputs these tools accept.
Missing parameter descriptions: stonewright-setup-profile, stonewright-wp-cli-run, stonewright-wp-cli-batch-run, stonewright-wp-cli-job-start, and stonewright-wp-cli-job-status all have parameters defined with only type and description fields, but descriptions are often minimal or non-existent. The 'command' parameter in stonewright-wp-cli-run is described only as 'WP-CLI command to execute', no guidance on syntax, expected format, error recovery, or constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | <=2025-11-25 | v2 |
Installs or updates WP-CLI components
Starts an asynchronous WP-CLI job
Checks the status of an asynchronous WP-CLI job
Executes a WP-CLI command synchronously
Returns WP-CLI status and availability information
Returns a compact task-aware Stonewright MCP tool profile for faster, lower-token client workflows. Auto routing sends ambiguous design tasks to gutenberg when surface=gutenberg, block/FSE terms, or a Gutenberg-first theme fingerprint appear; otherwise Elementor-active sites route to elementor-design.
No output schema documentation: None of the 12 tools document their output/return schema. LLMs cannot plan downstream composition, extract specific fields, or validate returned data. This violates pattern:tool and pattern:paginated-result (tools returning lists must specify pagination structure and field ordering).
No error handling guidance: None of the WP-CLI tools (stonewright-wp-cli-run, stonewright-wp-cli-batch-run, stonewright-wp-cli-job-start, stonewright-wp-cli-job-status) document what errors can occur, how to recover, or whether failures are retryable. Executing arbitrary WP-CLI commands can fail in dozens of ways (command not found, insufficient permissions, database errors, timeout), none of these recovery paths are documented.
No constraint validation in parameter schemas: stonewright-wp-cli-run accepts 'command' as a free-form string with no regex pattern, length limit, or validation rules. An LLM could pass malicious commands (e.g. shell injection via semicolons or pipes) without any schema-level defense. Parameterize high-risk inputs or document command syntax constraints explicitly.
Ambiguous tool naming for related functionality: stonewright-wp-cli-run vs stonewright-wp-cli-batch-run are clearly distinguished, but stonewright-wp-cli-job-start and stonewright-wp-cli-job-status lack clarity on whether jobs are async WP-CLI operations, background tasks, or something else. Naming should clarify scope, e.g. stonewright-wp-cli-async-start, stonewright-wp-cli-async-status.
Tool composition gaps: stonewright-wp-cli-discover returns available WP-CLI commands, but no tool accepts a 'discovered_command' or references the format discover() returns. If discover() returns {"commands": [{"name": "...", "signature": "..."}]}, stonewright-wp-cli-run should document that it accepts the 'name' field from this structure, enabling clear chaining.
stonewright/tool-profile is the only well-documented tool (score 78), but it exists at a meta/configuration level and requires a 'confirmation_token' parameter with no explanation of how to obtain it. This breaks discoverability for agents that haven't seen prior response metadata.