mcp-wordpress

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation4/5
Tools are generally organized around explicit resource+action pairs, so posts, pages, media, menus, widgets, blocks, patterns, and settings are easy to tell apart. A few edges could confuse an agent: wp_create_category vs wp_ensure_category have overlapping behavior, and the two Elementor tools are listed but marked unavailable. Overall, however, overlapping purposes are rare.
Naming Consistency4/5
The dominant pattern is wp_verb_noun (wp_list_posts, wp_create_menu, wp_delete_media) and most tools follow it predictably. The wp_blocks_* family breaks the pattern by placing the noun before the verb (wp_blocks_list, wp_blocks_update), and plugin-prefixed tools like wp_elementor_update_shortcode_content add a module prefix. These are readable deviations, not chaotic naming.
Tool Count2/5
80 tools is far beyond the comfortable agent-facing range and imposes heavy selection overhead even though the WordPress domain is broad. Several families (blocks, menus, widgets, patterns) could be consolidated with parameterized operations, and the two unavailable Elementor tools should not be included. As a set, it feels more like a full SDK surface than a curated MCP toolkit.
Completeness3/5
The content lifecycle is unusually thorough: posts, pages, media, terms, revisions, blocks, patterns, widgets, menus, and settings all have meaningful CRUD coverage. However, WordPress's core comments and user-management surfaces are absent, and the Elementor tools are dead ends because they are explicitly unavailable. That makes the set broad but uneven rather than complete.
Average 3.3/5 across 79 of 80 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 and only discloses unavailability and a reason about WordPress REST safety. It does not describe what happens when called or any actual retrieval behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy and is easy to parse. However, it is concise because it omits the tool's purpose, so brevity is achieved through under-specification.
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 has one well-documented parameter and no output schema, but the description still fails to define the operation. The unavailability warning is useful context, yet an agent cannot tell what content would be retrieved or what response to expect.
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 page_id documented as an integer 'Page ID' and exclusiveMinimum 0, so the baseline of 3 applies. The description adds no parameter information, but none is required beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It only declares that the tool is experimental and currently unavailable, with no verb and resource. The tool's purpose must be inferred entirely from its name.
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 tells the agent the tool is currently unavailable, which implicitly says not to call it. However, it provides no alternatives or conditions under which the tool should be used, so routing to sibling tools is not supported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 restates the tool's purpose. It does not explain mutation side effects, whether unspecified fields are preserved, how dry_run behaves, permission requirements, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, but it is under-specified rather than efficiently complete. One short sentence cannot support a six-parameter mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no output schema, and no annotations, this one-sentence description is severely incomplete. An agent has no way to know how to correctly configure the update, what fields are supported, or what outcome to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is very low (17%), with only dry_run described in the schema. The description adds no information about properties like name, slug, parent, or description, and does not compensate for the fact that most parameters are undocumented.
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 clear verb ('Update') and resource ('a WordPress category'), so an agent can tell it is for modifying existing categories rather than creating or deleting them. However, it does not explicitly differentiate among sibling update tools (e.g., wp_update_tag, wp_update_post) beyond the resource name.
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_create_category, wp_ensure_category, or wp_delete_category. The intended use is only implied by the word 'Update'; there are no explicit conditions, exclusions, or recommended alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 repeats that this is an update operation. It does not state whether updates are immediate, how missing tags are handled, whether existing fields are overwritten, or what response the agent should expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and free of fluff, but it is under-specification rather than useful conciseness. It does little more than restate the tool's name and misses the opportunity to add actionable context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A 5-parameter mutation tool with no annotations and no output schema needs far more context than 'Update a WordPress tag.' Missing information includes the required id, update semantics, dry-run behavior, return value, and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description adds no parameter-level meaning. It does not explain that 'id' is required, which fields are updatable, or how 'dry_run' changes behavior. The schema is mostly undocumented, and the description does not compensate.
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 identifies the action ('Update') and resource ('WordPress tag') clearly. However, it does not distinguish this tool from siblings like wp_create_tag or wp_ensure_tag, so it stops short of full 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 creating, ensuring, or deleting tags. The description does not mention prerequisites, partial updates, or any conditions that would make this tool the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 does not mention idempotency, duplicate handling, return values, or side effects, leaving the agent without any insight beyond the generic meaning of 'create'.
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, short sentence with no filler or redundancy. It front-loads the core action and resource, though its brevity is achieved by omitting valuable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a side-effecting tool with five parameters, no annotations, and no output schema, one sentence is severely inadequate. An agent cannot predict the operation's behavior, return format, or error conditions from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, with just dry_run described. The tool description names none of the five parameters and provides no hints about how name, slug, parent, or description should be used, so it does not compensate for the missing schema documentation.
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 clear verb ('Create') and resource ('WordPress category'), so an agent can tell what the tool does at a basic level. It does not differentiate from sibling tools such as wp_ensure_category or wp_update_category, so it misses the 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?
No usage guidance is provided. The description does not indicate when to use this tool instead of alternatives like wp_ensure_category, nor does it mention any prerequisites or context.
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 present, so the description carries a heavy burden for behavioral disclosure. It adds 'Supports dry-run,' but the schema already states this for the dry_run parameter. It does not disclose side effects, required permissions, validation behavior, or whether any output or confirmation is returned.
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 and free of filler: 'Create classic menu item. Supports dry-run.' Each sentence earns its place. It is concise, but it leans closer to under-specification than optimal compression given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A 15-parameter creation tool with no annotations, no output schema, and a two-sentence description is far from complete. The agent cannot determine required parameter relationships, expected return values, or side effects, making correct invocation unlikely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 15 parameters and only 7% schema description coverage, the description needed to compensate but adds no meaningful parameter guidance. It does not clarify required title/menus semantics or how type, object, object_id, and url interact. The only hint, dry-run, merely repeats the schema's own description.
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 and resource: 'Create classic menu item.' It clearly identifies this as a creation operation for menu items, which distinguishes it from menu, post, or widget tools. However, the 'classic' qualifier is ambiguous and no explicit differentiation from sibling menu-item tools is provided.
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 like wp_update_menu_item or wp_delete_menu_item. It does not mention prerequisites such as an existing menu, nor contexts where dry-run should be preferred.
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 only says 'Update' and 'Supports dry-run'; it does not describe side effects, irreversibility, permissions, or what happens to unspecified fields. The dry-run support is a useful behavioral hint, but it is already present in the schema and adds no depth beyond that.
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 brief and front-loaded, with no filler: 'Update classic menu item. Supports dry-run.' Both sentences earn their place. However, it is so sparse that it sacrifices usefulness for brevity, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 16 parameters, no output schema, no annotations, and only 6% schema coverage, the description is far too minimal. It omits return values, required-field guidance, classic-vs-block semantics, and any details about the update's effect or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 6%, with only dry_run described in the schema. The description does not compensate by explaining any of the 16 parameters, including the required id, url, title, status, or type. This leaves nearly all parameter semantics undocumented.
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 action and resource: 'Update classic menu item.' This clearly separates it from get/create/delete menu item siblings. However, 'classic' is not explained, so there is some ambiguity about what distinguishes a classic menu item from other menu item types.
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 like wp_create_menu_item, wp_get_menu_item, or wp_delete_menu_item. The dry-run mention hints at a preview workflow, but there are no exclusions, prerequisites, or alternative-selection criteria.
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 must disclose behavioral traits. It only mentions dry-run support, which is helpful, but omits details like whether creation overwrites existing menus, enforces uniqueness, or requires authentication. The mutation side effect is implied but not explicit.
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 short sentences with no fluff. It is front-loaded with the core action. However, it could add a bit more context without losing conciseness (e.g., mentioning required name).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain the meaning of 'classic menu', required parameters, or side effects. An agent would have to infer too much to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only dry_run has a description). The description adds nothing about name, slug, auto_add, locations, or description. It only reinforces dry-run, which is already in the schema. Fails to compensate for low coverage.
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 ('Create') and resource ('classic menu'), which is clear and distinguishes it from list/update/delete menu siblings. However, 'classic' is not explicitly contrasted with modern/block-based menus, leaving slight ambiguity about 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?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., existing menu locations) or when to prefer wp_update_menu or wp_create_menu_item. The dry-run mention hints at preview usage but does not clarify selection criteria.
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 must carry the full burden of behavioral disclosure. Saying 'permanently delete' indicates irreversibility, but it does not mention side effects such as impact on posts using the pattern, auth requirements, or the meaning of the 'force' parameter (which is constrained to true in the schema). The dry_run parameter is also unexplained in the description. There is no information about response behavior or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and free of redundancy. However, brevity here comes at the cost of necessary detail. It is not front-loaded with important constraints or usage notes; it conveys the basic action but omits critical context. It is appropriately sized for a trivial description but insufficient for a destructive operation.
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 annotations, output schema, and low parameter documentation, the description is incomplete. It does not explain the return value (there is no output schema), does not clarify the force flag semantics, and does not mention any preconditions or consequences. An agent cannot fully judge the impact of calling this tool beyond knowing it deletes something permanently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only dry_run has a description). The tool description does not add any explanation for the 'id' or 'force' parameters. It fails to compensate for the low schema coverage; for instance, it doesn't clarify that 'force' is always true or what dry_run does. The description offers no additional semantic value beyond the schema.
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 ('delete') and a specific resource ('synced pattern'), with the qualifier 'permanently' clarifying the operation's nature. It is clear what the tool does, though it does not explicitly differentiate it from sibling delete tools like wp_delete_post or wp_delete_page. However, the resource name is distinct enough that an agent can infer 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites (e.g., whether the pattern must be unused), or when to prefer other deletion tools. The sibling list includes many delete operations, but the description offers no selection criteria.
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. It communicates that this is a compare operation but does not state whether it is read-only, what form the comparison result takes, whether any side effects occur, or whether authentication/permissions are needed.
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, grammatically clear sentence with no filler or repetition. It is front-loaded with the key verb and resource, though it is so short that it misses useful behavioral and parameter context.
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?
There is no output schema and no description of the return value or the semantics of 'compare.' The tool has three parameters, including an ambiguous 'ref,' and the sibling set shows related revision tools, but the description does not explain how the result relates to wp_get_revision or wp_restore_revision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain 'ref,' 'revision_id,' or 'post_type' beyond what the bare parameter names suggest. 'ref' is especially ambiguous because it can be an integer or string, and the description does not clarify what identifiers are accepted.
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 the specific verb 'Compare' and names the resource ('current raw content of a post/page') against 'one revision,' which makes the tool's core function clear. It is reasonably distinguishable from sibling tools like wp_get_revision and wp_restore_revision, though it does not explicitly name those alternatives.
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 such as wp_get_revision or wp_list_revisions. There is no mention of exclusions, prerequisites, or common use cases, so the agent must infer when this tool is 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Supports dry-run.' This adds a small amount of insight, though dry_run is already described in the schema as 'Preview changes without writing.' It does not explain whether unspecified fields are reset, what permissions are required, whether the update is reversible, or what happens on failure.
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 compact and front-loaded, with the core action stated first and the dry-run capability in a short second sentence. There is no fluff or redundant phrasing, though more detail could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 7 parameters, no output schema, no annotations, and very low schema coverage, yet the description provides almost no contextual information. An agent would not know how to identify the menu via 'ref', what each field does, or what a successful update returns. The description is far too sparse for the complexity involved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, with just dry_run documented. The description does not explain the meaning of 'ref', 'auto_add', 'locations', or the other parameters, nor does it clarify how these fields map to a classic menu update. It fails to compensate for the sparse schema documentation.
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 classic menu.' This clearly indicates mutation of an existing menu and distinguishes it from creation/deletion tools. It does not explicitly differentiate from wp_update_menu_item, but the resource noun 'menu' provides enough initial clarity.
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, no prerequisites, and no mention of what makes a menu 'classic' versus other menu types. The tool name and brief description are not enough to help an agent decide between this and related menu tools such as wp_update_menu_item or wp_create_menu.
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 hints that the output includes paths and hashes for reading and editing, but it does not explain the output structure, confirm read-only behavior, or mention pagination, depth limits, or side effects.
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 with the core action front-loaded. It is efficient, though the second clause is terse and cryptic.
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 tool with four parameters, no annotations, and no output schema, this one-line description is insufficient. Agents are left without clarity on depth behavior, filter usage, post_type handling, or the shape of the returned block outline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, covering ref and filter but leaving depth and post_type undocumented. The description adds no parameter-level meaning and only obliquely refers to paths and hashes, which are not parameters. It fails to compensate for the low schema coverage.
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 ('List') and resource ('post/page Gutenberg outline'), making the core purpose understandable. However, it does not differentiate itself from nearby siblings like wp_blocks_find or wp_blocks_get, and the phrase 'outline' is somewhat ambiguous without further context.
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 its many block-related siblings. 'Use paths to read and hashes to edit' hints at how the output might be used, but it does not provide selection criteria, exclusions, 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the basic 'create' behavior and the dry-run capability, which is already documented in the dry_run parameter description. It does not disclose side effects, required permissions, return values, or what happens on validation failure.
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 appropriately short and front-loaded: 'Create synced pattern' leads with the core purpose, followed by the dry-run note. Every word earns its place, though more content would be needed for full usefulness.
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, no output schema, and no annotations, the two-sentence description leaves important context uncovered, such as default status behavior, expected content format, slug requirements, and what the response contains. The tool is a mutation operation with no supporting annotations, so the description is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description should compensate by explaining key parameters, but it only mentions dry-run and does not clarify title, content, slug, or status semantics. The schema provides parameter names and types, but the description adds little meaning beyond that.
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 action ('Create') on a specific resource ('synced pattern'), which is clear and distinguishable from sibling tools like wp_update_synced_pattern and wp_delete_synced_pattern by verb. However, it does not elaborate on what a synced pattern is or how it differs from related concepts like block patterns, so it is clear but minimal.
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 such as wp_update_synced_pattern or wp_create_post. The only usage hint, 'Supports dry-run,' implies a pre-write validation use case but does not explain when that mode should be chosen or any 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, but it only says 'Create' without explaining idempotency, duplicate handling, permissions, or how dry_run affects the operation. This leaves significant behavioral ambiguity for an agent.
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 filler and the core operation is front-loaded. It is appropriately concise, though it could have included more useful context 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?
For a four-parameter mutation tool with no annotations and no output schema, this minimal description leaves the agent to infer behavior around duplicate tags, optional fields, and preview mode. It is not sufficiently complete for confident invocation in non-trivial scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meaning beyond the schema. Schema description coverage is only 25%, and name, slug, and description lack explanations; the description should compensate for this gap but does not.
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 operation ('Create') and the resource ('WordPress tag'), making the tool's purpose immediately understandable. It is distinguishable from sibling list/update/delete tools, though it does not explicitly address overlap with wp_ensure_tag.
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 like wp_ensure_tag, wp_update_tag, or wp_delete_tag. The intended usage is only implicit in the verb 'create', with no exclusions or alternative conditions stated.
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 must carry the behavioral burden; 'List' implies a read-only operation and 'in menu order' communicates default ordering. However, it does not disclose pagination, status filtering, or response format, which are material for a list operation with no output schema.
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, front-loaded sentence with no filler; every word contributes to stating the core behavior. Its brevity contributes to under-specification, but as a structural choice it is efficient.
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 has 7 parameters, no annotations, and no output schema, yet the description gives no information about required inputs, filtering, pagination, or return shape. 'Classic' is left undefined and no relationship to sibling menu tools is provided, so an agent cannot reliably select or invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, so the description needed to compensate, but it explains none of the seven parameters. The phrase 'menu order' merely restates the schema's orderby default and adds no meaning beyond the structured input schema.
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 resource ('classic menu items'), and adds ordering context ('in menu order'). It is clear about what the tool does, but it does not explicitly differentiate itself from sibling tools like wp_list_menus or wp_get_menu_item.
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 instead of alternatives such as wp_list_menus, wp_get_menu_item, or wp_list_pages. There are no exclusions, prerequisites, or clarification of the 'classic' distinction.
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 present, and the description does not disclose side effects, authentication needs, or whether the operation replaces or merges metadata fields. 'Update' implies mutation, but the actual write behavior and safety profile are left entirely unstated.
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 verb is front-loaded. It is concise but does not earn full marks because it is too sparse to support confident invocation for a six-parameter tool.
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 mutation tool with no annotations and no output schema, the description is too thin: it does not mention accepted fields, partial-update behavior, or dry_run functionality. The schema supplies field names, but the overall context is insufficient for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, with only dry_run explained in the schema, and the tool description adds no parameter-level meaning beyond the word 'metadata.' The property names are self-explanatory, but id and dry_run semantics are not clarified anywhere.
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 ('Update') and resource ('media attachment metadata'), making the core action immediately clear. It is distinct enough from the media siblings like get/upload/delete/set_featured_image, but it does not explicitly name alternatives, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as wp_update_post or wp_set_featured_image. There is also no mention of prerequisites, permissions, or conditions that would make this tool the right choice.
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. It does disclose two important traits: changing the front page is site-wide and dry-run is supported. However, it does not explain permission requirements, reversibility, or what happens when partial settings are provided, which are significant gaps 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 front-loaded sentence with no filler. It efficiently states the primary purpose and calls out the two most important behavioral nuances. The phrasing around dry-run is slightly ambiguous, but the overall structure is tight and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 20 parameters, no annotations, and no output schema, so the description must carry substantial contextual load. It leaves out return value behavior, validation rules, side effects of applying settings, and any guidance on how dry-run interacts with the output. It is far from complete for an agent to invoke correctly and confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 5%, and the description adds meaning for only one parameter area ('front page'). The other 19 parameters rely entirely on their names and types in the schema, which is inadequate for parameters like page_on_front, page_for_posts, default_category, and date_format. The description does not compensate for the low coverage.
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 names the operation and resource: 'Update WordPress settings.' It distinguishes this from the many post/page/media tools in the sibling list, though it does not explicitly contrast with wp_get_settings or other settings-related tools. The added front-page note gives useful specificity about 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?
No guidance is provided on when to use this tool versus alternatives such as wp_get_settings, wp_update_post, or wp_update_page. The description implies it is for updating site-wide WordPress settings but does not state prerequisites, exclusions, or when a different update tool 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?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It states that content is inserted before or after an existing shortcode, but it does not mention side effects, failure behavior when the anchor is missing, the meaning of occurrence, or whether dry_run prevents writes.
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 and the core action is front-loaded. It is appropriately concise for what it communicates.
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 write operation with no annotations and no output schema, yet the description only covers the basic insertion action. It lacks context about return values, error conditions, ambiguous anchors, and the effect of occurrence or attribute matching, so an agent is under-informed before invoking it.
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 high (88%), so the baseline is 3. The description adds little parameter-specific meaning beyond what the schema already provides, though it does implicitly map to new_content, anchor_tag, and position.
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 names a specific action ('Insert'), a specific target ('existing shortcode'), and a scope ('in a page'). It is easy to tell apart from sibling tools like wp_replace_shortcode, but it does not explicitly call out that distinction.
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 choose this tool over alternatives like wp_replace_shortcode or wp_elementor_update_shortcode_content. It also omits prerequisites, such as the requirement that the anchor shortcode already exists in the page.
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 behavioral burden. It only states that categories are listed and which fields are returned; it does not disclose pagination behavior, handling of empty categories, hierarchical nesting, ordering, or authentication considerations.
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, resource, and key return fields, making it very easy to parse.
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 has no annotations or output schema, and three of five parameters are unexplained by either schema or description. The description gives a partial picture of the return payload but lacks enough context about filtering, pagination, and empty-category behavior for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description adds no meaning for the undocumented parameters parent, search, and hide_empty. page and per_page are already explained by the schema; the description does not compensate for the remaining coverage gap.
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 ('List WordPress categories') and names the returned fields: IDs, slugs, and usage counts. This clearly distinguishes it from sibling tools like wp_list_pages, wp_list_posts, and wp_list_tags.
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 such as wp_list_tags or wp_list_pages. There are no exclusions, prerequisites, or context notes to help an agent choose this over other listing tools.
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. 'Parse and list' implies a non-destructive operation, but the description never explicitly confirms the page content is unmodified, discloses failure behavior (page not found, both identifiers provided, or no identifiers given), or hints at the return format—especially problematic since there is no output schema to fall back on.
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 short sentences with the core function front-loaded; there is no fluff or redundant restating of the tool name. The second sentence, 'Useful for understanding page structure,' is somewhat generic but still adds a mild use-case rationale, so the structure earns solid marks without being exemplary.
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 tool with no output schema, no annotations, and three optional parameters, the description leaves significant gaps: it doesn't explain what the returned list looks like, how an agent should identify the page (prefer page_id vs page_slug, or neither), or what happens if no page matches. Given the low complexity, more could easily have been said.
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 (page_id, page_slug, filter_tag). The description adds no meaning beyond the schema—it doesn't clarify precedence between page_id and page_slug, whether filter_tag matches exact tags only, or whether the parameters are combinable. Baseline 3 applies.
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+resource: 'Parse and list all shortcodes found in a page's content.' The verb 'list' signals a read/enumeration operation, which visually distinguishes it from mutation siblings like wp_insert_shortcode and wp_replace_shortcode. However, it doesn't explicitly differentiate itself from wp_elementor_get_shortcode_content, another read-oriented shortcode tool, so it falls 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?
The only guidance is 'Useful for understanding page structure,' which is a vague rationale rather than actionable when-to-use direction. It never tells an agent when to pick this tool over the several shortcode-related siblings (wp_elementor_get_shortcode_content, wp_replace_shortcode, wp_insert_shortcode), and gives no 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, the description carries the full burden, but it only discloses that the tool replaces content and may filter by attribute. It does not state what happens to the original shortcode, whether changes are reversible, required permissions, failure behavior when no match is found, or that dry_run can preview the change.
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 no filler. It states the core action immediately and adds the optional matching behavior in a second clause. Every word contributes.
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 mutating tool with 7 parameters, no annotations, and no output schema. The description is too sparse to fully support invocation: it omits expected return values, error cases, permission requirements, and how occurrence/disambiguation rules affect the operation, though the schema does fill in some parameter details.
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%, so the baseline is 3. The description adds minimal context by tying 'specific shortcode' to the tag parameter and 'optionally match an attribute value' to match_attr/match_value, but most parameter meaning already exists in the schema.
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 clear verb ('replace') and resource ('specific shortcode in a page'), and the optional attribute matching adds precision. It is distinguishable from sibling tools like wp_insert_shortcode or wp_list_shortcodes, though it does not explicitly name alternatives such as wp_elementor_update_shortcode_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?
There is no guidance about when to use this tool versus alternatives like wp_insert_shortcode, wp_elementor_update_shortcode_content, or wp_blocks_replace. The description implies a use case ('specific shortcode', 'optionally match attribute value') but never states exclusions or selection criteria.
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 adds useful context by mentioning the preference for the wp-mcp companion endpoint and that the fallback 'rewrites core REST title, excerpt, and content'. However, it omits important behavioral details such as whether the restoration overwrites the current post, creates a new revision, requires specific permissions, or has failure conditions.
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 concise, using two sentences with no filler. The action is front-loaded, and the fallback behavior is stated efficiently. The phrase 'optional wp-mcp companion endpoint' is somewhat cryptic, but overall every sentence 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?
For a potentially destructive operation with 5 parameters, no annotations, and no output schema, the description is under-specified. It doesn't explain the effect on the current post, what the response looks like, how dry_run works, or what ref refers to. An agent would need to infer critical invocation details from the parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description adds no parameter-level meaning. It does not explain the roles of ref, revision_id, post_type, or how dry_run and if_unmodified_since affect the restore operation. With such low schema coverage, the description needed to compensate but did not.
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 the operation as 'Restore a revision', using a specific verb and resource. It also distinguishes itself from sibling revision tools like wp_list_revisions, wp_get_revision, and wp_diff_revision by implying this tool performs a write/restore action rather than inspection. However, it doesn't fully clarify whether the restoration is limited to title, excerpt, and content or is broader.
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_get_revision, wp_update_post, or other update tools. It mentions the fallback mechanism but doesn't state prerequisites, exclusions, or conditions that would help an agent choose this tool over 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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only mentions dry-run capability and the verb 'update,' leaving out details such as whether the update is partial or full, whether existing fields are overwritten, or what the response contains. This is insufficient 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 extremely concise at two short sentences, with no filler or repeated schema content. It front-loads the action and adds a useful feature note. It is efficient, though it could offer slightly more useful detail without harming conciseness.
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 6-parameter mutation tool with no annotations and no output schema, this description is incomplete. An agent would not know whether updates are partial, what fields are actually updated, what side effects occur, or what the return value looks like. The dry-run note is helpful but not enough to make the tool safely invocable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, with only dry_run described as 'Preview changes without writing.' The description adds no extra meaning for id, slug, title, status, or content beyond their names. Because the schema leaves most parameters undocumented, the description should compensate but does not.
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 clear verb and resource: 'Update synced pattern.' This differentiates it from sibling tools like wp_create_synced_pattern, wp_get_synced_pattern, and wp_delete_synced_pattern. It does not elaborate on scope, but the core action 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 sentence 'Supports dry-run' implies a workflow where the user can preview changes, giving some usage context. However, it provides no explicit when-to-use guidance or exclusions relative to similar update tools such as wp_update_content_block or wp_update_post. Usage must be inferred from the tool name and siblings.
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 for behavioral disclosure. It does reveal that dry-run previews are supported, which is useful and not obvious from the function name. However, it does not disclose side effects of actual creation, required authorization, default behavior, or what happens on success or 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?
The description is two short sentences with no filler. The core purpose is front-loaded, and the dry-run capability is stated efficiently. Every word contributes meaningful information.
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 creation tool with 12 parameters, no output schema, and no annotations, this description is incomplete. An agent gets no sense of required inputs beyond the schema, what the dry-run preview returns, how mutating the action is, or what a successful creation response looks like. The sparse context leaves important operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 8% (only dry_run has a description), yet the description does not compensate for the other 11 undocumented parameters. It adds some meaning by mentioning dry-run previews, which maps to the dry_run parameter, but it provides no semantic detail for title, slug, status, content, parent, or other fields.
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 and resource ('Create a WordPress page'), clearly identifying what the tool does and distinguishing it from sibling tools like wp_create_post. It also adds the non-obvious dry-run preview capability. It is clear, though it does not explicitly contrast itself with other siblings in the description.
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_create_post, wp_update_page, or wp_get_page. There is no mention of exclusions, prerequisites, or when to prefer a sibling tool. The intended use is only implied by the tool's name and basic statement.
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 burden of disclosing destructive behavior. 'Permanently delete' conveys irreversibility, which is useful, but it omits other behavioral context such as auth requirements, effects on related data, or confirmation 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, front-loaded sentence with no filler. Every word adds meaning: 'Permanently' signals irreversibility, 'delete' the action, and 'classic menu item' the target resource.
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 is destructive, has 3 parameters, no annotations, and no output schema. The description is too sparse to fully support correct invocation; it does not mention how to use dry_run, what confirms success, or any prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%. The description adds no meaning for the required 'id' parameter or the 'force' parameter, and the only parameter with a schema description is 'dry_run'. The description does not compensate for the low coverage.
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 clear verb and resource: 'Permanently delete a classic menu item.' It distinguishes the tool from wp_delete_menu by specifying it deletes an item rather than a whole menu, though it does not explicitly name that sibling.
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 wp_update_menu_item, wp_get_menu_item, or wp_delete_menu. The intended context is only implied by the verb 'delete'.
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. The 'raw' qualifier adds genuine context that title/excerpt/content are unfiltered revision values, distinguishing the output from regular post/page getters. However, it does not address permissions, what 'raw' entails, or behavior when the revision or ref is invalid.
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 14-word sentence that front-loads the verb and resource, lists the return fields compactly, and wastes no words. Every part of the sentence 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?
For a 3-parameter tool with no annotations and no output schema, this is too thin. The semantics of the two required parameters, the default post_type behavior, and the relationship to sibling get/revision tools are all missing, so an agent lacks what it needs to call the tool correctly on the first attempt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate — and it largely does not. 'ref' and 'revision_id', and how they relate, are completely unexplained; only the 'post/page' phrase hints at the post_type enum. An agent cannot reliably determine what 'ref' refers to.
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 ('Get'), a distinct resource ('one post/page revision'), and the returned contents (raw title, excerpt, and content). The qualifier 'one' implicitly separates it from wp_list_revisions, but it never names a sibling explicitly, so it stops short of full 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 when-to-use guidance is provided. The description does not say when fetching a revision is preferable to wp_get_post/wp_get_page, nor how it relates to wp_list_revisions, wp_diff_revision, or wp_restore_revision. Nothing is misleading, but the agent must infer the workflow 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?
No annotations are provided, so the description carries the full behavioral burden. It states 'read-only' (indicating no mutation) and 'optionally filter client-side' (implying the server returns all patterns and filtering happens locally). This adds some transparency, but it doesn't disclose return format, pagination, or any auth requirements. For a simple listing tool, this is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the primary action and scope. The phrase 'optionally filter client-side' is efficient and adds value without excess. No redundant wording.
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 with optional filters and no output schema, the description is adequate but not complete. It lacks explicit differentiation from similar listing tools (e.g., wp_list_synced_patterns) and doesn't mention what the returned data contains. However, given the name and context, an agent can likely call it correctly. It could be improved by stating that it returns block patterns (not synced patterns) and noting the absence of server-side filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not elaborate on any of the three optional parameters (search, source, category). 'Optionally filter client-side' hints at filtering but doesn't specify which parameters enable which filters. With 0% coverage, the description fails to compensate for the schema's bare definitions.
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?
Description states a specific verb (List), resource (registered read-only core, theme, and plugin patterns), and scope of filtering. It clearly distinguishes from siblings like wp_list_synced_patterns (synced patterns) and wp_blocks_list (content blocks) by specifying 'block patterns' and 'read-only'.
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 vs alternatives. It does not mention exclusions or provide context about related tools (e.g., wp_list_synced_patterns for synced patterns, wp_get_block_pattern for a single pattern). The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states that the tool lists pages, but does not mention pagination behavior, default ordering, status handling, filtering specifics, or whether the results are limited to certain page types. Some output shape is given, but broader runtime behavior is left unspecified.
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 efficiently conveys the core purpose and expected output fields, earning its place without unnecessary 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 list tool with seven parameters, no annotations, and no output schema, the description is minimal but not wholly insufficient. The purpose is clear and the schema fills in most parameter meaning, yet the absence of behavioral context and usage differentiation leaves an agent with notable inference work.
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 71%, so the schema already explains most parameters. The description adds no parameter-level semantics beyond indicating the returned fields, which are not parameters. This is adequate but does not meaningfully improve on the schema.
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 the action ('List'), the resource ('WordPress pages'), and the fields returned (ID, title, slug, status). It is easy to distinguish from related list tools like wp_list_posts, though it does not explicitly name sibling alternatives.
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 on when to use this tool versus alternatives such as wp_get_page for a single page or wp_list_posts for posts. The use case is only implied by the name and short description, with no exclusions or routing cues.
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 behavioral traits. It only states that it lists patterns; it does not mention that it is a read-only operation, nor does it describe pagination, default ordering, filtering behavior, or any potential side effects. The agent is left to assume it is a safe list operation without explicit assurance.
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, clear sentence that immediately states the purpose and scope. There is no redundancy, and the core action is front-loaded. This is an exemplary model of conciseness.
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 has 6 optional parameters and no output schema, yet the description provides no information about the return format, filtering options, or default behavior beyond what the schema already conveys. It also does not distinguish this listing tool from the many sibling list tools, leaving potential ambiguity. For a simple list operation, it is minimally adequate but lacks completeness for an agent to use it with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (page and per_page have descriptions), and the tool description adds no explanation of any parameters. It does not clarify what 'search', 'status', 'orderby', or 'order' do beyond their enum values in the schema. Given the low coverage, the description must compensate but fails to do so, leaving parameter semantics largely undocumented.
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 identifies the action (List) and the resource (reusable synced patterns stored in wp_block), which is a specific subset distinct from other list tools like wp_list_pages or wp_list_block_patterns. The use of 'synced patterns' and the storage location adds precision that separates it from generic block pattern listings.
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 implied by the description's specificity, but there is no explicit statement about when to use this tool versus alternatives such as wp_list_block_patterns or wp_list_posts. No exclusions or alternative references are provided, leaving the agent to infer based on 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?
With no annotations, the description must carry behavioral disclosure, but it only states what is listed. It does not mention that the operation is read-only, how pagination/search/hide_empty behave, or any ordering or response-size semantics.
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 front-loaded sentence with no filler and communicates the core action immediately. It could be more detailed, but the brevity itself is not a structural problem.
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 four-parameter tool with no annotations and no output schema, the description plus partial schema is only minimally adequate. An agent can list tags with defaults, but cannot learn what hide_empty/search do or what the full response shape is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only page and per_page have schema descriptions; search and hide_empty are undocumented in the schema, and the description adds no parameter information. Mentioning IDs, slugs, and usage counts describes output fields, not how to fill 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 uses the specific verb 'List' with the resource 'WordPress tags' and names concrete output fields (IDs, slugs, usage counts), so an agent can clearly identify this as the tag-listing tool among the WordPress siblings.
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 choose this tool over alternatives or which conditions favor it, such as needing a paginated tag list versus managing a single tag. Usage is only implied by the verb and resource name.
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 useful behavior: it reads the current protected page option and supports dry-run. However, it does not clarify the 'optional companion' dependency, permissions, failure modes, or side effects of writing the layout.
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 concise and front-loaded with the main purpose. The second sentence adds behavioral value. The phrase 'optional companion' is vague but does not add length; the overall structure is efficient.
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 mutation tool with no annotations and no output schema, this description is under-specified. It does not explain the 'optional companion' requirement, what the tool returns, how to confirm the change, or when this should be used instead of other page tools. The dry-run mention helps but is not enough.
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 only 33%, so the description must compensate. It does partially: it explains sidebar values (right, left, no sidebar) and connects the action to a page. However, page_id and the dry-run behavior are not explained beyond the schema, leaving a meaningful gap.
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 a specific action and resource: setting a Blocksy page's sidebar layout to right, left, or none. It is distinct from the sibling tools, though it does not explicitly differentiate itself from alternative page-modification tools.
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_page, wp_get_page, or wp_list_sidebars. There are no contextual triggers, exclusions, or fallback instructions.
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 disclose behavioral traits on its own. It only says 'Assign' without mentioning that this overwrites an existing featured image, whether it requires authentication, what happens on invalid ref/media_id, or how dry_run affects execution. These are meaningful side effects an agent needs to know.
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 or repeated information. It communicates the core purpose efficiently and every word contributes to meaning.
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 mutation tool with no annotations and no output schema, yet it leaves key invocation details undocumented: what ref accepts, behavior of dry_run, overwriting semantics, and failure scenarios. An agent cannot reliably predict the tool's full behavior from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description carries the burden of explaining parameters, but it only clarifies that the operation applies to a 'post or page' (matching post_type). It does not explain that ref is likely a post/page ID or slug, what media_id refers to beyond being 'media', or the role of dry_run beyond the schema's terse text.
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 ('Assign') on a specific resource ('media attachment') and where it applies ('as the featured image of a post or page'). It clearly distinguishes this from sibling tools like wp_update_media or wp_get_post, since no other tool appears to handle featured-image assignment.
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, nor does it mention prerequisites such as the post/page existing or the media attachment being uploaded. With dozens of sibling tools around posts and media, the lack of any routing or exclusion information leaves 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.
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 that only selected fields are changed, which is useful, but it does not mention permissions, reversibility, concurrency checks like if_unmodified_since, dry-run behavior, or what response to expect. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence. It front-loads the action and resource, then adds the key identification detail without any filler or redundancy.
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 complex tool with 14 parameters, no annotations, and no output schema, yet the description provides only a one-line overview. It does not cover required prerequisites, parameter relationships, or behavior details, so an agent would be under-informed when invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, so the description must compensate for the remaining undocumented parameters. It adds meaning for 'ref' by clarifying that it can be an ID or slug, but it does not explain the other 12 parameters such as status, date_gmt, menu_order, or featured_media.
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'), a clear resource ('WordPress page'), and the identification methods ('by ID or slug'). It distinguishes this tool from siblings like wp_get_page (read) and wp_update_page_content (content-only update) by indicating it updates selected fields.
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 such as wp_update_post, wp_update_page_content, or wp_create_page. There are no explicit conditions, exclusions, or naming of sibling tools, so an agent has to infer appropriate usage.
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 restates that an update happens and how the target is identified. It does not mention authentication requirements, error behavior when the post is missing, side effects on omitted fields, or whether the operation is reversible.
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 one front-loaded sentence with no filler. It places the action and target first, and every word adds information.
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 14-parameter mutation tool with no annotations and no output schema, this description is far from complete. It omits return behavior, failure modes, permissions, field semantics, and any relationship to the many similar sibling update tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, so the description needed to compensate, but it adds only 'by ID or slug' for ref and the generic notion of 'selected fields.' It does not explain the meaning or format of most of the 14 parameters; names are guessable but not documented.
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 ('Update selected fields'), a clear resource ('WordPress post'), and the two allowed target modes ('by ID or slug'). This is enough to distinguish it from read/create/delete siblings such as wp_get_post, wp_create_post, and wp_delete_post.
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 prefer this tool over close siblings like wp_update_post_content or wp_update_page, and no when-not-to-use conditions. The phrase 'selected fields' weakly implies partial updates, but no explicit context or alternatives are provided.
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?
The description discloses that the tool returns paths and hashes and frames itself as a precursor to edits, which suggests a read-only operation. However, with no annotations provided, the description does not explicitly state the absence of side effects, any authentication requirements, or how matching behaves. It gives a partial behavioral picture but not a complete one.
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, focused sentence. It front-loads the action and outcome, and every phrase adds value — 'all matching Gutenberg blocks' defines scope, while 'return paths and hashes for safe follow-up edits' conveys the key output and purpose without redundancy.
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 tool with a nested query object, no output schema, and no annotations, the description is too sparse to be complete. It omits details about how matching works, the format of the returned paths/hashes, the meaning of include_html, and whether the operation is fully read-only. The one-line description leaves too much for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 25% — only ref has a description in the schema. The description itself does not compensate by explaining the nested query object (block, contains, attrs_match) or the post_type and include_html parameters. An agent must rely on parameter names and infer semantics, which is risky for the query object.
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 action ('Find') and resource ('Gutenberg blocks'), and it is clear that this is a search/locate operation rather than a list/get/delete/modify operation. The mention of returning 'paths and hashes' further clarifies its purpose. However, it does not explicitly distinguish itself from sibling tools like wp_blocks_list or wp_blocks_get.
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 'for safe follow-up edits' implies this tool should be used before modifying blocks, providing some contextual guidance. But it does not explicitly state when to choose this tool over alternatives such as wp_blocks_list or wp_blocks_get, nor does it give any when-not-to-use 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?
No annotations are present, so the description carries the burden. It usefully discloses optimistic concurrency protection via hash references and dry-run support, but it does not describe failure behavior, side effects, or whether the operation can be partially applied.
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 carry the core message with no filler. The primary action is front-loaded, followed by the two most operationally relevant behaviors: hash safety and dry-run.
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 complex mutation tool with 8 parameters, rich selector unions, and no output schema, but the description provides only one sentence of operational context. An agent would need to infer most invocation semantics from the schema alone, leaving significant gaps around selectors, position behavior, and success/error outcomes.
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 50%, and the description adds meaningful context for hash-based references ('prevent overwriting a block changed since it was read'). However, it does not clarify the at selector variants, block structure, position values, or normalization behavior 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 clearly states 'Insert Gutenberg block(s)', giving a specific verb and resource. It distinguishes the insert operation from update/replace/move by name, though it does not explicitly reference any sibling tool.
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 wp_blocks_replace, wp_blocks_update, or wp_blocks_move. The mention of hash references and dry-run are safety features, not criteria for choosing this tool over 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?
No annotations are provided, so the description carries the full burden. It indicates a read operation via 'Get', but it does not disclose return behavior, error cases, what 'classic' means, or whether any side effects occur. This is a very thin behavioral description.
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 tight sentence with no filler. It is appropriately front-loaded for a simple tool and every word contributes meaning.
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 minimally viable for a tool with one clearly required parameter. However, it omits clarification of the 'classic' qualifier and provides no return or error context, which is a noticeable gap given there is no output schema and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. It does not explicitly state that the item is identified by 'id' or explain the meaning or constraints of the id beyond what the schema already shows.
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 resource ('menu item'), and a singular scope ('one'), clearly distinguishing it from sibling tools like wp_list_menu_items, wp_create_menu_item, and wp_get_menu. The qualifier 'classic' adds useful differentiation from block-based menu items.
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_list_menu_items or wp_get_menu. No prerequisites or exclusions are provided, so the 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 must disclose behavior. It mentions the return content but does not state that the operation is read-only, what happens on invalid ID, or any error conditions. The word 'Get' implies read-only but it is not 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 begins with the action verb 'Get' and lists the key deliverables without extraneous text.
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 enumerates the returned data categories but lacks an output schema and does not specify error handling, permission requirements, or the structure of the returned data. It is sufficient for a simple getter but incomplete for robust agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'id' parameter at all, and the schema provides no description for it. Since schema coverage is 0%, the description should at least indicate that the id identifies the widget to retrieve, but it does not.
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 retrieves a single widget and enumerates the pieces of information it provides (rendered output, raw instance, sidebar, and advertisement metadata). This distinguishes it from wp_list_widgets which lists widgets.
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 offers no guidance on when to use this tool over alternatives. It does not mention that it retrieves a single widget by ID or contrast with listing operations.
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 behavior, but it only mentions returned fields. It does not disclose pagination behavior, default per_page limit of 20, read-only nature, ordering defaults, or any side effects. This is a significant gap for a list operation with multiple filters.
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 wasted words. It front-loads the action and resource, and every word contributes to the core meaning.
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 tool with 9 optional parameters, no annotations, and no output schema, this description is incomplete. It does not mention filtering by status, tags, categories, author, or search, nor does it explain pagination or the shape of the response beyond four fields. An agent would not know how to perform common filtered listing tasks without opening the schema.
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 78%, which is near the high baseline, and the description adds no parameter-level meaning. The parameters are mostly documented in the schema, so the description does not need to repeat them, but it also does not clarify ambiguous ones like orderby or how filters combine.
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'), resource ('WordPress posts'), and the key return fields (ID, title, slug, status). It clearly distinguishes this from sibling list tools like wp_list_pages and wp_list_media by naming posts explicitly.
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 such as wp_get_post for a single post or wp_list_pages for pages. There is no mention of exclusions, prerequisites, or conditions that would route an agent to a sibling tool.
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 behavioral disclosure burden. It adds a valuable behavioral detail — 'position is a zero-based final index' — but it does not disclose the mutation's side effects on other widgets, persistence, or required permissions, leaving meaningful behavioral gaps for a write 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?
Two short sentences, with the operation stated first and the key index semantics second. Every sentence earns its place and there is no filler.
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 mutating tool with no annotations and no output schema, the description is incomplete: it doesn't explain how to obtain valid widget/sidebar IDs, what the operation returns, or what happens during a dry run vs. a real move. The dry_run parameter is documented in the schema, but overall context is sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25%, so the description must compensate for undocumented parameters. It clarifies 'position' semantics beyond the schema, but leaves 'id' and 'sidebar' undefined; an agent is not told how to identify or discover valid widget and sidebar identifiers.
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 ('Move') and resource ('widget') and adds the sidebar context, making the core operation clear. It does not explicitly distinguish itself from sibling widget tools such as wp_update_widget or wp_delete_widget, but the repositioning focus is evident from the wording and the position parameter.
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 repositioning a widget via 'Move and precisely order,' so an agent can infer the primary use case. It gives no explicit when-to-use/when-not-to-use guidance or alternatives, unlike a stronger definition that would direct users away from update/delete/create 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic retrieval action and identification methods. It does not disclose what happens if no block is found, if multiple blocks match an 'unambiguous query', or whether any side effects exist. It also omits error handling, permissions, or response format details. This minimal disclosure falls short for a tool with no annotations.
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 packed sentence. It front-loads the action and resource, then lists the identification criteria efficiently. There is no fluff or redundancy; 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?
The tool has a complex 'at' parameter with five variants, four total parameters, no output schema, and no annotations. The description does not mention return values, error behavior, default post_type, or how include_html affects the result. It is too brief to be complete for an agent to call it correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'ref' has a description). The description adds meaning for the 'at' parameter by listing its possible discriminators, but it does not explain the structure of the 'at' object or the other parameters like post_type and include_html. Given the low schema coverage, the description should compensate but only partially does, leaving the post_type default and include_html semantics undocumented.
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 ('Get'), the resource ('one Gutenberg block'), and five explicit identification criteria (path, hash, anchor, metadata name, unambiguous query). This distinguishes it from sibling tools like wp_blocks_list (which lists multiple) and wp_blocks_find (which likely finds matches). The singular 'one' emphasizes a single-object retrieval, setting it apart from list/find 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 when to use the tool: when you have a specific identifier (path, hash, anchor, name, or query). However, it does not explicitly state when not to use it or mention alternatives such as wp_blocks_find or wp_blocks_list. The guidance is implied rather than explicit, and no exclusions or comparative conditions are provided.
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 must disclose side effects itself. It clearly says posts are created and that dry-run previews avoid writing. However, it does not explain default status behavior, whether the post is immediately published, or what permissions or side effects are involved.
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 the core action front-loaded. Every word earns its place, and there is no redundant framing or filler.
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 12-parameter mutation tool with no output schema, no annotations, and low schema coverage, this description is far too minimal. An agent could infer the basic creation intent but lacks enough context about required inputs, status handling, and how dry-run output differs from real creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 8%, so the description should compensate for the 12 undocumented parameters, but it does not. 'Supports dry-run previews' only restates the dry_run parameter's existing schema description; title, status, categories, tags, author, and other fields are left entirely to inference.
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: 'Create a WordPress post.' This is unambiguous against siblings like wp_create_page and wp_update_post, and the noun 'post' clearly differentiates it from page/category/tag creation tools.
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 use this tool instead of alternatives. Sibling names imply a choice between post/page/category creation and update/delete flows, but the description does not help an agent decide.
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. 'Permanently' usefully discloses irreversibility and aligns with the schema's force: true. However, it omits other behavioral traits: what happens to posts in the deleted category, permission requirements, or that dry_run can preview the deletion safely.
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 five-word sentence, front-loaded with the action and resource. No filler or redundant detail.
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 operation with no annotations and no output schema, this one-liner is insufficient. It leaves out critical safety context: side effects on posts, inability to delete the default category, and the dry_run preview option. The agent gets the core action but not enough to invoke it safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only dry_run has a description). The tool description adds no parameter meaning: it does not explain id or force. The force const:true is inferable from the schema, but the description should compensate for the low coverage and does not.
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 clear resource ('WordPress category'), and a key qualifier ('Permanently'). This distinguishes it from sibling tools like wp_delete_tag, wp_delete_post, and wp_delete_page by naming the exact resource type.
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. It does not mention wp_delete_tag for tags, nor does it warn about constraints like deleting the default category. The intended use is only implied by the name and description.
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 does disclose key behavior: the deletion is permanent and WordPress requires force:true. However, it omits side effects, error conditions, and permission requirements, so coverage is partial.
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 the core action front-loaded and no wasted words. It packs the key behavior and a necessary invocation requirement concisely.
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 annotations and no output schema, this description is too sparse. It fails to clarify what ref should contain, what happens after deletion, or what responses/errors to expect, leaving the agent to guess important invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate for the undocumented ref and force parameters. It adds context for force ('WordPress requires force:true') but leaves ref completely unexplained beyond its schema type, which is a critical gap.
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: 'Permanently delete a classic menu'. This clearly distinguishes it from sibling delete tools like wp_delete_post or wp_delete_tag by naming the exact target resource.
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 vs alternatives such as wp_delete_menu_item or wp_delete_widget. The phrase 'classic menu' hints at a context, but there is no explicit when-to-use or exclusion 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, the description carries the burden of disclosing behavior. It does communicate the critical trait that deletion is permanent, but it does not explain side effects, whether the tag is removed from posts, required permissions, or what happens after deletion.
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 essential action and scope in five words, which is ideal for conciseness.
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?
As a destructive operation with no annotations, no output schema, and only 33% parameter documentation, the description is not complete enough. It omits return behavior, side effects, error conditions, and any mention of dry_run or force even though those affect invocation and safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documentation covers only dry_run, leaving id and force undocumented. The description does not explain the id parameter or the force behavior, though 'Permanently' loosely aligns with the force:true constraint. This is minimal compensation for the low 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 ('delete'), a specific resource ('WordPress tag'), and adds 'Permanently' to clarify the deletion is irreversible. This clearly distinguishes it from update/create/ensure tag tools and from deleting other WordPress resources.
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 on when to use this tool versus alternatives like wp_update_tag, wp_ensure_tag, or a soft-delete/trash flow. The only usage signal is the verb 'delete', but no alternative paths or exclusions are mentioned.
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 conveys that the tool returns menus and their theme locations, and 'list' implies a read operation, but it does not mention pagination behavior, response shape, or any access considerations.
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 focused sentence with no filler. It front-loads the action and resource, and every word contributes to understanding what the tool does.
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?
There is no output schema and no annotations, so the description is the only source of context. It names the result categories but omits return format, pagination details, and relationship between menus and theme locations, leaving an agent underinformed for a tool with five optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%; page and per_page are documented in the schema, but order, search, and orderby are not. The description adds no parameter-level meaning and does not compensate for the undocumented parameters.
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 specific resource ('classic navigation menus'), and adds 'assigned theme locations' to clarify scope. The word 'classic' helps distinguish this from other menu-related tools such as block-menu operations.
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 explicit guidance about when to use this tool versus alternatives like wp_get_menu or wp_list_menu_locations. It implies a list-style usage, but it does not state exclusions or preferred conditions.
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 present, the description carries the full burden of behavioral disclosure. It only mentions pagination and the post/page scope, but does not disclose read-only behavior, ordering, what 'ref' identifies, authentication requirements, or the shape of the response. This is too thin for a tool with no annotation support.
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 wasted words. The core action is front-loaded ('List revisions'), and the optional pagination behavior is stated compactly. This is an ideal size for the information it conveys.
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 that the tool has 4 parameters, no output schema, and no annotations, the description is too sparse to be complete. It does not explain the required ref parameter, the pagination semantics beyond the word 'pagination', or what the returned revision list looks like. An agent would need to open the schema and guess at the ref format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some semantic clues: 'post or page' maps to the post_type parameter and 'pagination' maps to page/per_page. However, schema coverage is only 50% and the required 'ref' parameter is left completely unexplained — the description never clarifies whether it expects an ID, slug, or something else. The partial compensation is insufficient for the required 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?
The description states a specific verb ('List') and resource ('revisions of a WordPress post or page'), making the tool's purpose immediately clear. It also naturally distinguishes itself from sibling tools like wp_get_revision, wp_diff_revision, and wp_restore_revision by signaling a list operation rather than a single-item, diff, or restore operation.
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 need to retrieve multiple revisions for a post or page. However, it provides no explicit guidance about when NOT to use it, such as preferring wp_get_revision for a single revision or wp_restore_revision for reverting, so the routing burden falls entirely on the agent.
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 must carry the behavioral burden. It conveys a read-style listing operation and hints at return content ('including structured advertisement inventory metadata'), but does not disclose return shape, pagination, error behavior, or whether any side effects 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 sentence with no filler: the action, optional filter, and a distinguishing output detail are all front-loaded. Every phrase 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?
For a simple list tool with one optional parameter and no annotations, the description is functional but minimal. It lacks return-format details and does not reference sibling tools that could disambiguate the sidebar value, though the low complexity keeps this from being a major 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 coverage is 0%, so the description must clarify the parameter. It does add meaning by marking sidebar as optional and as a filter, but it does not specify whether the value is an ID, slug, or name, or how it relates to wp_list_sidebars.
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 resource ('widgets'), and adds a filtering dimension ('optionally by sidebar'). It is clearly distinct from sibling tools like wp_get_widget or wp_list_sidebars, though it does not explicitly name an alternative.
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 prefer this tool over siblings such as wp_get_widget or wp_list_sidebars, and there are no stated exclusions or prerequisites. The only contextual cue is the optional sidebar parameter, which is not framed as a decision rule.
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 for behavioral disclosure. It mentions a two-step process (upload and set attachment metadata) but omits side effects, required permissions, reversibility, or any mention of the dry_run parameter's preview behavior. An agent cannot infer what gets written or changed.
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 verb and object, and every phrase contributes meaning. There is no filler, repetition, or tangential information.
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 9 parameters, no annotations, and no output schema, a description that only states the core action is insufficient. It lacks usage guidance, parameter semantics, and behavioral side effects, so an agent would need to investigate the schema and sibling tools to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, making the description responsible for compensating. It vaguely summarizes parameters as 'set attachment metadata' without naming title, caption, alt_text, description, post, filename, mime_type, or dry_run. The source types are already explicit in the schema, so the description adds little beyond what the schema already shows.
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?
Description uses a specific verb and resource ('Upload media') and adds source variants ('local path, URL, or base64 source') and a secondary action ('then set attachment metadata'). This clearly distinguishes it from sibling tools like wp_list_media, wp_get_media, wp_update_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 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 an agent needs to upload media from a local path, URL, or base64 source. However, it provides no explicit guidance about alternatives or exclusions, such as using wp_update_media for existing media or wp_set_featured_image for featured images.
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 dry-run support and automatic cache purge, which are meaningful behavioral traits beyond a bare 'create.' However, it does not disclose success/return behavior, required sidebar context, or what happens when neither block_content nor ad_creative is supplied.
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 front-load the purpose, then state the critical one-of constraint, then mention supported behaviors. There is no filler, repetition, or unnecessary detail.
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?
There are no annotations and no output schema, while the tool has a nested ad_creative object and several parameters. The description gives useful hints but omits required sidebar context, expected return value, and enough detail to confidently construct ad_creative or block_content. An agent would need to consult external knowledge to call this 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 low (20%), so the description must compensate. It adds the important exactly-one-of constraint and flags ad_creative as structured, which is not fully encoded in the schema. But it leaves sidebar, block_content format, and ad_creative subfields to be inferred from the schema.
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: 'Create a block widget.' This clearly differentiates it from widget update/get/delete/move siblings. It does not explicitly contrast with wp_blocks_insert or block-content tools, so differentiation is somewhat implied rather than fully explicit.
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 use when creating a new block widget and clarifies the one-of block_content/ad_creative input constraint. However, it gives no explicit guidance on when to prefer this tool over alternatives like wp_update_widget or wp_blocks_insert, and it lacks any when-not-to-use 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, the description carries the burden of behavioral disclosure. It does say the tool lists existing blocks and explicitly does not create positioning slots, which is useful non-mutation context. However, it omits other behavior an agent might need, such as response shape, empty-result behavior, pagination semantics, or any auth/read-only guarantees.
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 compact and front-loaded: the first sentence states the main action and key output features, and the second clarifies a non-creation boundary. Some jargon such as 'hook clues' and 'positioning slots' is undefined, but the overall length is well controlled.
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 list tool with optional filters and no output schema, the description communicates the core purpose and one boundary. It is missing usage guidance and any detail about return format or how search/status filters behave, so it is minimally 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 50%; page and per_page already have descriptions, and status has a self-documenting enum while search is inferable from its name. The description itself adds no parameter-level meaning, but it also does not mislead. This is adequate but not compensatory.
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: 'List existing Blocksy Content Blocks.' It also adds output details (slug/hook clues, structured advertisement inventory), which helps distinguish this listing tool from singular get/update siblings like wp_get_content_block and wp_update_content_block.
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 does not state when to choose this tool over alternatives such as wp_get_content_block, wp_blocks_list, or wp_update_content_block. It gives a negative hint ('Does not create positioning slots') but no explicit when-to-use or when-not-to-use 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, the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description doesn't state whether the call has side effects, requires authentication, or returns cached data.
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 or repetition. It is appropriately sized for a zero-parameter informational 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?
The tool is simple and has no parameters or output schema, so the description does not need to cover arguments. However, it doesn't enumerate what 'basic WordPress site information' includes, which is a meaningful gap for an agent deciding whether this tool returns the needed data.
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 coverage is effectively 100% since the schema is an empty object. There is nothing for the description to clarify about parameters, so the baseline score of 4 applies.
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 a getter for WordPress site information, using a specific verb and resource. However, 'basic WordPress site information' is vague about what fields are included, and it doesn't explicitly differentiate from related tools like wp_get_settings or wp_whoami.
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. The description does not mention exclusions or sibling tools, leaving the agent to infer that this is the default for site info.
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 burden of behavioral disclosure. 'Returns raw content' gives useful return-value context, and 'Get' implies a read operation, but it does not mention error behavior, authentication, or whether raw means unrendered/unfiltered content. It is 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?
Two short sentences with no filler. The core action and return type are front-loaded, and 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?
For a simple getter, the description covers what it returns, but it omits any guidance on when to use this instead of related getters and does not clarify that id/ref are alternate identifiers or whether at least one is expected. The lack of an output schema makes the raw-content note helpful, but gaps remain.
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 the schema already documents both id and ref. The description adds no parameter-level meaning beyond that; saying 'by ID' slightly underplays ref's slug support, though the schema clarifies it.
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 and resource ('Get full content of a WordPress post') and usefully notes the return type ('Returns raw content'). It does not explicitly distinguish this from close siblings like wp_get_page or wp_get_revision, and 'by ID' understates the fact that ref can also be a slug.
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 wording implies this tool is for direct retrieval of one post when you know its identifier, in contrast to list/update/create siblings. However, it gives no explicit guidance about when to prefer this over wp_get_page or how to choose between id and ref, so usage context is only implied.
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 that the response contains raw Gutenberg content, which is useful. It does not mention not-found behavior, permissions, or read-only status, though the simple getter nature reduces the risk.
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 or redundant re-statements of the schema. It is appropriately concise, though the terseness leaves some useful context unstated.
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 one-parameter getter, the description names the resource and the key output detail, but with no annotations and no output schema it leaves the agent to infer the role of the id parameter and what happens if the pattern is not found. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain that the required 'id' parameter is the synced pattern ID or how to obtain it. The schema's property name is self-evident, but the description adds no parameter-level meaning and fails to compensate for the low 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 ('Get') and resource ('synced pattern'), and the qualifier 'raw Gutenberg content' clarifies what is returned. This clearly distinguishes it from sibling tools like listing, creating, updating, or deleting synced patterns.
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 is implied by the tool name and description: use this when you need to retrieve a single synced pattern. However, it does not explicitly mention alternatives such as wp_list_synced_patterns or wp_get_block_pattern, nor does it state when not to use this tool.
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. It does state the operation is a read/list operation and that URLs are included, which is useful. It does not disclose defaults like result-page ordering, whether all media or only certain types are returned, or the exact response shape, but the core read-only behavior is reasonably clear.
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, focused sentence with no filler words. It front-loads the action and resource, though it is terse and leaves room for richer contextual guidance without compromising conciseness.
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 list tool with 5 optional parameters, no annotations, and no output schema, the description is somewhat thin. The schema covers several parameters, but the description does not mention available filters, pagination defaults, or the shape of the returned list beyond URLs, leaving some gaps for an agent deciding how to invoke it optimally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%: page, search, and per_page have descriptions, but mime_type and media_type have no meaningful description in either the schema or the tool description. The description adds no parameter-level guidance, so the agent must rely on parameter names and the enum to infer semantics.
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 resource ('media files in the WordPress media library'), and adds a concrete output signal ('with URLs'). This clearly distinguishes it from sibling media tools like upload, update, get, and delete, and from other list tools like wp_list_posts.
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 'List' implies the tool is appropriate when an agent needs to retrieve media-library entries, rather than fetch one item (wp_get_media) or upload new media. However, it does not explicitly state when to choose this tool over alternatives, mention pagination behavior, or provide 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 present, so the description carries the full burden. It does disclose valuable behaviors: hash-based concurrent update prevention and dry-run support. However, it does not explicitly state that deletion is a permanent mutation of the parent post content, nor does it mention permission requirements or failure conditions. The verb 'delete' implies destructiveness, but side-effect context is incomplete.
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 compact sentences, with the core action front-loaded. Each sentence earns its place: the action, the concurrency safety mechanism, and the dry-run capability. There is no redundant filler or repetition of schema content.
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 destructive mutation tool with a complex 'at' selector (five locator modes), six parameters, no output schema, and no annotations. The description omits guidance on how to construct the 'at' selector for non-hash modes, what happens to the surrounding content after deletion, and the need to specify ref and post_type. The schema provides structure but not enough context for reliable invocation across all modes.
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 67%, with ref, dry_run, allow_normalization, and if_unmodified_since already documented. The description adds meaning by explaining hash references (mapping to the 'at' hash mode) and dry-run (mapping to the dry_run parameter). However, it does not clarify the other 'at' locator modes (path, anchor, name, query) or the post_type parameter, leaving those to be inferred from schema structure.
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 'Delete one Gutenberg block', a specific verb and resource that clearly differentiates it from sibling block tools like wp_blocks_update, wp_blocks_insert, or wp_blocks_move. The resource type is precise, avoiding confusion with post, page, or tag delete tools.
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—use this when you want to remove a single Gutenberg block—and highlights safety mechanisms like hash references and dry-run support. However, it gives no explicit guidance on when to prefer this over wp_blocks_replace or wp_blocks_update, nor does it name alternatives 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 burden of behavioral disclosure. It usefully reveals a concurrency safeguard ('Hash references prevent overwriting a block changed since it was read') and the existence of dry-run, but it does not explain that this is a persisting write to the post/page, what happens on conflict, or what the operation returns. The disclosure is partial rather than comprehensive.
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 primary action is front-loaded and each sentence adds either scope, safety rationale, or a capability. The description is appropriately sized for the tool's complexity.
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 mutating tool with 8 parameters, complex block-locator options, no annotations, and no output schema, the description is too thin. It does not explain prerequisites (locating source/target blocks), how 'to' relates to 'from', what return value or confirmation is produced, or failure behavior beyond the implicit hash safeguard. The agent would need to infer a significant amount of task logic from the schema alone.
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 only 50%, so the description should add param-level meaning. It adds a little by explaining the purpose of hash references and mentioning dry-run, but dry-run is already in the schema and the description does not clarify the key from/to locator relationship or the meaning of position values. The schema's enums and constraints carry most of the load.
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 'Move one Gutenberg block relative to another,' a specific verb and resource that clearly identifies a repositioning operation. This differentiates it from sibling block tools such as wp_blocks_insert, wp_blocks_replace, wp_blocks_update, and wp_blocks_delete without needing to inspect their 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?
When to use the tool is implied by the move semantics and the mention of dry-run, but the description gives no explicit guidance about when not to use it or which sibling alternative to prefer (e.g., wp_blocks_update for content edits vs this for reordering). The agent can infer the main use case but is not told about prerequisites like reading blocks first.
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 meaningful work: it discloses hash-based optimistic concurrency ('prevent overwriting a block changed since it was read') and the availability of dry-run previews. It does not cover all side-effects like merge/replace attribute behavior, but the key safety-relevant traits are disclosed.
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 tight sentences front-load the core purpose, then add two valuable behavioral notes. No filler or repetition of schema details; every sentence 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?
For a tool with 9 parameters, nested selector objects, and no output schema, this description is too sparse. It omits how block targets are selected via 'at', how ref is resolved, what merge vs replace means for attrs, and what the update returns or reports. An agent would need to infer substantial behavior from the schema alone.
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 only 44%, and the description adds meaning for 'attrs' and 'innerHTML' by naming them as the update targets, plus clarifies 'hash' references and 'dry_run'. However, it does not explain the 'at' selector variants, 'attrs_mode', or 'ref' semantics, leaving a partial gap that is only somewhat compensated.
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 ('Update'), a precise resource ('Gutenberg block'), and a concrete scope ('attributes or inner HTML'). This clearly differentiates it from block deletion, insertion, movement, and listing siblings without needing to open 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?
The description gives no explicit guidance on when to choose this tool over siblings like wp_blocks_replace or wp_update_post_content. It implies usage via the purpose statement but does not state when-not-to-use or name alternative 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?
No annotations are present, so the description carries the burden. It does disclose an important behavioral trait: the return value is 'raw content with shortcodes visible,' which goes beyond the schema. However, it does not mention error behavior, authentication needs, or confirm that this is strictly non-mutating beyond the word 'Get.'
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 primary purpose ('Get full content of a WordPress page by ID or slug') and adds one valuable detail about the return format. There is no fluff or repetition.
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 tool's simplicity and high schema coverage, the description is reasonably complete. It states what is returned ('full content', 'raw content with shortcodes visible'), which partially compensates for the missing output schema. It does not explain behavior when no parameter is provided or when multiple identifiers are passed, but this is a minor gap for a simple read 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 baseline is 3. The description restates that lookup is by ID or slug, which matches the schema, but it adds no extra meaning about the relationship between id, ref, and slug or how conflicts are resolved. It does not need to compensate for schema gaps.
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?
Description clearly states the verb 'Get', the resource 'WordPress page', and the lookup methods 'by ID or slug'. It is distinct from wp_get_post via the word 'page', but it does not explicitly distinguish itself from sibling tools or mention alternatives. This fits 'clear but no 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'by ID or slug'—an agent can infer this is for retrieving a single specific page. However, there is no explicit guidance about when to choose this over wp_list_pages, wp_get_post, or other page-related tools, and no exclusions are stated.
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. It usefully discloses that an update 'Never creates orphan slots' and requires an existing block, which goes beyond a bare 'update' statement. However, it omits permissions, reversibility, response shape, and the runtime effects of auto_purge or dry_run.
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 compact and front-loaded, stating the action first and then the most important usage constraints. Every sentence contributes information without repeating schema details.
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 nested mutation tool with no annotations, no output schema, and low schema description coverage, so the description needs to supply substantial context. It gives the key constraint but still lacks return value expectations, permission requirements, ref semantics, and clarity on dry_run/auto_purge behavior, leaving it incomplete for confident 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 description adds a meaningful mutual-exclusion constraint — 'exactly one of content or structured ad_creative' — that is not explicitly encoded in the schema. Given only 20% schema description coverage, this helps, but auto_purge, ref, and the exact meaning of content remain underspecified.
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 opens with a clear verb-and-resource statement, 'Update an existing positioned Blocksy Content Block', which identifies what the tool acts on. It does not explicitly differentiate from related siblings such as wp_blocks_update or wp_update_post_content, but the resource type is specific enough to be recognizable.
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 instruction 'Supply exactly one of content or structured ad_creative' gives concrete usage guidance for selecting the right payload. It also implies this tool is for existing blocks, not creation, but it does not explicitly name alternatives or state when not to use this tool.
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 discloses that existing content is entirely overwritten (not merged), which is a key behavioral trait. However, it does not mention whether the operation is destructive/reversible, any permission requirements, or the availability of the dry_run parameter as a preview/safety mechanism.
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 scope with no filler. Every word contributes to 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?
For a simple three-parameter mutation tool with fully described parameters, the description plus schema covers what an agent needs to invoke it correctly. It would be more complete with a note on return behavior or exclusions, but nothing structurally necessary 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 description coverage is 100%, so the parameter definitions already document id, content, and dry_run meaningfully. The main description adds no parameter-level nuance, but the schema is sufficient; 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 uses a specific verb ('Replace'), a clear resource ('the entire raw content of a WordPress post'), and explicitly scopes the operation to full-content replacement. This distinguishes it from broader sibling tools like wp_update_post or wp_update_page_content 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 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 choose this tool over sibling tools such as wp_update_post, wp_update_page_content, or wp_elementor_update_shortcode_content. Applicable context must be inferred entirely from the name and the word 'content'.
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 burden of behavioral disclosure. It adds meaningful context: hash references prevent overwriting a block changed since read, dry-run is supported, and replacement can produce zero blocks. This goes well beyond a bare mutation statement, though it stops short of explaining all failure and normalization behaviors.
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 with no filler. The core operation is front-loaded, followed by two high-value behavioral details. Every sentence 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 tool is a mutating operation with 7 parameters, no annotations, no output schema, and a complex selector parameter. The description covers the core operation and key safety features, but an agent would still need to rely heavily on the schema to understand selector semantics and preconditions. It is adequate but not fully self-contained.
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 57%, and the description adds some value by clarifying that 'blocks' can be zero or more and that 'hash' references are concurrency-protected. However, it does not explain the meaning of the at selector variants (path, anchor, name, query), which is a notable gap for a required, complex 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?
The description opens with a precise verb and resource: "Replace one Gutenberg block with zero or more blocks." This clearly distinguishes the tool from siblings like insert, delete, update, or move, and even clarifies the zero-blocks edge case.
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 about when to use this tool instead of wp_blocks_update, wp_blocks_delete, wp_blocks_insert, or wp_blocks_move. The verb 'replace' implies the use case, but the description does not state conditions, exclusions, or alternatives.
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 disclosure burden. It does so well by distinguishing between the recoverable trash action and the permanent destructive action via force:true. It omits other behavioral aspects like required permissions or error behavior, but the most consequential behavior is clearly stated.
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 efficiently communicates the default behavior and the key exception. Every word earns its place, and the most important information is 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 description is adequate for a relatively simple delete tool, covering the core trash-vs-permanent behavior. However, with no output schema, it does not describe the return value or success/failure indication, and it leaves the ref parameter's accepted forms (ID or slug) undocumented in prose.
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 description adds meaning to the force parameter by explaining its effect, but it does not explain the ref parameter beyond what the schema's anyOf already implies. The dry_run parameter is covered by the schema description, so the description partially compensates for the low schema coverage but not fully.
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 the resource (WordPress page) and the action (trash or permanently delete with force:true). It is unambiguous and self-contained, but it does not explicitly differentiate from sibling delete tools such as wp_delete_post, relying instead on the tool name for that distinction.
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 need to delete a WordPress page — and clarifies the force flag's role. However, it offers no explicit guidance on when not to use it or which sibling tool to use instead, such as wp_delete_post for posts.
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, but it mainly restates the obvious update/move behavior and repeats the dry-run capability already present in the schema. It does not disclose overwrite vs. merge semantics, what auto_purge actually does, permission requirements, or side effects on caches or related widgets.
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 front-load the core operation and immediately follow with the most critical usage constraint and dry-run support. There is no filler or redundancy; every clause contributes to correct invocation.
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 mutation tool with a nested object, six parameters, no annotations, and no output schema, this description covers the primary operation and the mutual-exclusion rule, but leaves gaps around auto_purge behavior, return values, and content replacement semantics. It is workable 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 description adds meaningful parameter-level guidance by requiring at most one of block_content or ad_creative and by linking sidebar to the 'move' operation. However, schema description coverage is only 17%, and auto_purge remains unexplained, so the description only partially compensates for the low 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 uses a specific verb-resource pair ('Update widget content') and extends it with 'and/or move it to another sidebar', clearly distinguishing this from siblings like wp_move_widget, wp_list_widgets, and wp_delete_widget. It is specific, non-tautological, and tells an agent exactly what the 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 gives clear operational context: update content, move to another sidebar, or both, and use dry-run to preview. It also imposes the important constraint to supply at most one of block_content or ad_creative. It does not explicitly name alternatives or exclusions, but the intended use is clear enough for selection.
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 the write mechanism and notes that the menu-locations endpoint is read-only, which is useful. However, it does not explain side effects such as whether existing location assignments are overwritten or how the menu resource 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?
Two short sentences, front-loaded with the core action and followed by a relevant endpoint caveat. There is no filler or repetition.
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 relatively simple with only two required parameters and one optional dry_run flag, so the description is nearly adequate. However, the ambiguous 'ref' parameter and lack of any note about return values or mutation effects leave meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the dry_run parameter has a schema description, leaving ref and location mostly undocumented. The description adds some meaning to 'location' but does not clarify what 'ref' refers to, and the low schema coverage means the description should compensate more than it does.
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: assigning a location via the menu's writable locations field. It also distinguishes this from the read-only menu-locations endpoint, making the tool's purpose immediately clear.
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 signals that this tool is the write path for menu locations and that the separate menu-locations endpoint cannot be used for writing. It does not explicitly name alternative sibling tools, but the context is sufficient for an agent to understand when to use this one.
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 does reveal the key behavioral distinction between trashing (default) and permanent deletion (force:true), which is valuable. However, it omits prerequisites, return behavior, and potential side effects, leaving notable gaps for a destructive 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?
The description is a single sentence with no filler, front-loading the action and resource. Every word contributes 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should also cover return behavior, the meaning of ref, and any prerequisites. It does cover the trash-versus-force distinction but leaves these operational details unspecified, making it incomplete for a 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?
The description adds meaning to force by explaining that force:true permanently deletes, which the schema does not convey. It does not clarify the ref parameter, and dry_run already has a schema description, so overall parameter coverage remains partial given the 33% schema description 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 uses specific verbs ('Trash', 'permanently delete') and names the resource ('WordPress post'), while also distinguishing the two modes of operation. This makes the tool's purpose immediately clear and sets it apart from sibling deletion tools for other content types.
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 on when to use the tool: when you need to trash or permanently delete a WordPress post. It contrasts the default trash behavior with force:true, though it does not explicitly mention alternatives or when-not conditions.
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 behavioral disclosure burden. It explicitly reveals the get-or-create behavior and idempotency ('Safe to call repeatedly'), which is valuable. It does not describe permissions, failure modes, or what happens on invalid input, but the core side-effect semantics are disclosed.
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 main behavior is front-loaded, and 'Safe to call repeatedly' adds essential info without redundancy.
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 get-or-create tool, the description covers the key purpose and safety. However, with no output schema, it does not describe the return value, and it does not explain matching criteria or how slug/parent affect creation. These gaps make it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the tool description does not compensate. Only dry_run has a schema description; name, slug, and parent are left undefined. The description does not clarify whether existing categories are matched by name or slug, which is a meaningful ambiguity for correct invocation.
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: 'Return an existing category, or create it.' This clearly conveys an idempotent ensure operation and distinguishes it from unconditional creation tools like wp_create_category and listing tools like wp_list_categories.
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 'Safe to call repeatedly' implies this is intended for get-or-create scenarios, but it never explicitly says when to prefer this over wp_create_category or wp_list_categories. Usage context is implied rather than stated, with no exclusions or alternatives named.
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 must carry behavioral disclosure. It does correctly disclose the key behavior: the tool is idempotent and will not create duplicates. However, it does not explain matching semantics, whether an existing tag is modified, or what happens with dry_run, leaving gaps beyond the most important trait.
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, no filler, and the core behavior is front-loaded. Every sentence adds value, especially the safety clause 'Safe to call repeatedly.'
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 covers the essential purpose and idempotence, but the tool has no output schema, no annotations, and incomplete parameter semantics. An agent still lacks clarity on how matching occurs, what is returned, and how slug/dry_run behave in practice, so the context is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not compensate. It does not explain that `name` is the matching key, what role `slug` plays during creation, or how `dry_run` interacts with the ensure semantics. The description adds little parameter-level meaning beyond the word 'tag'.
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 returns an existing tag or creates it, which is a specific verb-resource pairing. It also differentiates the ensure behavior from a plain create by emphasizing idempotence, so an agent can distinguish it from wp_create_tag and wp_list_tags.
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?
'Safe to call repeatedly' gives clear context that this is intended for idempotent setup or reconciliation scenarios. It does not explicitly name alternatives or exclusions, but the behavior makes 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 transparency burden. It discloses the cache targets and the required plugin, but it does not mention side effects such as temporary performance impact or whether any permissions are needed. The core side effect (clearing caches) is visible in the verb, so this is 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?
Two short sentences front-load the action and add only the essential plugin prerequisite. There is no filler or repetition of schema content.
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 two-parameter tool with a fully documented schema, the description plus schema cover purpose, scope, prerequisite, and parameter behavior. It does not describe the return value or all edge cases, but those are unlikely to prevent 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?
Schema description coverage is 100%: both dry_run and page_id already have clear descriptions in the schema. The tool description adds no parameter-level meaning, 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 states a specific action ("Flush") and a clear resource set ("WordPress, Elementor, and page caches"). The sibling list contains no other cache-flush tool, so this tool is easily distinguished by purpose alone.
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?
It provides a prerequisite ("Requires the optional cache helper mu-plugin"), which tells an agent when it is safe to call, but it does not describe concrete scenarios, exclusions, or alternatives. Since no cache-related sibling exists, the missing alternative guidance is less harmful, but the when-to-use context is still largely implied.
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?
Since no annotations are provided, the description carries the full burden and it explicitly labels the operation 'read-only', which signals no mutation. It does not cover not-found behavior or response shape, but for a simple getter the read-only disclosure provides the most important safety-relevant transparency.
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 with no filler and the essential scoping ('exact namespace/name') is front-loaded. 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 core call intent is clear and the read-only nature is disclosed, but with no output schema and no annotations, the description still leaves include_content unexplained and gives no indication of behavior when the pattern does not exist. This is minimally adequate for a simple getter, not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that the required 'name' parameter is an exact namespace/name, but it completely omits 'include_content', leaving one of two parameters undocumented. The semantics are therefore only partially conveyed.
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 bounded resource ('one registered read-only pattern'), and the addressing scheme ('exact namespace/name'). This distinguishes it clearly from sibling listing and synced-pattern getter tools even without naming them.
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 'exact namespace/name' implies the tool is for callers who already know the precise identifier, but it never explicitly states when to prefer this over wp_get_synced_pattern or wp_list_block_patterns. No alternatives or exclusions are given, so usage context is only implied.
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 behavioral burden. It clearly indicates a read operation, implying no destructive side effects, and the static-front-page detail adds scope context. However, it does not disclose return format, authentication expectations, or any edge-case behavior, leaving some burden unmet.
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, lean sentence that front-loads the action and resource. Every phrase adds meaning, with no filler 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 zero-parameter read-only tool with no output schema, the description provides enough core orientation. It could mention what is returned, but the simple scope and the static-front-page example make it sufficiently complete for an agent to invoke 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 accepts zero parameters, so the description is not required to explain parameter behavior. Baseline of 4 applies because there is no parameter surface to document.
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 ('Read') and identifies the resource ('WordPress site settings'), and the mention of static-front-page configuration adds useful specificity. It does not explicitly differentiate from nearby siblings like wp_site_info, but the reading vs. updating distinction from wp_update_settings is clear.
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 for when the tool is appropriate: call it to read WordPress site settings. It does not mention alternatives or exclusions, but for a simple zero-parameter read operation the usage intent 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 clearly signals that deletion is permanent and discloses a non-obvious WordPress requirement: 'force:true' is required. It could add more side-effect detail, but the core 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?
Two short sentences with no filler. The primary action is front-loaded, and the second sentence adds a necessary requirement without 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 small deletion tool with no output schema, the description covers the essential behavior: permanent removal, required force flag, and a previewable dry_run from the schema. It could mention irreversibility side effects or return format, but the tool is simple enough that the current description is nearly 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 only 33%, so the description must compensate. It adds meaningful context for the force parameter by explaining WordPress requires it, and the phrase 'media attachment' helps clarify that id identifies the attachment. It does not fully describe id or force beyond the schema, but it provides enough to guide invocation.
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: 'Permanently delete a media attachment.' The word 'permanently' adds important scope and distinguishes this irreversible delete operation from update/get/list media tools among the siblings.
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 purpose statement implies when to use the tool: when a media attachment must be permanently removed. However, it does not explicitly name alternatives or exclusions, such as distinguishing this from wp_delete_post or wp_update_media.
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. 'Get' reasonably signals a read-only retrieval with no mutation, but the description does not disclose error behavior, authentication needs, or return format. It is acceptable for a simple getter but leaves some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 communicates the resource, the action, and the required lookup key 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?
For a one-parameter getter tool, the description is nearly complete: the caller knows the action and the required ID. It would benefit from a brief note about the return value or not-found behavior, but nothing essential is missing for invoking it 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?
The schema has one required 'id' integer with a minimum of 1 and no schema-level description. The description adds that the ID identifies a media attachment, which provides some contextual meaning, but it does not elaborate on formatting or edge cases. Adequate given the single obvious 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?
The description uses a specific verb ('Get') and resource ('media attachment by ID'), which clearly identifies what the tool does. It also stands apart from sibling tools like wp_list_media, wp_upload_media, wp_update_media, and wp_delete_media due to the 'by ID' qualifier.
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?
'Get a media attachment by ID' makes the usage condition clear: use this tool when you already know the media attachment's ID. It does not explicitly name alternatives or when-not-to-use conditions, but the context is sufficient for correct selection.
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. It communicates that the tool destructively replaces the entire page content and instructs the agent to read the original first, which is valuable. However, it does not mention reversibility, auth requirements, side effects, or the dry_run preview option, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler; the core action is front-loaded and the follow-up instruction earns its place. This is an example of efficient, well-structured documentation.
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 mutation tool with fully documented schema fields and no output schema, the description covers the key operational requirement: read before replacing and pass full content. It does not describe return values or explicit side effects, but the read-first warning and full-replacement emphasis make it sufficiently complete 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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description reinforces that content must be the full replacement, but it adds little semantic detail beyond what the schema provides; 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 states a specific verb ('Replace') and a precise resource ('entire raw content of a WordPress page'), so an agent knows exactly what this tool does. The 'page' versus 'post' framing differentiates it from wp_update_post_content, and 'entire raw content' separates it from wp_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?
It gives clear usage context: read the page first and pass the full replacement content, implying this is for full overwrites rather than partial edits. It does not explicitly name alternatives or give when-not-to-use conditions, but the page-scoped resource and raw-content emphasis provide enough guidance for correct selection.
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 no annotations, the description carries the full disclosure burden and does so effectively by warning that writes are silently discarded. This reveals the exact failure mode an agent needs to know and prevents false confidence in apparent success.
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 the critical warning front-loaded before the mechanism. Every word earns its place, and there is no repetition of schema information or filler.
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 an experimental, disabled mutation tool with no annotations and no output schema, the description supplies the decisive fact: writes are discarded, so the tool cannot be relied upon. It does not mention an alternative or expected response, but those are secondary when the tool is currently unusable.
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%, so the schema already documents both page_id and new_content, establishing a baseline of 3. The description adds no further per-parameter meaning; the _elementor_data mention indirectly clarifies what new_content affects but offers no additional syntax or constraints.
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 identifies the operation as direct writes to Elementor's _elementor_data via WordPress REST, clearly implying this is the update path for Elementor shortcode content. It is specific about the mechanism and current status, though it does not explicitly compare itself to sibling tools such as wp_elementor_get_shortcode_content.
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?
It explicitly states 'currently unavailable,' giving an unambiguous do-not-use signal. It does not name an alternative, but for a disabled tool the core guidance is to avoid invocation, which is clearly communicated.
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 behavioral burden. 'Get' communicates a read-only retrieval, but the description does not disclose return shape, not-found behavior, or any other runtime details that an agent could expect.
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, front-loaded with the action, resource, and parameter meaning. Every word contributes and nothing is redundant.
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 (one required parameter, no nested objects), so the description covers selection and invocation fully. With no output schema, it would be slightly stronger if it stated the return object shape, but the operation is a straightforward getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only exposes a bare 'ref' as integer or string with no description. The description fully compensates by clarifying that this value is the menu ID or slug, which is exactly the missing semantic.
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 has a specific verb ('Get'), a specific resource ('classic menu'), and the supported identifiers ('by ID or slug'). It clearly marks this as the single-menu getter rather than wp_list_menus or wp_get_menu_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 description implies when to use this tool: to retrieve one classic menu when an ID or slug is known. However, it never explicitly states exclusions or names alternatives such as wp_list_menus for listing menus or wp_get_menu_item for menu items.
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 shoulders the behavioral burden. It explicitly states 'read-only,' which communicates that no mutation occurs. However, it does not describe return format, ordering, or behavior when a location has no assigned menu, though this is a minor gap for such a simple list 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 a single, front-loaded sentence with no wasted words. It communicates the operation, the resource, the read-only safety trait, and the return content in a compact form.
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, read-only listing tool with no output schema, the description is fully sufficient. It tells the agent exactly what the tool lists and what data it returns, so no additional context is necessary to call 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 100% schema description coverage of an empty schema. No parameter explanation is needed, so the description carries no burden here; the baseline score of 4 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 action ('List'), a distinct resource ('theme menu locations'), and the output ('assigned menu IDs'). This clearly distinguishes it from sibling tools like wp_list_menus, which would list menu objects rather than theme location assignments.
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 reading menu location assignments, but it does not explicitly contrast it with alternatives such as wp_list_menus or wp_assign_menu_location. The 'read-only' wording and domain-specific resource give some context, but no explicit when-to-use or when-not-to-use guidance is provided.
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 communicates a read-only listing action and specifies the returned information ('ordered widget IDs'), which is adequate for a simple list tool. It does not add extra context like empty-sidebar behavior, but none is critical for this 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 a single, tight sentence that front-loads the action and resource. Every word adds value, and there is no redundant or filler phrasing.
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 read-only list operation, the description is complete: it names the resource, the qualifying scope ('classic-theme'), and the output contents ('ordered widget IDs'). No further details are necessary for an agent to invoke this tool 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?
This tool has zero parameters, so the baseline is 4. The description adds meaning by clarifying what the output will contain, which is the only relevant semantic context for a parameter-less 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 ('List') and a specific resource ('registered classic-theme sidebars'), and it clarifies the output scope ('ordered widget IDs'). This clearly distinguishes it from siblings like wp_list_widgets, which would list widgets instead of sidebars.
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 an agent needs an inventory of registered classic-theme sidebars and their widget assignments. However, it gives no explicit guidance about alternatives or exclusions, such as saying 'use wp_list_widgets to list widgets independently.'
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 it well: it discloses that force:false archives the widget to wp_inactive_widgets, while force:true permanently deletes it. This communicates the key side effects and irreversibility risk beyond what the schema alone expresses.
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 contain all essential behavioral information with no filler. The primary action is front-loaded and the force distinction is compactly stated, making the description 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 small delete-style tool, the description covers both the default non-destructive path and the permanent deletion path, while the schema documents dry_run. There is no output schema, so return-value documentation is not strictly required; missing details about id sourcing or error behavior are minor for this scope.
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 covers only dry_run explicitly, so the description meaningfully compensates by explaining the force parameter's two states and their consequences. The id parameter remains lightly documented, but its role is largely inferable from the operation name, and dry_run is already described in 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 starts with a specific action ('Remove') and resource ('a widget'), and immediately clarifies the two deletion modes. This distinguishes it from sibling operations like wp_move_widget or wp_update_widget, since the intended operation is clearly removal rather than repositioning or editing.
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 tool when a widget needs to be removed, either to the inactive list or permanently. It does not explicitly name alternatives or exclusions, but the deletion semantics and force distinction make the appropriate use case unambiguous for an agent scanning sibling tool names.
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 must carry the full behavioral burden. 'Show' clearly indicates a read-only introspection operation, and specifying 'authenticated user and granted capabilities' reveals exactly what data is exposed. It does not explicitly state that no changes are made, but the wording strongly implies a non-mutating diagnostic.
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, front-loaded with the core action and followed by the diagnostic use case. There is no filler, and every clause contributes to selecting and using the tool.
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 diagnostic tool with no output schema, the description covers the purpose and a key use case. It does not describe the return format in detail, but 'user and granted capabilities' sufficiently sets expectations. Minor gap: no explicit statement about what happens when no user is authenticated.
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 there are no parameter details to clarify. The description adds context by implying the tool operates on the current authenticated session, which is helpful. Per the zero-parameter baseline, a 4 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 uses a specific verb ('Show') with a clear resource: the authenticated WordPress user and their granted capabilities. This uniquely distinguishes it from the large sibling set, none of which target authentication or capability introspection.
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 concrete use case: 'Useful for diagnosing 403 errors.' This tells an agent when to reach for this tool. It does not enumerate when not to use it, but no sibling performs this function, so explicit exclusions are less necessary.
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 transparency burden. The word 'existing' indicates this is a non-mutating retrieval, and the description discloses that the response will include raw content and ad inventory metadata. It does not cover not-found behavior or auth requirements, but for a simple getter this is acceptable.
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 worded sentence. The action and primary lookup mode are front-loaded, followed by the return-value highlights. There is no redundant or filler content.
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 tool with one required parameter and simple read semantics, the description supplies the necessary information: what to pass ('ID or slug') and what to expect back ('raw content and ad inventory metadata'). The only minor gaps are unspecified not-found behavior and the exact shape of the ad inventory metadata, but these do not impair basic tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'ref' as an integer or string with no property description. The description adds critical meaning by stating that the value can be an ID or slug, effectively explaining how to use the single required parameter. This fully compensates for the 0% structured 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 uses a specific verb ('Get'), identifies the exact resource ('one existing Blocksy Content Block'), states the lookup method ('by ID or slug'), and names the return payload ('raw content and ad inventory metadata'). This clearly differentiates it from sibling tools like wp_list_content_blocks and wp_update_content_block.
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: use this tool to retrieve a single existing content block by ID or slug. It does not explicitly state 'use wp_list_content_blocks for listing' or 'use wp_update_content_block for updates,' but the one-and-only existing semantics are enough to guide selection.
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:

[![mcp-wordpress MCP server](https://glama.ai/mcp/servers/leonardobora/mcp-wordpress/badges/card.svg)](https://glama.ai/mcp/servers/leonardobora/mcp-wordpress)

Score Badge

Copy to your README.md:

[![mcp-wordpress MCP server](https://glama.ai/mcp/servers/leonardobora/mcp-wordpress/badges/score.svg)](https://glama.ai/mcp/servers/leonardobora/mcp-wordpress)

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/leonardobora/mcp-wordpress'

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