Loading ToolBench
WordPress MCP server with free Elementor MCP editing. 133 typed abilities for posts, pages, Gutenberg, Elementor, media, menus and themes, served over MCP with OAuth 2.1, safety profiles, change evidence and rollback.
This MCP server exposes three meta-tools (discover-abilities, get-ability-info, execute-ability) that serve as a discovery and execution gateway for an underlying ability system. While the three visible tools have descriptions and basic schemas, they are thin wrappers around a dynamic ability registry not visible in the source. The actual '133 typed abilities' are backend abstractions resolved at runtime, not statically declared in tool definitions. This creates a critical visibility gap: the source code does not contain explicit schemas, parameter descriptions, or error handling for the 133 claimed abilities. The three gateway tools themselves have moderate quality, naming is reasonable (verb-prefix pattern), descriptions are informative, but input schemas lack depth for the discovery and info-retrieval tools. The execute-ability tool includes a confirmation_reason parameter (good for safety), but the schema does not specify what constitutes valid confirmation text, acceptable ability_name values are not enumerated, and there is no documented error classification for execution failures. Per-tool scoring reflects this: the tools are functional but lack the depth expected of production-grade agent tools.
Discover the WordPress abilities available in this system. Returns the list of ability names (which are descriptive, e.g. wppilot/update-post). Call this first to find the exact ability name for a task, then copy the name verbatim; use get-ability-info if a name is unclear.
Execute one ability by its exact name with parameters matching its schema. Use only names returned by discover-abilities; do not construct names from categories. Prefer a specific, scoped ability over general code execution.
Get detailed information about one ability, including its description and full input schema, so you can build valid parameters for execute-ability.
Dynamic ability system not statically documented. The server advertises '133 typed abilities for posts, pages, Gutenberg, Elementor, media, menus and themes' but these are resolved at runtime by discover-abilities. Source code does not expose explicit tool definitions, schemas, or descriptions for any of these 133 abilities. This violates the principle that tool definitions should be discoverable and verifiable from the source, downstream agents and MCP clients cannot validate ability schemas without runtime calls.
discover-abilities input schema is overly permissive. The parameter '_' (underscore) has type 'string' with description 'Unused; pass an empty string.' This is confusing, if the parameter is truly unused, it should not exist. If it exists, it should have a clear purpose, validation rule, or be removed. Passing an empty string is a low-confidence signal that the schema was hastily designed.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
execute-ability lacks error classification and recovery guidance. The source does not document which execution errors are retryable (transient failures), which are user-fixable (invalid ability_name or parameters), and which are fatal (permission denied, system error). Error handling guidance is required by pattern:recovery-guide so that agents know whether to retry, ask the user, or abort.
execute-ability confirmation_reason parameter has no validation or bounds. The description says 'A very short single-line question' with minLength=1, but does not specify a maximum length, format rules, or examples of good vs. bad confirmation text. An LLM could submit a 10,000-character string. Specify maxLength and provide clear examples of acceptable confirmation text.
No documented output schemas for the three tools. discover-abilities returns 'the list of ability names' but the schema does not specify the return type (array? object with 'abilities' field? paginated?). get-ability-info returns 'description and full input schema' but the exact structure is not documented. Without documented return types, agents cannot plan downstream operations reliably.
No pagination or result limits documented. If discover-abilities returns 133 abilities as a flat array, this risks overwhelming the agent context. No mention of limit, offset, page, or cursor parameters. Large result sets without pagination cause context explosion and degrade agent reasoning.
Tool composition gap: discover-abilities and get-ability-info are sequential gatekeepers, not independent. LLMs must call discover-abilities first to get an ability name, then get-ability-info to retrieve its full schema before execute-ability. This three-step discovery + execution flow is inefficient and error-prone. Consider returning ability schemas directly in discover-abilities response or offering a bulk discovery tool.