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 real behavioral context beyond them: the log contains only mutating calls (writes are filtered out), it is populated by the bridge, and it is ordered newest-first. It omits truncation/pagination behavior and any retention window, which keeps it out of 5 territory.

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, both load-bearing: the first defines the payload and ordering, the second defines the use case. Nothing is repeated from the name, 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?

There is no output schema, so the description carries the burden of explaining what a log entry looks like — and it doesn't (no mention of timestamp, tool/action, actor, or payload fields), nor does it explain the limit semantics. For a one-parameter read tool this is workable but leaves the agent guessing about the return shape.

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% and the single 'limit' parameter (default 50, max 500) is never mentioned in the description. The word 'recent' hints that results are bounded, but the agent gets no guidance on how many entries come back or how to widen the window.

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 the exact resource and scope: 'Recent mutating calls recorded by the bridge, newest first.' An agent immediately knows this is a read of the bridge's audit trail containing only mutating operations — no sibling tool (wp_health_check, wp_bridge_status, wp_content_list) overlaps with that content, so no disambiguation is needed.

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?

'Check this when you need to know what an agent already changed' gives an explicit trigger condition, which is exactly the right framing for an audit tool. It does not name alternatives (e.g. wp_health_check) or state exclusions, so it stops just 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.

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

Annotations already declare destructiveHint and openWorldHint. The description adds concrete capability names and a least-privilege instruction beyond the annotations, though it omits auth, rate-limit, and irreversibility details.

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 with no filler. The purpose is front-loaded before the safety guideline, making it easy to scan.

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 security-sensitive flag tool, the description omits whether flags persist, whether omitted flags change, and what the call returns. Annotations cover destructive/openWorld behavior and all parameters are named, but key toggle semantics remain unstated.

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 has zero description coverage and five booleans. The description lists all five parameter names and frames them as server-side capabilities, but does not explain individual flag effects or omitted-flag behavior; the names themselves carry much of the meaning.

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 ('Toggle') and resource ('server-side capabilities'), and enumerates five flags. It does not explicitly relate to sibling tools such as wp_php_run or wp_db_query that these flags may gate, so sibling differentiation is implicit 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?

Provides a clear usage principle: start read-only and widen only when the task demands it. Lacks explicit when-not or alternative-tool guidance, but the posture guidance is actionable.

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 genuine behavioral context by explaining that the returned flags gate PHP, shell, DB writes and file writes — but it says nothing about auth requirements, caching, or how frequently the flags change, so it is incremental rather than rich.

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 that lists its outputs with no filler. It is dense but every clause carries content, with only minor readability cost from packing three categories into one line.

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 parameters and no output schema, the description carries the burden of telling the agent what comes back, and it does enumerate the return contents (version, environment, flags). The remaining gap is routing: it never positions itself against wp_bridge_flags or wp_site_info, which an agent may reach for instead.

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 schema baseline of 4 applies; there is nothing for the description to clarify and no ambiguity to resolve.

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 ('Report') and enumerates exactly what is returned: plugin version, WP/PHP/theme/plugins environment, and the safety flags gating PHP, shell, DB and file writes. It does not, however, differentiate itself from the overlapping siblings wp_bridge_flags and wp_site_info, which cover adjacent territory.

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 statement of when to call this rather than wp_site_info, wp_health_check or wp_bridge_flags, and no prerequisites or exclusions. The agent must infer that this is the broader environment/flag snapshot from the description's contents 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 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?

Beyond the broad openWorldHint/destructiveHint annotations, the description enumerates concrete guardrails: DROP DATABASE, GRANT, OUTFILE and multi-statements are blocked, and writes are gated behind allow_db_write. That is meaningful behavioral context the annotations do not carry, though it does not describe result format or failure behavior.

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

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

Three tightly packed sentences with no filler: operation, permission model, placeholder support, and blocked operations, in that order. Every clause carries operational information.

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

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

