wpagent-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.4
Disambiguation4/5
Most tools follow a clear resource+action split (plugin, content, order, comment, media, user), but a few overlap: wp_site_info vs wp_site_health, wp_get_content vs wp_elementor_get_page, and wp_cli_execute can replicate many dedicated tools. Descriptions generally prevent misselection.
Naming Consistency4/5
The overwhelming pattern is wp_<domain>_<verb>_<noun> in snake_case, which is predictable and easy to navigate. Deviations include noun-only names like wp_woocommerce_shipping_zones, wp_woocommerce_payment_gateways, and wp_elementor_widget_types, plus nominal names like wp_site_info and wp_site_health.
Tool Count2/5
With 58 tools, this is far beyond the typical well-scoped MCP surface and creates a large namespace for an agent to navigate. While each subdomain is heavily covered, the count is excessive for a single server and many tools could be consolidated or exposed as subcommands.
Completeness3/5
The server covers a broad range of domains with solid CRUD cycles for content, plugins, media, options, and comments. However, notable lifecycle gaps remain: themes have no update/delete, WooCommerce coupons and tax rates have no update/delete, and users have no delete operation.
Average 3.7/5 across 58 of 58 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that a new user is created and mentions optional fields, but does not disclose behavior around duplicate usernames/emails, password auto-generation, whether an email notification is sent, required permissions, or side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. It is appropriately concise, though it does not add any structured detail that could help an agent beyond the minimum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 7 parameters, no annotations, and no output schema, the description is under-specified. It does not explain what happens on success or failure, what permissions are needed, or what the return value is. The schema covers parameters, but the overall context is incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has a description. The tool description adds modest grouping ('optional role/name fields') but no deeper meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new WordPress user'), and names the key inputs (username, email, optional role/name fields). It distinguishes itself from related operations like wp_update_user and wp_get_user through the phrase 'Create a new', but it does not explicitly call out sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as wp_update_user, wp_get_user, or wp_list_users. The only usage signal is the word 'Create' and 'new', which implies creating rather than updating or reading, but there is no explicit context, prerequisites, or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states that the tool can enable, disable, or configure a gateway, but does not disclose consequences such as partial updates, merging behavior of options, requirement that the gateway already exists, or any side effects on WooCommerce settings. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with the action front-loaded. It is concise and free of fluff. However, it omits essential context that could be integrated without bloating the text, so it is efficient but not a model of completeness-plus-concision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, a nested options object, and no output schema or annotations, the description is insufficiently complete. It does not explain how to obtain a valid gateway ID, what 'configure' entails for the options object, whether the update is partial or full, or what success/failure looks like. The sibling listing tool exists but is not referenced, so an agent must infer the necessary prerequisite steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no field-level meaning beyond the schema's own parameter descriptions, but because the schema already documents all five parameters clearly, the description does not need to compensate. It neither harms nor meaningfully enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Enable/disable or configure') and a clear resource ('WooCommerce payment gateway'). It is unambiguous about the tool's function and implies per-gateway targeting via ID, distinguishing it from broader settings tools. However, it does not explicitly call out the sibling listing tool wp_woocommerce_payment_gateways, so it misses the full sibling differentiation that would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as wp_woocommerce_payment_gateways (for reading gateways), wp_woocommerce_update_settings, or other configuration tools. The description does not mention prerequisites like needing an existing gateway ID, nor does it state when this tool is the right choice. No exclusions or conditional context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects, but it only says 'Update' and lists fields. It does not mention whether partial updates are allowed, what happens if the user ID does not exist, whether permissions are required, or what the return value is. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and resource, then lists the relevant field categories. It avoids unnecessary wording and is easy to parse, though it could have included slightly more operational guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool mutates data, has no annotations, and has no output schema, so the description alone must provide sufficient context. It explains what can be updated but not the effects of a partial update, error behavior for invalid IDs, required permissions, or what response the agent should expect. This leaves important gaps for a 6-parameter mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 each parameter clearly. The description adds a helpful grouping by calling email, role, and name fields, but it does not provide additional semantic detail beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update an existing WordPress user' and enumerates the editable fields ('email, role, name fields'). This clearly distinguishes it from read-only tools like wp_get_user and wp_list_users, though it does not explicitly differentiate it from wp_create_user beyond the word 'existing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing user' implies this tool is for modifying an already-created user rather than creating one, which is useful context. However, there is no explicit statement about when to choose this tool over wp_create_user or other user-related tools, and no mention of prerequisites such as the user needing to exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Create a new' signals a write operation, but it does not mention persistence, permission requirements, duplicate handling, side effects on checkout, or whether the rate is immediately active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words and the core action is front-loaded. It is concise, though it sacrifices useful context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too thin for a 7-parameter mutation tool. It does not state what the tool returns, how to confirm success, whether the rate applies immediately, or what prerequisites exist beyond the schema parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 7 parameters with 100% coverage, so the baseline is 3. The description adds minimal parameter-level insight beyond pointing at country/state scope, which the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a new WooCommerce tax rate.' It also adds scope ('for a specific country/state'), which makes the tool's purpose concrete and distinguishable from sibling tools like wp_woocommerce_list_tax_rates or wp_woocommerce_create_coupon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but gives no guidance on when to choose it over alternatives, nor any exclusions. There is no mention of checking existing tax rates first, verifying WooCommerce status, or when create_coupon or update_settings would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'Update' which implies a write operation, but does not explain side effects (e.g., whether it merges with existing settings), permission requirements, idempotency, or what the response contains. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus an example, which is appropriately concise. The key information is front-loaded and the example clarifies the expected format without additional fluff. However, it could be slightly more structured by separating the action from the example, but this is a minor point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a write operation with no annotations or output schema, the description should be more complete. It does not mention return values, error conditions, or the impact on existing settings. It also does not clarify whether this tool is specifically for WooCommerce options as opposed to general options, though the name implies it. The example helps but does not compensate for the lack of behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the settings object and the requirement that keys start with 'woocommerce_'. The description adds an example with concrete key-value pairs, which is helpful but not beyond the schema's stated format. Since schema coverage is 100%, the baseline of 3 is appropriate; the example provides marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update WooCommerce settings') and the resource type. It distinguishes itself from sibling tools like wp_woocommerce_get_settings (which reads settings) and wp_set_options (which updates generic WordPress options) by specifying the WooCommerce scope. The example keys further clarify the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as wp_woocommerce_get_settings or wp_set_options. It does not mention any prerequisites (e.g., checking current settings first) or scenarios where a different tool would be more appropriate. The usage is only implied by the tool name and the example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it 'Delete(s)' but does not disclose that this is a destructive, likely irreversible action, whether the option must exist, or what happens if the key is not found. The description is factual but omits any side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and resource without wasted words. It is appropriately sized for a simple delete operation and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema and no annotations, the description is minimal. It fails to mention expected return values, error behavior, or the irreversibility of the operation. An agent would lack context on what constitutes success or failure, making the tool incomplete from an operational standpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters (only 'key') and describes it as 'Option key to delete'. The description adds no additional meaning beyond that, such as format constraints or case sensitivity. Since schema coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('WordPress option'), and the specific mechanism ('by key'). It distinguishes from sibling tools like wp_get_option and wp_set_options by specifying deletion, and from wp_delete_content and wp_delete_plugin by naming 'option' as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 that this is the destructive counterpart to wp_set_options, nor any conditions that should prompt its use (e.g., when an option is no longer needed). There is no discussion of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the 'active' precondition but does not explain side effects, reversibility, permission requirements, or what happens when the plugin is already inactive. For a mutating tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description conveys the core action and the parameter is fully documented in the schema. However, the absence of annotations and output schema leaves behavioral and return-value context unaddressed, and the description does not clarify how deactivation differs from deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the plugin parameter is fully described ('Plugin file path, slug, or name'). The description adds no additional meaning about parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (deactivate) and resource (WordPress plugin), with the qualifier 'active' defining the applicable state. It distinguishes itself from siblings like wp_activate_plugin and wp_delete_plugin through the unique verb and target condition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as wp_delete_plugin or wp_activate_plugin. There are no exclusions, prerequisites, or routing hints; usage is only implied by the action name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only restates the destructive action and does not mention that deletion may be reversible via trash, that force=true is permanent, or what side effects may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single direct sentence with no filler. The essential action and resource are front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with complete schema coverage, the description is minimally viable. However, with no annotations and no output schema, it omits important context such as default trash behavior and the irreversibility of force=true.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 id and force. The description adds no additional parameter-level meaning, which is acceptable but not value-adding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete'), a precise resource ('media file'), and the location ('WordPress media library'). It is clearly distinguishable from sibling delete tools like wp_delete_plugin and wp_delete_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of conditions like trashing or permanence. Among a large sibling list, an agent must infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It conveys a read operation but does not explain what 'detailed information' includes, whether special permissions are needed, or how errors are handled. The description adds little beyond the retrieval intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action and resource, making it immediately scannable and appropriately sized for a tool with one simple parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The single parameter is fully covered by the schema, and the description is minimally sufficient for a low-complexity read tool. However, there is no output schema and no annotation, so the vague phrase 'detailed information' leaves the response shape and behavioral edge cases unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the 'id' parameter. The description's 'by ID' phrasing merely reinforces the schema and adds no new constraints, format details, or semantic distinctions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get'), resource ('WordPress user'), and selection criterion ('by ID'). It clearly distinguishes this from sibling tools like wp_list_users or wp_update_user by indicating it targets a single known user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as wp_list_users or wp_get_comment. The only implied usage is that you need a user ID, but no conditions, exclusions, or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'List comments,' which connotes a read operation, but it does not explicitly state that it is non-destructive, whether any permissions are needed, or what the response shape looks like. With zero annotation support, this is a noticeable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately identifies the verb and resource, then lists the filtering options compactly. There is no redundant filler, and every clause earns its place despite only restating schema-visible info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool whose 5 optional parameters are fully described in the schema, the one-sentence description is adequate. However, with no annotations and no output schema, it leaves some ambiguity around the return structure and any ordering or permission constraints, so it is minimally viable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 every parameter including the allowed status values, defaults, and meaning of search and post_id. The description merely restates these dimensions without adding extra semantic detail, meeting the baseline of 3 for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('comments'), and enumerates the filtering dimensions (status, post ID, search). It naturally distinguishes from the singular 'wp_get_comment' sibling by being a plural listing operation, so an agent can identify the tool's role without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives like wp_get_comment, wp_update_comment_status, or wp_delete_comment. The description only implies usage through the word 'List' and the optional filters; there are no explicit conditions, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It does convey that the operation is a read-only listing with optional filtering and pagination, but it does not mention response format, permissions, default ordering, or any edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that is front-loaded with the action and resource and covers the key optional dimensions without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus schema is sufficient for a basic call, but the lack of annotations and absence of an output schema leaves response shape, defaults, and edge-case behavior undisclosed. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 six parameters. The description mentions role, search, and pagination, but adds no semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('WordPress users'), and names the major filtering dimensions. It is unambiguous, but it does not explicitly differentiate itself from the sibling wp_get_user or other list tools, so it stops short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives such as wp_get_user, wp_list_comments, or other list operations. The intended usage is somewhat implied by the name, but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 creates content (a write/creation operation), but provides no details on permissions, side effects (e.g., immediate visibility on publish), or consequences of the action. No extra behavioral context is offered beyond the basic verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff, front-loaded with the purpose. For a tool with 21 parameters, keeping the description short is appropriate since the schema handles parameter details. It is concise but could arguably add a tiny bit more context without becoming wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (21 parameters, multiple post types, WooCommerce variations), the description covers the high-level purpose and the WooCommerce special case, but omits important details like the requirement to set type='product' for WooCommerce fields, the default status (draft), and what the return value contains. The schema compensates for some gaps, but the description leaves room for confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description highlights the WooCommerce-specific parameters (prices, SKU, stock), but these are also described in the schema with the 'WooCommerce:' prefix, so the description adds minimal new meaning. It groups them but does not clarify usage beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'new WordPress post, page, or product', which immediately distinguishes it from update, list, and delete operations. It also mentions WooCommerce product specifics (prices, SKU, stock), adding specificity without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Create' implies this tool is for new content, but the description does not explicitly reference sibling tools like wp_update_content or wp_list_content, nor does it state when to use this instead of those. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description carries the burden of behavioral disclosure. 'Permanently delete' clearly communicates destructiveness and irreversibility, but it does not mention permissions, side effects on replies, or failure behavior. This is sufficient but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant wording. The key behavioral trait, 'permanently', is front-loaded, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool, the description is nearly complete: the agent knows the required id and that the deletion is permanent. Minor gaps remain, such as the return value and whether related replies are also deleted, but these are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the only parameter, 'id', with the description 'Comment ID', so schema coverage is 100%. The tool description adds no additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('delete') and resource ('comment'), and the qualifier 'permanently' signals this is a hard delete rather than a status change or trash operation. It does not explicitly name a sibling, but the wording is clear and helps differentiate it from wp_update_comment_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like wp_update_comment_status, nor any prerequisites such as retrieving the comment ID first. Usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only restates the basic operation and gives no information about return format, handling of missing keys, or any limits, leaving the agent to guess what happens when a requested option does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core operation is front-loaded, and the only additional sentence provides direct instruction on the input format. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read tool, but with no output schema and no annotations, the description should have explained at least the return shape or behavior for nonexistent keys. It does neither, leaving a meaningful gap in what an agent needs to properly interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already documents the comma-separated key format with an example. The description adds no new parameter semantics beyond reinforcing what the schema states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('WordPress options'), and the batch scope ('multiple... at once'), which directly distinguishes it from the sibling wp_get_option (singular). It is specific and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'at once' and 'multiple' imply this tool is for retrieving several options rather than one, giving some usage context. However, it never explicitly names alternatives like wp_get_option or states when NOT to use this tool, so guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description states the basic action and filter options but omits crucial behavioral traits such as pagination behavior, default ordering, response format, or any rate-limiting considerations. For a tool that lists potentially many items, this lack of detail could lead to incorrect assumptions about the return payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the primary action. It efficiently communicates the tool's core function and includes relevant examples without unnecessary verbosity. The structure is clear and to the point, though it could benefit from a brief note on usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of full schema descriptions, the description covers the essentials but leaves gaps. There is no output schema, so the description should arguably mention what the response contains (e.g., array of media objects with IDs, URLs, etc.) or how results are ordered. Without this, an agent might not know what to expect from the call, though the core capability is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with descriptions (100% coverage), so the baseline is 3. The description adds minor value by providing examples of MIME types ('image/jpeg, video/mp4, etc.') and clarifying that search is by name/filename. This is helpful but not significantly beyond the schema, which already explains each parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'media files', and the scope 'WordPress media library'. It also specifies two key capabilities (filtering by MIME type and searching by name) which immediately distinguish it from sibling tools like wp_get_media (single retrieval) or wp_upload_media (upload). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing media but does not explicitly mention when to use this tool versus alternatives. It notes filtering and search capabilities, which suggests typical browsing scenarios, but there is no explicit direction such as 'use wp_get_media to fetch a single item' or 'use wp_delete_media to remove'. The guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It communicates that this is a create/write operation, but it does not mention permissions, duplicate-code behavior, whether the operation persists immediately, or what response/return value the agent should expect. For a mutation tool with no annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It front-loads the action and resource immediately, making the tool's purpose quickly scannable. It earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema is rich and covers parameters, there is no output schema and no annotation context. The description does not mention return behavior, required-field expectations beyond the schema, default behaviors, or constraints such as uniqueness of the coupon code. For a 10-parameter create tool, the description alone is not enough for an agent to invoke it with full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already explaining its meaning (e.g., 'discount_type', 'usage_limit', 'expiry_date'). The description adds only the generic phrase 'with discount rules' and no parameter-specific detail beyond the schema. The baseline of 3 applies because the schema handles parameter documentation well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a clear resource ('a new WooCommerce coupon'), and the domain ('discount rules'). This is immediately distinguishable from sibling tools like wp_woocommerce_list_coupons and wp_woocommerce_create_tax_rate, so an agent can identify this as the coupon creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is the tool to call when creating a new WooCommerce coupon. However, it provides no explicit when/when-not guidance or references to alternatives, such as when to use wp_woocommerce_list_coupons instead. Usage context is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'List' and gives output fields. It does not state that the operation is read-only, how pagination works, what permissions are needed, or whether 'all' means one page or multiple pages given the per_page default of 20.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, naming action, resource, and output content. It could have added a short pagination qualifier to remove ambiguity, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, this is mostly adequate: the resource, output fields, and default are covered between description and schema. However, without annotations or an output schema, it lacks explicit response-shape, authentication, and pagination behavior, so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents per_page with a default, so the description adds little parameter-level meaning. 'List all coupons' hints at pagination scope but not precisely enough to raise the score above the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('List all WooCommerce coupons') and lists the meaningful output dimensions (discount types, amounts, usage stats). This is enough for an agent to distinguish it from sibling tools such as wp_woocommerce_create_coupon or wp_woocommerce_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied by the verb and resource; there is no explicit statement about when to prefer this over wp_woocommerce_stats or wp_woocommerce_create_coupon, nor any exclusion criteria. It is minimally usable but leaves the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'List' reasonably implies a read-only operation, which is the main behavioral trait for a zero-parameter enumerator, but the description does not explicitly confirm no side effects or describe what the response contains. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler: the verb, resource, and scope appear first, and the parenthetical examples are the only addition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with no parameters and no annotations, the description covers what the tool acts on and the scope. The only gap is the return format, which is not stated and cannot be inferred from an output schema because none exists — though a 'list' verb makes the collection return self-evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the rubric sets a baseline of 4 for that case. Nothing is left undocumented; the description's clarification of what counts as a template adds useful semantic color even with no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List'), resource ('saved Elementor templates'), and scope ('all'), with a parenthetical enumerating template kinds (sections, pages, headers, footers) that sharpens the resource. It is clearly distinct from siblings like wp_list_content, but it does not explicitly name or differentiate from any sibling, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Nearby siblings such as wp_elementor_get_page, wp_elementor_widget_types, and wp_list_content overlap conceptually, and the description offers no selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It richly discloses the data structure (section/column/widget hierarchy, elType, widgetType, id format, settings, elements array). However, it never states that this is a full-replacement overwrite operation, what happens to the existing tree, error behavior, or permission requirements. The structural detail is strong, but mutation semantics are inferred rather than stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with its purpose, followed by the payload structure and finally the sequencing guidance. It is efficiently written with no filler or redundancy. The dense structural explanation, while valuable, is packed tightly into the middle of the paragraph, which slightly reduces scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with nested objects and no output schema or annotations, the description covers the input payload structure thoroughly. However, it omits what a successful call returns, the overwrite/destructive nature of the update, and validation constraints. For a tool this complex, the missing return behavior and mutation semantics are notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, setting a baseline of 3. The description adds significant meaning beyond the schema for the 'elements' parameter by detailing the exact element hierarchy, required fields (elType, id, settings, elements), id format (8-char hex), and valid widgetType values. This substantially enriches the 'arrays of sections' schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update the Elementor data for a page/post.' This clearly identifies the tool's action and target. It implicitly differentiates from wp_elementor_get_page (read vs. update) but never distinguishes itself from the generic sibling wp_update_content, leaving some ambiguity about which update tool handles Elementor-specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives one actionable directive: 'Always read the page first with wp_elementor_get_page to understand the current structure.' This is useful sequencing guidance but does not explain when to prefer this tool over wp_update_content, nor when NOT to use it, nor any prerequisites beyond reading first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 disclosing behavioral traits. It only states the basic action and optional activation; it does not mention mutational side effects, required permissions, behavior if the plugin already exists, installation failure modes, or what the response contains. For a state-changing tool this is a meaningful transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the action, resource, source, and optional behavior with zero filler. It is concise and every phrase contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema or annotations, the description covers the essential inputs and primary behavior. However, it omits practical details an agent might need for correct invocation, such as what happens when the plugin is already installed and whether the operation returns a confirmation or error. The description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'slug' and 'activate' have descriptive text with examples and a default. The description adds context about the source repository and the option to activate, but this largely overlaps with the schema, so it does not significantly enhance parameter understanding beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Install') and resource ('plugin from the WordPress.org repository by its slug'), clearly stating the tool's core function. It also mentions the optional activation behavior, which distinguishes it from wp_activate_plugin. This makes the purpose unambiguous even without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you have a WordPress.org plugin slug and want to install it), and the optional activation note clarifies that you may not need a separate activate step. However, it does not explicitly name alternatives or state when NOT to use it, such as pointing to wp_search_plugins for finding a slug or wp_activate_plugin for activating an already-installed plugin.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. 'Search' implies a read-only operation against an external directory, which is useful, but it does not describe pagination, network dependency, or result-shape behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. The key resource and action are front-loaded before the result clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity search tool with fully documented parameters, so the one-sentence description is mostly sufficient. It would be slightly stronger with an explicit note that results come from the live WordPress.org API and what fields are returned, but no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so query and per_page are already documented structurally. The description only restates query matching and adds no additional meaning or usage details for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action ('Search'), resource ('WordPress.org theme directory'), and filter ('matching a query'). It does not explicitly contrast with sibling tools like wp_list_themes, but the external-directory wording makes the distinction reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use it when you need to find themes in the remote WordPress.org directory. However, it does not state when not to use it, nor does it mention wp_list_themes for installed themes or wp_search_plugins for plugins, so alternatives are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It clearly states the mutating upload action, requires base64 data, and adds a 10MB size limit. However, it does not mention response/return behavior, permissions, or failure handling, leaving meaningful operational gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action is front-loaded, and the maximum size constraint is a valuable addition without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple upload tool, the description is nearly complete: required inputs, encoding, and size limits are covered, and the schema documents the optional fields and title default. The only notable gap is that no output/return behavior is described, but this is minor for an upload operation where the side effect is the main purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the schema with 100% coverage, so the baseline is 3. The description adds the 10MB file size cap and reinforces base64 encoding, which is useful but only marginal beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (upload), a clear resource (WordPress media library), and the input format (base64), making it instantly distinguishable from sibling media tools like wp_list_media, wp_get_media, and wp_delete_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, and no exclusions or fallback tools are mentioned. The uniqueness of the upload action is implied by the name, but the description itself offers no selection help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose the returned metric set and implies a read-only operation via 'Get', but it does not explicitly state read-only behavior, authentication requirements, or response format/aggregation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, then the key output metrics. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter tool with no output schema, the description covers what the tool returns and what the period parameter means. It is slightly light on explicit side-effect/read-only framing, but the simplicity of the tool keeps the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the schema already documenting period values and the default of 'month'. The description's 'for a given period' adds no semantic detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('WooCommerce sales statistics') and enumerates the exact metrics returned (total revenue, order count, average order value, customer count). This clearly distinguishes it from sibling tools like wp_woocommerce_status or wp_woocommerce_list_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over related WooCommerce siblings (e.g., list_orders, get_order, status). The phrase 'for a given period' implies a time-window use case, but it never states exclusions, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It communicates the core action but does not explain what happens if the plugin is already active, if the plugin is missing, whether activation can partially fail, or what the command returns. For a state-changing tool, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences with no filler. The action and target are front-loaded, and the identifier options are presented immediately after, making the content easy to scan and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the description covers what the plugin argument can be. However, with no output schema and no annotations, the absence of any note about return values, error conditions, or idempotency leaves the definition only minimally complete for an agent that needs to verify successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameter as 'Plugin file path, slug, or name', and the description adds concrete examples for each form. This enrichment reduces ambiguity and helps the agent correctly format the 'plugin' argument, going slightly beyond the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Activate') on a specific resource ('installed WordPress plugin'), which clearly distinguishes it from siblings like wp_deactivate_plugin, wp_install_plugin, and wp_delete_plugin. It also covers the accepted identifier forms, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'installed' implies the plugin must already be installed, which gives some usage context. However, it does not explicitly state when to use this tool instead of wp_install_plugin or wp_deactivate_plugin, nor does it mention any exclusions or prerequisites beyond installation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'Switch' and repeats the input requirement, without mentioning side effects, persistence, prerequisites such as the theme being installed, or what the response will look like. This is a mutating operation that could affect the entire site, so more transparency is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the parameter guidance is immediately useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no nested objects), but the absence of an output schema and annotations leaves gaps: the description does not state expected return data or the prerequisite that the theme must already be installed. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the lone parameter ('slug') with an example, and the description merely restates 'theme slug (directory name)'. With 100% schema coverage, the description adds no meaningful semantic value beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Switch') and resource ('active WordPress theme'), making the tool's purpose immediately clear. It also differentiates from sibling tools like wp_list_themes, wp_search_themes, and wp_install_theme by targeting the active theme rather than discovery or installation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need to change the currently active WordPress theme. It does not explicitly name alternatives or exclusion conditions, but the active-theme framing implies the theme should already be installed, which is sufficient guidance for selecting this tool over install/search/list siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for behavioral disclosure. It only restates the core operation (get by key) and provides examples; it does not state that this is a read-only operation, what happens if the key is missing, how missing vs. false values are represented, or whether any authentication or capability is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the purpose precisely, and the second offers useful examples. There is no filler or repetition, making it compact and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and one-parameter, so the description is largely sufficient for basic invocation. However, with no output schema and no annotations, the description does not cover behavior for missing or unset options, which matters because get_option can return false for a missing key; an agent could misinterpret that as a stored false value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'key' parameter at 100% coverage with examples, so the baseline is 3. The description adds value by expanding the set of common option keys (blogname, date_format, posts_per_page, etc.), which helps an agent choose realistic, valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('single WordPress option value'), and the access method ('by key'). The word 'single' also helps distinguish it from the sibling wp_get_options_batch, so an agent can identify this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving one option at a time, and the listed common options give practical context. However, it never explicitly says 'use wp_get_options_batch for multiple options' or 'use wp_set_options to modify values', so the agent must infer alternatives from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral burden. It adds a meaningful detail by specifying that the reply is authored as the site administrator, but it does not disclose side effects such as whether the reply is immediately public, whether notifications are triggered, or whether the parent comment status is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that front-loads the core action and actor. There is no filler, no repetition of schema details, and every word contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with fully described required parameters, this is nearly sufficient. However, with no annotations and no output schema, a brief note on the expected result (e.g., new comment ID) or a prerequisite like 'the parent comment must exist' would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters completely with 100% coverage. The description adds no parameter-level meaning beyond the admin actor context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Reply to a comment') and adds the actor ('as the site administrator'). It clearly distinguishes this tool from sibling comment tools like wp_update_comment_status, wp_get_comment, wp_delete_comment, and wp_list_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action is self-evident: use it when an administrator needs to reply to a comment. However, it provides no explicit when-not-to-use guidance, alternatives, or prerequisites such as the parent comment existing or the post allowing comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 makes the retrieval nature clear through 'Get' and lists the types of information returned, which is helpful. However, it does not mention output structure, sensitivity of server details, read-only guarantees, or any potential failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every phrase adds scope information, and the list of included categories is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-input tool, the description is mostly complete: it lists the main result categories an agent should expect. However, with no output schema, the exact structure of 'server details' and how plugin/theme/version data are represented remains somewhat ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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%, so the description need not explain parameter semantics. It correctly focuses on the output scope instead, matching the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('WordPress site information'), and enumerates the included content categories: version, plugins, theme, post types, WooCommerce status, and server details. This clearly conveys what the tool does and subtly distinguishes it from focused siblings like wp_list_plugins or wp_woocommerce_status, though it does not name alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'comprehensive WordPress site information' implies use when a broad overview is needed, but the description does not explicitly state when to prefer this tool over siblings like wp_site_health for health checks or wp_list_plugins for plugin details. It provides implied usage context without exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It communicates that this is a mutating operation fetching from WordPress.org, but does not disclose side effects such as overwriting the plugin's existing files, losing local customizations, or requiring filesystem permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 12-word sentence with the action verb front-loaded and zero filler. It states the tool's action, resource, and source efficiently in a format an agent can parse immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with full schema coverage, the description covers the core call essentials. However, with no output schema and no annotations, the absence of side-effect or prerequisite disclosure leaves the agent without a complete picture of what happens on invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the 'plugin' parameter already documents its three accepted formats (file path, slug, or name). The description adds no parameter-level information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('update') and resource ('WordPress plugin') with precise scope ('to the latest version from WordPress.org'). It clearly distinguishes the tool from its siblings (wp_install_plugin, wp_activate_plugin, wp_deactivate_plugin, wp_delete_plugin) without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage scenario is implied—an installed plugin needs upgrading—but never stated explicitly. There is no guidance on when to prefer this over wp_install_plugin, nor any prerequisites mentioned such as the plugin already being installed and active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 clearly conveys a read-only status check and version retrieval, which is the core behavior. However, it does not disclose the response shape, how 'active' is determined, or behavior when Elementor is not installed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with no filler. It front-loads the action and includes the two relevant outputs without redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter status tool, the description is mostly complete: it states what is checked and what is retrieved. Since there is no output schema, a bit more detail about the return value (e.g., boolean active flag and version string) would be helpful, but the current level is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is fully covered by its empty properties object, so parameter explanation is unnecessary. The baseline of 4 applies because there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and resource ('Elementor'), plus the exact facts returned (active status and version). It is clearly distinct from Elementor page/template tools like wp_elementor_get_page and wp_elementor_list_templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as wp_woocommerce_status, wp_cli_status, or wp_list_plugins. The intended use is implied by the name and siblings, but the description does not explicitly state when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Get' and 'full details' signal a read-only retrieval and indicate the response includes complete comment data, but the description does not disclose errors, permissions, or response format beyond saying 'full details.' For a simple getter this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part contributes to identifying the operation and its key parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one required parameter and no output schema, the description is reasonably complete: it names the operation, the target resource, and the lookup key. It could be more explicit about what 'full details' includes, but the tool is simple enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter 'id' is already described as 'Comment ID.' The description adds 'by its ID,' which reinforces the parameter's purpose but provides no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('a single comment') with a clear identifier ('by its ID'). It distinguishes itself from siblings like wp_list_comments, wp_update_comment_status, and wp_delete_comment by emphasizing retrieval of a single item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'single comment... by its ID' implies this tool is for retrieving one specific comment when the ID is known. However, it does not explicitly mention alternatives or state when not to use it, leaving usage guidance mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool supports search, pagination, and status filtering, which gives some behavioral context. However, it does not mention return format, pagination limits, required permissions, or how errors are handled. It's read-oriented by nature, but that's not explicitly stated, and no edge cases are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary purpose ('List WordPress content') and then lists supported capabilities in a compact list. Every phrase adds value, no redundancy or fluff, making it an exemplary concise definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters and no output schema, the description covers the main functional aspects: what content types are supported, key filtering options, and pagination. It omits details like return structure or how to handle unusual custom post types, but given the simplicity of a listing operation, it's fairly complete. The lack of output schema means the description could hint at the return format, but it's not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters already have detailed descriptions in the schema. The description adds a brief mention of search, pagination, and status filtering, which reinforces some params but doesn't add new meaning beyond what the schema provides. Baseline 3 is appropriate as the schema does the heavy lifting and the description doesn't introduce additional nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists WordPress content, enumerates specific post types (posts, pages, products, custom post types), and lists capabilities like search, pagination, and status filtering. This is a precise verb-resource pairing that distinguishes it from siblings like wp_get_content (single item) and wp_create_content (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing content, but it doesn't explicitly mention when to prefer this over wp_get_content (for a single item) or other listing tools like wp_list_comments. It provides clear context that it's for lists of content, but no explicit exclusions or alternatives are named, leaving some inference needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the output fields (status, version, update availability) but does not explicitly confirm this is a read-only operation, nor does it mention error handling, pagination, or potential side effects. The verb 'list' implies safety, but that is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the core purpose and the key output fields. It is front-loaded with the main action and resource, and contains no unnecessary wording—every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, no annotations, no output schema), the description adequately covers what the tool does and what information it returns. It stops short of describing the return format or pagination behavior, but for a simple list tool, the provided details are largely sufficient for an agent to understand the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. The baseline for 0-param tools is 4, and the description appropriately adds no parameter-related content, avoiding redundancy with an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is highly specific: it names the resource ('installed WordPress plugins'), the action ('List'), and the exact details returned (status, version, update availability). This clearly distinguishes it from sibling tools like wp_search_plugins, wp_install_plugin, or wp_list_themes based on its verb and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as wp_search_plugins or other list tools. There is no mention of scenarios where searching is preferable or when this tool is the right choice, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that multiple options can be set at once and that sensitive options like siteurl and admin_email are blocked for security. However, it does not explain the consequences of hitting a blocked option, whether the operation is atomic, permission requirements, or what is returned on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The first states the purpose, the second gives the payload shape, and the third provides an important security constraint. Every sentence earns its place and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with a single parameter, no output schema, and no annotations, this is nearly complete: it covers what to pass and warns about blocked options. It falls short only by omitting response/error behavior and what happens when a blocked option is requested in a multi-option call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the options parameter with an example. The description reinforces the key-value format and adds the 'one or more' batching cue, but it does not meaningfully extend the schema's semantic content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'WordPress options', and 'one or more' clarifies the batching capability. This distinguishes it from sibling tools like wp_get_option, wp_get_options_batch, and wp_delete_option without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb 'Set' and the instruction to provide key-value pairs, so an agent can infer when to use it. However, it does not explicitly mention alternatives or say when not to use it; the blocked-options note is the only exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It does disclose the core behavior—changing a comment's status—and clarifies 'hold' as 'unapprove,' but it does not mention side effects such as visibility changes, permission requirements, or whether trashing is reversible. This is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence delivers the action and all valid status values with no filler. Every word earns its place, and the key information is immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation, the description combined with the fully documented schema is sufficient for an agent to invoke the tool correctly. It lacks information about return values or edge cases, but nothing essential to passing the correct id and choosing a valid status is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes both parameters clearly: 'id' is a comment ID and 'status' is one of the four allowed values. The description adds only the parenthetical clarification for 'hold (unapprove),' which provides minimal extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource ('Change a comment status') and enumerates the exact allowed states: approve, hold, spam, or trash. It is immediately distinguishable from sibling tools like wp_delete_comment, wp_reply_comment, and wp_get_comment because it names the mutation being performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever a comment's moderation status needs to be changed. However, it does not explicitly contrast it with alternatives such as wp_delete_comment or wp_reply_comment, nor does it state when not to use it. The usage context is clear from the wording but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. 'List' implies a read-only operation, and it discloses output contents and pagination support, but it does not mention authentication needs, rate limits, ordering behavior, or response format beyond the listed fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences carry the essential purpose and capabilities without redundancy. Key information is front-loaded in the first sentence, making it easy for an agent to scan and understand the tool quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read/list tool with fully self-documented parameters and no output schema, the description covers the core invocation details: what it lists, what fields are returned, and what query options are supported. It is slightly sparse on return-shape details but sufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters page, status, and per_page are already documented. The description's mention of filtering by status and pagination reinforces the schema but does not add meaning beyond it, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('WooCommerce orders'), and the key included data ('customer info, totals, and status'). It also distinguishes itself from single-order retrieval tools like wp_woocommerce_get_order by emphasizing plural order listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used for retrieving multiple orders and mentions filtering/pagination, but it does not explicitly state when to use it versus alternatives such as wp_woocommerce_get_order. There is clear context, but no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose the mutating nature (install) and the optional activation step, but it doesn't mention potential side effects like overwriting an existing theme, privilege requirements, or failure behavior. Core behavior is present, but meaningful gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It states the action, source, and optional secondary behavior efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full schema coverage, and lack of output schema, the description is adequate but not complete. It doesn't describe return values, error conditions, or the impact of activation, which would be useful for an agent without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adequately. The description's 'Optionally activate it after installation' largely restates the 'activate' parameter description and adds no new parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Install'), the resource ('theme'), and the source ('WordPress.org'), plus the optional activation. This clearly differentiates it from siblings like wp_activate_theme, wp_search_themes, and wp_install_plugin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear use case: install a theme from WordPress.org by slug. It doesn't explicitly compare to alternatives or provide when-not conditions, but the action is unambiguous and the context is clear enough for an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose mutation and the partial-update behavior ('Only provide the fields you want to change'), which is valuable. However, it omits permission requirements, failure modes, and response shape, which are important for a write operation with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the primary action and then provides the essential usage rule efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for identifying the tool and its core update behavior, and the schema fully covers parameters. However, there is no output schema and no mention of what the tool returns, and type-specific behavior (e.g., WooCommerce product fields) is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so all 15 parameters already have individual descriptions. The description adds the key partial-update context but does not add per-parameter meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Update') and resource ('existing WordPress post, page, or product'), distinguishing it from create/get/list/delete content tools in the sibling set. The word 'existing' reinforces that it is not for creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Only provide the fields you want to change' is a useful usage instruction for partial updates. It implies this tool is for modifying already-created content, but it does not explicitly name alternatives such as wp_create_content or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns store details and lists the categories, but it does not state failure behavior when WooCommerce is absent, whether the operation is read-only, or any permission/context requirements. The read-only nature is only implied by 'Check'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the operation and the main output categories with no filler or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status check, the description gives the core output categories, but without an output schema it omits the actual result shape for both success and failure. 'Enabled features' also remains unspecified, leaving some ambiguity about interpretation when WooCommerce is not installed or active.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has no parameters, so the schema already fully covers this dimension. The description does not need to add parameter semantics, earning the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('WooCommerce installed and active'), and then clarifies what data is returned. This distinguishes it from sibling tools like wp_woocommerce_stats and wp_woocommerce_get_settings by its status-check intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when an agent needs to confirm WooCommerce is installed/active and get basic store context. However, it does not explicitly compare against overlapping siblings such as wp_woocommerce_stats, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses two important traits: the plugin will be deactivated first if active, and deletion is permanent file removal. It does not mention permission requirements or failure behavior, but the key destructive consequence is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no wasted words. The main action and resource are front-loaded, the deactivation caveat is parenthetical, and the permanence statement earns its place by clarifying the destructive nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the essential context: what gets deleted, that active plugins are deactivated first, and that removal is permanent. Minor omissions such as permissions or return values are not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage by describing the parameter as 'Plugin file path, slug, or name', so the baseline is 3. The description adds no further clarification about which identifier format is preferred or how plugin resolution works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'WordPress plugin', and it distinguishes itself from the sibling wp_deactivate_plugin by noting that it deactivates first and permanently removes the plugin files. This gives an agent no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'permanently removes the plugin files' implies this tool is for permanent deletion rather than mere deactivation, and the automatic deactivation note provides context. However, it never explicitly names wp_deactivate_plugin as the alternative or states when not to use this tool, leaving the comparison mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral transparency burden. It communicates a read operation through 'Get' and discloses the conditional nature of WooCommerce product data with 'if applicable,' which is useful. However, it does not state whether it modifies anything, what happens on invalid IDs, or any permission requirements, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-front-loaded sentence that starts with the essential action and resource, then appends relevant detail. There is no filler, and every listed field contributes to the agent's understanding of what the tool returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description provides a reasonable picture by naming returned data categories and the conditional WooCommerce data. For a simple two-parameter retrieval tool, this is largely sufficient, though it omits details about error behavior or response format, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with 100% coverage, establishing a baseline of 3. The description adds value by indicating that a product type yields WooCommerce product data ('if applicable') and by associating the ID with a single-item lookup, giving extra semantic meaning beyond the schema's simple type enumeration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get a single WordPress content item by ID' and clarifies the scope with 'full details including content, meta fields, categories, tags, and WooCommerce product data if applicable.' It clearly distinguishes from list-oriented siblings like wp_list_content by emphasizing 'single' and 'by ID', and from other getters by focusing on content items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: call this when you have a content item ID and need detailed data for one item. However, it does not explicitly name alternatives such as wp_list_content for multiple items or wp_get_comment for comments, nor does it provide exclusion conditions. The guidance is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose what the agent will receive (active/inactive status, version, parent theme), implying a read-only enumeration. However, it does not address contextual behavior such as WordPress multisite semantics (network-active vs site-active themes), output format, or any permissions needed to enumerate themes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 18-word sentence with zero waste: the verb and resource are front-loaded, and the return fields are listed compactly. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, zero-parameter tool with no output schema, the description adequately conveys the result contents (status, version, parent theme info), compensating for the missing output schema. The main gaps are the lack of comparative guidance versus wp_search_themes and no annotation coverage to confirm the read-only safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4; the description correctly implies a no-input operation and adds no misleading parameter claims. Since there is nothing to document, the description provides appropriate meaning for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('all installed WordPress themes') with explicit scope ('all installed'), which distinguishes it from siblings like wp_search_themes, wp_install_theme, and wp_activate_theme. It also enumerates the specific fields returned (status, version, parent theme info). An agent can tell exactly what this tool does without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List all installed' implies the use case of enumerating the full theme inventory, but there is no explicit when-to-use guidance or exclusion. With wp_search_themes as a close sibling, the description misses the opportunity to route the agent ('to find a theme by criteria, use wp_search_themes instead'), leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 clearly indicates a search against an external directory and implies no installation occurs, but it does not explicitly state that it is read-only, describe rate limits, or mention network dependence. This is adequate for a simple search but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The primary purpose is front-loaded, and the usage context is given immediately, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with only two parameters, the description covers what the tool does, how it relates to the install workflow, and the query target. It does not describe return value structure, but no output schema exists and the tool's purpose is straightforward enough that an agent can infer the expected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'query' and 'per_page' are already documented in the schema. The description adds only the general 'by name or keyword' hint, which aligns with the query parameter but does not substantively improve parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), a clear resource ('WordPress.org plugin directory'), and the intended workflow context ('before installing them'). This distinguishes it from sibling tools like wp_list_plugins (installed plugins) and wp_install_plugin (installation), so an agent can route appropriately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this to find plugins by name or keyword before installing them' provides clear usage context and implies it is the discovery step prior to installation. It does not explicitly name alternative tools or exclusion cases, but the context and sibling list make the intended usage reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the two checks performed, but it does not disclose behavior such as potential timeout handling, error responses, or whether a boolean/status object is returned. The core behavior is transparent enough for a simple health check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without any filler or redundant information. It is immediately scannable and understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema health check tool, the description captures the essential purpose. It could be slightly more complete by specifying the return format or behavior when the site is unreachable, but given the simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter meaning. This is the appropriate baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and identifies the exact resources being verified: WordPress site reachability and WP AI Assistant plugin activity. This clearly differentiates it from siblings like wp_site_info and wp_list_plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used as a health check before relying on the plugin or site, but it does not explicitly state when to use it versus alternatives or any exclusions. The context is understandable though not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. 'Get' implies a read operation and the listed fields indicate what the response contains, but it does not explicitly state that no modifications occur or mention any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; the verb and object are front-loaded and the included fields are enumerated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has one required parameter, and no output schema. The description covers what the tool returns and the target resource, so an agent can invoke it correctly; a small gap is that it doesn't explicitly state non-mutating behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the id parameter is already described as 'Order ID'. The description does not add meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Get full details') on a specific resource ('a single WooCommerce order') and lists key content (line items, billing/shipping addresses, payment info). This clearly distinguishes it from list-oriented siblings like wp_woocommerce_list_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the context for use: fetching a single order's full details rather than a list or settings. It does not explicitly name alternatives or state when not to use it, but the 'single' vs listing contrast provides clear situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. 'List' signals a read-only enumeration and 'all...configured on the site' bounds the result set, though it does not describe response shape, ordering, or pagination. It is minimal but non-misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It names the action, resource, and scope in eight words, so every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing tool, the description provides the essential facts: what is listed and which scope applies. It does not elaborate on return structure, but no output schema exists and the simple semantics make that omission acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is nothing beyond the schema for the description to explain. The baseline for 0-param tools is 4, and the description properly avoids inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'List' with a specific resource ('all WooCommerce tax rates') and scope ('configured on the site'). This clearly distinguishes it from sibling tools like wp_woocommerce_create_tax_rate, which have different actions and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: call this when you need the set of currently configured tax rates. It does not explicitly identify alternatives or exclusions, but no sibling tool offers the same tax-rate listing function, so the implied usage is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly states the output format (checklist with status pass/fail/warning and auto-fixability), and the audit nature implies a read-only operation, though it does not explicitly state 'does not modify anything'. It is adequately transparent for an audit tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, leading with the main purpose and then detailing the checklist categories. It is slightly verbose with the enumerated lists, but every clause adds information about scope and output, so it is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only audit tool without an output schema, the description is quite complete: it specifies what is checked, the status values, and the auto-fix indicator. It does not cover potential error conditions or performance expectations, but those are not critical for this type of tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema has 100% coverage. Per the baseline for 0 parameters, the description need not add parameter details, and it does not attempt to. This is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Audit') and a clear resource ('WordPress site'), then enumerates the exact categories and checks (security, SEO, performance, maintenance, theme), making it easy to distinguish from sibling tools like wp_site_health or wp_fix_best_practices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies its use for auditing best practices, but it does not explicitly compare itself to alternatives (e.g., when to use this vs. wp_site_health or wp_fix_best_practices). The name itself is a strong hint, but explicit routing is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It explicitly discloses the default trash behavior and the force=true permanent delete option, which is the central safety-relevant distinction for deletion. It does not mention permissions or side effects on related data, but the key destructive behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the action, resource, default behavior, and the force option efficiently without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter delete tool with no output schema and no annotations, the description covers the operation, target content types, default behavior, and the force option. It doesn't describe return values, but with 100% schema coverage and a clear purpose, nothing critical is missing for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 three parameters. The description adds context that type accepts post/page/product and that force defaults to false, but this mostly restates the schema's own descriptions. Baseline 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('WordPress post, page, or product'), clearly distinguishing it from sibling delete tools like wp_delete_plugin, wp_delete_comment, wp_delete_media, and wp_delete_option. It leaves no ambiguity about what content type this tool operates on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly scopes the tool to posts, pages, or products, which implies when to use it versus other delete tools. It does not explicitly name alternatives or exclusion conditions, but the scope is specific enough that an agent can confidently select it for content deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly indicates this is a read operation ('Get'), describes what is returned (element tree, page settings, metadata), and implies no side effects by recommending it before modifications. It does not detail error behavior for invalid IDs or non-Elementor pages, but for a simple read tool the key traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The first sentence front-loads the action and resource; the second adds return details and the intended use case. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description explains the input, the output shape, and the practical use case. It is sufficiently complete for an agent to select and invoke the tool correctly, though it could mention what happens if the ID doesn't correspond to an Elementor-enabled page.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage, describing the only parameter as 'The WordPress post/page ID.' The description repeats this in prose ('by its ID') without adding format, constraints, or additional meaning. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('Elementor data for a page/post'), and a clear identifier ('by its ID'). It also names the returned content (element tree, page settings, metadata), which distinguishes it from generic content tools like wp_get_content and from modifier tools like wp_elementor_update_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool 'to understand the current structure before making modifications,' giving a clear context for when it is appropriate. It doesn't enumerate exclusions or name alternatives, but the pre-modification framing effectively routes agents away from using it after edits and toward update tools for changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does disclose exact side effects: permalinks are set to /%postname%/ and XMLRPC is disabled via an mu-plugin. It does not describe return values or error behavior for invalid fix IDs, which keeps it slightly below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the main action, and packs the essential supported values and behaviors into minimal space. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides everything needed to invoke it correctly: the fix IDs and their effects. It could be more complete by noting that wp_audit_best_practices is the companion discovery step and by describing the response, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description goes beyond the schema by explaining what each supported fix ID actually does. It explicitly lists 'permalinks' and 'xmlrpc' as the currently supported values and adds the consequence of applying them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Apply') with a clear resource ('auto-fixes for best practice issues') and enumerates the exact supported fixes and their effects. This distinguishes it from the sibling audit tool (wp_audit_best_practices) and from content/plugin operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when best-practice issues need correction and only supports the listed fix IDs, but it never explicitly says to run wp_audit_best_practices first or explains when not to use this tool. The usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'Get detailed information' clearly signals a read-only operation, and 'including all available sizes and URLs' discloses what the caller should expect. It does not discuss error cases or permissions, but for a simple read tool the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly written sentence with no filler. The main action and key differentiator are front-loaded, and every word contributes to the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one required parameter and no output schema, the description provides enough orientation by naming the resource and the expected detail level. It could mention the response shape more explicitly, but for a low-complexity single-resource getter it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with 'id' documented as 'Media attachment ID'. The description does not add new parameter-level meaning beyond already stating it targets a single media file, so it stays at the baseline for well-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), resource ('media file'), and scope ('single media file'), and distinguishes itself from wp_list_media by emphasizing a single item. It also adds concrete detail about the return content ('all available sizes and URLs').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when you need detailed info about one media file. It does not explicitly mention alternatives like wp_list_media for multiple files or wp_upload_media for creation, but the singular focus and 'detailed information' phrasing provide adequate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It indicates a read/list operation and reveals that each zone includes configured shipping methods, but it does not mention pagination, ordering, empty-zone handling, or prerequisites such as WooCommerce being active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word adds relevant information about the operation and its output scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list operation, the description is sufficient to invoke the tool safely and to know the broad shape of the result. It is slightly incomplete because there is no output schema and the description only names the included methods without detailing zone fields or list behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics to document; the empty schema is fully consistent with the description. The baseline for a zero-parameter tool is a 4, as there is no ambiguity to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a concrete resource ('WooCommerce shipping zones'), and adds that results include configured shipping methods. This clearly distinguishes it from sibling WooCommerce tools such as order, coupon, tax-rate, and settings tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context: use it when you need to enumerate shipping zones and their methods. It does not explicitly name alternatives or exclusions, but no sibling tool covers shipping zones, so the selection context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It explicitly discloses that the list serves as an allowlist and that anything not present is refused, which is valuable non-obvious behavior. It also implies a read-only listing operation, though it does not detail output format or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, then adds the critical allowlist constraint without any filler. Every word contributes meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with no output schema, the description covers both what will be returned (allowed commands, subcommands, refused flags) and how to interpret the result (anything absent is refused). This is sufficient for an agent to decide to call it and use its output correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so parameter documentation is unnecessary. The description still provides useful semantics about what the output contains, which is the relevant information for an agent calling the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('List') and a precise resource: allowlisted WP-CLI commands, their permitted subcommands, and refused global flags. This clearly distinguishes the tool from siblings like wp_cli_execute and wp_cli_status, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is meant to be consulted to discover what may be run, especially with the statement that anything absent is refused. However, it does not explicitly say when to use this versus wp_cli_execute or other WP-CLI-related tools, leaving the usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' strongly implies a non-mutating read, but the description does not state what is returned, that omitting group returns all settings, or any access considerations. It is adequately clear but not behaviorally rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: a front-loaded action statement followed by a compact enumeration of valid groups. There is no filler, repetition, or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read tool with full schema coverage. The description plus input schema give the agent everything needed to select and invoke the tool correctly, including all valid group values and the optional nature of the parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by giving concrete examples of what each group contains, such as 'store address, currency' for general and 'guest checkout' for checkout. This helps an agent map a natural-language request to the correct group value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get WooCommerce settings by group.' It also enumerates the available groups, making the tool's purpose and scope immediately clear. This is easily distinguished from sibling tools like wp_woocommerce_update_settings or wp_woocommerce_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: call this tool when you need to read WooCommerce settings, optionally scoped to a named group. It does not explicitly name alternatives or state when not to use it, but for a simple read-only settings tool this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral disclosure burden. It makes clear this is a read-only enumeration and specifies what output information is conveyed (enabled/disabled status), which is appropriate for a zero-parameter listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, with no filler or repetition. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with no output schema or annotations, the description gives sufficient information to select and call it correctly: it states the resource, scope, and the status information returned. No critical invocation knowledge is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so the schema fully accounts for invocation. Per the rubric, 0 parameters warrants a baseline of 4; there is nothing for the description to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), names the exact resource ('WooCommerce payment gateways'), and adds scope ('all available') plus the key returned attribute (enabled/disabled status). This clearly separates it from the sibling update tool, wp_woocommerce_update_payment_gateway, which mutates rather than enumerates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case—when an agent needs an inventory of payment gateways and their statuses—but it never states when to prefer it over alternatives or mentions the update sibling. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full disclosure burden and delivers thoroughly: the deny-by-default model, explicit denylists for commands and flags, the WPAIA_ENABLE_WPCLI feature-flag gate, and the shell-quoting requirement. This is exactly the behavioral context an agent needs before invoking an arbitrary command executor, including the prerequisite status check that prevents wasted calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence and nearly every clause is informative — the denylist, flag restrictions, quoting rule, and prerequisite all earn their place. The 19-item allowlist and several rules run together in one dense paragraph, so bulleted structure would improve scannability without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-risk generic executor with no annotations and no output schema, it admirably covers the safety model, permitted and refused inputs, the prerequisite status check, and the invocation format. It stops short of describing return or error behavior for denied commands, and it does not route to any of the many sibling tools that cover specific task families.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds meaning beyond the schema's brief example: it communicates the quoting requirement, reinforces the no-prefix convention, and explains the allow/deny constraints that determine legal values for the command parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource — 'Execute a WP-CLI command' — and then defines scope precisely via the allowlisted command namespaces (cache, plugin, post, etc.), which clearly distinguishes this raw executor from purpose-built siblings like wp_install_plugin or wp_get_option. The description leaves no doubt about what the tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit operational rules: 'call wp_cli_status first', 'Do NOT include the "wp" prefix', and 'Quote any value containing shell metacharacters.' It also names refused commands and flags. However, it never tells the agent to prefer a specific sibling wrapper (e.g., wp_install_plugin) when an allowlisted command family has a dedicated tool, so the when-vs-alternative routing is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly discloses the exact checks performed (wp-config.php enablement, proc_open availability, path, version) and implies a non-destructive read-only nature. It doesn't discuss failure modes, but the listed returns give a solid picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero filler. The core purpose and key return fields are front-loaded, followed by a crisp usage directive. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status-check tool with no output schema, the description fully covers what the tool does, what it returns, and when to call it. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so no parameter explanation is needed. The baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Check WP-CLI availability.' It enumerates exactly what it returns, distinguishing it from sibling tools like wp_cli_execute and wp_cli_list_commands, which are clearly different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instruction: 'Call this before any WP-CLI command.' This clearly tells the agent when to use it, though it doesn't mention alternatives or when-not-to-use, but given this is a preflight check, no alternatives are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List all available' makes the read-only nature clear and the field enumeration tells the agent what to expect. It lacks an explicit no-mutation statement, but the listing verb strongly implies a safe, non-destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. The first sentence delivers the core function and output fields; the second adds the practical use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only catalog tool with no output schema, this description is sufficiently complete. It states what the tool lists, what fields are included, and when to use it, giving an agent everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline is 4. There are no parameter ambiguities for the description to resolve, and the description correctly focuses on what the tool returns rather than inventing parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the concrete resource 'Elementor widget types' and enumerates the returned fields: names, titles, icons, and categories. This clearly distinguishes it from sibling tools like wp_elementor_status and wp_elementor_get_page, which target different Elementor concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: 'Use this to know which widgets you can use when building pages.' This tells an agent when the tool is relevant, though it does not explicitly name alternatives or state when not to use it, so it stops short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![wpagent-mcp MCP server](https://glama.ai/mcp/servers/THE-KIPDEV/wpagent-mcp/badges/card.svg)](https://glama.ai/mcp/servers/THE-KIPDEV/wpagent-mcp)

Score Badge

Copy to your README.md:

[![wpagent-mcp MCP server](https://glama.ai/mcp/servers/THE-KIPDEV/wpagent-mcp/badges/score.svg)](https://glama.ai/mcp/servers/THE-KIPDEV/wpagent-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/THE-KIPDEV/wpagent-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server