Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint, idempotentHint=false and destructiveHint=false, so the mutation semantics are partly covered. The description adds genuinely useful context by stating the return value (new ID and link), which matters because there is no output schema, but it omits defaults (status=draft, type=post), auth requirements, and what happens if creation fails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with the key return-value information front-loaded; nothing is padded. The lead sentence 'Create content.' is close to a tautology of the name, but the remainder earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter mutation tool with no output schema, the description is thin: it covers the return shape (a real plus) but says nothing about the draft-by-default status, the post-vs-page type switch, required title, or the arbitrary meta object. An agent can call it, but only by reading the schema closely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 21%, so the description must carry the load for 14 parameters, and it largely does not. It mentions meta, taxonomy terms (tags/categories) and page templates, which loosely maps to three params, but leaves slug, parent, menu_order, featured_media, excerpt, status, type and title undocumented beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description together give a clear verb+resource ('Create a post or page' / 'Create content'), which separates it from wp_content_get, wp_content_update and wp_content_delete. However, the description alone says only 'Create content', which is broad enough that the sibling differentiation comes mostly from the title rather than the body text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance is given: it never says to use this instead of wp_content_update for existing posts, or to use wp_term_create/wp_post_meta for related resources. The capability note about meta, taxonomy terms and templates hints at scope but does not tell the agent when this tool is the right choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, but the description adds critical nuance: deletion is reversible by default (trash) and irreversible only when force=true, which also requires confirm:"delete". This is meaningful operational context beyond the annotations, though it does not mention permissions or post-deletion side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the default behavior before the force/confirm caveat. Every phrase earns its place and nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with no output schema and helpful annotations, the description supplies the key safety facts: default trash behavior, permanent deletion path, and the confirmation requirement. Only minor gaps remain around id/type semantics and broader usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25%, so the description must carry more weight. It adds important meaning for force and confirm (including their conditional relationship), but leaves id and type semantics entirely to the schema, which is only partially documented there.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Delete') and resource ('a post or page'), and the title confirms the trash semantics. It is immediately distinguishable from sibling content tools like wp_content_get, wp_content_create, and wp_content_update.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states the default behavior (moves to trash) and the condition for permanent deletion (force=true), which tells an agent when to use the force path. It does not name alternatives such as wp_snippet_delete or explain when to prefer trash over permanent deletion beyond the parameter behavior.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnlyHint) and scope (openWorldHint). The description adds useful context about the return payload ('raw and rendered content plus open Graph-ish fields'), which matters since there is no output schema. It still omits that context=edit vs view changes what content is returned, a behavioral detail an agent would want.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single efficient sentence with the core action front-loaded and no filler. It is appropriately sized for a simple read tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 0% schema coverage, the description does well to name the returned content fields, but it leaves the context parameter and key-precedence behavior unexplained. Adequate but with clear gaps for a 4-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It addresses id/slug ('by ID or slug') and implicitly the type enum ('post or page'), but says nothing about the context enum (view vs edit), which governs whether raw or rendered content comes back. Three of four parameters get partial coverage and the most consequential one is silent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Fetch') and resource ('single item'/post or page) with the lookup keys (ID or slug). It clearly reads as the single-item counterpart to wp_content_list, though it doesn't name that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The single-vs-list framing implicitly tells the agent when to reach for this tool rather than wp_content_list. However, there is no explicit when-to-use/when-not guidance, no mention of required permissions, and no note on which lookup key takes precedence if both id and slug are supplied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint and openWorldHint already present in annotations, the description adds useful default behavior: it returns compact rows and omits full content unless otherwise requested. It does not describe pagination behavior or permission needs, but the annotation coverage lowers the bar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with no waste. The default return behavior is front-loaded, and the routing to wp_content_get follows immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter read-only list tool with no output schema, the description covers the key list-vs-get distinction and default compact return, but it leaves out filter meanings, pagination details, and compact-row field structure. It is minimally sufficient but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 46% across 13 parameters, so the description must compensate, but it only says 'with filters' and 'no full content' generically. It does not clarify filter semantics, pagination, ordering, or most parameters, adding little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource ('List content with filters') and explicitly distinguishes itself from the sibling retrieval tool by saying to use wp_content_get for the body. An agent can identify the tool's core purpose without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the alternative for full body retrieval ('Use wp_content_get for the body') and implies the default compact-list context. However, it does not explain when to use include_content instead of wp_content_get, nor does it state when not to use this listing tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With only openWorldHint and idempotentHint supplied, the description adds a meaningful behavioral fact: 'Only supplied fields change,' i.e. true patch semantics consistent with idempotentHint. It does not disclose what a status change does, whether revisions are created, or auth requirements, so it is useful but incomplete for a mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler, with the core patch semantic and the key alternative both front-loaded. Nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter mutation with no output schema and no destructive/readOnly annotations, the description is too thin: it never enumerates updatable fields, never states side effects of status/parent/content changes, and leaves 13 optional parameters undocumented in both schema and prose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 14 parameters, so the schema documents none of them and the description names none either. 'Only supplied fields change' conveys the general optional-field contract, but an agent gets no per-parameter meaning (meta, status, template, menu_order, featured_media, etc.) from either source.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'Patch' plus the sibling routing to wp_el_set makes the update intent clear, and the title names the resource (post or page). However, the description itself calls the target a generic 'item' rather than naming post/page, forcing the agent to rely on the title for the resource identity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit alternative for one case ('For a full Elementor rewrite use wp_el_set instead'), which is genuine routing value. But it offers no guidance against the many other closely related siblings (wp_content_create, wp_el_patch, wp_el_build), so the when-to-use picture is only partially drawn.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety profile is covered. The description adds real behavioral value by disclosing the layered probe order and that it reads the debug log size, but it says nothing about failure modes, error semantics, or what the diagnostic report looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste, front-loaded with the enumerated diagnostic layers followed by the usage cue. Every listed item carries distinct information about what is probed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only diagnostic with no output schema, the description supplies everything an agent needs to decide to call it and understand what surfaces it inspects. The only mild gap is the exact shape of the returned report, which is not required to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline for this dimension is 4. Nothing in the schema requires further explanation, and the description correctly spends no words on inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Diagnose') and enumerates exactly what is checked: REST reachability, credentials, bridge claim, Elementor presence, permalinks, debug log size. That is far more specific than siblings like wp_bridge_status or wp_el_status, though it never names them to sharpen the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use before blaming the code' gives a loose trigger condition (run this when connectivity problems are suspected), which is better than nothing. But it never routes between this tool and the narrower siblings (wp_bridge_status, wp_el_status, wp_site_info), so the agent must infer the boundary itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds no behavioral context beyond that – no pagination behavior, default ordering, or result limits, despite per_page/page existing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with no waste and the key filtering capability front-loaded. Its brevity is appropriate, though it is arguably too terse given the missing pagination details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with annotations covering safety, the description is minimally adequate. It omits pagination behavior and return shape, which matters since no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 25% (only mime_type documented inline). The description compensates by naming the MIME filter and search, covering two of four parameters, but leaves page and per_page entirely unexplained in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

