Loading ToolBench
MCP server that gives AI tools full WordPress management via WP-CLI — themes, plugins, posts, menus, users, database, and more
The wp-cli-mcp server defines 33 tools with reasonable naming conventions and broad coverage of WordPress administration tasks. However, there are significant gaps in parameter descriptions, schema completeness, and error handling guidance. Most tools follow a consistent verb_noun naming pattern (wp_plugin_*, wp_post_*, etc.), which is good for LLM discoverability. However, many parameter descriptions are minimal or missing validation constraints. Output schemas are not documented for most tools, callers must infer structure from wp-cli output descriptions. Error handling is absent from all tool definitions; there is no guidance on recovery, retryability, or actionable error messages. The server caps at 50 for protocol readiness due to STDIO-only transport, which significantly limits its production viability. Overall, this is a competent but incomplete implementation, adequate for local automation but lacking polish for agentic reasoning.
Clear all WordPress caches
Check if WordPress core updates are available. Returns a list of available versions with download URLs. Use this before running updates to see what's new.
Get the currently installed WordPress core version. Returns the version string (e.g. '6.7.1'). Useful for checking compatibility before installing plugins or themes.
Export the WordPress database
Execute a raw database query
Import media from URL
Create a new navigation menu
Output schemas not documented for any tool. LLMs must infer response structure from wp-cli behavior alone, risking misinterpretation of fields, types, and pagination.
Many parameter descriptions are under 20 characters or provide minimal context. E.g., wp_theme_activate: 'Theme slug' (11 chars), wp_user_list: no description, wp_menu_list: no description. LLMs lack actionable guidance on valid values or usage context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Add a custom link to a menu
List all navigation menus
Get a WordPress option value
Update a WordPress option
Activate an installed but inactive WordPress plugin. The plugin must already be installed.
Deactivate an active WordPress plugin without removing it. The plugin files remain on disk and can be reactivated later.
Permanently delete a WordPress plugin from the filesystem. The plugin must be deactivated first. This cannot be undone.
Install a WordPress plugin from the official wordpress.org plugin directory. Optionally activate it immediately after installation.
List all installed WordPress plugins with their name, status (active/inactive/must-use), version, and update availability. Returns a JSON array of plugin objects.
Search the official wordpress.org plugin directory for plugins matching a search term. Returns top 10 results with name, slug, rating, and active install count.
Create a new WordPress post, page, or custom post type entry. Returns the new post ID. Content supports full HTML.
Delete a post
Get a single post by ID
List WordPress posts, pages, or any custom post type. Returns ID, title, status, date, and type for each item.
Update an existing post
Flush WordPress rewrite rules
Generate a new Gutenberg block
Generate a new plugin
Generate a new child theme
Search and replace text across the database
Activate a theme
Delete a theme
Install a WordPress theme from the official wordpress.org theme directory. Optionally activate it immediately.
List all installed WordPress themes with their name, status (active/inactive), version, and update availability. Returns a JSON array.
Create a new user
List all users
No error handling or recovery guidance in any tool definition. Errors like 'plugin not found' or 'invalid slug' have no actionable recovery path. LLMs cannot self-correct or suggest alternatives.
wp_db_query accepts raw SQL with no input validation or injection protection documented. A prompt-injected LLM could pass DROP TABLE commands. No mention of read-only vs write scope.
Destructive tools (wp_plugin_delete, wp_post_delete, wp_theme_delete, wp_db_query, wp_search_replace) lack dry-run or confirmation mechanisms. No protection against accidental irreversible operations.
List tools (wp_plugin_list, wp_theme_list, wp_post_list, wp_user_list, wp_menu_list) lack pagination parameters or limits. Large WordPress installations could return hundreds of items, bloating context.
Many tools accept boolean flags (activate, force, dry_run) with defaults that could cause unintended side effects. E.g., wp_post_update allows arbitrary field names without validation; wp_search_replace defaults dry_run=true but documentation is unclear on whether this means 'changes applied' or 'changes previewed'.
wp_post_update uses generic 'fields' parameter accepting arbitrary post field names. No enum or validation. LLM could pass invalid field names without clear error feedback.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. LLMs cannot infer operation safety from metadata; they must reason from descriptions alone.