This server enables AI tools to manage a WordPress installation comprehensively through WP-CLI, working both locally and over SSH with multisite support.
Core Management: Check WordPress version and available core updates.
Plugin Management: List, install, activate, deactivate, delete, and search plugins from wordpress.org.
Theme Management: List, install, activate, and delete themes; scaffold new child themes.
Post/Content Management: List, get, create, update, and delete posts/pages of any post type; manage post meta.
User Management: List users and create new ones with specified roles.
Options Management: Get and update any WordPress site option.
Navigation Menus: List menus, create new menus, add items, and assign locations.
Media: Import media files into the WordPress library from a URL.
Database Operations: Execute raw SQL queries, export the database, and perform search-and-replace (with dry-run support).
Scaffolding: Generate skeleton code for child themes, plugins, and Gutenberg blocks.
Cache & Rewrites: Flush rewrite rules and the WordPress object cache.
Raw Access: Execute any arbitrary WP-CLI command or PHP code within the WordPress context for maximum flexibility.
Complements the official Automattic WordPress MCP by providing WP-CLI based tools alongside REST API tools for comprehensive WordPress management.
Pairs with Elementor MCP for complete page building workflows, complementing WordPress management with Elementor-specific tools for AI-powered development.
Enables scaffolding of custom Gutenberg blocks through WP-CLI, allowing AI agents to create and manage block-based content for WordPress sites.
Supports WooCommerce installation and management through WP-CLI commands, allowing AI agents to handle e-commerce functionality within WordPress sites.
Provides comprehensive WordPress management tools via WP-CLI, enabling AI agents to manage themes, plugins, posts, users, menus, database operations, and scaffolding for WordPress installations.
"Install WooCommerce and activate it"
"Create a new page called About Us with this content..."
"List all plugins and deactivate the ones I'm not using"
"Scaffold a new child theme called my-theme"
"Create a navigation menu with Home, About, Contact links"
"Search and replace old domain with new domain in database"
"Export the database before I make changes"
"Generate a custom Gutenberg block for testimonials"All powered by WP-CLI under the hood. Works locally or over SSH to remote servers.
Related MCP server: WP MCP Ultimate
Category | Tools |
Core |
|
Plugins |
|
Themes |
|
Theme Files |
|
Posts |
|
Post Meta |
|
Taxonomies |
|
Users |
|
Options |
|
Menus |
|
Widgets |
|
Media |
|
Database |
|
Scaffold |
|
Cache |
|
PHP |
|
Site |
|
Raw |
|
WP-CLI installed and in PATH
WordPress installation (local or accessible via SSH)
Node.js 18+
npm install -g wp-cli-mcpAdd to your Claude Code MCP settings (~/.claude/claude_desktop_config.json):
{
"mcpServers": {
"wordpress": {
"command": "wp-cli-mcp",
"env": {
"WP_PATH": "/path/to/your/wordpress"
}
}
}
}{
"mcpServers": {
"wordpress": {
"command": "wp-cli-mcp",
"env": {
"WP_SSH": "user@yourserver.com:/var/www/html"
}
}
}
}Variable | Description | Example |
| Local WordPress path |
|
| SSH connection string |
|
| Site URL (multisite) |
|
You: "Scaffold a child theme based on twentytwentyfour"
Claude: Uses wp_scaffold_theme → creates child theme files
You: "Install and activate it"
Claude: Uses wp_theme_activate → theme is live
You: "Create the homepage with a hero section and 3 feature cards"
Claude: Uses wp_post_create → creates page with HTML contentYou: "What plugins do I have installed?"
Claude: Uses wp_plugin_list → shows all plugins with status
You: "Install Contact Form 7 and WooCommerce"
Claude: Uses wp_plugin_install twice → both installed and activatedYou: "I'm migrating from staging.example.com to example.com"
Claude: Uses wp_db_export → backup first
Uses wp_search_replace (dry_run) → preview changes
Uses wp_search_replace → apply changes
Uses wp_cache_flush → clear cacheElementor MCP — 97 tools for Elementor page building
WordPress MCP — Official Automattic REST API tools
wordpress-claude-stack — CLAUDE.md + Cursor rules for WordPress
Use all three together for complete AI-powered WordPress development.
MIT — Mustafa Vatandas
Flush the WordPress object cache
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Flush' implies a destructive operation that clears cached data, the description doesn't specify whether this requires admin permissions, whether it affects site performance temporarily, what happens to persistent vs transient cache, or if there are any side effects. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized for a simple tool with no parameters and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (flushing cache implies data modification) with no annotations and no output schema, the description is incomplete. It should address behavioral aspects like permissions needed, performance impact, what types of cache are affected, and whether the operation is reversible. The current description provides only basic purpose without necessary operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to explain any parameters, which is appropriate. A baseline of 4 is given since no parameter documentation is required, and the description doesn't attempt to describe non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Flush') and the target resource ('WordPress object cache'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its sibling 'wp_rewrite_flush', which also performs a flushing operation but on a different resource (rewrite rules vs object cache).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when flushing the object cache is appropriate (e.g., after plugin updates, cache invalidation needs) or contrast it with related tools like 'wp_rewrite_flush' for different cache types. There's only an implied context from the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute any WP-CLI command directly
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Full WP-CLI command (without 'wp' prefix, e.g. 'post meta get 1 _thumbnail_id') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states 'Execute any WP-CLI command directly' but doesn't disclose permissions needed, potential destructive effects, rate limits, error handling, or output format. For a powerful raw execution tool, this is inadequate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core functionality. There's zero wasted verbiage, and it's perfectly front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary WP-CLI commands with no annotations and no output schema, the description is insufficient. It doesn't explain what kind of output to expect, error conditions, safety considerations, or how this differs from the many specialized sibling tools. The context demands more guidance than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single 'command' parameter well-documented in the schema. The description adds no additional parameter semantics beyond what the schema already provides (e.g., no examples beyond the schema's example, no clarification of command syntax rules). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Execute') and resource ('any WP-CLI command'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like wp_db_query or wp_search_replace, which also execute specific WP-CLI commands but with predefined functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many specialized sibling tools. It doesn't mention alternatives, prerequisites, or appropriate contexts for raw command execution versus using specific tools like wp_post_create or wp_plugin_activate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check for WordPress core updates
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('Check for') but lacks behavioral details: it doesn't specify if this is a read-only operation, requires authentication, has rate limits, returns structured data, or indicates success/failure. For a tool with zero annotation coverage, this is a significant gap in transparency about how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Check for WordPress core updates' is a single, efficient sentence that front-loads the core action and resource. There is zero waste—every word contributes directly to understanding the tool's function, making it appropriately sized and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (checking for updates) with no annotations, 0 parameters, and no output schema, the description is incomplete. It doesn't explain what the check entails (e.g., remote API call, local version comparison), what it returns (e.g., update availability, version details), or any behavioral constraints. For a tool that likely involves external checks, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter semantics, and it doesn't introduce any confusion about parameters. Baseline is 4 for zero parameters, as the description appropriately focuses on the tool's purpose without unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check for WordPress core updates' clearly states the verb ('Check for') and resource ('WordPress core updates'), making the purpose immediately understandable. It distinguishes from siblings like wp_core_version (which returns current version) and wp_plugin_list (which checks plugins). However, it doesn't specify what constitutes an 'update' (e.g., security patches, major versions), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to verify if WordPress core has available updates, which is reasonable context. However, it provides no explicit guidance on when to use this versus alternatives like wp_core_version for current version or wp_plugin_list for plugin updates, nor does it mention prerequisites (e.g., admin access) or exclusions. This leaves usage somewhat open to interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get WordPress version
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Get WordPress version' implies a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns cached data, or provides error handling. For a tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('Get WordPress version') that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimally adequate. However, without annotations or output schema, it doesn't explain what the return value looks like (e.g., version string format, error responses) or any behavioral constraints. For a read operation with no structured context, it should provide more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of parameters. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters. A baseline of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get WordPress version' clearly states the verb ('Get') and resource ('WordPress version'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'wp_core_check_update' which might also provide version-related information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'wp_core_check_update' that might overlap in functionality, there's no indication of when this specific tool is appropriate or what distinguishes it from other version-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export database to SQL file
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Output filename |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Export') but doesn't mention whether this requires specific permissions, if it's a read-only or destructive operation, what happens during the export process, or any rate limits. For a database export tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, front-loading the core action. Every word earns its place by specifying what's being exported and to what format. There's zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a database export tool with no annotations, no output schema, and minimal description, the description is incomplete. It doesn't explain what the export contains, where the file is saved, whether it's a full or partial export, or any error conditions. For a tool that presumably creates SQL files from a database, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter ('filename') clearly documented in the schema. The description doesn't add any additional parameter information beyond what's already in the schema. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export') and resource ('database to SQL file'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'wp_db_query' or 'wp_search_replace' that might also interact with the database, so it doesn't achieve full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, timing considerations, or comparison to sibling tools like 'wp_db_query' for database interactions. It's a basic statement of function without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a raw SQL query (read-only recommended)
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'read-only recommended,' which hints at safety concerns, but doesn't specify permissions required, potential side effects (e.g., performance impact), rate limits, or what the output looks like (e.g., result format, error messages). For a tool that executes raw SQL with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Execute a raw SQL query') and includes a crucial caution ('read-only recommended'). There is no wasted verbiage, and every word serves a purpose, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing raw SQL queries, no annotations, and no output schema, the description is incomplete. It lacks details on security implications, expected return formats, error handling, and performance considerations. While concise, it doesn't provide enough context for safe and effective use, especially compared to siblings with more specific purposes like wp_post_list or wp_option_get.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'sql' parameter clearly documented. The description adds minimal value beyond the schema by implying the query should be 'read-only recommended,' but doesn't provide additional semantics like supported SQL dialects, query length limits, or parameter binding. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('execute') and resource ('raw SQL query'), making the purpose specific and understandable. It distinguishes from siblings like wp_db_export (which exports data) or wp_option_get (which retrieves specific options), but doesn't explicitly contrast with other query-related tools since none are listed. The 'read-only recommended' adds nuance but doesn't fully differentiate from potential write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for executing SQL queries, with 'read-only recommended' suggesting caution for write operations, but it doesn't explicitly state when to use this tool versus alternatives. No guidance is provided on prerequisites, error handling, or specific scenarios where this tool is preferred over other data retrieval methods like wp_post_list or wp_option_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import media from URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the media file to import | |
| title | No | Title for the media item |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this requires admin permissions, what happens on failure (e.g., invalid URL), if it overwrites existing media, rate limits, or the expected output format. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's apparent complexity, though it may be too brief given the lack of other context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool (import implies write), the description is incomplete. It doesn't cover permissions, error handling, return values, or how it fits with sibling tools. For a tool that likely modifies WordPress state, this leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (url and title). The description adds no additional meaning beyond implying URL import, which is already covered by the schema's url description. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Import media from URL' clearly states the action (import) and resource (media), with the URL source specified. It distinguishes from siblings like wp_post_create or wp_plugin_install by focusing on media import specifically, though it doesn't explicitly differentiate from all media-related tools (none listed).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., WordPress media library access), exclusions, or related tools for media handling, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a WordPress option value
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Option name (e.g. blogname, siteurl, permalink_structure) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' a value, implying a read-only operation, but doesn't disclose whether this requires authentication, has rate limits, returns cached data, or what happens if the option doesn't exist. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, read operation) and high schema coverage, the description is adequate but not complete. Without annotations or output schema, it should ideally mention what type of data is returned (string, array, etc.) or common use cases. The description meets minimum viability but has clear gaps in behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'key' well-documented with examples. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('WordPress option value'), making the purpose immediately understandable. It distinguishes from siblings like wp_option_update (which modifies options) and wp_post_get (which retrieves posts). However, it doesn't specify what type of options it retrieves (site settings, theme options, etc.), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to retrieve a WordPress option value, but provides no explicit guidance on when to use this versus alternatives like wp_post_get for posts or wp_plugin_list for plugins. It doesn't mention prerequisites, error conditions, or specific scenarios where this tool is preferred over others in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a WordPress option
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Option name | |
| value | Yes | New value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation (implying mutation) but doesn't mention permission requirements, whether changes are permanent or reversible, potential side effects, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's perfectly front-loaded with the core action, making it immediately scannable and appropriately sized for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what constitutes a valid 'WordPress option', what format the value should be in, whether the update is atomic, or what the tool returns. Given the complexity and lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('key' and 'value') clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured data, so it meets the baseline for adequate but unhelpful parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('WordPress option'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'wp_option_get' (which retrieves options) or explain what a 'WordPress option' specifically is, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'wp_post_update' or 'wp_option_get'. It doesn't mention prerequisites, error conditions, or typical use cases, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate an installed plugin
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Plugin slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose whether activation requires admin permissions, if it affects site functionality immediately, potential side effects (like plugin conflicts), or what happens if the plugin is already active. The description is technically accurate but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'activate' entails operationally, what permissions are required, what the response looks like, or how this differs from related plugin operations. Given the complexity of plugin management and potential side effects, more context is needed for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with the 'slug' parameter clearly documented, so the baseline is 3. The description doesn't add any parameter information beyond what the schema provides (no examples of valid slugs, no clarification that this is WordPress-specific slug format). It simply restates the tool's purpose without enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('activate') and resource ('an installed plugin'), making the purpose immediately understandable. However, it doesn't differentiate from its sibling 'wp_plugin_deactivate' beyond the verb, nor does it specify what 'activate' means in WordPress context (enabling functionality vs just marking as active).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'wp_plugin_install' (for new plugins) or 'wp_plugin_deactivate'. It doesn't mention prerequisites (plugin must be installed) or consequences of activation, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deactivate a plugin
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Plugin slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Deactivate' implies a mutation, but it doesn't disclose behavioral traits like whether it requires admin permissions, if deactivation is reversible, potential site impact (e.g., broken functionality), or error handling. For a mutation tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Deactivate a plugin' is front-loaded and directly conveys the core action. Every word earns its place, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with potential site impact), lack of annotations, no output schema, and incomplete behavioral disclosure, the description is inadequate. It doesn't cover return values, error cases, or operational consequences, leaving the agent under-informed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'slug' parameter is documented in the schema), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain slug format, examples, or how to obtain it from wp_plugin_list. This meets minimum viability but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Deactivate') and resource ('a plugin'), making the purpose immediately understandable. It distinguishes from siblings like wp_plugin_activate and wp_plugin_delete by specifying the exact action. However, it doesn't explicitly mention WordPress context or differentiate from wp_theme_activate, leaving minor room for improvement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., plugin must be active), contrast with wp_plugin_delete (remove vs. deactivate), or specify scenarios like troubleshooting or updates. This lack of context could lead to misuse among similar plugin management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a plugin
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Plugin slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete a plugin' implies a destructive, irreversible mutation, but it doesn't specify permissions required, whether it's safe or has side effects (e.g., breaking site functionality), or what happens on success/failure. For a destructive tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Delete a plugin' is extremely concise—just three words—and front-loaded with the core action and resource. There is zero wasted language, making it efficient and easy to parse, though this conciseness comes at the cost of completeness in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive deletion with no annotations) and lack of output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, permissions, or return values, nor does it provide usage context. For a mutation tool with significant implications, this minimal description is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'slug' documented as 'Plugin slug'. The description adds no additional parameter information beyond this. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a plugin' clearly states the action (delete) and resource (plugin), making the purpose immediately understandable. It distinguishes from siblings like wp_plugin_activate or wp_plugin_install by specifying deletion rather than other plugin operations. However, it doesn't explicitly differentiate from wp_theme_delete or wp_post_delete, which target different resources, so it's not fully sibling-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., plugin must be deactivated first), when not to use it (e.g., for core plugins), or refer to related tools like wp_plugin_deactivate or wp_plugin_list for context. This leaves the agent without usage context beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a plugin from wordpress.org
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Plugin slug (e.g. 'woocommerce', 'advanced-custom-fields') | |
| activate | No | Activate after install |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether installation requires admin permissions, what happens on failure, if it overwrites existing plugins, or any rate limits. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (installing plugins) with no annotations and no output schema, the description is incomplete. It should address permissions, error handling, or what the tool returns, but it only states the basic action, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (slug and activate). The description doesn't add any meaning beyond what the schema provides, such as examples of slugs or implications of activation. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Install') and resource ('a plugin from wordpress.org'), providing specific purpose. However, it doesn't explicitly differentiate from sibling tools like wp_theme_install (for themes) or wp_plugin_activate (for already installed plugins), which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like wp_plugin_activate (for already installed plugins) or wp_plugin_search (to find plugins first). The description implies usage for installing new plugins but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all installed plugins with status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List') but doesn't describe key behaviors: whether this is a read-only operation, what the output format looks like (e.g., list of objects with names and statuses), if there are rate limits, or if it requires specific permissions. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the key action ('List') and resource ('all installed plugins with status'), making it easy to scan. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations, no output schema), the description is complete enough for basic understanding. It covers what the tool does but lacks details on output format, permissions, or error handling. Without annotations or output schema, the agent must infer behavior from the description alone, which is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it correctly avoids mentioning any. This meets the baseline for tools with no parameters, where minimal description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all installed plugins with status'), making the purpose immediately understandable. It distinguishes from siblings like wp_plugin_activate or wp_plugin_search by focusing on listing rather than modifying or searching. However, it doesn't explicitly differentiate from wp_theme_list or wp_menu_list, which follow similar patterns for other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., WordPress installation), exclusions (e.g., not for uninstalled plugins), or comparisons to siblings like wp_plugin_search for finding plugins not yet installed. Usage is implied by the name and purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search wordpress.org plugin directory
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Search term |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but provides no information about what the search returns (list of plugins? detailed metadata?), whether it accesses external APIs, rate limits, authentication requirements, or error conditions. For a search tool with no annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the essential information and doesn't include any unnecessary elaboration. This is an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a search operation that likely returns structured data, the description is incomplete. It doesn't explain what the tool returns, how results are formatted, or any behavioral characteristics. For a tool that presumably queries an external directory, more context about the operation would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'term' parameter. The description doesn't add any additional semantic context about the parameter (like search syntax, examples, or special characters). This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and target resource ('wordpress.org plugin directory'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'wp_plugin_list' or 'wp_search_replace', but the combination of verb and resource is sufficiently specific for this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple related sibling tools (wp_plugin_list, wp_search_replace, wp_plugin_install) where the agent might need clarification about which tool to choose for different search or plugin-related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new post or page
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Post title | |
| content | Yes | Post content (HTML) | |
| post_type | No | Post type (default: post) | |
| status | No | Post status: draft, publish, pending, private |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, it lacks details on permissions required, whether it's idempotent, error handling, or what happens on success (e.g., returns a post ID). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by directly contributing to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication requirements, error conditions, or return values. While the schema covers parameters well, the overall context for safe and effective use is lacking, especially compared to siblings with more complex operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters (title, content, post_type, status) with descriptions and required fields. The description adds no additional parameter semantics beyond implying creation of posts/pages, which is redundant with the tool name. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new post or page'), making the purpose immediately understandable. It distinguishes from siblings like wp_post_update or wp_post_delete by specifying creation rather than modification or deletion. However, it doesn't explicitly differentiate from wp_user_create or other creation tools in the sibling list beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication needs), when not to use it, or how it differs from similar tools like wp_post_update for editing existing posts. Without such context, an agent might struggle to select this tool appropriately in complex scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a post
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Post ID | |
| force | No | Skip trash and force delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete a post' implies a destructive mutation, but it doesn't specify whether deletion is permanent, reversible, or requires specific permissions. It mentions the 'force' parameter in the schema but doesn't explain its behavioral impact (e.g., skipping trash). For a destructive tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It is front-loaded with the core action ('Delete a post'), making it immediately understandable. Every word earns its place by directly conveying the tool's purpose without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive mutation with 2 parameters) and the lack of both annotations and an output schema, the description is incomplete. It doesn't cover behavioral aspects like permanence, permissions, or error conditions, nor does it explain the return value. For a delete operation, this leaves critical gaps that could lead to misuse or confusion by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (id and force) fully documented in the schema. The description adds no additional meaning about parameters beyond what the schema provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a post' clearly states the verb (delete) and resource (post), making the purpose immediately understandable. It distinguishes from sibling tools like wp_post_create, wp_post_get, and wp_post_update by specifying deletion rather than creation, retrieval, or modification. However, it doesn't specify what type of post (e.g., WordPress post) or provide additional context about the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing post ID), exclusions (e.g., when not to delete), or comparisons to related tools like wp_post_update or wp_post_get. The agent must infer usage from the tool name alone, which is insufficient for informed decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single post by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Post ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether authentication is required, what happens with invalid IDs (e.g., error vs. null response), rate limits, or response format. This leaves significant behavioral aspects undocumented for a tool that retrieves data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the core purpose with zero wasted language. Every word earns its place, making it easy for an agent to parse quickly while scanning available tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what data is returned (post object fields), error handling, authentication requirements, or how it differs from similar tools. The agent would need to guess important contextual details about this tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'id' documented as 'Post ID' in the schema. The description adds no additional parameter semantics beyond what's already in the structured schema, so it meets the baseline for adequate but unenriched parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a single post by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like wp_post_list or wp_post_create, which would require explicit comparison to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like wp_post_list (for multiple posts) or wp_post_update (for modifying posts). It lacks context about prerequisites, error conditions, or typical use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List posts of any type
| Name | Required | Description | Default |
|---|---|---|---|
| post_type | No | Post type (post, page, product, etc.) | |
| count | No | Number of posts to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'List posts of any type' implies a read-only operation but doesn't specify whether this requires authentication, has rate limits, returns paginated results, or includes metadata. For a listing tool with zero annotation coverage, this leaves significant behavioral gaps about what the agent can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words ('List posts of any type'), with zero wasted language. It's front-loaded with the core action and resource. Every word earns its place by specifying the verb, resource, and scope (any type), making it efficient and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a listing operation that likely returns structured data, the description is incomplete. It doesn't explain what information is returned (e.g., post titles, IDs, dates), whether results are paginated, or if there are default behaviors when parameters aren't provided. For a tool with two parameters and no structured output documentation, the description should provide more context about the operation's results and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters (post_type and count). The description adds no additional parameter semantics beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List posts of any type' clearly states the verb ('List') and resource ('posts'), making the purpose immediately understandable. It distinguishes from siblings like wp_post_get (retrieve single post) and wp_post_create/update/delete (write operations). However, it doesn't specify whether this includes all post types by default or requires explicit filtering, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like wp_post_get (for single posts), wp_plugin_list (for listing plugins), or wp_theme_list (for themes). There's no context about prerequisites, limitations, or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing post
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Post ID | |
| post_title | No | New title | |
| post_content | No | New content | |
| post_status | No | New status: draft, publish, pending, private |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update an existing post' implies a mutation operation, but it doesn't disclose critical behavioral traits: whether it requires specific permissions, if updates are reversible, what happens to unspecified fields (partial vs. full updates), error handling, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Update an existing post') that is front-loaded with the core action. There is zero waste—every word earns its place by conveying the essential purpose without unnecessary elaboration. It's appropriately sized for a straightforward update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects (e.g., permissions, side effects), usage context, or return values. While the schema covers parameters well, the description fails to provide the additional context needed for safe and effective tool invocation, especially for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (id, post_title, post_content, post_status) with clear descriptions. The tool description adds no additional meaning beyond what's in the schema—it doesn't explain parameter interactions, default behaviors, or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing post' clearly states the verb ('Update') and resource ('an existing post'), making the purpose immediately understandable. It distinguishes from siblings like wp_post_create (create) and wp_post_delete (delete), though it doesn't explicitly differentiate from wp_post_get or wp_post_list. The description is specific but could be more precise about what aspects can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing post ID), when not to use it (e.g., for creating new posts), or how it differs from similar tools like wp_post_create or wp_post_get. The agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flush rewrite rules (fix permalink issues)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool flushes rewrite rules to fix permalinks, implying a mutation or maintenance action, but doesn't disclose behavioral traits like side effects, permissions needed, or impact on site performance, which is a significant gap for a tool with potential system changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and purpose without any wasted words. It's appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that likely modifies system settings (rewrite rules), the description is incomplete. With no annotations, no output schema, and minimal behavioral disclosure, it fails to provide enough context for safe or effective use, such as what 'flush' entails or what happens after execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add param semantics beyond the schema, but with no parameters, a baseline of 4 is appropriate as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('flush rewrite rules') and the purpose ('fix permalink issues'), providing a specific verb and resource. However, it doesn't explicitly differentiate from siblings like wp_cache_flush or wp_search_replace, which might also address site issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions fixing permalink issues, but it doesn't specify prerequisites, exclusions, or recommend other tools for related problems, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Gutenberg block skeleton
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Block slug | |
| plugin | No | Plugin to add block to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a creation/generation action but lacks details on side effects (e.g., file creation, overwriting), permissions required, or output format. This is inadequate for a tool that likely modifies the filesystem or plugin structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of generating code skeletons (likely involving file creation and plugin integration), no annotations, and no output schema, the description is insufficient. It does not cover behavioral aspects, output details, or error conditions, leaving significant gaps for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (slug and plugin). The description does not add any meaning beyond what the schema provides, such as explaining the format of the slug or what 'plugin' refers to in context. Baseline 3 is appropriate as the schema handles the documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and the resource ('Gutenberg block skeleton'), making the purpose understandable. It distinguishes from some siblings like wp_scaffold_plugin and wp_scaffold_theme by specifying 'block', but could be more specific about what 'skeleton' entails compared to other block-related tools that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as needing a plugin context, or contrast with other scaffolding tools like wp_scaffold_plugin, leaving the agent to infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a plugin skeleton
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Plugin slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Generate' implies creation/writing, but the description doesn't disclose behavioral traits like whether this creates files locally, requires specific permissions, has side effects, or what the output looks like. For a tool that likely creates WordPress plugin files, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words with zero wasted language. It's front-loaded with the core purpose and appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that likely creates files (implied by 'generate'), the description is incomplete. It doesn't explain what a 'plugin skeleton' includes, where files are created, or what happens on success/failure. For a scaffolding tool, more context about the generated structure would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'slug' documented as 'Plugin slug'. The description adds no additional parameter semantics beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate a plugin skeleton' clearly states the action (generate) and resource (plugin skeleton), which is specific enough to understand the tool's function. It distinguishes from most siblings like plugin management tools (activate, deactivate, install) but doesn't explicitly differentiate from other scaffold tools (wp_scaffold_block, wp_scaffold_theme).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or how it differs from related tools like wp_scaffold_block or wp_scaffold_theme. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a child theme skeleton
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Theme slug | |
| theme_name | No | Theme display name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Generate' implies a write operation, but the description doesn't specify what gets created (files, directories), whether it overwrites existing files, what permissions are needed, or what the output looks like. This leaves significant gaps for a tool that modifies the filesystem.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core functionality and appropriately sized for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that generates files (implied by 'scaffold'), the description is incomplete. With no annotations and no output schema, it doesn't explain what gets created, where files are placed, or what the tool returns. This is inadequate for understanding the tool's full behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters ('slug' and 'theme_name'). The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and the resource ('child theme skeleton'), providing specific functionality. However, it doesn't explicitly differentiate from sibling tools like 'wp_scaffold_block' or 'wp_scaffold_plugin', which also generate code skeletons but for different WordPress components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over other theme-related tools like 'wp_theme_install' or 'wp_theme_create', nor does it specify prerequisites or typical use cases for child theme scaffolding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and replace in database
| Name | Required | Description | Default |
|---|---|---|---|
| old_value | Yes | String to search for | |
| new_value | Yes | Replacement string | |
| dry_run | No | Preview changes without applying (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'search and replace in database,' implying a potentially destructive write operation, but doesn't clarify risks, permissions needed, or the impact of the dry_run parameter. This is inadequate for a tool that modifies database content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a database search-and-replace operation, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, or return values, leaving significant gaps for the agent to understand the tool fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters (old_value, new_value, dry_run) with descriptions. The description adds no additional meaning beyond what the schema provides, such as scope or constraints, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search and replace in database' clearly states the verb ('search and replace') and resource ('database'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like wp_db_query or wp_db_export, which could also involve database operations, so it lacks sibling differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as when to use wp_db_query for custom queries instead. This leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate a theme
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Theme slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Activate a theme' implies a mutation operation, but it doesn't disclose behavioral traits like required permissions, whether activation affects site appearance immediately, potential downtime, or error conditions. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Activate a theme' is extremely concise—three words that directly convey the core function. There's no wasted language, repetition, or unnecessary elaboration. It's front-loaded with the essential action, making it efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what 'activate' entails operationally, what happens on success/failure, or return values. For a tool that changes system state, more context is needed to use it effectively and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'slug' documented as 'Theme slug'. The description doesn't add any parameter semantics beyond what the schema provides. According to scoring rules, with high schema coverage (>80%), the baseline is 3 even with no param info in description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Activate a theme' clearly states the action (activate) and resource (theme) with a specific verb. It distinguishes from siblings like wp_theme_list (list themes) and wp_theme_install (install themes), but doesn't explicitly differentiate from wp_plugin_activate (activate plugin) which shares the same verb pattern. The purpose is clear but sibling differentiation could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., theme must be installed), when not to use it (e.g., if theme is already active), or refer to related tools like wp_theme_list to check current themes. The description offers no context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a theme
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Theme slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Delete' implies a destructive mutation, but the description doesn't specify whether this is irreversible, requires admin permissions, affects site functionality, or has confirmation steps. For a destructive operation with zero annotation coverage, this is a significant gap in safety and behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and resource, making it immediately scannable and efficient. This is an example of optimal brevity for simple tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like what happens after deletion (success/failure indicators), whether the theme must be inactive first, or potential side effects. The combination of destructive operation and minimal description creates significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'slug' fully documented in the schema. The description adds no parameter information beyond what the schema provides, which is acceptable given the high schema coverage. The baseline score of 3 reflects adequate but minimal value addition from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a theme' clearly states the action (delete) and resource (theme), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like wp_theme_activate or wp_theme_install, which would require more specific language about what distinguishes deletion from other theme operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites (e.g., theme must be inactive), exclusions (e.g., cannot delete active theme), or related tools (e.g., wp_theme_list to identify themes first). This leaves the agent without context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a theme from wordpress.org
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Theme slug | |
| activate | No | Activate after install |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action. It doesn't cover critical aspects like whether this requires administrative permissions, if it's idempotent (e.g., handling already-installed themes), potential side effects (e.g., affecting site performance), or error conditions (e.g., invalid slug). This leaves significant gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, front-loading the core action and resource. It's appropriately sized for a simple tool, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a write operation (theme installation) with no annotations and no output schema, the description is incomplete. It lacks details on permissions, error handling, return values, or interactions with sibling tools (e.g., 'wp_theme_activate'), which are essential for an agent to use this tool correctly in a WordPress context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('slug' and 'activate') clearly documented in the schema. The description adds no additional parameter semantics beyond implying the theme source ('from wordpress.org'), which is minimal value. This meets the baseline score of 3 for high schema coverage without compensating detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Install') and target resource ('a theme from wordpress.org'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'wp_theme_activate' or 'wp_plugin_install', which would require more specific language about theme installation versus activation or plugin installation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin access), when not to use it (e.g., for custom themes not on wordpress.org), or direct alternatives like 'wp_theme_activate' for already-installed themes, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all installed themes
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but doesn't disclose behavioral traits such as whether this is a read-only operation, what the output format looks like, if there are any permissions required, or if it includes inactive themes. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and no output schema, the description is incomplete. It doesn't explain what the output includes (e.g., theme names, statuses, versions) or any behavioral context. For a tool with no structured data to rely on, this minimal description leaves too much undefined for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is given as it handles the zero-parameter case correctly without unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all installed themes', making the purpose immediately understandable. It doesn't differentiate from sibling tools like wp_plugin_list or wp_menu_list, which follow the same 'list' pattern, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like wp_theme_activate or wp_theme_install, or explain scenarios where listing themes is appropriate versus other theme-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new user
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Username | |
| Yes | Email address | ||
| role | No | User role (subscriber, editor, administrator, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create a new user' implies a write operation, but it doesn't disclose critical behavioral traits such as required permissions, whether the operation is idempotent, what happens on duplicate usernames/emails, or any rate limits. This leaves significant gaps for an agent to understand how to use it safely and effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. No structural improvements are needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a user creation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral aspects (e.g., permissions, error handling), output format, or how it fits into the broader WordPress context. For a mutation tool with three parameters, more completeness is needed to guide an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (username, email, role) with basic descriptions. The description adds no additional semantic context beyond what's in the schema, such as format requirements (e.g., email validation) or role implications. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new user' clearly states the action (create) and the resource (user), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like wp_user_list, but the verb 'create' inherently distinguishes it from read-only operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., admin permissions), when it's appropriate (e.g., for adding users to a WordPress site), or what distinguishes it from similar tools like wp_post_create or wp_menu_create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all users
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List all users' implies a read-only operation, but it doesn't specify details like pagination, sorting, filtering, or potential rate limits. For a tool with zero annotation coverage, this leaves key behavioral traits unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('List all users') that is front-loaded and wastes no words. It directly communicates the core function without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the list includes (e.g., user fields, format) or behavioral aspects like performance or errors. For a tool in a server with many siblings, more context is needed to ensure proper agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description doesn't add parameter details, but with no parameters, this is acceptable, and it doesn't contradict the schema, earning a baseline score above 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all users' clearly states the verb ('List') and resource ('users'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like wp_user_create, but the action is specific enough to avoid vagueness or tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like wp_user_create or wp_post_list. It lacks context about prerequisites, such as authentication or permissions needed to list users, which is a significant gap for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0wp_cache_flushwp_cli_rawwp_core_check_updatewp_core_versionwp_db_exportwp_db_querywp_media_importwp_menu_createwp_menu_item_addwp_menu_listwp_option_getwp_option_updatewp_plugin_activatewp_plugin_deactivatewp_plugin_deletewp_plugin_installwp_plugin_listwp_plugin_searchwp_post_createwp_post_deletewp_post_getwp_post_listwp_post_updatewp_rewrite_flushwp_scaffold_blockwp_scaffold_pluginwp_scaffold_themewp_search_replacewp_theme_activatewp_theme_deletewp_theme_installwp_theme_listwp_user_createwp_user_listEvery tool has a clearly distinct purpose targeting specific WordPress resources and actions. For example, wp_post_create, wp_post_update, and wp_post_delete are clearly differentiated for post management, and there are no overlapping tools that could cause confusion.
All tools follow a consistent wp_ prefix with verb_noun pattern (e.g., wp_post_create, wp_plugin_activate). The naming is uniform throughout, using snake_case consistently without any deviations or mixed conventions.
With 34 tools, the count is borderline high for a WordPress CLI server. While it covers many aspects comprehensively, it may feel heavy and could potentially overwhelm agents with its breadth, though each tool serves a specific purpose.
The tool set provides complete coverage for WordPress management, including core, plugins, themes, posts, users, database, and scaffolding. It supports full CRUD operations for key resources like posts and plugins, with no obvious gaps in the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
WordPress MCP server: publish posts, AI images, SEO and full site management, self-hosted
WordPress MCP server: generate SEO posts, AI images, autoblog & WooCommerce on your self-hosted site
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mvtandas/wp-cli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