For a high-risk execution tool with no output schema, the description covers the critical decision points an agent needs: what is allowed read-only, what requires the write flag, and what is outright blocked. It stops short of describing the return shape or error surfaces, which would be the last gap.

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 33% (just `confirm` is documented), so the description must compensate. It does so for `params` by explaining the %s/%d placeholder mechanism and mentions the write-gating requirement, but says nothing about the `sql` parameter's constraints (e.g. single-statement enforcement) beyond the paragraph context.

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 ('Run a single SQL statement against the WordPress database') and scopes it to one statement. It clearly separates itself from sibling execution tools like wp_php_run, wp_fs and wp_snippet_run by naming the exact execution surface.

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?

Gives explicit read-vs-write conditions: SELECT/SHOW/EXPLAIN are allowed read-only, while writes require the allow_db_write flag. It does not name sibling alternatives (e.g. wp_php_run) for cases where raw SQL is the wrong choice, so 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.

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 known. The description adds useful workflow context (dry_run gate, dry_run-first advice), but never states what an overwrite actually destroys on an existing page or whether auth is needed, so it only partially earns credit beyond the annotations.

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?

Front-loaded with the core action, followed by the dry_run gate, then post_id behavior, then setting-key examples. Every sentence is useful; only the widget-key examples edge toward verbosity.

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 deeply nested 5-param tool with no output schema, the description covers the spec shape, the dry_run workflow, and new-vs-existing page selection. It is nearly complete, with only the destructive effect of overwriting an existing page and the return shape left implied.

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?

With 60% schema coverage, the description compensates well: it explains the spec's section/column/widget shape and gives concrete Elementor setting-key examples (heading {title, header_size}, button {text, link.url}), which the schema cannot convey. The post_id omission behavior is also clarified, though confirm='overwrite' is left to 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?

States a specific verb (convert spec into Elementor data) plus the conditional write behavior, and the resource is clearly an Elementor page. This distinguishes it from read/write siblings like wp_el_get and wp_el_set, though it does not explicitly name the closest sibling (wp_el_set) as an alternative.

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?

Gives clear operating context: the write only happens unless dry_run, post_id omission creates a new page, and it recommends always inspecting the dry_run output first. It lacks explicit when-not/alternative routing against wp_el_set or wp_content_create, so it stops short of full 5-level 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 idempotentHint=true and openWorldHint=true, so the agent knows re-running is safe and the tool reaches beyond a closed set. The description adds that it both regenerates CSS and flushes the object cache, which clarifies side effects on cached data. It does not mention permissions, performance cost, or any downtime, so it adds only moderate context above the annotations.

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 the action front-loaded and the usage condition second. No filler or redundancy; every clause carries information.

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

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

For a parameterless maintenance tool with no output schema and annotations covering idempotency/open-world behavior, the description supplies what it does and when to run it. It could add a note on scope (whole site vs. specific element) or overlap with wp_el_build, 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 zero parameters, so per the rubric the baseline is 4. The description correctly implies the operation is unconditional, matching the empty schema, and there is nothing further for it to document.

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: 'Regenerate Elementor CSS and flush the object cache.' It goes beyond the title by naming both the CSS regeneration and the object-cache flush. However, it does not differentiate itself from related siblings such as wp_el_build, which could also plausibly regenerate Elementor assets.

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 a clear triggering condition: 'Run after bulk edits if the front end looks stale.' That tells the agent when to reach for it. It stops short of naming alternatives (e.g., wp_el_build or wp_el_patch) or stating when this is the wrong 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful context on what summary vs raw produce, but says nothing about tree size, depth limits, pagination, or what happens for pages with no Elementor data.

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

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

Two tight sentences with the core purpose front-loaded before the format behavior. No filler, though the second clause is somewhat compressed and omits the 'both' case.

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 no parameter descriptions, the description needs to carry more weight; it covers the two primary formats but leaves 'both' undefined and gives no sense of return shape or size. Adequate but with clear gaps for an agent choosing a format.

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 carries the burden, and it explains the summary and raw format values usefully. However, the enum's third value 'both' is never explained, and post_id semantics (post ID of the target page) are left entirely to 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?