'List attachments' gives a clear verb+resource, and 'attachments' is specific WordPress media terminology. It does not distinguish itself from the sibling wp_content_list, but the resource is unambiguous enough that an agent can identify it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says nothing about when to use this versus wp_content_list, wp_media_upload, or wp_search. No prerequisites or context are given, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations supply only openWorldHint=true, so the description carries most of the behavioral burden. It discloses that url means sideloading (download-then-upload), but says nothing about overwrite/duplicate-filename behavior, permission requirements, size limits, or success/failure semantics for a mutating upload.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the core action and followed by the input-mode clarification. No filler, though it could be marginally more informative without growing much.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should convey what happens on success/failure, but it doesn't. Combined with sparse annotations and partial parameter documentation, it is adequate for a basic upload but leaves real gaps around results and edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is low at 40%, so the description should compensate. It does explain the two primary parameters (path and url) and their mutual exclusivity, but title, alt_text, and filename remain undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Upload a local file to the media library') and clarifies the two intake modes (local path vs remote url). An agent can easily distinguish this from wp_media_list, but the description never names or contrasts a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The sentence 'Provide path, or url to sideload a remote file' gives concrete guidance on the two mutually-exclusive input modes, which is implied usage context. However, it offers no when-to-use vs. alternatives, no prerequisites, and no exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true. The description adds useful behavioral detail beyond those: a delete confirmation guard, the install source, and a security warning about activation. It does not cover authentication needs, reversibility, or per-action return behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words, with the important destructive-action prerequisite front-loaded after the action list. Every sentence adds necessary meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-action mutating tool with destructive/open-world annotations and no output schema, the description covers the key safety prerequisites and install source. It leaves some per-action parameter mapping implicit, but the schema supplies the plugin-file parameter and enum action values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%, and the description adds meaning for the action enum, the slug parameter's install use, and the confirm value for deletion. It does not add semantics for the plugin parameter beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names four specific verbs (activate, deactivate, install, delete) and the resource (plugin), and it specifies that install uses a wordpress.org slug. It does not explicitly contrast itself with siblings such as wp_plugins_list, so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear action-specific context: install comes from wordpress.org by slug, deletion requires confirm:"delete", and activating an untrusted plugin is a security decision. It does not state when not to use this tool or name a specific alternative for listing/viewing plugins.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish the safe-read profile (readOnlyHint=true, openWorldHint=true), so the description's remaining burden is low. It adds genuine value by disclosing what the payload contains — plugin status and available updates — which matters since no output schema exists. It does not mention permissions or pagination, so not 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, tightly scoped sentence with the resource front-loaded and the returned fields listed after. No filler, no redundancy with the title or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list operation whose safety profile is covered by annotations, the description supplies purpose and a summary of returned fields. Without an output schema it would be marginally better to name the exact fields (e.g. version, active/inactive), but nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool is 4. Schema coverage is 100% and the empty schema is consistent with the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List installed plugins') plus the scope of data returned ('status and available updates'). This is clearly distinguishable from the mutating sibling wp_plugin_action and from wp_themes_list, though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance, and no pointer to siblings like wp_plugin_action for changing plugin state. For a zero-parameter read-only listing tool the usage is self-evident from the purpose, so implied usage is adequate but not helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and reach are covered. The description adds the useful 'single call across three content types' nuance, but says nothing about result ordering/ranking, pagination behavior, or what a match contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, purpose front-loaded ahead of usage. The second sentence is short and earns its place as routing guidance; nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only search with no output schema and paging parameters (per_page 1-50, default 20), the agent is left guessing about result shape and how to page through matches. Acceptable minimum, but incomplete for a tool whose return format is entirely undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description documents none of the three parameters — no guidance on query syntax, the sub-type selector, or the per_page cap. Worse, it advertises 'media' as searchable while the subtype enum only offers post/page/any, so it adds confusion rather than compensating.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (search) and the resources it spans (posts, pages, media), plus the aggregation angle 'in one call' that separates it from the per-type listers like wp_content_list and wp_media_list. It stops short of explicitly naming those siblings, so the differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this to locate content before editing it' gives a clear intent and implicitly points at the edit flow (wp_content_update). However it names no alternatives and gives no when-not — nothing tells the agent why to search here versus wp_content_list or wp_media_list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a useful boundary by specifying 'REST-exposed' settings, implying non-REST settings are omitted, but gives no detail on return shape or size.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. The parenthetical field list is the most informative part and is placed immediately after the scope statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description reasonably compensates by naming the settings returned. The 'REST-exposed' qualifier hints that the result set is partial, which is a useful caveat, though it stops short of clarifying whether sensitive settings are excluded.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies. The description has no parameters to explain and correctly does not fabricate any, keeping it consistent with the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (read) and resource (site settings) and enumerates concrete settings returned (title, description, timezone, permalinks, front page). This clearly distinguishes it from its write sibling wp_settings_set, though it does not name that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the read-only nature and the presence of wp_settings_set in the sibling list, but the description never says when to call this versus wp_site_info or other read tools. No prerequisites or exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint=true and idempotentHint=true, so safety/idempotency is covered structurally. The description adds the meaningful scope constraint that only REST-exposed settings can be touched, but says nothing about required capabilities, what happens to omitted settings, or whether updates are partial or full replacement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler. The primary action leads, and the fallback routing follows immediately after the scoping clause that motivates it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation tool with 7 fully undocumented parameters, no output schema, and only partial annotation coverage. The description should at least indicate which settings class it targets or what a successful update returns; as written, an agent cannot confidently populate the body from the definition alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 7 parameters, and the description names none of them. 'REST-exposed settings' only indirectly implies the WordPress settings endpoint fields; an agent gets no help distinguishing title/description/page_on_front/show_on_front from the other options, nor any hint about the enum values or integer expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Update REST-exposed settings') and scopes it precisely to settings reachable through the REST API, which separates it from the sibling wp_settings_get and from arbitrary option manipulation. It is clear what the tool does, though it stops short of naming wp_settings_get explicitly as its read counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives a real routing rule: arbitrary/non-REST options must go through wp_php_run or wp_db_query instead. That is an explicit alternative with a condition, not just implied usage. It lacks only a stated 'use wp_settings_get first' or prerequisite/permission guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data rather than the prose. The description adds useful scope context by disclosing that an authenticated user's capabilities are exposed, but says nothing about permissions required, caching, or whether the call is cheap to repeat.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler. The data returned is front-loaded in a dense noun list and the usage cue is placed last, which is the right emphasis for an entry-point tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must carry the return-value burden, and it does so by enumerating the site identity, version, and capability fields an agent needs to orient itself. For a zero-parameter read-only tool, nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4 by rule; there is nothing for the description to clarify beyond the empty input schema. The description does not waste words re-explaining absent inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (identify) and resource (the connected site), then enumerates the concrete data surface: name, description, URL, REST namespaces, authenticated user and capabilities, and bridge/Elementor/plugin versions. That is clearly distinguishable from sibling tools like wp_content_list or wp_plugins_list, which address subsets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Start here when you inherit a project" gives a concrete trigger for calling this tool first, which is genuine usage guidance. It does not name alternatives or state when not to use it, so it stops short of a full when/when-not routing rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide only openWorldHint=true, so they carry almost none of the behavioral burden. The description does not say what happens on duplicate names/slugs, whether an existing term is mutated, what permissions are required, or how the default taxonomy is applied. For a mutation tool with near-zero annotation coverage this is a real gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded sentence with no wasted words, which is good. But the brevity comes from under-specification rather than discipline — there is simply nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter mutation tool with no output schema, no readOnly/destructive hints, and 0% schema coverage, the description is far too sparse. An agent cannot tell from this definition whether the call is safe, what it returns, or how the non-required parameters behave.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across five parameters, and the description compensates for none of them: slug, parent, and description are never explained, and the crucial 'taxonomy' parameter is only obliquely referenced via 'category or tag' without noting it defaults to 'categories'. Parent (integer, implies hierarchy) is entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Create a category or tag'), so the agent knows it makes a new taxonomy term. However, it never names or distinguishes itself from the closest sibling, wp_terms_list, and gives no indication of what a 'term' maps to beyond the category/tag gloss. The purpose is understandable but thin.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no statement of prerequisites (e.g. capability/permission needs), and no alternative named against wp_terms_list or wp_content_create. The agent is left to infer that this is the tool for adding taxonomy terms.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds nothing behavioral — no pagination behavior, no defaults, no auth context — and its claim of 'any public taxonomy' is subtly misleading since the schema enum restricts taxonomy to 'categories' and 'tags' only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no wasted words, but it is under-specified rather than genuinely concise — it omits essential parameter and behavioral detail needed to invoke the tool correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With four parameters at 0% schema coverage, no output schema, and no annotations explaining returns, the description is far too thin. It should at minimum explain pagination, the taxonomy default, and what a returned term looks like.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate for four undocumented parameters (page, search, per_page, taxonomy). It only vaguely gestures at taxonomy via 'categories, tags' and says nothing about pagination or search semantics, leaving the agent to guess parameter meaning from names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (List) and resource (taxonomy terms), and enumerates the main term types: categories and tags. It clearly identifies this as a read operation on taxonomy terms, though it doesn't explicitly name the sibling it differs from (e.g., wp_term_create is the write counterpart).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus alternatives such as wp_search or wp_content_list, nor any mention of prerequisites. The agent must infer that this is the read-side of wp_term_create.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context beyond that: the change is 'high-impact' and should be staged first. It doesn't mention reversibility or auth requirements, keeping it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero filler. The core action is front-loaded and the risk warning follows immediately, which is exactly the right ordering for a destructive operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation with full schema coverage and annotations covering the destructive profile, the description supplies the one thing structured fields can't: the operational risk advisory. Nothing critical is missing, though naming the inspect-first sibling would have made it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters (stylesheet slug, confirm='activate') are fully documented in the schema. The description adds no syntax, format, or validation detail beyond that, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Switch the active theme.' An agent immediately knows this mutates the site's active theme, distinguishing it from read-oriented siblings like wp_themes_list. It stops short of naming any sibling explicitly, so it lands at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies a caution condition ('on a live site... prefer a staging copy') but never states when to call this tool versus the alternatives (e.g., wp_themes_list to inspect first, or wp_plugin_action for plugin counterparts). Usage is implied through the risk warning rather than spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the response reveals the active theme, which is useful, but says nothing about ordering, counts, or whether inactive/broken themes are included.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. Both the action and the notable return detail are stated in one pass.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-argument read tool with annotations covering the safety profile and no output schema, this is nearly complete. Minor gap: no hint about response shape or whether the call reaches the live site (openWorldHint).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter semantics are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('List') plus resource ('installed themes') and an extra payload detail ('which one is active'). It is clearly distinguishable from wp_plugins_list and wp_terms_list by resource, but it never names or contrasts with its obvious sibling wp_theme_activate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: a read-only inventory of themes, contrasted only implicitly with wp_theme_activate for state changes. No explicit when-to-use, when-not-to-use, or prerequisite statement is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read nature is established. The description usefully adds the administrator-credential requirement, which annotations do not convey, but says nothing about result volume, pagination, or what user fields are returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler, and the core action is front-loaded before the auth caveat. Size is appropriate, though the terseness leaves room that could have been spent on the undocumented parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With four entirely undocumented parameters and no output schema, the description should carry more of the burden, but it only covers roles and credentials. Missing filtering/pagination behavior leaves the definition under-specified for a list tool with this many knobs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across four parameters. The description only alludes to 'roles' and says nothing about page, per_page (max 100), or search, so an agent must guess at filtering and pagination semantics from bare property names and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (list users) plus a returned attribute (roles), which distinguishes it from sibling list tools like wp_content_list and wp_media_list that target other resources. It does not mention pagination or search scope, so the picture is slightly incomplete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides the prerequisite (administrator credentials) but gives no guidance on when to use this versus wp_search or other listing tools, and no exclusions or conditions. An agent has little to infer beyond 'this lists users'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.