Loading ToolBench
MCP server for WordPress with 190+ tools - complete WordPress control including WooCommerce, Gutenberg, SEO, Security, Performance, Backup, and User Roles - 99% developer task coverage
Scoring was not performed
Output schemas are not documented in tool definitions. The provided source shows input parameters but no visible return type schemas, making it impossible for LLMs to plan multi-tool chains or extract required fields for downstream calls.
Parameter descriptions lack format constraints and validation guidance. For example, 'frequency' in wordpress_schedule_backups says 'Backup frequency (default: daily)' but does not specify allowed values (daily, weekly, monthly?) or format. 'time' says 'Time to run backups (default: 03:00)' but does not specify HH:MM format or timezone handling.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 25 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Many read-only discovery tools (wordpress_list_*, wordpress_get_*) lack pagination parameters. Example: wordpress_list_cron_jobs returns 'all scheduled WordPress cron jobs' with no limit or page parameter visible. Large result sets will blow context windows. Pattern baseline expects limit/page/offset on paginated results.
Destructive operations (wordpress_delete_backup, wordpress_delete_file, wordpress_delete_term, wordpress_delete_reusable_block) lack confirmation/dry-run steps. Per Arcade pattern confirmation-request, irreversible operations should support a confirmation step to prevent catastrophic agent mistakes.
Tool descriptions often lack context on when to use them versus similar tools. For example, wordpress_get_terms vs wordpress_get_post_types, when should an agent call each? The descriptions do not clarify the distinction or provide dependency hints (e.g., 'Call wordpress_get_taxonomies first to see available taxonomy names').
Parameter 'updates' in wordpress_update_reusable_block is typed as 'object' with description 'Updates to apply', far too vague. LLMs cannot know which fields are accepted. This should enumerate allowed fields (title, content, status, etc.) or reference a schema.
wordpress_execute_sql allows arbitrary SQL with description 'SELECT, SHOW, DESCRIBE, EXPLAIN only for safety' but no visible input validation or query whitelisting in the schema. This is a security risk and the constraint is only documented in text, not enforced by the schema.
No error handling guidance visible in tool descriptions. When wordpress_restore_backup fails (e.g., 'Backup corrupted' or 'Disk full'), what should the LLM do next? Should it retry, ask the user for a different backup, or is it unrecoverable? Descriptions lack recovery hints per pattern:recovery-guide.
Parameter names use inconsistent conventions. Some params are clear (backupId, blockId, termId) but others are underspecified. Example: 'namespace' in wordpress_get_block_types, does this filter by block namespace or return blocks in a namespace? 'context' in wordpress_get_post_types is ambiguous without enum values (view, edit, embed?).
Some tools combine multiple concerns. Example: wordpress_schedule_backups with parameters frequency, time, and keepCount appears to both schedule backups AND set retention policy. Per pattern:tool, this should be split into separate tools (schedule_backup_task and set_backup_retention) so the agent can compose them independently.