States a specific verb+resource ('Read the Elementor tree for a page'), which is clear and distinct from write-oriented siblings like wp_el_set or wp_el_patch. It does not, however, distinguish itself from wp_el_snapshots, which an agent might reasonably confuse with reading page structure.

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 gives a genuine selection rule between two of the three formats (summary vs raw), noting raw is for 'precise edits'. It offers no guidance on when to prefer this tool over siblings such as wp_el_snapshots or wp_content_get, so usage is implied rather than fully framed.

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's valuable addition beyond structured data is the merge contract ('Settings are deep-merged into the node'), which tells the agent existing keys are preserved rather than replaced. It still omits reversibility/snapshot behavior and the finality implied by the confirm gate.

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 behavior and the path/source constraint front-loaded ahead of the merge detail. Every sentence adds information.

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

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

For a destructive mutation with no output schema and sparse schema coverage, the description covers the mechanism well but glosses over the snapshot parameter (which determines whether the patch is undoable) and the meaning of the mandatory confirm token, which an agent needs to reason about risk.

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%, so the description must compensate; it explains the path format ('0/1/2') and its source via wp_el_get, and the deep-merge semantics of settings. However, post_id and snapshot (default true, suggesting undo coverage) receive no description anywhere, leaving a real gap.

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 ('Update settings on specific nodes') plus a distinguishing trait ('without rewriting the page'), which implicitly separates it from wp_el_set/wp_el_build. It does not name the sibling alternative explicitly, so it falls short of a 5.

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

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

The description tells the agent where paths originate ('Paths come from wp_el_get') and the accepted formats, which is genuine usage context. But it never states when to prefer this over wp_el_set, wp_el_build, or wp_el_restore, nor when patching is inappropriate.

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 bar is partly met. The description adds genuinely new behavioral context that the annotations cannot convey: the current tree is automatically snapshotted before the rollback, making the operation undoable. It still omits permission/auth requirements and any failure behavior on an out-of-range index.

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 action and followed immediately by the key risk mitigation. Every clause earns its place with no filler.

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, no-output-schema mutation with a confirmation parameter, the reversibility guarantee is the most important thing and it is present. Missing are the confirm token requirement, where valid indices come from, and what the tool reports on success or an invalid index, leaving real 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 coverage is only 33% (only 'confirm' is documented, as "Must be \"restore\""). The description partially compensates by clarifying that 'index' refers to a snapshot index and that 'post_id' identifies the page being rolled back, which is real added meaning. It does not, however, cover the required confirm='restore' guard or the valid range/derivation of the index.

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 ('roll a page back to a snapshot index'), which clearly separates it from list-style siblings like wp_el_snapshots and read-style siblings like wp_el_get. It stops short of naming an alternative sibling or the prerequisite that the index comes from a snapshot listing, so it is clear but not sibling-differentiating in the way a 5 requires.

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 gives no when-to-use or when-not-to-use guidance. It never says the index must come from wp_el_snapshots, nor does it mention what to do if you want to preview the target state first (wp_el_get). Usage is only inferable from the tool name.

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 known. The description still adds real behavioral context — that the previous tree is snapshotted automatically and that a confirm:"overwrite" token is gated in — which is more than the annotations alone convey. It stops short of saying how to recover or whether the snapshot is prunable.

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, front-loaded with the destructive replace, then the alternative, then the constraints. Every sentence earns its place and 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 destructive, no-output-schema write tool, the definition covers purpose, alternative, gating token, and the safety net. Missing only recovery pointers (wp_el_restore / wp_el_snapshots) that would fully close the loop on an overwrite operation.

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

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

Schema description coverage is 50%, so the description has to carry some weight, and it does: it explains the exact confirm value and reveals the automatic snapshot behavior behind the snapshot parameter, plus frames what data must contain (valid Elementor JSON). post_id is left unexplained, but that is self-evident.

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: "Replace the whole Elementor tree for a page." It also implicitly distinguishes itself from wp_el_build by naming it and by scoping the tool to already-valid Elementor JSON, so an agent can tell the two apart without opening schemas.

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?

