mcp-wordpress
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools have clearly distinct resource+action pairs, and descriptions explicitly disambiguate overlapping areas (e.g., wp_media_update vs wp_media_set_alt_text, wp_cpt_* vs wp_posts_*). A few near-duplicates like wp_posts_publish/schedule vs wp_posts_update exist, but they are shortcuts with clear purposes.
Naming Consistency3/5The dominant pattern is wp_<resource>_<action> (e.g., wp_pages_get, wp_taxonomies_create_tag), which is consistent and readable. However, there are notable exceptions: a cluster of wp_get_* tools (wp_get_site_info, wp_get_post_types, wp_get_taxonomies), plus standalone wp_health_check, wp_batch, wp_search_posts, and wp_detect_page_builder, mixing conventions.
Tool Count2/5At 73 tools, the server is extremely large and likely overwhelming for agents to navigate efficiently. While WordPress is a broad domain, many tools are thin wrappers or convenience shortcuts (e.g., wp_posts_publish, wp_media_set_alt_text) that could be consolidated without losing functionality.
Completeness5/5The tool set provides comprehensive CRUD coverage for posts, pages, media, comments, users, taxonomies, CPTs, and blocks, plus SEO, site settings, batch operations, search, and health checks. It covers the full lifecycle of WordPress content management with no obvious dead ends.
Average 4/5 across 73 of 73 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 140 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 failing
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.
This server has been verified by its author.
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. It only conveys that the operation is a read ('fetch'), but discloses nothing about behavior on missing revisions, potential errors, authentication requirements, or return format. This is minimal and does not go beyond the obvious semantics of the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is appropriately front-loaded with the action and resource. Every word earns its place, though it may be under-specified, that is captured in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with two required parameters and no output schema. It does not clarify what a 'revision' is, how revision_id relates to page_id, or what the response contains. It also lacks any context relative to sibling tools (e.g., wp_pages_get_revisions), leaving the user uncertain about the tool's exact role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no parameter information. The phrase 'by id' is singular and ambiguous, failing to mention that two ids (page_id and revision_id) are required. It does not explain the relationship between the parameters or their meaning beyond the names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: fetch a single revision of a page by id. The verb 'fetch' and resource 'revision of a page' are specific, and the singular 'a single revision' distinguishes it from the sibling wp_pages_get_revisions (plural). However, it does not explicitly differentiate from wp_posts_get_revision, though the 'page' qualifier implies the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention wp_pages_get_revisions (for fetching all revisions) or wp_pages_restore_revision, nor does it explain under what circumstances one would need a single revision. The description offers no usage context or exclusions.
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 behavior. It only states that it lists blocks, without mentioning pagination, filtering, output structure, permissions, or side effects. The added context about reusable blocks is domain knowledge, not behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the core action. It avoids fluff and is efficient, though it could potentially be even clearer with parameter context. Still, it earns its place by clarifying the resource type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It gives domain context about reusable blocks but fails to explain pagination, filtering, statuses, sorting, or the response format. The agent would struggle to use this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 6 parameters (page, order, search, status, orderby, per_page). It neither lists nor explains them, leaving the agent entirely dependent on the schema's raw names and enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists reusable Gutenberg blocks (post type wp_block), using a specific verb (List) and resource. It distinguishes itself from sibling tools like wp_blocks_get (single block) and wp_posts_list (regular posts) by focusing on reusable blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by explaining what reusable blocks are and their purpose, implying usage for listing such blocks. However, it does not explicitly mention alternatives or when not to use this tool, so guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 does reveal a key trait: partial update semantics ('Only fields provided are changed'), which is useful. However, it omits other important behaviors like permission requirements, error conditions, or how nested objects like 'meta' are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant information. It front-loads the core action and partial-update behavior, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, no output schema), the description is insufficient. It does not explain return values, error behavior, or prerequisites, and it does not mention how to use 'meta' or what fields are accepted. The description is too sparse to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meaning. It provides no details about any of the 8 parameters, including the 'meta' object, acceptable values for 'status', or constraints. The description merely says 'fields provided' without connecting to the actual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: updating a CPT item partially, with only provided fields changed. It distinguishes itself from sibling tools like wp_posts_update or wp_pages_update by targeting 'any CPT', 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating custom post types and emphasizes partial updates, but it does not explicitly state when to use this tool over wp_posts_update/wp_pages_update or provide exclusions. The context is implied rather than clearly articulated.
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 itself. It only states 'Fetch', implying a read-only operation, but does not describe return format, error behavior (e.g., 404 if not found), or any other side effects. This is insufficient for an unannotated 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the verb and resource, containing no filler words. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should clarify return value and error handling. It does not, leaving the agent uncertain about what to expect from the response. The low complexity does not excuse the lack of return information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. 'by id' simply restates the parameter name 'id' without adding semantic detail such as what the ID represents (e.g., WordPress term ID) or how to obtain it. The exclusiveMinimum is already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' with resource 'category', and specifies 'by id', distinguishing it from sibling tools like list_categories, create_category, update_category, and delete_category. It clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, situations where this should be preferred, or reference sibling tools such as list_categories for multiple categories.
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 shoulders the burden of behavioral disclosure. It adds useful context by explaining that status values serve as moderation actions (e.g., 'spam', 'trash') and that content/author fields are editable. However, it does not disclose potential side effects (e.g., whether trash is reversible), permission requirements, or response behavior, leaving 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action 'Update a comment'. It efficiently packs essential information about moderation and editable fields without redundancy or excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no output schema, the description is adequate but not complete. It conveys the core purpose, status semantics, and editable field groups, but omits important contextual details such as whether trash deletion is permanent, how author fields interact with permissions, and what the tool returns after a successful update. More would be needed for full agent confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 does partially by mapping the status enum values to their moderation meanings ('approved (publish), hold (pending), spam, trash') and grouping content and author fields as editable. However, it does not describe the id parameter (though its role is obvious from the name) or provide details on constraints like minLength or uri formats, which the schema alone lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb+resource 'Update a comment', clearly distinguishing this update tool from sibling tools like create, get, list, and delete. It further clarifies the scope by listing moderation actions and editable 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. While 'Update a comment' implies modifying an existing comment, it does not state that create/delete should be used for new/removal operations, nor does it mention any prerequisites or exclusions.
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. It discloses only which fields can be changed, but does not mention partial-update behavior, error handling if the category doesn't exist, or side effects like URL changes from slug updates. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and scope. Every word is meaningful, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations, 0% schema coverage), the description is sparse. It fails to explain that updates are partial, what the return value is, how to indicate the parent category, or any prerequisites. More detail is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 merely repeats the property names ('name, slug, description, re-parent') without adding constraints, formats, or clarifying examples. The phrase 're-parent' adds a bit of meaning to the 'parent' parameter, but overall it provides minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update a category.' It lists the specific fields that can be changed (name, slug, description, re-parent), which distinguishes it from sibling tools like wp_taxonomies_create_category, wp_taxonomies_delete_category, and wp_taxonomies_update_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this to modify an existing category rather than create or delete it. It doesn't explicitly state exclusions or mention alternatives, but the verb 'update' and the listed fields guide the agent to choose this tool when a category needs modification.
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 burden of disclosing behavioral traits. It only lists which fields can be changed, but does not mention requirements like a valid existing ID, potential side effects, error behavior, or permission needs. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action. Every word adds value and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with 4 parameters, no output schema, and no annotations, the description is adequate but lacks important context such as the mandatory `id`, uniqueness constraints on slug, or what happens if the tag does not exist. An agent could probably invoke it correctly using the schema, but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate. It does mention three of the four parameters (name, slug, description) and implies they are optional, but omits the required `id` parameter and does not explain how it identifies the tag. Adds some meaning but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a tag' with a specific verb and resource, and lists the updatable fields (name, slug, description). This distinguishes it from sibling tools like create, delete, get, and list tags, as well as update_category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying a tag, but gives no explicit context about when to use it versus alternatives, prerequisites (e.g., tag must exist), or when not to use it. The purpose is clear, but no guidance beyond 'update a tag' is 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?
No annotations are provided, so the description carries the burden. It discloses that the tool returns 'normalized media including source_url and thumbnails,' which is useful. However, it does not explicitly state that the operation is read-only or describe pagination/ordering defaults (though schema has defaults). The verb 'List' implies read-only, mitigating the gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: purpose in the first sentence, filters in the second, return value in the third. No fluff, but the incomplete media_type list is a minor deduct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no annotations, and no output schema, the description is under-specified. It lacks guidance on pagination controls, what 'normalized' means beyond source_url/thumbnails, and potential response structure. Enough to get started, but significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It enumerates several filters (media_type, mime_type, search, date range, parent post) but omits pagination and sorting parameters (page, per_page, order, orderby). Additionally, the media_type list is incomplete and potentially misleading: the schema enum includes 'application' and 'text,' but the description only lists 'image/video/audio/file.' This is a meaningful gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing media library items with filters. It distinguishes from sibling tools like wp_media_get (single item) and wp_media_upload (upload) by specifying 'media library items' and 'filters.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when you need to list/filter media. It does not explicitly mention alternatives like wp_media_get for single items, but the list nature is apparent. No exclusions are given, hence 4.
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 convey behavioral traits. It mentions 'revisions/autosaves,' which clarifies the scope, and 'List' implies a read-only operation. However, it lacks details on return format or pagination, leaving some ambiguity for a tool with no annotations to provide context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It immediately states the primary purpose and includes the key detail of 'revisions/autosaves,' making it exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the core functionality adequately. It explicitly states the action and scope, which is sufficient for an agent to invoke the tool correctly. Minor missing details like return shape could be inferred from the context, but the description is not misleading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. The phrase 'of a page' provides context that page_id refers to the page whose revisions are listed, adding some meaning beyond the schema's bare type. However, it does not elaborate on page_id's value or constraints, leaving the parameter only partially explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List revisions/autosaves of a page' clearly states the action (list) and the resource (revisions of a page). It distinguishes from the singular sibling wp_pages_get_revision by explicitly mentioning 'revisions/autosaves' in the plural, indicating it returns multiple 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. While sibling names like wp_pages_get_revision and wp_posts_get_revisions imply distinctions, the description itself fails to state when to choose this tool, such as listing all revisions vs. retrieving one specific revision.
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 'Fetch' and 'read', which is self-evident from the tool name. It does not disclose the return format (e.g., a WP_Post object), error handling for non-existent revisions, or any side effects, leaving significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with no filler. The first sentence states the core action, and the second provides the necessary workflow context. Every word earns its place, delivering key information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter fetch tool with no output schema, the description covers the main action and the relationship to the listing tool. However, it omits the exact return value (e.g., whether it returns the full content or a post object) and any error behavior. The mention of 'content' hints at the return but lacks structural detail, making it adequate yet incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two required parameters (post_id, revision_id) but zero schema descriptions. The description says 'by id' but does not clarify which id is which or how the two parameters relate (e.g., post_id is the parent post, revision_id is the revision). It adds minimal meaning beyond the parameter names themselves, failing to compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb-resource pair: 'Fetch a single revision of a post by id.' It clearly distinguishes this from the sibling tool wp_posts_get_revisions by stating the workflow: list revisions first, then fetch a specific one. The mention of 'diffing or restoration' further clarifies the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly references wp_posts_get_revisions as the tool to list revisions, saying 'Use wp_posts_get_revisions to list revisions, then this to read a specific one's content.' This provides a clear use case and workflow. However, it does not mention when to use alternative tools like wp_posts_restore_revision, nor any explicit when-not-to-use conditions.
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?
Without annotations, the description must carry the burden of behavioral disclosure. 'Fetch' implies a read-only operation, but the description does not mention return format, error handling (e.g., 404 if not found), or that it only applies to tags. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. It is appropriately sized for a simple get-by-id operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema and no annotations, the description is minimal. It clearly states the primary purpose, but lacks details about return value and behavior on missing tags. Given the simplicity, it is partially complete but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 merely says 'by id' without explaining what the id refers to beyond the tool name, or providing any additional context such as a positive integer or required status. The schema already specifies the type and exclusivity, so the description adds little value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a single tag by id' clearly states the action (fetch), the resource (tag), and the distinguishing qualifier (by id). This differentiates it from sibling tools like wp_taxonomies_list_tags (lists) and wp_taxonomies_get_category (different taxonomy).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a tag ID and need that specific tag, but it does not explicitly mention alternatives or exclusions. There is no guidance such as 'use list_tags to find all tags' or 'this is not for categories', so it relies on the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the edit context includes author email, which is a useful behavioral nuance not evident from the schema. It also implies read-only behavior via 'Fetch'. However, it does not explain the effect of other context values (view/embed) or what happens if the comment is not found, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of ten words, front-loaded with the action and resource. Every word contributes meaning, with no redundancy or filler. It is appropriately concise for a simple fetch tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema, no annotations), but the description is still lean. It covers the main purpose and one behavioral detail (author email in edit context), yet it omits information about return structure and the behavior of non-edit contexts. Given that the description is the only source of guidance, this leaves some context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. It clarifies 'id' implicitly by saying 'by id', and it partially explains the 'context' parameter by noting that edit context includes author email. However, it does not define the 'view' or 'embed' contexts, nor does it mention that 'edit' is the default, leaving the parameter semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a single comment by id', which specifies the action (fetch) and resource (comment) with a precise identifier. This distinguishes it from sibling tools like wp_comments_list (list), wp_comments_create, update, delete, and other comment tools. The added detail about author email and edit context does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a comment ID and need its details, as indicated by 'by id'. However, it does not explicitly mention alternatives or when not to use this tool. There is no referral to wp_comments_list for broader queries, so the guidance is solely implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List items' and gives parameter context; it does not disclose return format, pagination behavior, authentication requirements, or whether the operation is read-only. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences front-load the core action, provide a concrete example, and give an exclusion. No filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain what the response looks like (e.g., array of items, pagination metadata) and any constraints on the listed parameters. It only covers the post_type mapping and built-in alternatives, leaving the tool's full behavior under-specified for a 7-parameter list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for 7 parameters. The description adds meaningful guidance for post_type (must match rest_base), but leaves page, order, search, status, orderby, and per_page unexplained. Conventional names help but the description does not compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as 'List items of any registered Custom Post Type', which is a specific verb and resource. It also differentiates from built-in posts/pages by directing users to wp_posts_list / wp_pages_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool (for custom post types) and when to prefer alternatives (wp_posts_list / wp_pages_list for built-in posts/pages). It also provides a concrete prerequisite that post_type must match the rest_base from wp_get_post_types.
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 disclosing behavior. It does list what the tool returns (post type slugs, taxonomy slugs, namespaces, plugin installed), which is helpful. However, it does not explicitly state that the tool is read-only or that it has no side effects. The 'summary/probe' wording implies safety but not definitively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose ('High-level summary'), and lists specific outputs. It is succinct and each sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (0 parameters, no output schema), the description is complete enough. It clearly states the scope and content of the return value. It could mention that the response is likely a structured object, but for a summary probe, this is not necessary. The description fully covers what an agent needs to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter-level semantics to add. The description correctly emphasizes that it is a high-level summary without requiring inputs. Per the rubric, 0 parameters earns a baseline of 4, and the description does not need to compensate for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'high-level summary' of what the WordPress install supports, listing specific content (post types, taxonomies, REST namespaces, plugin status). While the verb is implied rather than explicit, it is distinct from sibling tools like wp_get_site_info or wp_get_post_types by framing itself as a combined 'what can I do here?' probe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it is 'useful as a single probe,' implying initial reconnaissance. However, it does not explicitly state when to use this tool instead of more specific tools (e.g., wp_get_post_types, wp_get_taxonomies) or mention exclusions. The usage context is clear but lacks direct alternatives.
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 state that this is a 'partial update,' which implies PATCH-like semantics (only provided fields are modified). However, it omits other relevant behaviors such as permissions, side effects, error handling, and return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and includes the alternative tool reference without unnecessary detail. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with 8 parameters, no annotations, and no output schema, the description is too sparse. It covers the basic purpose and one alternative, but leaves out important context such as update semantics, return value, permission requirements, and possible error conditions. The agent would likely need to infer much of this behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description should compensate by explaining parameter semantics. It lists the field names (title, alt_text, caption, description, attached post, slug, status), but these already appear in the schema properties. The description adds no extra detail about formats, constraints, or relationships beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('update') with a clear resource ('media item') and enumerates the fields it affects. It explicitly distinguishes itself from the sibling tool wp_media_set_alt_text by positioning this as the generic alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage alternative: 'Use wp_media_set_alt_text for the focused alt+caption+description tool when that's all you need.' This tells the agent when to choose a different tool, though it doesn't fully cover when not to use this tool beyond that scenario.
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 adds context about the 'edit' and 'view' contexts, indicating that 'view' returns only the rendered version. However, it does not mention authentication, error conditions, or side effects, and leaves context=embed unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, front-loaded with the primary action ('Fetch a single page by ID with full content') followed by immediate usage guidance. There is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description leaves gaps: context=embed in the enum is not explained, and there is no mention of return structure or potential errors. While adequate for basic use, the lack of full coverage for the context parameter prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains the 'context' parameter well ('edit' for raw fields, 'view' for rendered version), but provides no additional meaning for 'id' beyond the schema's type and requirement. Partial compensation for one of two parameters makes this a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fetch a single page by ID with full content.' It uses a specific verb and resource, and distinguishes from list tools by specifying 'by ID.' The context parameter clarification also helps differentiate between raw and rendered output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance for the context parameter ('Use context=edit for raw fields, context=view for the public rendered version only'), which is helpful. However, it does not mention when to use this tool versus alternatives like wp_posts_get or wp_pages_list, nor does it discuss exclusions or prerequisites.
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 burden of disclosing behavior. It explicitly describes the hierarchy semantics and the default ordering, which is useful. However, it omits details about return format, pagination, or status filtering behavior, leaving the agent partially in the dark about what to 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core purpose and packs essential hierarchy information into a concise, readable format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It explains hierarchy and default ordering but fails to cover filtering semantics, pagination, or response shape. The tool's complexity demands more contextual detail to be safely invoked without further exploration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 only adds meaningful context for the 'parent' parameter and clarifies the default ordering, but leaves seven other parameters (author, search, status, per_page, page, order, orderby) undefined. Given the high parameter count and zero schema descriptions, this is insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List pages with filters', a clear and specific verb-resource-scope statement. It clearly distinguishes from sibling tools like wp_pages_get (single page) and wp_posts_list (posts) by focusing on pages and their hierarchical filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool, especially for hierarchical page listing via the parent parameter. It states the default menu_order behavior, but does not explicitly mention alternatives or exclusions. The context is strong enough to guide selection without being overly verbose.
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 exist, so description carries full burden. It discloses default draft status, publish tier requirement, and scheduling behavior, which is useful. However, it omits return value expectations, permission requirements beyond publish tier, and side effects beyond post creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first is direct and front-loaded. Every clause adds value, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 13 parameters and no output schema or annotations, yet description addresses only status behavior. Many parameters (meta, sticky, excerpt, featured_media) and expected response are left undefined, making it insufficient for full autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 13 parameters, description only clarifies status and date. Required title/content and other fields like meta, sticky, format remain unexplained, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Create' with resource 'blog post', clearly distinguishing from update/publish/schedule tools. It even explains how to achieve publish/schedule via status field, reinforcing its role as the create action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for status values: default draft is safe, publish requires publish tier, future schedules with date. Doesn't explicitly name alternative tools but the guidance prevents misuse and orients the agent toward appropriate statuses.
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 fully disclose behavior. It adds value by noting that the response includes full Gutenberg block markup, but omits other behavioral traits such as error handling for nonexistent ids, required permissions, or any side effects. It is minimal but adequate for a simple read 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It states the action, target, and a crucial detail about the return value in a compact and readable manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool, the description covers the core purpose and the nature of the returned content. With no output schema, it offers enough orientation for an agent, though it might have added more about the context parameter or error cases. Overall it is reasonably complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains 'by id' which clarifies the primary 'id' parameter, but the 'context' parameter (with enum view/edit/embed) is left entirely unmentioned. With schema description coverage at 0%, the description partially compensates but has a clear gap for one of the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('single reusable block by id'), clearly distinguishing this from sibling tools like wp_blocks_list, create, update, or delete. It also adds the clarifying detail that it returns full Gutenberg markup, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (fetch one block by id) but gives no explicit guidance on when to use this versus alternatives. There is no mention of using wp_blocks_list to find ids, nor any exclusions, making it only implicitly useful for tool 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 burden of behavioral disclosure. It reveals a conditional requirement: when 'author' is omitted, 'author_name' and 'author_email' are required. This adds useful context, but it does not disclose other behaviors such as auth requirements, default status, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that provides the essential information without redundancy. It earns its place with the key conditional requirement and reply capability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no annotations, no output schema, and 0% schema description coverage, this sparse description is inadequate. It omits what the response looks like, any error conditions, and details on most parameters. The conditional author rule is helpful, but the tool remains under-specified for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explains the relationship between 'author' and 'author_name'/'author_email', and the role of 'parent' for replies. However, it does not describe the other 8 parameters, relying on their self-explanatory names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the resource 'comment', and clarifies the reply scenario via parent. This clearly distinguishes it from sibling tools like wp_comments_get, update, and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool (to create a comment or reply via parent), and the verb 'Create' implies it's for creation rather than updating or deleting. However, it does not explicitly mention 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, the description must carry the behavioral transparency burden. It adds useful semantic context by clarifying that 'Hold status = pending moderation', and 'List' implies a read-only operation. However, it does not disclose pagination behavior, default status, or other operational details beyond the filter list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and every clause provides useful information. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 10-parameter tool with no annotations, no output schema, and zero schema-level descriptions. The description covers the core filtering idea but omits defaults, pagination, the distinction between order and orderby, and any permission or response details, leaving significant gaps for such a parameter-rich tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage), so the description needs to compensate. It names the major filter parameters and clarifies the status values, which adds some meaning. Yet it leaves several parameters (page, per_page, orderby, order) underspecified and collapses order/orderby into the vague term 'ordering'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List comments', immediately distinguishing it from sibling comment tools like wp_comments_get, wp_comments_create, wp_comments_update, and wp_comments_delete. It also enumerates the filtering dimensions, making the scope 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating this is a list operation with various filters, which implies when it should be used (when a collection of comments is needed). It does not explicitly name alternatives or exclusions, but the listing purpose is unambiguous and naturally differentiates it from single-comment operations.
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 be self-sufficient. It discloses the default draft status and the meta registration requirement, which is valuable. However, it does not mention permissions, error handling, or the response structure, leaving some behavioral aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences, leading with the purpose then listing requirements and a key caveat. It contains no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, this description covers the essential creation flow and the meta caveat, but it omits explanations for content, slug, and excerpt, and does not describe return values or failure modes. It is minimally adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description is the main source of parameter meaning. It explains post_type, title, meta (with the registration caveat), and the status default, but it does not define slug, content, or excerpt, which are left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new item of any Custom Post Type' with a specific verb and resource. It distinguishes itself from sibling tools like wp_cpt_update and wp_posts_create by specifying 'any Custom Post Type' and the creation intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidelines by listing required fields ('post_type, title'), default status ('Defaults to draft status'), and how to set custom fields via the meta object. It lacks explicit comparisons to alternatives like wp_posts_create, but the scope is 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?
No annotations are provided, so the description carries the full burden. It discloses a useful behavioral constraint (post_type must match rest_base), which goes beyond the raw schema. However, it does not describe the response format, error behavior (e.g., 404 for missing id), authentication requirements, or any side effects. For a read-only fetch tool this is acceptable but not 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the primary action stated first and the additional constraint following. No wasted words. It is front-loaded and easy to scan, making it an exemplar of concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (3 params, no output schema). The description covers the core action and a key constraint, but it omits context like default behavior (context=edit), possible output shape, or error handling. Given the availability of sibling tools, an agent could infer some context, but the description alone is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the description must compensate for explaining parameters. It adds meaning for post_type by requiring it to match rest_base, but it does not explain id or context at all. The context parameter has an enum (view, edit, embed) and a default of 'edit', but the description offers no guidance on when to use which. With 3 parameters and only one partially explained, the description falls short.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb-resource pair: 'Fetch a single item of a Custom Post Type by id.' This clearly distinguishes the tool from sibling tools like wp_cpt_list (list), wp_cpt_update, and wp_cpt_delete. It also matches the naming convention 'get' for single-item retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a concrete prerequisite: 'post_type must match rest_base from wp_get_post_types.' This tells the user how to provide a valid post_type value. It doesn't explicitly say when to use this tool instead of alternatives, but the purpose is clear enough that a user would not confuse it with list/update/delete operations. The absence of explicit 'use this when...' language prevents a higher score.
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 description carries full burden. It discloses that the tool returns metadata fields, but does not mention the effect of the 'context' parameter on response shape, nor error behavior (e.g., 404 for missing id) or permission requirements. It is a read operation by nature, but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the action and lists key return fields without fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description needs to cover return values and parameter semantics. It partially does by listing some metadata, but omits explanation of the context parameter, possible response variations, and error conditions. Overall adequate for a simple fetch but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It clarifies the 'id' parameter is the media item identifier, but says nothing about 'context' (view/edit/embed) or its implications. Only half the parameters are meaningfully explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a single media item by id, with a specific verb and resource. It lists the metadata returned (dimensions, file size, thumbnails, etc.), which distinguishes it from sibling tools like wp_media_list, wp_media_update, and wp_media_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need a single media item by id, contrasting with listing or modifying operations. It does not explicitly name alternatives, but the context is clear enough for an agent to select it appropriately.
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 states that the tool writes revision title/content/excerpt back to the parent page, making clear it mutates the page. However, it does not disclose potential side effects (e.g., whether the current content is overwritten without undo, whether a new revision is created, or permission requirements), leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and adds a clarifying parenthetical. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two integer parameters and no output schema, the description adequately explains the core operation and the specific fields affected. It is complete enough for typical use, though it omits details about return values or behavior after the restore, which would be nice but are not essential given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions and the description does not explicitly map page_id and revision_id. However, the phrase 'revision of a page' and the tool name strongly imply that page_id identifies the page and revision_id identifies the revision to restore. This provides some semantic value beyond the bare schema, but it stops short of fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool restores a previous revision of a page, with the specific verb 'Restore' and resource 'page'. It further clarifies the action by listing the fields written back (title/content/excerpt), which distinguishes it from the sibling tool wp_pages_get_revision (which retrieves) and wp_posts_restore_revision (which targets 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: if you want to revert a page to a previous revision, use this tool. However, it does not explicitly specify when not to use it or mention alternatives like wp_posts_restore_revision for posts, nor does it discuss prerequisites such as checking that the revision belongs to the page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that tags are flat, returns terms with post counts, and supports search/hide_empty filtering. However, it does not explicitly state that the operation is read-only, require authentication, or describe pagination/sorting behavior. Some behavioral context is provided but not 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences, each adding value: it states the purpose, clarifies the flat nature of tags, indicates the return content, and lists filtering capabilities. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema and no annotations, the description covers the core behavior (listing tags) and high-level return type (terms with post counts). However, it omits details on pagination, sorting, and the exact response structure, which are left to the parameter names. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 the 'search' parameter (filter by search text) and 'hide_empty' (hide tags with zero posts), but leaves pagination (page, per_page) and sorting (order, orderby) undocumented. This is only partial compensation for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List blog tags', a specific verb and resource that clearly distinguishes this from get/create/update/delete operations on tags. It further notes tags are flat (no hierarchy) and returns terms with post counts, which reinforces its list/read nature and differentiates it from category listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need a flat list of tags, especially since tags are flat as opposed to hierarchical categories. It also mentions filtering options (search text, hide tags with zero posts) which helps decide if this tool fits. However, it does not explicitly name alternative tools like wp_taxonomies_list_categories or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 discloses required versus optional fields and the default role ('subscriber'), which is useful. However, it omits expected behavior like response format, uniqueness constraints, error handling, or permission requirements, so it only partially covers the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the primary action front-loaded. Every sentence adds value: the first states purpose, the second clarifies required/optional fields and default behavior. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and zero annotations, the description is too sparse. It doesn't describe the return value (e.g., created user ID or object), side effects, or unique constraints. Missing parameters like slug, locale, and nickname add to the incompleteness. This is insufficient for an agent to fully understand the tool's contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 lists most parameters (9 of 12) and adds note about default roles, giving meaning beyond the schema's raw property names. Yet it completely ignores slug, locale, and nickname, and doesn't explain the format or purpose of 'roles' beyond a default, so it doesn't fully compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new WordPress user' — a specific verb and resource that clearly differentiates this tool from siblings like wp_users_update, wp_users_delete, and wp_users_list. It immediately states the action and the target, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for creating new users, which implies it's for new records rather than modifying existing ones (use wp_users_update) or deleting (wp_users_delete). However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5.
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 explains the validation modes and default behavior ('require-all-validate' rejects the batch if any request fails validation; 'normal' runs best-effort), which is valuable. However, it does not disclose authentication requirements, rate limits, or detailed error handling for partial failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function, and every clause adds value. It avoids fluff and clearly communicates the key facts: what it does, when to use it, and the critical validation behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of output schema, the description covers the main purpose, use case, maximum batch size, and validation semantics. It does not describe the response format or error propagation, but the existing information is sufficient for an agent to select and invoke the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter understanding. It explains the 'validation' parameter and its enum values, but does not describe the 'requests' parameter structure beyond what the schema already provides. The schema is self-explanatory for 'requests', but the description adds minimal value for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes up to 25 WP REST requests in a single round-trip via /wp/v2/batch/v1, identifying the specific action and resource. It distinguishes itself from sibling tools that operate on individual resources by emphasizing the batch mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using the tool 'for performance when applying many independent writes,' providing a clear usage context. It does not explicitly mention when not to use it or name alternatives, but the inference that individual tools are better for single requests is straightforward.
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. It discloses two critical behaviors: default draft status (safe) and publish/future/private requiring a publish tier. This directly addresses the main risks of a create tool (unintended publication and permission requirements). It does not mention return values, error handling, or other side effects, but the disclosed safety and permission context is genuinely valuable and goes beyond a generic 'create' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and each subsequent clause conveys a distinct, essential piece of information. There is no fluff or repetition. For its length, it is efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no output schema, no annotations), this description is incomplete. It lacks information about the return value (e.g., the created page object), auth requirements for basic draft creation, error scenarios, and the meaning of most parameters. It covers only a few key points, leaving significant gaps for an agent trying to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there are 12 parameters, so the description must compensate. It adds meaning for only three parameters: status (default draft, publish tier requirement), parent (page id for hierarchy), and menu_order (ordering). The remaining nine parameters (date, meta, slug, title, content, author, excerpt, template, featured_media) are left entirely unexplained. With such low coverage, this is insufficient for an agent to correctly construct a request beyond those three fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new page.' It is specific about the resource (page) and the action (create), distinguishing it from sibling tools like wp_posts_create (posts) and wp_cpt_create (custom post types). The additional details about status, hierarchy, and ordering reinforce the specific purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by noting the default draft status (safe), support for hierarchy via parent, and ordering via menu_order. It also flags that publish/future/private statuses require a publish tier, which helps an agent understand permission boundaries. However, it does not explicitly mention alternatives (e.g., 'for posts use wp_posts_create') or state when NOT to use this tool, so it stops short of full 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?
The description goes beyond the schema by stating that it returns 'normalized post summaries' and listing the included fields, which signals that this is not a full-content endpoint. However, with no annotations, it omits behavioral details such as pagination, default status/order, or edge cases, leaving some transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and filters, and wastes no words. Every sentence carries useful information, including return type and the pointer to wp_posts_get.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters and no output schema, the description covers the core purpose, filters, and return fields, but omits pagination behavior, defaults, and full parameter explanations. It is adequate for a basic understanding but incomplete for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description groups parameters into filter categories (status, search, author, categories, tags, date range, ordering), giving high-level meaning that the schema lacks. It fails to mention pagination parameters (page, per_page) and doesn't explain formats or how filters combine, so it provides only partial value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List blog posts with filters' and specifies the resource (blog posts) and the action (list). It also distinguishes itself from the sibling tool wp_posts_get by noting 'Use wp_posts_get to fetch full content,' clarifying the scope of this tool as a summary-returning list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need a filterable list of posts, and explicitly provides a pointer to an alternative: 'Use wp_posts_get to fetch full content.' However, it doesn't explicitly contrast with wp_search_posts or mention exclusions, so it earns a 4 rather than a 5.
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. It adds return behavior ('Returns terms with post counts') and explains 'hide_empty', but does not explicitly state that this is a read-only operation or address pagination, rate limits, or side effects. The read-only nature is implied by 'List' but not confirmed, leaving some 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the main action and uses parentheses to clarify filter meanings. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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. The description provides a reasonable summary but is incomplete: it doesn't cover pagination parameters, default ordering behavior, limitations, or computation details of post counts. For a list tool, it is adequate but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description must explain parameters. It covers 'search', 'parent', 'hide_empty', and 'ordering', but omits 'page' and 'per_page' pagination parameters. This partial coverage adds meaning to some parameters but fails to fully compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List'), resource ('blog categories'), and scope (filters). It also implicitly distinguishes from the sibling 'wp_taxonomies_list_tags' by naming categories explicitly, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for listing blog categories and mentions filters, but does not explicitly mention when to use this tool versus alternatives like 'wp_taxonomies_list_tags'. It gives clear context but lacks explicit exclusion or alternative guidance, which would be helpful given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It notes the status default and typical availability for embedding, which is helpful. However, it omits details such as required capabilities, return value, or side effects (e.g., slug auto-generation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every sentence provides distinct value: the purpose, the content format requirement, and the status default rationale. No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description covers the core action, the most important parameter semantics, and a behavioral default. It doesn't explain slug or return value, but for a simple create operation this is nearly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 does clarify the critical 'content' parameter format (Gutenberg markup) and reinforces the 'status' default. However, 'slug' remains unexplained, and 'title' is left to inference. The added value is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Create a new reusable block.' This clearly distinguishes it from siblings like wp_blocks_update, wp_blocks_list, and wp_blocks_get. The phrase 'reusable block' also differentiates from generic post 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context: content must be Gutenberg block markup, and status defaults to publish with the rationale that reusable blocks are typically immediately available for embedding. It doesn't explicitly name alternatives or state when not to use it, but the guidance is clear enough for typical use.
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 discloses that only provided fields change (idempotent partial update) and that status transitions to publish/future/private require a publish tier (authorization constraint). This adds meaningful transparency beyond the schema, though it could also mention error handling or general permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct purpose: defining the operation, noting the partial-update behavior, and providing usage guidance for specific parameters. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 13 parameters, no output schema, and no annotations, the description covers core update semantics and one usage tip, but omits details about return values, error cases, and general authorization. It is adequate but not fully complete for an agent to use confidently in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 adds semantics for only two parameters: "parent" (re-parenting) and "status" (publish tier requirement). The remaining 11 parameters (e.g., title, content, featured_media) lack any explanatory context in the description, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb "Partially update" and resource "existing page by id", clearly distinguishing it from create/delete operations. The phrase "Only provided fields are changed" further clarifies it is a PATCH-like update, not a full replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it specifies the partial update behavior and gives a prerequisite (publish tier for certain status transitions). It also advises on using the parent parameter for re-parenting. However, it does not explicitly mention when to prefer this tool over sibling tools like wp_posts_update, so it falls short of a 5.
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 must carry the full transparency burden. It discloses exactly which fields are restored (content, title, excerpt) and the important side effect that the parent's current state becomes a new revision automatically, implying reversibility. It doesn't mention permissions, return value, or validation behavior, which prevents a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the purpose, the second explains the mechanism, the third discloses a critical side effect. No vague or redundant language. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter restore tool with no output schema, the description covers the core behavior and its most important consequence (new revision created). It doesn't mention the return value, permissions, or what happens if the revision is invalid, but it is otherwise sufficient for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate. It clarifies that post_id refers to the parent post and revision_id to the revision being restored, but it doesn't explicitly state that the revision must belong to the post or describe any error conditions. This is adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Restore a previous revision of a post' and details the exact mechanism: reads content, title, and excerpt from the revision and writes them back to the parent post. This is specific enough to distinguish it from siblings like wp_posts_get_revision (which only reads) and wp_posts_get_revisions (which lists revisions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is clearly implied: use this to roll back a post to a previous revision. However, there is no explicit guidance about when not to use it or comparisons with alternatives (e.g., using wp_posts_get_revision to inspect a revision before restoring). The absence of explicit exclusions or alternative references keeps it slightly below a 4.
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 disclosure burden. It reveals the write nature (status set to 'future'), the validation requirement (future date), and the authorization requirement (publish tier). It doesn't mention reversibility or output, but for a simple scheduling operation, this is sufficient and adds practical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of three short sentences, each adding value: purpose, constraint, and permission. It is front-loaded and avoids redundancy, achieving maximum clarity with minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, validation, and permission, but it doesn't explain the 'id' parameter semantics or what the response will be. Given the tool's simplicity and lack of output schema, these gaps reduce completeness, as an agent still might not know exactly how to pass the post identifier.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It adequately explains the 'date' parameter (must be in the future) but fails to describe the 'id' parameter, which is critical—the agent cannot infer from the description that 'id' refers to the post ID. This is a significant omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: scheduling a post for future publication by setting status to 'future' and a date. This distinguishes it from siblings like wp_posts_publish or wp_posts_update, as it specifically targets future scheduling while mentioning the underlying mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (scheduling posts with a future date) and provides a clear constraint ('The date must be in the future') and a prerequisite ('Requires publish tier'). It lacks explicit exclusions or alternative tool references, but the context is clear and actionable.
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 explicitly warns that deletion is permanent (no trash) and specifies the exact confirm string format and MODE=full requirement, which are critical for a destructive operation. It does not discuss permissions or return values, but the core safety-critical behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences with no filler. The key information is front-loaded ('Delete a tag'), followed immediately by the permanent nature and required confirmation. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tag-deletion tool, this description is nearly complete: it states the action, permanence, the confirmation necessity, and the MODE=full gate. It omits return-value details and permission requirements, but for this simple operation with no output schema, the provided details are sufficient for an agent to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions at all (0% coverage), so the description must compensate. It adds significant meaning for the confirm parameter by specifying the exact format 'DELETE_TAG_<id>'. The id parameter is left to its name and schema constraints, which is largely self-evident, but the description does not fully elaborate on it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Delete a tag'. It also adds the permanent/no-trash behavior and required confirmation, which distinguishes it from related tag and category tools like wp_taxonomies_update_tag and wp_taxonomies_delete_category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context—what action to perform, that deletion is permanent, and that confirm and MODE=full are required. However, it does not explicitly mention when to use this tool instead of alternatives like wp_taxonomies_delete_category, nor does it state any when-not-to-use 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?
No annotations are provided, so the description carries the transparency burden. It discloses that the 'edit' context returns specific fields (email, locale, capabilities) and that capabilities require manage_options, adding valuable behavioral context. However, it does not mention read-only status, error handling, or default behavior explicitly, so it is not fully exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the primary purpose in the first sentence, and adds a relevant behavioral note in the second. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with two parameters and no output schema, the description provides sufficient context: what it does, key parameter behavior, and permission requirements. It lacks details about return format or error handling, but given the tool's simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions, so the description must add meaning. It clarifies that 'id' is the user identifier and explains the effect of the 'edit' context for the context parameter. However, it does not explain the 'view' or 'embed' contexts, leaving partial coverage of the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a single user by id', which specifies a verb ('fetch'), a resource ('user'), and a scope ('by id'). It distinguishes from siblings like wp_users_list and wp_users_get_current by focusing on a single user lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single user by ID but does not explicitly mention alternatives or exclusions. The information about 'Edit context' is behavioral rather than guidance on when to use this tool vs. others. No explicit 'use this when' or 'use another tool when' 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, the description discloses the key side effect that changes propagate to every post/page using the block. It also communicates PATCH-like partial update behavior. It does not cover auth, return values, or reversibility, but the most significant behavioral trait is revealed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action and a vital caveat; no redundant filler. Efficient and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description presents the core action and a crucial side effect. It omits details like return value or permissions, but the schema covers acceptable fields and the description gives enough context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 any of the five parameters. It adds no meaning beyond the raw schema, failing to compensate for the low coverage; only 'partial update' implies optionality of fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Partially update' with a clear resource ('a reusable block'), distinguishing it from sibling create/delete/get operations. It also differentiates from general post/page updates by focusing on the reusable block resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating reusable blocks and adds critical context via the NOTE about global propagation across posts/pages. It lacks explicit alternatives or when-not-to-use guidance but provides clear contextual direction.
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 reveals that `url` causes the server to fetch and forward bytes, that `data` must be base64-encoded, and that there is a 25 MB cap. But it omits return values, authentication needs, and potential side effects such as creating a new media item.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the tool's purpose clearly, and the second packs in input modes, required companions, optional metadata, and size limit. Every clause earns its place; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter upload tool with no output schema, the description thoroughly covers inputs and constraints but fails to explain the return value or error behavior. Since no output schema exists, the description should have clarified what the agent can expect after a successful upload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 does so by naming and explaining all nine parameters, including the exclusive-or relationship between `url` and `data`, the meaning of `filename`/`mime_type`, and the purpose of `post`. It does not detail valid value formats, but it is strong compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb+resource: 'Upload a file to the WordPress media library.' This uniquely identifies the tool's action and differentiates it from sibling tools like wp_media_get, wp_media_update, and wp_media_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit input guidance: provide EITHER `url` OR `data`, with `filename` and `mime_type` also required for the data path. It also lists optional metadata and the 25 MB limit. However, it does not explicitly mention alternatives among sibling tools, though the upload action is clearly distinct.
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?
Without annotations, the description discloses key behavioral traits: partial update semantics ('Only fields provided are changed') and permission requirements ('Status transitions to publish/future/private require the publish tier'). This adds value beyond the schema, though it does not cover return format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the purpose and then adding behavioral nuance. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters) and absence of annotations or output schema, the description covers the critical partial-update behavior and status permission but omits other useful context such as expected response format, error cases for non-existent ids, and potential side effects. It is adequate but not comprehensive for a complex mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It does by explaining that all fields are optional and partially updated, which is critical for understanding the parameter semantics. However, it does not describe any individual parameters or their formats (e.g., date, meta, categories), leaving the agent to rely on parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Partially update an existing post by id', which specifies the verb (update), resource (post), and scope (by id, partial). It distinguishes this from sibling tools like wp_posts_create, wp_posts_publish, and wp_posts_schedule by focusing on updating an existing post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use for existing posts by id and only fields provided are changed. It also mentions the publish tier requirement for status transitions, which is a practical prerequisite. However, it does not explicitly name alternatives or state when not to use it, though this is largely implied by 'existing post by id'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the analyses performed and the optional keyword behavior, but doesn't state whether the tool is read-only, return format, or defaults (e.g., what happens if language is omitted).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb, no redundancy. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain return values; it mentions stats but not structure or defaults. Overall it covers main functionality but leaves operational details unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining focus_keyword (presence stats and density) and language (ES/EN/PT readability). post_id is implied by 'on a post' but not explicitly detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs SEO/content analysis on a post, listing specific checks (readability, keyword density, headings hierarchy, content length), which distinguishes it from siblings like wp_seo_get_meta or wp_seo_detect_provider.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is for analyzing a post's SEO/content quality, and explains optional focus_keyword usage. However, it doesn't explicitly mention alternatives or when not to use this tool versus other SEO tools.
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 does disclose important behavioral traits: ranking weights (title matches 3x > excerpt matches 1x + recency boost) and source post exclusion when post_id is given. This goes beyond a generic 'suggest' and helps the agent understand how results are ordered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one sentence for the main purpose, one for ranking logic, and one for exclusion behavior. Every sentence adds meaningful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, ranking behavior, and exclusion, but it does not specify the structure of the returned list (e.g., whether items include post ID, title, score) nor clarify how limit/status interact with the described behavior. Given no output schema, this leaves some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the roles of 'keyword' and 'post_id' as alternative inputs, which is valuable since schema coverage is 0%. However, 'limit' and 'status' are not addressed in the description; 'status' is only indirectly implied by 'published posts', and 'limit' is left to the schema's default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Suggest internal links') and resource ('returns a ranked list of related published posts'). It also includes distinctive details on ranking weights and source post exclusion, which differentiates it from sibling tools like wp_search_posts and wp_posts_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 find related posts to link to, given a keyword or post_id. It does not explicitly name alternatives or exclusion criteria, but the unique purpose makes the usage scenario evident.
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 full burden. It discloses that the operation requires manage_options, signals a publish-tier change, and explains why (affects every visitor), adding meaningful behavioral context. It does not mention return values or rollback options, but the global impact warning is a strong extra.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and target, followed by a capability requirement and a caution about impact. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 optional parameters and no output schema, the description covers purpose and caution but misses key behavioral details: whether the update is partial (only provided fields) or full replacement, what happens if no parameters are passed, and what the response looks like. These gaps make it less than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter descriptions, so the description's listed examples (title, tagline, URL, language, timezone, default category, posts_per_page) provide partial compensation. However, it uses 'etc.' and leaves many parameters (email, date_format, start_of_week, etc.) unexplained. The property names are self-explanatory, but the description doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('site-wide settings'), clearly distinguishing it from post-level or taxonomy tools. It lists concrete examples like title, tagline, URL, language, timezone, default category, and posts_per_page, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by stating the required capability (manage_options) and emphasizing the publish-tier impact on all visitors. While it doesn't name alternative tools, the site-wide scope inherently differentiates it from sibling tools like wp_posts_update or wp_cpt_update. It lacks explicit exclusions, so it earns a 4 rather than 5.
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 transparency burden. It discloses that context=edit requires the manage_options capability and returns additional fields (email, locale, capabilities). However, it does not mention pagination behavior or explicitly confirm read-only status, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. The first sentence states the operation; the second packs filter semantics and permission info efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core listing semantics and key filters well, but for an 8-parameter tool with no output schema and no annotations, it omits explanation of pagination/ordering parameters and does not describe the default return structure for context=view. Some operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains the semantic effect of who=authors, roles format, and context=edit's return/permission implications. It leaves page, per_page, order, orderby undocumented, but their names and schema defaults provide reasonable clues.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List users' – a clear verb+resource that distinguishes this from single-user tools like wp_users_get. It immediately enumerates filtering options, making it unambiguous that this is a collection listing endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes specific filters (search, roles, who=authors) and explains the permission requirement for context=edit (requires manage_options). This gives clear context for when to use these options, though it doesn't explicitly name alternative tools or when-not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a key dependency (companion plugin) and the reason the check matters, but does not specify output format, failure behavior if plugin missing, or confirm read-only nature. With no annotations, more could be said.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: purpose first, then consequence and prerequisite. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter detector, description covers what, why, and prerequisite. Omits explicit output shape but domain context implies a simple boolean/list; acceptable for low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema already fully covers inputs; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it detects specific page builders (Elementor, Divi, Beaver Builder, WPBakery) and why this matters (content outside post_content), distinguishing it from general detection tools like wp_seo_detect_provider.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the use case: detecting page builders that limit MCP editing, and notes a prerequisite (companion plugin). It does not explicitly name alternatives or state when not to use, but context is 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?
No annotations are provided, so the description carries the full burden. It adds useful behavior details: alt_text is required, caption/description are optional, and empty alt_text is allowed to explicitly clear the value. However, it does not disclose auth requirements, whether unsupplied fields remain unchanged, or return/error behavior, leaving meaningful 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and fields. Every sentence adds value: the first defines scope, the second gives the SEO use case and the clearing edge case. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a focused metadata update with no output schema and no annotations, the description sufficiently covers purpose, applicable fields, use case, and an important edge case. It lacks explicit success/return details and permission notes, but these are less critical for such a simple tool and do not prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 identifies alt_text as required, caption/description as optional, and adds a key semantic that empty alt_text clears the value. It does not explicitly describe the 'id' parameter, but it is self-evident from the tool name and schema. This is adequate for the tool's simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Update accessibility and descriptive metadata of a media item,' and enumerates the exact fields (alt_text required; caption and description optional). This clearly distinguishes it from the more general wp_media_update and other media siblings by focusing on SEO/accessibility metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool: 'Useful for bulk SEO improvements on existing media.' This implies it is for updating already-uploaded media, not for upload or general editing. It does not explicitly mention alternatives like wp_media_update or state when not to use it, so it misses the full 5.
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 provided, so the description carries full burden. It discloses the output format (rendered HTML, raw fields in edit) and the effect of context, but omits explicit read-only confirmation, error behavior, and permission requirements. Partial credit for adding behavioral context around context modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no fluff. Every sentence contributes to understanding the tool's purpose and key behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with only two parameters, the description covers the return payload and context behavior sufficiently. It lacks edge-case details like 404 handling or permissions, but these are not critical given the low complexity and clear scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains the semantics of 'context' (edit/view) and default behavior, adding value beyond the schema. It does not explain 'embed' or elaborate on 'id', but 'id' is self-explanatory and the explanation covers the most important parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches a single blog post by ID, with a specific verb and resource. Distinguishes from sibling list/get tools by emphasizing single post and full 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for selecting the 'context' parameter (edit vs view) and default behavior. However, it does not explicitly mention alternatives or exclusions relative to list tools, though the 'single post by ID' phrasing implies its use case.
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 full burden of disclosing behavior. It explicitly states 'Read-only' and describes the return fields (id, parent post id, author, dates, rendered content). It does not cover limitations like pagination or permissions, but for a read-only list this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with front-loaded purpose, followed by return details and a read-only note. Every clause contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without an output schema, the description adequately covers the operation, return fields, and safety trait. It lacks explicit comparison to sibling tools but is otherwise complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single post_id parameter with 0% description coverage. The description's 'of a post' directly maps to post_id, clarifying that it is the post whose revisions are fetched. This adds meaning beyond the schema's bare type and constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'List' with resource 'revisions of a post', clearly identifying it as a listing operation. It distinguishes from sibling tools like wp_posts_get_revision (singular) and wp_posts_restore_revision by focusing on plural revisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the action described, but there is no explicit guidance on when to use this tool versus alternatives such as wp_posts_get_revision or wp_posts_restore_revision. No exclusions or conditional advice are 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, the description carries the full behavioral burden. It clearly states the operation is a read, and importantly discloses that meta is sourced from whichever SEO provider is active, adding context about provider dependency. It does not cover all edge cases (e.g., missing post, provider errors) but provides meaningful behavioral insight beyond a simple '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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose ('Read the current SEO meta for a post'), and packs a detailed field list into a parenthetical. No wasted words; every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter. The description lists the fields returned, which compensates for the absent output schema, and notes the provider dependency. It does not explain return format or error scenarios, but for a read operation of this scope, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (post_id) with no description and 0% schema description coverage. The description implies the post is identified by post_id but does not explicitly name or elaborate on it. Since the parameter is simple and self-explanatory, the marginal value added is minimal, warranting a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Read'), the resource ('SEO meta for a post'), and enumerates the specific fields involved (title, description, OG, Twitter, canonical, robots, JSON-LD, focus_keyword). This distinguishes it from sibling tools like wp_seo_set_meta (write operation) and wp_seo_detect_provider (provider detection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear when-to-use context (reading current SEO meta) and explicitly instructs to call wp_seo_detect_provider first to know the active provider. It does not explicitly compare against alternatives like wp_seo_analyze_post, but the prerequisite guidance is valuable and goes beyond mere implication.
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 explains hierarchy via parent ID and auto-slug generation, but does not mention required permissions, error conditions, or side effects. This is partial transparency, not full.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core purpose. Every sentence adds functional information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description provides key behavioral details (required name, auto-slug, parent hierarchy) but omits return format and potential failure modes. It is sufficient for selection and basic invocation, though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 name (required), slug (auto-generated if omitted), and parent (category id), covering 3 of 4 parameters. The 'description' parameter is not addressed, so it adds significant but not complete semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new blog category' with a specific verb and resource, distinguishing it from sibling tools like create_tag, update_category, or delete_category. The scope 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case—creating a new category—and provides context about hierarchy and slug generation. It does not explicitly mention alternatives or when-not-to-use, but the verb 'Create' makes the intended scenario clear.
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 reveals that slug auto-generates from name if omitted, which is not evident from the schema. It does not mention return values or error conditions, but the core behavior is sufficiently covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every sentence adds useful detail. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with 3 parameters and no output schema, the description covers required fields, slug behavior, and structural constraints. It lacks return value or error details, but is reasonably complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. It explains that 'name' is required and 'slug' auto-generates if omitted, but it does not describe the 'description' parameter. This partial compensation earns a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Create a new blog tag.' It also clarifies the taxonomy's flat nature ('no parent'), distinguishing it from sibling create_category tool. This fully communicates the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool creates a blog tag and notes it is flat without a parent, implying it is for flat taxonomies as opposed to hierarchical categories. It does not explicitly name alternative tools, but the context strongly indicates when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that updates are partial (only provided fields change) and mentions permission boundaries. This adds valuable behavioral context beyond the tool name, though it does not detail return values or side effects like password hashing, leaving some 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and immediately followed by key permissions. Every word earns its place; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: purpose, partial update behavior, and authorization. It does not explain return values or error conditions, but given the simple update nature and the absence of an output schema, it is reasonably complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 groups parameters into 'profile fields, password, or roles,' which gives high-level meaning, but it does not explain individual parameters beyond their schema types. The schema property names are self-explanatory for most fields, but the description adds minimal semantic detail about how roles or password updates behave.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Partially update a user by id.' It specifies the resource (user), the action (update), and the identifier (id). It also distinguishes from sibling tools by noting it can change profile fields, password, or roles, which aligns with its update role versus create/delete/list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for updating an existing user by id, and it notes authorization requirements ('Self-update permitted; updating other users requires elevated capabilities'). While it doesn't explicitly state when not to use it, the 'partial update' wording and resource-specific nature make usage clear without needing exclusions.
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 fully discloses the safety workflow: dry-run default, confirm token required to apply, and the limitation to rendered post_content. This goes well beyond the schema to inform the agent about side effects and safeguards.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loads the core purpose. The 'Requires MODE=full' clause is a minor distraction but does not undermine clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 6 parameters, the description covers the essential workflow and scope well. Missing details include parameter semantics for status/per_page and the MODE requirement, which leaves a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains dry_run, confirm, and find/replace implicitly. However, with 0% schema description coverage, it leaves status, per_page, and the 'MODE=full' requirement unexplained, creating partial ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Find and replace a literal substring across post content,' using a specific verb and resource. It clearly differentiates from siblings by noting it operates on post_content only and does not affect titles/excerpts/meta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the dry-run then confirm workflow, which is key to using the tool safely. It also clarifies scope by stating what it does not touch, but it does not explicitly name alternative tools or exclusion 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 burden. It adds useful behavior context: includes custom taxonomies (e.g., product_cat for WooCommerce) and explains the filter's effect. However, it does not mention return format or any limitations, but for a read-only list, the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no unnecessary words. It efficiently covers purpose and filter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter, the description is complete enough. It covers scope, custom taxonomy inclusion, and the filter. It lacks return structure details, but given the low complexity and absence of an output schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter 'type' with no description. The description fully explains it as an 'Optional type filter to list only taxonomies associated with a given post type,' providing meaning beyond the bare schema and compensating for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all taxonomies registered on this site' with a specific verb and resource. It also mentions the optional type filter and distinguishes from sibling tools that handle terms or post types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it lists taxonomies and supports a filter, but it does not explicitly contrast with alternatives like term-listing tools or provide when/when-not guidance. The context is clear but lacks exclusions.
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 provided, the description fully carries the responsibility of disclosing behavior. It reveals that the tool is write-oriented, safe by default (dry-run), requires a confirmation token, writes through the active SEO provider, and silently drops unsupported fields. This is substantial and non-obvious behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding necessary information: purpose, mode requirement, dry-run default, apply workflow, and provider behavior. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex bulk-update tool with no output schema, the description covers the main workflow, safety mechanism, and provider caveat. It notes the dry-run return type (count + sample) but does not describe exact response formatting or batching/pagination behavior, which are relevant for a tool with a per_page parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 does explain dry_run, confirm, and the general semantics of meta, but filter and per_page are not described beyond their schema names and types. This leaves a moderate gap for parameters that are central to selecting which posts are updated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object — 'Apply the same SEO meta to many posts at once' — which clearly conveys the tool's bulk update purpose. This distinguishes it from single-post SEO tools like wp_seo_set_meta and from other bulk operations like wp_bulk_find_replace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage instructions: requires MODE=full, dry-run by default, and the exact steps to apply changes using dry_run=false with the confirm token. It does not explicitly name alternatives for single-post updates, but the bulk phrasing makes the intended use clear.
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 full burden and discloses key behaviors: default soft delete, the hard delete confirmation format, and the MODE=full requirement. It does not mention return values or error handling, but the disclosed behaviors are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with no fluff. It efficiently covers the action, default behavior, and hard-delete prerequisite in a compact structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite four parameters, no annotations, and no output schema, the description provides essential operational details: soft delete default, hard delete confirmation format, and MODE requirement. It omits return value details and permissions, but these are less critical for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, but the description explains the force and confirm interaction, and implicitly defines post_type and id through context. It adds significant meaning beyond the schema, though it could explicitly state that post_type is the CPT slug and id is the item ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete an item') and specifies the resource ('any CPT'), effectively distinguishing it from sibling tools that target posts, pages, or media. The mention of default trash behavior further clarifies its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on default behavior (trash) and how to perform a hard delete (force=true with confirm string), including the MODE=full requirement. While it does not name alternative tools or state when not to use it, the context and name imply its scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It discloses the recoverable nature of trash, the irreversible permanent deletion, and the additional safety confirm mechanism. This gives the agent a good understanding of consequences, although it doesn't cover edge cases like deleting already-deleted posts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the core action, and every sentence adds value. It packs essential behavioral details into two sentences without any fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter delete tool with no output schema and no annotations, the description covers the critical aspects: default behavior, permanent deletion path, and required confirm format. Minor omissions like error handling or permissions are not critical for basic invocation, but the description could have noted the irreversibility explicitly. Overall, it is well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, so the description must compensate. It explains 'force' and 'confirm' in detail, including the exact format 'DELETE_PERMANENTLY_<id>', but does not explicitly describe 'id'. That said, 'id' is self-evident from context and the schema's basic type, so the non-obvious parameters are well handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action with a specific verb and resource ('Delete a post'), and immediately distinguishes between the default trash behavior and permanent deletion, making its purpose unambiguous and distinct from sibling tools like wp_posts_update or wp_posts_publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use the default trash path versus the permanent deletion path, including the required confirm string format and MODE=full prerequisite. However, it does not explicitly mention alternative tools or when-not-to-use, so it stops short of a 5.
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. It discloses that the tool returns only a lightweight result shape (id, title, url, type, subtype) and directs users to fetch full content separately. It implies a read-only operation and does not discuss permissions or pagination, but the disclosed behavior is clear and honest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundancy: the first sentence states the purpose and endpoint, the second describes the return shape, and the third covers filtering and alternatives. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is fairly complete for a search tool. It covers scope, result format, filtering, and follow-up actions, but omits details like pagination parameters and sorting behavior. Overall, it provides enough context for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains the meaning of 'query' and 'type' (with defaults and enum options), but does not elaborate on 'page', 'per_page', or 'subtype'. This provides partial parameter semantics but not complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as a full-text search across posts, pages, custom post types, and terms, and explicitly mentions the WP /wp/v2/search endpoint. This distinguishes it from sibling tools that list or retrieve specific posts/pages, and it specifies the lightweight result shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it mentions the default search target (type=post), allows filtering by type=term, and directs users to wp_posts_get / wp_pages_get for richer content. This clearly indicates when to use this tool versus 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, the description carries full burden. It transparently implies a read-only list operation and discloses that it includes both built-in and custom statuses. It doesn't detail return format or edge cases, but for a zero-parameter list tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action. It includes useful illustrative examples (publish/draft/pending/private/future) without verbosity. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and a simple list operation, the description is complete. It fully explains what the tool returns (all statuses, including custom ones) and requires no further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description adds nothing about parameters because there are none to explain. This is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all available post statuses.' It specifies the resource (post statuses) and the action (list), and distinguishes itself from sibling tools like wp_get_post_types and wp_get_taxonomies by focusing specifically on statuses. The inclusion of built-in and custom statuses adds depth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it obvious when to use this tool: whenever you need a complete list of post statuses. While it doesn't explicitly mention alternatives, the context is clear and no exclusions are needed. For a simple listing tool, this is sufficient guidance.
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. It discloses the tool's scope (all post types), includes examples of built-in and custom types, and specifies return fields (rest_base, hierarchy, supported features, taxonomies). This goes beyond the minimal 'list' verb, though it does not explicitly state read-only behavior or potential exclusions like internal post types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: purpose with examples, return fields, and usage tip. Every sentence adds distinct value with no redundancy or filler, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is remarkably complete. It covers what the tool does, the scope (all post types), return content, and when to use it relative to wp_cpt_* tools. No critical information is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description adds relevant output context about what the tool returns, which is useful even with no input schema to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all post types registered on this site' with a specific verb and resource, and distinguishes itself from sibling wp_cpt_* tools by explicitly covering both built-in and custom post types. The parenthetical examples (post, page, WooCommerce, ACF CPTs) further clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit usage directive: 'Use this before wp_cpt_* tools.' This tells the agent when to invoke this tool in relation to the custom post type tools. However, it does not mention when not to use it or name specific alternatives for other scenarios, so it stops short of full when/when-not guidance.
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. It discloses the return items and implies a read-only diagnostic operation. It does not mention side effects, but the semantics of 'verify' and the return values make it adequately 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys purpose, methodology, and outputs without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no params and no output schema, the description fully explains what the tool does and what it returns. It is complete for a health-check tool and needs no further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not add parameter details. The baseline for 0-param tools is 4, and the description correctly focuses on behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verify') and names the resources (connectivity, authentication, capabilities), then lists concrete outputs (reachability, REST API namespaces, MCP Bridge plugin status). This clearly distinguishes it from CRUD siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for diagnosing the WordPress connection before using operations. It doesn't explicitly exclude alternatives, but the context is strong and no conflicting use cases are present among siblings.
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 full burden. It states the core behavior (sets status to 'publish'), clarifies it operates on an existing post (not creating), and discloses the 'publish tier' permission requirement. It does not mention return values or idempotency, but for a simple mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action and effect, then add the shortcut relationship and the tier requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the action, the resulting state, the prerequisite permission, and how it relates to an alternative tool. It is fully complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only 'id' with no description coverage. The description compensates by explaining that the id refers to an existing post, providing essential semantic meaning. It doesn't go into further detail, but for a single parameter this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Publish') and resource ('an existing post by id'), and explicitly defines the effect as setting status to 'publish'. It also differentiates itself from wp_posts_update by being a shortcut, making its purpose unambiguous relative to sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to publish an existing post by id, and it's a shortcut for wp_posts_update with status='publish'. It also mentions the 'publish tier' requirement. However, it does not explicitly state when NOT to use it (e.g., for scheduling, use wp_posts_schedule), leaving some implicit inference.
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 discloses the key destructive behavior: the arrays replace existing taxonomies. It also warns about the need to fetch existing terms if preservation is desired. However, it doesn't specify what happens when only one array is provided (e.g., whether tags are left untouched or cleared), which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver the core purpose and a usage caveat without fluff, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main replacement behavior and gives a preservation strategy, it leaves ambiguity about omitted arrays and lacks mention of return value or side effects. For a mutation tool with no output schema and no annotations, this is a notable gap, warranting a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains that the arrays correspond to categories and tags and that they replace existing values, adding important semantic meaning beyond the schema's parameter names and types. It could further detail that IDs are term IDs, but that's inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it replaces categories and/or tags of a post, using a specific verb ('Replace') and resource, distinguishing it from sibling tools that create/update/delete taxonomy terms individually or manage posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to use wp_posts_get first if preserving existing terms and adding to them, providing a clear alternative. It also implies this tool is for replacement scenarios, giving contextual when-to-use guidance.
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 revealing behavioral traits. It discloses that deletion is permanent (no trash), that reassign transfers content ownership, and that a confirm string is required. This goes beyond a generic 'delete' statement, though it does not cover response shape or post-conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the core action, then packs essential constraints (permanence, required parameters, confirm format, MODE=full) into a compact, scannable structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action with no annotations or output schema, the description covers the key operational aspects: what happens (permanent delete), what is required (id, reassign, confirm), and execution constraints (MODE=full). It does not mention response format or error cases, but the provided details are sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does so effectively: reassign is described as 'user id to inherit deleted user's content', confirm's exact format is given ('DELETE_USER_<id>'), and id is contextually clear from the tool name and confirm pattern. All three parameters are semantically accounted for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb and resource: 'Delete a user'. It immediately clarifies the permanent nature ('WP REST has no trash for users — always permanent'), distinguishing this delete operation from trashable content types and setting clear expectations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear prerequisites: all three required parameters, the confirm format, and the MODE=full requirement. It does not explicitly name alternatives, but the unique resource (user deletion) makes the usage context clear. The permanence warning implicitly communicates when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses a key behavioral trait: the user is determined by the Application Password used for authentication. This adds valuable context beyond the tool name, though it does not detail error cases or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose, followed by a practical usage note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description fully covers its purpose, authentication dependency, and typical use cases. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to document. The baseline for zero-parameter tools is 4, and the description appropriately omits any irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the current authenticated user (via Application Password), with a specific verb 'Return' and a clear resource. It distinguishes itself from siblings like wp_users_get and wp_users_list by focusing on the current user context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states usefulness for 'whoami' checks and discovering role/capabilities, giving clear context for when to use it. It does not mention alternatives or exclusions, but the usage context is clear enough.
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 provided, the description fully discloses the destructive behavior: default trash, hard-delete requires force=true and confirm='DELETE_PERMANENTLY_<id>', and referencing posts/pages will show empty placeholders. This is comprehensive for a delete operation, including the MODE=full implementation detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a clear purpose: the action, the deletion modes, and the warning. It is front-loaded with the primary purpose and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter delete tool with no annotations and no output schema, the description adequately covers the deletion process, the confirmation requirement, and the impact on referencing content. It does not describe the return value or error cases, but these are less critical for a delete tool and the warning covers the main risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by explaining the force parameter (force=true triggers hard delete) and the confirm string format. The id parameter is implied but not explicitly described, though it is obvious from the context. This adds significant value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states "Delete a reusable block" with a specific verb and resource, clearly distinguishing it from sibling tools like wp_blocks_create, wp_blocks_get, and wp_blocks_update. It also clarifies the default trash behavior and the hard-delete option, further defining the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to perform both trash (default) and permanent deletion (force=true with confirm), including the required confirmation format. It does not explicitly name alternative tools or state when to choose one deletion mode over the other, but the warning about placeholder blocks gives practical guidance for usage.
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 provided, the description fully carries the burden of behavioral disclosure. It states that trash is not available for terms, so deletion is always permanent, and it explicitly explains the impact on posts (they are not deleted but lose the category). It also discloses the confirm string requirement and MODE=full as environmental constraints, making the tool's behavior highly 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, with the core action and permanence in the first sentence, and prerequisites plus post-effects in the second. Every word adds value; there is no padding or repetition of schema fields. This is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations or output schema, the description covers the essential context: permanence, confirm requirement, MODE=full requirement, and the effect on posts. It does not describe the response format or error cases, but these are less critical for a delete operation and the description is otherwise complete enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 fully specifies the confirm parameter format ('DELETE_CATEGORY_<id>'), which is critical because otherwise confirm is just an undocumented string. The id parameter is implicitly the category ID from the tool name and its use in the confirm string. This adds meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Delete a category,' a specific verb and resource that clearly distinguishes this from sibling tools like wp_taxonomies_delete_tag and wp_taxonomies_create_category. It also adds important context that the deletion is permanent, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: the confirm parameter must be in the format 'DELETE_CATEGORY_<id>' and the operation requires MODE=full. It also clarifies that posts in the category are not deleted but only lose the assignment. However, it does not explicitly name alternatives or exclusions (e.g., 'use this instead of delete_tag'), so it falls short of a 5.
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 provided, the description fully carries the behavioral disclosure burden. It discloses that the default action is a recoverable trash, that permanent deletion requires force=true plus a specific confirmation string, and that MODE=full is required. This gives the agent important safety-relevant behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action, the second packs the behavioral details. It is front-loaded and every clause earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with no annotations and no output schema, the description covers the essential decision points: default trash, permanent deletion path, and the MODE=full requirement. It does not mention return values or error handling, but for a simple comment delete operation the provided information is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 the semantic meaning of force and confirm, including the exact confirmation format 'DELETE_PERMANENTLY_<id>', and clarifies the default of force=false. The id parameter is self-evident from the purpose, so the description adds meaningful value for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Delete a comment.' It clearly distinguishes this from sibling tools like wp_comments_get, wp_comments_update, and wp_comments_create by stating the deletion action. The additional details about trashing and permanent deletion reinforce the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains the default behavior (trash, recoverable) and when to use force=true with the required confirmation string for permanent deletion. It does not explicitly mention alternatives or when-not-to-use, but the context is sufficient for an agent to decide when deletion is appropriate.
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 full behavioral disclosure burden. It reveals that the tool combines two API endpoints (/wp-json/ root and /wp-json/wp/v2/settings), notes the settings endpoint is admin-only, and clarifies that admin email is returned only if accessible. This goes beyond basic read semantics and provides useful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, then adds implementation details. The list of fields is comprehensive but focused, and every sentence adds value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with no output schema, the description is complete. It names the exact configuration values returned, explains the data source and access constraints, and notes version-specific behavior for the sitemap URL. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing to document. The description appropriately focuses on what is returned rather than inputs. Baseline 4 applies for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads site-level configuration and enumerates specific fields (title, tagline, URL, etc.). It distinguishes itself from write operations like wp_update_site_settings and from wp_get_site_capabilities by focusing on configuration details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (reading site configuration), but it does not explicitly mention when not to use it or name alternatives. However, the sibling tools make the distinction obvious, and the read-only verb plus configuration scope is unambiguous.
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 provided, the description carries full responsibility and does so thoroughly. It reveals dangerous/irreversible behavior (permanent delete requires explicit confirm), prerequisites (MODE=full), and a non-obvious edge case (children are orphaned, no auto-cascade). This exceeds the bare minimum and gives strong 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, front-loaded with the core action ('Delete a page') followed by necessary exceptions and edge-case behavior. Every sentence provides practical information without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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, the description covers safety, prerequisites, and an important edge case. It does not describe the return value or error handling, which would arguably be useful in the absence of an output schema, but the operational guidance is strong enough to be nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because property descriptions are absent, so the description must compensate. It explains the exact confirm format ('DELETE_PERMANENTLY_<id>'), when force is required, and implies id is the page to delete. This adds significant semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Delete a page' with specific verb and resource. The description distinguishes this tool from sibling delete tools (posts, media, CPTs) by naming 'page' and details trash vs. permanent deletion, which uniquely identifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: default sends to trash (recoverable), permanent deletion requires force=true plus a specific confirm string and MODE=full. It also explains parent-child cascade behavior, but does not explicitly mention alternatives or when to use a different delete tool (e.g., posts vs. pages), so it stops short of a 5.
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 transparency burden. It explains what the tool reports (provider and capabilities) and connects that to downstream persistence/rendering behavior. However, it does not explicitly state side effects or permissions, though the name 'detect' implies a read-only 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two sentences—with the core purpose front-loaded and the usage guideline following immediately. Every word earns its place; there is no redundant detail or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity (0 params, no output schema), the description is complete. It states what the tool does, what it reports, and why to use it before wp_seo_set_meta. No critical information is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Baseline for 0 params is 4. The description adds context about possible return values (provider list and capabilities), which is helpful even though it does not pertain to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function with the verb 'detect' and specifies the resource: the active SEO provider (bridge/yoast/rankmath/null). It also distinguishes itself from siblings by noting that it reports capabilities relevant to wp_seo_set_meta, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage directive: 'Use this before calling wp_seo_set_meta to know what fields will actually be persisted and rendered.' This tells the agent exactly when to invoke this tool and why, differentiating it from 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, the description carries the transparency burden. It discloses partial updates ('Pass any subset'), silent ignoring of unsupported fields, and points to provider detection. However, it doesn't mention whether existing meta is overwritten or merged beyond the subset implication, and no return behavior is specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the core action, the second lists all supported fields and the critical caveat. No wasted words, and the structure is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no output schema, the description covers the essential behaviors: what fields are accepted, that partial updates are possible, and that unsupported fields are ignored. It also references the provider detection tool. Missing details like return format or auth requirements are not critical given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by enumerating all accepted meta fields, adding format hints (URL, object, robots structure), and clarifying that a subset is allowed. This adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Write' and resource 'SEO meta for a post', distinguishing it from the sibling getter wp_seo_get_meta. It also specifies 'via the active provider', which is a unique qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to call wp_seo_detect_provider to know which features apply, and warns that unsupported fields are silently ignored. This is clear guidance on when to use this tool and which alternative to consult first.
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 provided, the description carries the full burden of disclosing side effects. It clearly states that the default operation is a recoverable trash action, while permanent deletion requires force=true and a confirm string, and requires MODE=full. It also transparently warns about the variability of trash behavior in WP across sites, going beyond simple operation descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loading the primary action and then addressing optional behavior and caveats. No words are wasted; every sentence contributes useful information, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and schema descriptions, this description is notably complete. It covers the operation's default behavior, the permanent deletion path with its prerequisites, and a relevant platform-specific caveat. It leaves little to no critical gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), so the description's explanations of force and confirm are critical. It specifies the exact format for confirm ('DELETE_PERMANENTLY_<id>') and clarifies that force=true is a prerequisite for permanent deletion, adding meaning well beyond the bare type/default information in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete a media item', which is a specific verb+resource statement that clearly distinguishes this tool from media get/update/list/upload and from delete tools for other resources. It further clarifies the two modes of deletion (trash vs permanent), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the default trash behavior vs the force=true permanent deletion, and explicitly states the confirm parameter is required for permanent deletion. It also provides a site-specific caution about trash reliability, which is useful context, though it doesn't explicitly name alternative tools or state 'when not to use'.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/iamsamuelfraga/mcp-wordpress'
If you have feedback or need assistance with the MCP directory API, please join our Discord server