Explicitly routes the agent: "Use wp_el_build for authored pages and this only when you already have valid Elementor JSON." That is a clear when-to-use plus a named alternative, leaving almost nothing to inference.

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 and openWorldHint, so the safety profile is covered. The description still adds real behavioral constraints beyond the annotations: results are capped at five, restricted to automatic snapshots, and metadata-only (no content payload). It does not cover ordering guarantees or failure modes when no snapshots exist.

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 result cap and metadata-only qualifier come after the core verb+resource, so the most important information lands first.

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?

There is no output schema, so the description must describe return values, and 'metadata only' is only a partial answer — it never says what fields the metadata contains (id, timestamp, author, size) that an agent would need to pick a snapshot to restore. Adequate for a simple list tool, but with a clear gap.

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?

One parameter with 0% schema description coverage, so the description must carry the burden. 'For a page' does establish that post_id refers to a page rather than a revision or template, which is genuine added meaning, but it never clarifies ID format, whether drafts are included, or what happens with an invalid ID.

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' plus 'Elementor snapshots for a page' gives a specific verb and resource with useful scope qualifiers ('five most recent', 'automatic', 'metadata only'). It is distinguishable from wp_el_get and wp_el_restore by scope, but it never names a sibling explicitly, so it falls short of the top band.

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 only implied: an agent can infer this is the discovery step before wp_el_restore, and 'metadata only' hints it is cheap to call, but no when-to-use condition or alternative is stated. No exclusions or prerequisites 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 readOnlyHint and openWorldHint, so safety is covered. The description adds real content beyond that: it enumerates the exact facts returned (Pro detection, version, flexbox containers), which is valuable for a status probe with no output schema. It stops short of noting caching, cost, or failure behavior.

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

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

A single front-loaded sentence that lists the three reported facts with no filler or redundancy.

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

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

For a no-argument, read-only status probe with no output schema, the description adequately tells the agent what it will learn. Only the absence of usage framing against the related wp_el_* and site-info tools leaves a small gap.

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 per the rubric the baseline is 4. Nothing in the description conflicts with the empty schema, and there is no parameter information to add.

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?

Clear verb ('Report') plus specific resource (Elementor/Pro activation, version, flexbox container flag). It is readily distinguishable from siblings such as wp_el_get, wp_el_widgets, or the generic wp_site_info/wp_health_check. It does not explicitly contrast itself with those siblings, which keeps it short of a 5.

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

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

The description says only what is reported, never when to reach for it. It gives no guidance on using it versus wp_site_info, wp_health_check, or the other wp_el_* tools, and no prerequisites or exclusions are mentioned.

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

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. With no output schema, the description adds genuine behavioral value by disclosing the return shape (widgetType, title, category) and the fact that results reflect what is registered on this specific site.

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 filler. The what (enumerate widget names with title/category) comes first and the when/why follows, so it is well front-loaded.

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 enumeration with no output schema, the description covers purpose, return fields, and call timing. It omits any note on result size or ordering, which is a minor gap for a registry listing.

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. The description's mention of widgetType is a return-field clarification rather than parameter guidance, which is appropriate here.

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

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

States a specific verb (Enumerate) and resource (every registered widget name / widgetType) plus the fields returned (title, category). This is clearly distinct from siblings like wp_el_build or wp_el_get, which operate on pages rather than the widget registry.

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?

Explicitly says when to call it ('before building a page') and why (so you only reference widgets that actually exist on this site), which implicitly routes the agent away from guessing widget types in wp_el_build. It does not name an alternative tool or state when not to use it, 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.

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

Annotations only say openWorldHint and destructiveHint; the description adds genuinely new behavioral context that the annotations do not: writes are jailed to wp-content, extension-limited, and the prior file is backed up under wp-content/woodpresser-backups. That materially lowers the perceived risk of destructive ops. It still omits auth/permission requirements and error 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 dense sentences: the operation/scope statement first, then the write-safety constraints. No filler, no repetition of the title, and the risk-relevant information is front-loaded.

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 multi-op filesystem tool with no output schema, the description covers the essential safety model (jail, extension limit, backup). Minor gaps remain: nothing about return shapes for read/stat, pagination for list, or the specific allowed-extension policy.

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 67%: path and content carry descriptions, while op is only an enum with no prose. The description enumerates the same op values as the enum, so it adds little beyond the schema aside from naming what each operation does at a high level. 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?

The description names the exact operations (list, read, stat, write, append, mkdir, delete) and the resource/scope ('files under wp-content'), which maps cleanly onto the op enum. It is clear what the tool does, though it does not explicitly contrast itself with the many wp_content_* and wp_media_* siblings that could look similar.

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 or when-not-to-use guidance and no named alternatives, despite a crowded sibling set where wp_content_get, wp_media_upload, and wp_php_run all overlap in the filesystem/content space. The op list implies usage but leaves the agent to infer selection.

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 and openWorldHint, so the safety bar is lower; the description adds real value by disclosing that WordPress is fully loaded, that output buffering and return values are captured, and that fatal errors are surfaced. It could say more about persistence (whether executed code alters site state), but the behavioral picture is noticeably richer than the annotations alone.

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?

Four tight sentences, each earning its place: execution context first, then output/error behavior, then the usage directive, then the confirmation requirement. Zero filler and well front-loaded.

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 high-power execution tool with no output schema, the description covers context loading, result capture and error behavior, which is sufficient to call it correctly. It does not warn about persistence or side effects of arbitrary code, a minor gap that destructiveHint partially offsets.

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

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

Schema description coverage is 100%, so the schema already documents code, mode (enum with default) and confirm. The description only repeats the confirm:"run" requirement and adds no syntax or format detail beyond the schema, making the baseline 3 correct.

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 (Execute) and resource (PHP inside the live WordPress runtime) with concrete scope, naming $wpdb, WP_Query and plugins as available. It does not, however, differentiate itself from close siblings like wp_snippet_run or wp_db_query, so an agent must infer the boundary.

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 it to inspect real state, not to guess" gives a clear operating context, and the confirm:"run" prerequisite is stated. It stops short of naming alternatives (e.g., wp_db_query for reads, wp_snippet_run for saved code), so no explicit exclusions are provided.

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 destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds useful context — that it bypasses REST filtering and thus touches hidden keys — but does not say that 'set' overwrites existing values, that 'delete' is irreversible, or what auth is required for write actions.

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 with zero filler; the capability scope is front-loaded and the action list is compact. Every clause carries information.

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

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

For a 5-parameter, destructive, no-output-schema tool, the description covers the action set and the REST-bypass angle but omits return shape and any warning about overwriting or irreversible deletion. Adequate but leaves real 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 coverage is only 20%, so the description must compensate. It does clarify that 'get' can return all keys or a single key (implying key is optional for get), but 'value' is documented nowhere, and the 'hide_internal' flag is only explained in the schema itself.

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 (read/write) and resource (post meta keys) and enumerates the three actions it supports. It also differentiates itself from generic content/settings tools by noting direct access to keys hidden from REST, though it never names a sibling tool 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 phrase 'including keys hidden from REST (SEO plugins, page builders, custom fields)' implies when this tool is the right choice vs. wp_content_get/wp_settings_get, but that routing logic is left to inference. No explicit when-not-to-use or named alternatives 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 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 already declare destructiveHint=true and openWorldHint=true, so the safety profile is known. The description adds value beyond them by stressing 'Permanently' (irreversibility) and disclosing the required confirmation token 'confirm:"delete"' — a mutation guard the schema does not encode (confirm is only typed as a plain string with no enum).

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, front-loaded sentences with zero filler: the action and permanence come first, then the confirmation requirement. Every sentence 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 destructive two-parameter tool with no output schema, the description covers the essential behavior (permanent removal, mandatory confirm token). It omits only secondary details such as required permissions and what happens on a missing/incorrect confirm value.

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% and there is no enum on 'confirm', so the description must carry parameter meaning — and it does, specifying the exact literal value 'delete' required for confirmation. The remaining 'id' parameter is self-evident as the snippet identifier, so this is only a minor gap.

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 ('Permanently remove') and resource ('a stored snippet'), clearly distinguishable from sibling tools like wp_content_delete, wp_snippet_save, and wp_snippet_run. An agent can tell exactly what this does without opening the schema.

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

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

Usage is implied ('Permanently remove a stored snippet') but there is no explicit when-to-use, when-not, or alternative guidance. It does not tell the agent how to choose this over wp_snippet_save (to overwrite) or that deletion is irreversible with no undo path.

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 structurally. The description adds real domain context (versioned blocks, scope enum values, active flag) that tells the agent what a listed item represents, but it says nothing about ordering, pagination, or result size — minor gaps given the safety profile is already disclosed.

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, front-loaded with the action and resource. The second sentence is partly domain education rather than invocation-critical information, but it is short and directly supports interpreting the result, so it still 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 zero-parameter, read-only list tool with no output schema, the description supplies the concept model (scope values, active flag) an agent needs to reason about results. It stops short of describing what a returned record looks like or how results are ordered, which would be the only remaining gap.

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 schema carries no semantic burden and the baseline is 4. The description does not need to explain arguments, and none are omitted.

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?

Names a specific verb+resource ('List PHP snippets stored by the bridge') and then defines what a snippet actually is (versioned PHP blocks with a scope and active flag), so the agent understands the domain object without opening anything else. The read-only retrieval framing is unmistakable against wp_snippet_save/wp_snippet_run/wp_snippet_delete.

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 contextualizes snippets as 'the safe way to add behaviour without editing theme files', which implies the intended workflow, but it never states when to call this versus wp_snippet_run or wp_snippet_save, nor any prerequisite such as inspecting snippets before running one. Usage is inferable but not 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 openWorldHint and destructiveHint, so the safety bar is lower. The description still adds real value by disclosing that execution happens immediately and bypasses active state — an important behavioral trait not captured by the annotations — though it doesn't elaborate on side effects or failure behavior despite the destructive hint.

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 the execution semantics front-loaded and the use case second; no filler, no repetition of the title.

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 usefully states that it returns the snippet's output, and it covers when the snippet executes. However, it leaves the sole parameter undocumented and doesn't address error or side-effect behavior for a tool flagged as destructive, so it is only minimally complete.

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

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

Schema description coverage is 0% for the single required 'id' parameter, so the description carries the burden but only implies that 'id' selects 'one stored snippet'. It gives no format, source, or lookup guidance for the identifier.

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 (run) and resource (one stored snippet), plus a scope qualifier ('regardless of active state') that meaningfully distinguishes it from arbitrary-code siblings like wp_php_run. It never names a sibling explicitly, so 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?

'Ideal dry-run before activation' gives a concrete usage context that tells the agent when to reach for this tool. It offers no exclusions or named alternatives (e.g., wp_php_run for ad-hoc code), so the routing guidance is clear but incomplete.

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 are thin (only openWorldHint=true), so the description carries most of the burden. It usefully advises keeping new snippets inactive and testing before activation, which is real behavioral guidance, but says nothing about permissions, what an update does to existing snippet state, or reversibility of 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, front-loaded sentences with zero filler. The create/update rule and the test-then-activate workflow are both stated before anything else.

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 and annotation coverage is minimal, so the description is the only source of behavioral context for a 7-parameter mutation tool. It covers the create/update distinction and activation safety, but is incomplete on the remaining parameters and on permissions or side effects.

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 14% (just the code param), so the description must compensate. It clarifies id (create vs update) and active (stay false), but leaves name, scope, priority, and description semantics to the schema, and doesn't explain the scope enum values.

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+resource ("Save a snippet") with an explicit create/update discrimination keyed on the id parameter, so an agent knows exactly what the tool does. It names one sibling (wp_snippet_run) but doesn't distinguish itself from wp_snippet_list/delete beyond the operation name.

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?

Gives a concrete workflow: omit id to create, pass id to update, and the sequence "keep active=false, test with wp_snippet_run, then activate." This routes the agent to a sibling tool and states the safe path. No explicit 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.

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.