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

The description discloses critical behavioral details: the activation hook runs immediately and can cause fatal errors, dry_run defaults to true and changes nothing, allow_prod defaults to false to protect production, and activating an already-active plugin is a no-op. It clearly states side effects and default behaviors, compensating for the lack of 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?

The description is informative but slightly repetitive, with the 'DEFAULTS TO' phrasing used twice. It is structured in clear sentences and covers essential warnings without excessive verbosity. The repetition is minor and does not hinder comprehension, but a more concise version could improve readability.

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?

The description covers activation behavior, dry-run semantics, production protection, and plugin name formats, but it omits the meaning of the required `install` parameter and does not describe the output or return value (though no output schema is provided). This missing information leaves a significant gap for an agent to safely invoke the 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?

The description explains the `plugin` parameter (accepts slug, file, or .php path), `dry_run` (preview vs. apply), and `allow_prod` (production guard). However, the required `install` parameter is not mentioned at all, leaving users to guess its meaning (likely a site identifier). This gap reduces the overall parameter coverage despite explanations for three of four parameters.

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 clearly states the tool's function: 'Activate one already-installed plugin.' It uses a specific verb and resource, distinguishing it from sibling tools like wp_deactivate_plugin and wp_list_plugins. The purpose is immediately identifiable without needing to inspect 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?

The description provides practical usage warnings, such as the risk of breaking a live site and the recommendation to test on staging first. It also explains the dry_run and allow_prod flags, giving clear guidance on safe execution. It does not explicitly compare with alternatives, but the actionable advice is sufficient for most use cases.

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?

No annotations are provided, but the description fully discloses key behaviors: dry_run default prevents writes, verification is done by reading the menu back, prod writes require allow_prod=true, and ambiguous menu references are refused. This gives the agent a reliable mental model of 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?

The description is dense and well-structured, with each sentence adding meaningful detail. It avoids repetitive or vague phrasing and uses clear separations for target, nesting, and safety flags.

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?

The description covers the core action, safety defaults, verification mechanism, and parameter relationships. It does not describe the output/return format, but that is not required by the instructions. The only notable gap is the lack of explicit semantics for 'install' and 'title', which keeps it slightly below a perfect score.

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 zero schema-level descriptions, the tool description compensates well by explaining most parameters: menu (id/name/slug and exact match), page_id vs url, parent, position, dry_run, and allow_prod. However, 'install' and 'title' are not explicitly defined, though 'title' is implied by the action and 'install' is likely a shared context parameter.

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 clearly states the tool's purpose with the verb 'Add' and specifies the resource: a navigation menu item. It distinguishes itself from sibling tools like wp_update_menu_item and wp_remove_menu_item by focusing solely on adding a new item.

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 strong usage guidance by explaining when the tool writes (dry_run=false) and when it only previews (default dry_run=true), as well as the prod safety requirement. It could be slightly more explicit in contrasting with update/remove tools, but the intent 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?

With no annotations provided, the description carries the full burden of behavioral disclosure — and it excels. It discloses mutation side effects (old URL 404 behavior), the uniquification behavior for duplicate slugs (still succeeds with `uniquified: true`), sanitization rules, the safe default (dry_run=true), and verification via read-back. No annotation contradiction.

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?

The description is long (11 sentences) but dense with critical operational information for a side-effectful mutation tool. Key warnings are front-loaded (old URL 404s) and emphasized via ALL-CAPS markers (CHECK, DEFAULTS TO). Minor redundancy: sentence 4 partially restates the warning already given in sentences 2-3.

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 complex mutation tool with no output schema, no annotations, 5 parameters, and 0% schema coverage, the description is remarkably complete. It covers side effects, result fields to inspect, parameter semantics, defaults, environment constraints, and verification. Nothing critical 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?

Schema description coverage is 0%, so the description fully compensates. It explains dry_run's default and effect, where post_id comes from, new_slug's sanitization and refusal behavior, and allow_prod's requirement. Only `install` is left implicit, but it is a common identifier pattern across sibling tools.

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 opening sentence states a specific verb ('Rename'), a precise resource ('one page/post's URL slug'), and immediately flags the key side effect (old URL 404s). This clearly differentiates it from siblings like wp_edit_page (content editing) and wp_find_page (lookup). No ambiguity about what this tool does.

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?

Extremely explicit. It tells the agent to check `old_url_redirects` in the result, explains exactly when the old URL 404s (pages vs. posts), names the source of `post_id` (wp_find_page / wp_get_content), flags the dry_run default, and states environment prerequisites (REST transport, allow_prod for prod). Little is left 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?

With no annotations provided, the description carries the full safety burden. It explicitly states that dry_run writes nothing, that existing slugs are skipped (idempotent), and that prod writes require allow_prod=true. This is strong transparency for a tool that can create content.

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?

The description is dense but well organized, with each sentence serving a clear purpose. The block type enumeration is necessary detail and does not feel 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?

The description covers the critical workflow: dry-run behavior, item structure, SEO mapping, idempotence, and production safety. It does not describe the non-dry-run success response shape or elaborate on post_type, but it gives enough context for an agent to invoke the tool safely.

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 description explains items, seo, dry_run, and allow_prod in detail, and connects install to the required profile discovery. It does not explicitly define post_type beyond the schema default of 'page', leaving a small semantic 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?

The description clearly states the tool bulk-creates posts/pages and even specifies the builder context (Divi 4 / Gutenberg). It is distinct from sibling tools like wp_edit_page or wp_get_content by focusing on creation and bulk behavior.

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 practical usage guidance: run wp_discover_site first, dry_run is the default, and allow_prod is required for production writes. It does not explicitly name an alternative tool for single-item creation, but the context of bulk creation is clear enough.

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 no annotations, the description fully discloses behavior: dry_run defaults to true and writes nothing, false performs the create, and the result is verified by reading the term back. It also warns that prod writes require allow_prod=true and that parent is ignored for tags.

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?

The description is focused and uses backticks to highlight terms, with safety caveats placed clearly. It is slightly repetitive around dry_run and prod requirements but remains efficient.

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?

The description covers preconditions, side effects, and verification, but because there is no output schema it does not state what is returned beyond the implied reading back of the term. The missing install parameter also prevents full operational 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?

The prose explains taxonomy, slug, parent, dry_run, and allow_prod, but the required 'install' parameter and the 'description' parameter are not explained. Since the schema has no per-parameter descriptions, this leaves gaps for two of eight parameters.

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 opens with 'Create one term' and specifies the resource as 'a category, tag, or any custom taxonomy term', making the action and target unambiguous. It also distinguishes from assignment by pointing to wp_set_post_terms.

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 provides practical guidance: taxonomy should come from wp_list_taxonomies, parent only applies to hierarchical taxonomies, and assignment should use wp_set_post_terms. It also explains dry_run and allow_prod flags, though it does not contrast with update/delete term tools.

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?

The description transparently discloses important behavioral details: the password is never echoed back and must be recorded beforehand, dry_run creates nothing by default, and the tool requires specific credentials and flags. This fully informs the agent about side effects and preconditions.

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?

The description is somewhat long but every sentence adds valuable information. It is well-structured with clear emphasis on critical warnings. No filler or redundancy, though it could be slightly trimmed without loss of 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?

The description provides good safety and requirement context, but it lacks details about the 'install' parameter and does not mention what the tool returns (e.g., user ID or success object). Given the absence of an output schema and annotations, these gaps reduce completeness for an agent deciding to call it.

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 description explains the semantics for username, email, roles, password, dry_run, and allow_prod, but omits two parameters: 'name' (likely a display name) and the required 'install' parameter, which specifies the target WordPress installation. This is a significant gap since 'install' is required and not mentioned at all.

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 clearly states the tool's purpose: creating a WordPress user with role and password. It uses a specific verb and resource, and the context distinguishes it from siblings like wp_update_user, wp_delete_user, and wp_list_users.

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 explicit usage instructions: dry_run defaults to true and must be set to false to actually create, prod writes require allow_prod=true, and it requires REST transport and an administrator app password. This provides clear guidance on when and how to use the 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?

The description is exceptionally transparent about side effects, including immediate downtime, refusal to deactivate wp-ops-connect, no-op behavior for already-inactive plugins, dry-run default, verification after applying, and the prod write 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?

The description is information-dense but repetitive, especially the all-caps warning about deactivating a live plugin that restates the opening sentence. It could be tightened without losing 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 safety-critical mutation, the description covers the necessary context: destructive effects, protected plugin, dry-run default, prod guard, verification, transport requirement, and return behavior. It is sufficient for an agent to use the tool responsibly.

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 description explains plugin formats, dry_run, and allow_prod in detail. However, the required 'install' parameter is not described at all, leaving a significant gap for agents deciding what value to pass.

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 opens with a clear verb-object statement: 'Deactivate one plugin.' It also explains the consequence (taking functionality offline), making the tool's purpose unmistakable and distinct from activation or listing tools.

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 provides strong guidance: use dry_run first, prefer staging, pass dry_run=false to apply, and require allow_prod=true for prod writes. It does not explicitly contrast with wp_activate_plugin, but the inverse relationship is obvious from the name and sibling context.

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?

Describes the difference between trashing (recoverable) and force-deleting (permanent), explains dry_run behavior with a preview, and warns that force deletion cannot be undone. With no annotations, this full disclosure is essential and well done.

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?

Information is front-loaded with the main action and then details. Slight redundancy (e.g., repeating trash/permanent distinction) but overall well-structured and not excessive.

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?

Covers the primary behaviors and side effects, including dry_run output preview and permanent delete warning. Lacks explicit error-handling or return format details, but for a deletion tool with no output schema, it is sufficiently 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?

Adds meaning to force, dry_run, and comment_id (source from wp_list_comments). Does not explain install or allow_prod in detail, but the overall semantics are significantly enhanced beyond the bare 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 clearly it deletes a comment and distinguishes between trash and permanent delete. Also differentiates from wp_moderate_comment for spam handling, making its purpose unambiguous.

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 advises to prefer wp_moderate_comment for spam, explains the dry_run default and allow_prod requirement, and notes the REST transport constraint. Provides clear when-to-use guidance.

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

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

With no annotations present, the description carries the full burden of disclosing side effects, and it does so thoroughly. It explains irreversibility, impact on plugin settings and site behavior, the no-op result for nonexistent options, dry-run behavior, and production safeguards.

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?

The description is dense but mostly well-structured, leading with the core action and then covering important caveats and usage details. Some phrasing, such as 'Read it with wp_get_option and keep the value first,' is slightly awkward but not confusing enough to hurt clarity significantly.

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?

Given the lack of annotations and output schema, the description provides substantial context: destructive consequences, dry-run behavior, no-op reporting, required permissions, and production guard. It does not describe the output format in detail, but it covers the information most needed to use the tool safely and 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 description explains dry_run and allow_prod clearly, but the required parameters name and install are not explicitly described. While name is fairly inferable as the option name and install may be contextually understood, the description does not fully compensate for the 0% schema coverage.

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 clearly states the tool deletes a wp_options row entirely and explicitly contrasts it with setting the option to empty, which distinguishes it from wp_set_option and other option-related tools. The verb and resource are specific and unambiguous.

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 provides practical usage guidance by warning against using this for setting an empty value, pointing to wp_get_option for reading values first, and explaining the dry_run default and the need to pass dry_run=false to actually delete. It also mentions required environment and permission conditions, though it does not explicitly say 'use this when permanent deletion is intended'.

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?

The description thoroughly explains the consequences: permanent deletion, no trash, force is required, posts keep their content but lose the term, and the term's archive URL 404s. It also explicitly mentions the dry_run default and the allow_prod requirement, making the behavior highly transparent.

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

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

The text is slightly verbose with repeated warnings (e.g., 'DEFAULTS TO' in caps) but every sentence contributes relevant safety context. The structure is acceptable for a destructive operation, focusing on warnings and prerequisites.

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?

Despite lacking annotations and an output schema, the description gives comprehensive context: consequences, safety defaults, related tools (wp_list_terms, wp_set_post_terms), and reminders about production protection. This is sufficient for an agent to safely decide when and how to invoke the 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?

The description mentions that term_id comes from wp_list_terms and states the defaults for dry_run and allow_prod, but it does not explain the install or taxonomy parameters. Since the input schema has no descriptions and coverage is 0%, the description only partially compensates for the missing parameter semantics.

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 clearly 'Delete a term' and emphasizes the permanent nature of the operation, distinguishing it from update or list operations. It also notes that the term is unassigned from every post, leaving no ambiguity about the tool's core function.

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 provides actionable guidance: check the term's post count with wp_list_terms first, prefer re-filing posts with wp_set_post_terms before deletion, and defaults to dry_run=true to avoid accidental deletion. This gives the agent a clear safe workflow.

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?

No annotations are present, so the description carries full responsibility. It thoroughly discloses permanence, force-delete behavior, no undo, content deletion risk, reassign semantics, dry-run behavior, and production safeguards.

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?

The description is focused and well-structured, with important safety warnings. Minor redundancy exists around permanence and deletion guarantees, but each statement contributes useful context.

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?

Covers side effects, safety defaults, and reassign behavior thoroughly. However, the required install parameter is not addressed, and the return value for a successful delete is not described, leaving the description incomplete for a 5-parameter tool with no output schema.

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 schema has zero descriptions, and the description compensates well for reassign, dry_run, allow_prod, and user_id implicitly. However, the required 'install' parameter is never explained, leaving a meaningful gap in parameter understanding.

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?

Clearly states the tool permanently deletes a user and how content is handled via reassign. The verb-resource relationship is explicit and distinguishes it from user-related sibling tools like wp_update_user and wp_create_user.

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 clear operational guidance: dry_run defaults to true, pass false to delete, use allow_prod for production, and reassign to preserve authored content. Does not explicitly contrast with sibling tools, but the conditions and prerequisites are clearly stated.

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?

The word 'Delete' indicates destructive behavior, and the mention of 'Prod writes require allow_prod=true' provides a safety guard. While it does not detail permanence or side effects, the key behavioral aspects are covered.

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

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

The description is a single concise sentence that conveys the core action and the critical safety condition without any fluff.

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?

The description is adequate for a simple delete action but lacks context about what 'staged' means, what happens after deletion, and how install relates to the operation. The missing parameter details contribute to a moderate completeness 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 description only touches on allow_prod (in the context of prod writes) and does not explain install or draft_id. With zero parameter descriptions in the schema, the description fails to compensate for the missing semantics of two out of three parameters.

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 action (Delete) on a specific resource (staged wpops draft) and explicitly contrasts it with publishing, making the purpose clear and distinct from sibling tools like wp_publish_swap.

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 when to use this tool (for drafts that should not be published) and includes a key condition for production writes (allow_prod=true). However, it does not explicitly name alternative tools for cases like publishing or editing, leaving some inference required.

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 no annotations, the description carries the full burden. It discloses that the tool persists a profile and explains the two transport modes. It does not cover error cases or permissions, but for a discovery tool the key behaviors are stated.

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 paragraphs: the first states purpose and method, the second adds the prerequisite context and parameter explanation. No fluff, key 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?

Covers purpose, operational method, and its role as a prerequisite. It doesn't specify return values, but there is no output schema and the tool's purpose is clear. Slightly more detail on what the profile looks like would help, but it's not essential for 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 schema has zero description coverage, but the description explicitly defines `install` as 'the WP Engine install name', providing essential meaning beyond the bare string type. It lacks format examples, but this is sufficient.

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 clearly states the verb 'fingerprint' and the resource 'install', enumerating exactly what is captured (active theme, builder + Divi version, WP/PHP versions, plugin count, multisite). It also distinguishes itself from siblings by being the 'learning entrypoint' that other content/settings tools depend on.

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 explicitly positions the tool as the prerequisite: 'This is the learning entrypoint: content/settings tools expect a profile to exist.' It also describes the transport-aware behavior (REST vs SSH/WP-CLI), giving clear context for when it is appropriate.

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 no annotations provided, the description carries the full burden of explaining side effects. It clearly discloses that the default behavior writes nothing, that dry_run=false only stages changes to a draft duplicate, that the live post is never directly written, and that prod writes require allow_prod=true.

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?

The description is dense but efficient, packing workflow, safety defaults, and prerequisites into a few sentences without redundant fluff. The parenthetical format keeps related information together and aids readability.

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?

The description provides strong workflow context, including the draft-duplicate mechanism, promotion via wp_publish_swap, builder requirements, and production safety guard. It does not describe the return value or error behavior, but this is partially mitigated by the detailed operational guidance.

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 schema provides no parameter descriptions, and the description only partially compensates. It explains dry_run, allow_prod, and enumerates the ops operation types, but it does not describe the structure of the operation dicts, nor does it explicitly explain install or post_id beyond their names. This leaves important parameter details unspecified.

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 clearly states the tool edits an existing page via a draft duplicate and explicitly notes the live page is never written. It distinguishes itself from related tools like wp_publish_swap and wp_create_content by describing the edit-and-promote workflow.

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 concrete usage conditions: it requires a discovered profile (wp_discover_site) and an editable builder (Divi or Gutenberg), defaults to dry_run=true for previews, and explains that dry_run=false stages changes for later promotion with wp_publish_swap. This gives clear guidance on when and how to use the 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 no annotations provided, the description carries the burden of disclosing behavior. It explicitly states 'read-only, no writes', which is a key behavioral trait. It also mentions the prerequisite of a profile via wp_discover_site, adding transparency about required setup. No contradictory annotations exist, so no false claims.

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?

The description is highly concise, consisting of two sentences that pack essential information: purpose, read-only nature, return structure, and a prerequisite. No unnecessary words or repetition. It is well-structured for quick comprehension.

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?

The description covers the return value structure in detail (builder, roundtrip_ok, tree with node attributes) and mentions the prerequisite profile. It does not discuss error cases or edge conditions, but given the simplicity of a parse operation and the read-only declaration, the provided information is largely sufficient for an agent to invoke the tool correctly. Slightly more detail on parameter semantics would improve completeness.

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 schema provides no descriptions for the two required parameters, install and post_id. The description does not explain 'install' at all, leaving ambiguity about what it refers to (likely a WordPress installation identifier). 'post_id' is somewhat self-explanatory but still lacks explicit context. Since schema coverage is 0%, the description needed to compensate but only partially does so.

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 clearly states the tool's purpose: 'Parse one page into an editable element tree'. It identifies the specific verb 'Parse' and resource 'one page', and distinguishes it by emphasizing the 'editable element tree' structure and 'read-only' nature, which sets it apart from content-fetching or editing tools.

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 provides usage context by noting it is 'read-only, no writes' and that it 'Requires a profile (wp_discover_site)'. While it does not explicitly compare to sibling tools like wp_get_content or wp_edit_page, the focus on an 'editable element tree' implies its use case for structure-aware inspection before editing. This is sufficient guidance but not exhaustive.

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?

Explicitly declares 'Read-only', which is the most important behavioral trait and there are no annotations to rely on. It does not mention authentication, rate limits, or error behavior, but no destructive behavior is implied.

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?

The description is brief and well structured, with the core purpose first, a read-only note, workflow guidance, and parameter definitions. No redundant or filler content.

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?

The description includes the return fields (id, title, slug, status, type) and names the follow-up tools, which is useful given there is no output schema. It omits details like result limits or empty-result behavior, but the essential context for using this finder is present.

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?

Despite having no schema descriptions, the text explains both parameters: install is the WP Engine install name, and query is a simple search term. This fully compensates for the 0% schema coverage.

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?

Clearly states the tool finds pages and posts matching a query, returning a merged set of id, title, slug, status, and type. It also explicitly positions the tool as a read-only locator for post_id to feed wp_extract_page or wp_edit_page, distinguishing it from related operations.

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 concrete usage direction: use it to locate the post_id for downstream extraction/edit tools and notes it is read-only. It does not explicitly enumerate when to avoid this tool in favor of alternative search/retrieval siblings, but the intended workflow 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?

The description explicitly states the operation is read-only, which implies no side effects, and describes the error behavior for missing ACF. It does not detail further side effects or error codes, but for a simple read operation this is sufficient.

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

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

The description is concise but includes a slightly redundant second sentence about return types. Overall it is well-structured, focused, and avoids unnecessary filler, though a minor trim could improve clarity.

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?

Given the absence of an output schema, the description covers the essential context: it specifies the output format, the types of values, prerequisites, and error behavior. It does not address edge cases like pagination, but these are less relevant for a simple ACF retrieval.

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 schema provides no descriptions, but the tool description explains that 'install' is the WP Engine install name and instructs the agent to obtain 'post_id' from wp_find_page or wp_get_content. This adds meaningful semantics beyond the bare parameter names.

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 clearly states the action (read), the resource (page/post's ACF values), and the output format (JSON object). It also distinguishes this read operation from the sibling wp_set_acf tool by explicitly noting 'Read-only'.

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 provides practical guidance by specifying the prerequisite that the REST transport and ACF must be active, and explains that a site without ACF returns an error rather than crashing. It effectively tells the agent when and how to use this tool.

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

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

With no annotations provided, the description must carry the behavioral burden. It discloses that the result is a lean list (id, title, slug, status, type), explains defaults for post_type, and notes query is an optional search term. However, it does not mention pagination, sorting, permissions, or the exact return format beyond the field list. For a simple listing tool, this is acceptable but not rich.

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

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

The description is extremely concise—two sentences—and front-loads the primary purpose. Every sentence adds value: the first states the action and result fields, the second clarifies parameter defaults. There is zero fluff, and the structure is efficient.

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 lean list tool with no output schema and no annotations, the description covers the core purpose, returned fields, and parameter defaults. It omits details such as pagination, sorting, filtering beyond post_type, and any rate limits or auth requirements. These are not critical for a simple list, but the absence means the description is not fully comprehensive.

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 compensate. It explains that post_type defaults to 'page' and query is an optional simple search term, adding meaning to two of the three parameters. The 'install' parameter is not described, leaving its meaning (likely the install identifier) to inference. This is partial compensation, not complete.

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 clearly states the verb (List) and resource (posts/pages on an install) and specifies the returned fields (lean: id, title, slug, status, type). It is distinguishable from siblings like wp_find_page (which likely finds a specific page) and wp_extract_page (which extracts content), though it does not explicitly name them. The purpose is specific and unambiguous.

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 the use case (listing content) and gives parameter defaults, but it does not explicitly state when to use this tool versus alternatives such as wp_find_page for finding a specific page or wp_create_content for creating content. There is no mention of when not to use it or exclusions. The guidance is adequate but not explicit.

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

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

Despite lacking annotations, the description discloses that the operation is read-only, explains how to interpret falsy values, and notes response values are returned as stored. It does not explicitly describe error behavior or the full response shape, but the key behavioral caveats are covered.

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

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

The description is concise and well-structured: it opens with the core purpose, then provides important caveats, and ends with prerequisites. Every sentence adds value and no unnecessary detail is included.

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?

The description covers the essential usage context, including the existence check, serialization behavior, and access prerequisites. It does not describe the output schema or error cases, but for a simple read operation the guidance is largely sufficient.

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 `name` parameter is clearly implied as the exact option name, but the required `install` parameter is never explained. With no schema descriptions or enums, this leaves a significant gap in parameter understanding.

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 clearly states the tool reads one wp_options row by exact name and explicitly notes it works for non-autoloaded options. This distinguishes it from sibling tools like wp_list_options, wp_set_option, and wp_delete_option.

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 provides concrete guidance: check the `exists` field rather than the value, be aware that serialized values may come back as strings, and that administrator credentials and a specific transport/plugin version are required. This is actionable and specific.

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 no annotations present, the description carries the transparency burden. It explicitly labels the operation read-only, notes the REST transport requirement, and explains that SEO plugin metadata is normalized from SEOPress/Rank Math/Yoast; however, it does not mention behavior when no SEO plugin is active.

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?

The description is compact and front-loaded, leading with the action and resource, then adding mapping behavior, constraints, and parameter provenance in three concise sentences. No redundant wording.

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?

It lists the expected output fields (title, description, canonical, noindex) and prerequisites, which is enough for a simple read tool. Since there is no output schema, a note on failure/empty cases would make it fully complete, but the core context is present.

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?

Both parameters are explicitly explained: install is identified as the WP Engine install name and post_id is given a source (wp_find_page / wp_get_content). The schema itself provides only names and types, so the description adds substantial semantic value.

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 opens with a specific verb ('Read') and a specific resource ('a page/post's SEO meta'), listing the exact fields returned. This clearly distinguishes it from content retrieval tools like wp_get_content and the write counterpart wp_set_seo.

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 states the tool is read-only, which implies the write counterpart wp_set_seo should be used for modifications. It also tells the agent that REST transport is required and explains where to obtain post_id, but it does not explicitly contrast with all nearby alternatives.

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 no annotations, the description alone must convey behavioral traits. It clearly states 'Read-only' and explains that only the seven listed fields are returned, while explicitly noting exclusions (site URL, admin email, language). It also mentions the required authentication level and transport. This fully discloses the tool's effects and limitations.

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?

The description is relatively concise but includes slight redundancy, such as repeating 'editable settings' and then saying 'deliberately narrow: only those seven fields are returned'. It is still well-organized and not overly verbose, earning a strong score.

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?

While the description covers auth requirements, field exclusions, and read-only behavior, it omits any explanation of the 'install' parameter and provides no output format details. Since there is no output schema, this missing context makes the tool incomplete for a new user.

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 only parameter, 'install', is completely unexplained in the description and the schema provides no description (coverage 0%). A user cannot infer what value to pass (e.g., site ID, URL, or name) without external knowledge. This is a significant gap in usability.

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 clearly states the tool's purpose: to read a site's editable settings, and explicitly lists the seven fields it returns. This distinguishes it from sibling tools like wp_get_option or wp_set_setting, making its function unambiguous.

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 provides clear context for when to use this tool (to retrieve the specified settings) and notes its narrow scope, implying that other settings would require different tools. However, it does not explicitly name alternative tools or state 'use this instead of X', so it falls short of a perfect 5.

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

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

With no annotations, the description carries the transparency burden. It discloses permission requirements, path restrictions, default theme behavior, and the refusal condition under DISALLOW_FILE_EDIT. It also implies read-only semantics via 'Read', but does not mention behavior on missing files or whether raw contents 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?

All sentences contribute necessary information without redundancy. The description is about 60 words and stays focused on usage, constraints, and prerequisites. No filler or irrelevant detail.

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?

Given the lack of an output schema, the description does not specify the return format (e.g., raw text, JSON, escaped HTML) or error handling (e.g., file-not-found). It also omits the meaning of `install`, which is a required parameter in the schema. These gaps leave the agent uncertain about expected output and the role of one parameter.

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 description explains `file` (relative path, restrictions) and `theme` (defaults to active child, pass for specific theme), but provides no explanation for the required `install` parameter. Since the schema has zero parameter descriptions, the description only partially compensates for two of three parameters.

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?

Clearly states the action (read) and the resource (theme file), and explicitly distinguishes from the sibling write operation `wp_set_theme_file`. The emphasis on ACTIVE theme is clarified by noting that a specific theme can be passed via the `theme` parameter.

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 concrete usage constraints: relative path required, absolute paths and '..' refused, default to active child theme, and an optional theme parameter. Also lists prerequisites (REST transport, plugin version, app password with `edit_themes`) and a known blocker (DISALLOW_FILE_EDIT), which effectively tells the agent when this tool will fail.

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?

Explicitly declares read-only behavior and states auth requirements. With no annotations, this covers the key side-effect and access constraints, though it doesn't mention failure/not-found 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?

Every sentence adds useful information and there is no redundancy. The description is compact and front-loaded with the core action.

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?

Missing parameter semantics for install and no output schema or error behavior are provided. While the read-only nature and returned fields are mentioned, the call cannot be made confidently without knowing what 'install' refers to.

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 no parameter descriptions, and the text only explains where user_id comes from. The 'install' parameter is never described, so the agent cannot fully understand how to fill both required arguments.

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 exactly what the tool does: reads one WordPress user by id, and lists the fields returned. Clearly distinct from sibling list/create/update/delete user tools.

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 practical context: read-only, obtains user_id from wp_list_users, and requires REST transport with an administrator app password. Doesn't explicitly contrast with alternative single-user lookup tools, but the prerequisites and source of user_id give enough direction.

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 no annotations, the description correctly carries the burden of declaring side effects by stating 'Read-only'. It also discloses the required app password capability. It does not mention output pagination or error behavior, but the key behavioral guarantee of not modifying data is explicit.

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?

The description is compact, well-structured, and free of redundant text. Each line adds necessary information about fields, filters, defaults, or requirements.

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?

The description covers filters, defaults, and permissions, but lacks output format/pagination details and leaves the required install parameter unexplained. Given there is no output schema and no annotations, these omissions leave some ambiguity for an agent.

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 description explains status values and the source of post_id, but the required install parameter is not described at all. Since the schema has zero parameter descriptions, the missing explanation for a required parameter is a significant 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?

The description clearly states the tool's purpose as listing comments, identifies the returned fields, and explicitly marks it as read-only. This distinguishes it from sibling moderation/deletion tools like wp_moderate_comment and wp_delete_comment.

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 concrete usage guidance: how to filter by post_id and/or status, what happens when both are omitted, and the required permission and transport. It does not explicitly name alternative tools for comment moderation, but the read-only label and filter instructions are sufficient for most use cases.

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?

Explicitly states 'Read-only', which is a behavioral guarantee. It also discloses a limitation (does not fetch menu items) and a prerequisite (REST transport). Since no annotations are provided, the description carries the full burden and does so effectively.

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?

The description is concise, consisting of exactly four short sentences with clear structure. It covers the core purpose, usage pointers, and constraints without any fluff 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?

Given the low complexity of the tool (single read-only operation), the description provides adequate context for typical use, linking it to the menu-item workflow and transport requirements. It lacks parameter explanation, which is a minor gap but not critical for the main scenario.

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 only parameter, 'install', has no description in the schema and is not explained in the tool description. Schema coverage is 0%, and the description does not compensate, leaving the agent without information about what value to pass.

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 clearly states the verb 'List' and the resource 'a site's navigation menus', and explicitly enumerates the returned fields (id, name, slug, theme locations). It distinguishes itself from sibling tools by indicating this is the starting point before adding menu items.

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 explicit guidance on when to use this tool ('Start here'), notes that menu items are not fetched (so another tool is needed for that), and mentions the REST transport requirement, which is a key usage constraint.

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?

Since there are no annotations, the description carries the full burden of behavioral transparency. It discloses the limitation that only autoloaded options are listed and emphasizes that a missing name does NOT prove the option does not exist. It also mentions the permission requirement (manage_options), making the behavior fully transparent.

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

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

The description is somewhat verbose but well-structured, with a clear statement of purpose, a limitation section, and a requirements section. Each sentence adds value, and the use of capitalization (AUTOLOADED, LIMITATION) helps draw attention to key points. It could be slightly more concise but is not overly wordy.

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?

The description is complete for the tool's simplicity. It covers what the tool returns (option names only), what it excludes (non-autoloaded options), how it relates to wp_get_option for missing names, and the necessary runtime and permission context. No critical information about when or how to use this tool 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 only parameter 'install' is not described in the tool description, and the schema provides no description either. With schema description coverage at 0%, the description must compensate but does not mention what 'install' refers to (likely a site installation ID). Agents may be uncertain about what value to pass for this parameter.

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 clearly states the action ('List') and the specific resource ('the site's AUTOLOADED option names') with explicit detail that only names are returned, not values. It also distinguishes this tool from wp_get_option by noting the absence of non-autoloaded options, making its purpose unambiguous.

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 provides explicit usage guidance: it is read-only, limited to autoloaded options, and explicitly points to wp_get_option for non-autoloaded options. It also states the prerequisites (REST transport, wp-ops-connect 1.3.0+, and administrator app password) which tells the agent when and how to invoke it.

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?

The description declares the tool is read-only and explicitly lists what operations it does not perform (install/update/delete). It also mentions the REST transport prerequisite. However, it does not discuss potential error conditions, pagination, or output size, which would provide fuller transparency.

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?

The description is brief and mostly front-loaded, but the sentence 'Counts come back as `active` / `inactive`' is confusing—likely a typo for 'Status'—and detracts from clarity. The rest is straightforward, but this error lowers the score.

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 fully describe the return shape; it lists fields but not the structure (array/object). More critically, the required 'install' parameter is completely unexplained, making it impossible for an agent to know how to invoke the tool correctly. The description covers purpose and usage but fails on parameter and response details.

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 input schema defines one required parameter named 'install' but the description provides no explanation of its meaning or format. The parameter name is ambiguous (could be a path, slug, or something else) and there is zero schema description coverage, leaving the agent without any guidance.

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 clearly states that the tool lists all installed plugins with fields (id, name, status, version, requirements). It also differentiates itself from sibling tools by noting that it is read-only, that the returned plugin id feeds the activation tools, and that install/update/delete are not offered here.

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 explicitly tells the agent to start here before toggling plugins, explains how the returned `status` field indicates whether a toggle is needed, and directs install/update/delete actions to the separate plugin-audit/MainWP process. The transport requirement (REST) is also stated.

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?

The verb 'List' implies a read-only operation, and the description explicitly states that it returns 'ids + count only,' setting clear expectations about the response. It does not explicitly mention side effects, authentication, or rate limits, but the read-only nature is strongly implied.

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?

The description is concise, uses a clear structure with a main statement and filter details, and avoids unnecessary words. It is easy to scan and matches the schema parameter names.

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?

The description covers the output shape and filters, but it does not clarify whether multiple filters are combined with AND/OR, how results are ordered, or whether pagination is supported. It also omits behavior for empty results or invalid filter values, leaving some context 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?

All three parameters are described in the prose: account, environment, and query. The query substring behavior is clear, and environment values are given as prod|staging, though the 'account' value 'hostacct1-6' is somewhat ambiguous and lacks a concrete format.

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 clearly states the tool's purpose with a specific verb ('List') and resource ('fleet sites'), and enumerates the fields involved. It also distinguishes the output as 'ids + count only,' making the tool's function unambiguous.

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 explains the available filters and their accepted values, which is useful for how to use the tool. However, it does not explicitly mention when to prefer this tool over sibling tools or when not to use it, so the usage guidance is only partially complete.

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 no annotations, the description carries the full burden and does disclose read-only behavior plus transport and visibility constraints. It does not mention error conditions or return envelope details, but the core behavioral expectations are clearly communicated.

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

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

The description is compact and front-loaded with the main purpose, then adds essential usage and constraint details in three sentences. No filler or redundant phrasing.

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?

Given the simple list operation and lack of output schema, the description covers the key output fields, the relationship to term tools, and operational constraints. It is slightly incomplete only because the install parameter is unexplained, but overall context is strong.

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 only parameter, install, has no schema description and the tool description does not explain it at all. Since schema coverage is 0%, the description should compensate, but it provides no guidance on what install means or how to specify it.

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?

Clearly states the tool lists a site's taxonomies and names the key returned fields (slug, name, rest_base, hierarchical, post types). It also distinguishes its role as the starting point for term tools by explaining the returned slug is used as the taxonomy parameter elsewhere.

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 to 'start here' and explains that the slug returned is what every other term tool expects as the taxonomy parameter. It also notes important constraints: only taxonomies with show_in_rest appear, and the tool requires the REST transport rather than the wpcli/SSH gateway.

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 no annotations, the description carries the burden of explaining side effects. It explicitly states 'Read-only' and provides a notable behavioral nuance: the parent field returns None for flat taxonomies, contrasting with WordPress's 0 for top-level. It does not detail error cases, but this is sufficient for a read-only list operation.

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

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

The description is concise and well-structured. It front-loads the core purpose, lists returned fields, and then expands on the taxonomy and search parameters. The parent None vs 0 explanation is valuable and not verbose, adding clarity without unnecessary length.

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?

Although there is no output schema, the description indirectly outlines the return structure (id, name, slug, parent, post count) and explains an important edge case. It does not mention pagination, sorting, or error responses, but for a straightforward read-only list tool, the information provided is sufficient for basic use.

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 description explains taxonomy (a slug from wp_list_taxonomies) and search (optional simple filter on term name), but does not explain the 'install' parameter at all. Since the schema provides no parameter descriptions, this gap leaves a required parameter undefined, limiting the agent's ability to correctly invoke the tool.

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 clearly states the tool's purpose: listing terms in a taxonomy, and enumerates the fields returned (id, name, slug, parent, post count). It also clarifies the taxonomy parameter, making the intended use unambiguous even without annotations.

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 provides a prerequisite (requires REST transport) and explains that search is an optional filter. It does not explicitly compare with sibling tools like wp_list_taxonomies or wp_create_term, but the read-only nature and simple listing behavior are clear enough for an agent to decide when to invoke it.

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?

Despite no annotations, description discloses read-only behavior, required permissions, and error-vs-crash outcome. It doesn't discuss pagination or rate limits, but with no annotation burden the description carries the main behavioral load well.

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?

Purpose and key constraints are front-loaded and compact, though the parenthetical '(that comes back as an error, not a crash)' is slightly redundant.

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?

Description includes output fields, permissions, and integration with sibling user tools, enough for a simple list. It lacks explicit install parameter description and pagination/limits, but remains largely self-contained.

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?

Search is fully explained as an optional substring matched against login/name/email, but the required install parameter is not explicitly defined beyond implying site context, leaving a gap with 0% schema coverage.

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?

Clearly states it lists a site's WordPress users with specific fields, and orients the caller to use returned IDs with wp_get_user/wp_update_user/wp_delete_user, distinguishing it from related user tools.

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 notes read-only nature, describes search parameter behavior, and states admin app password requirement and failure mode, giving concrete conditions for use.

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 no annotations provided, the description carries the full burden and does so excellently. It discloses the default dry_run=true (writes nothing), the need to pass dry_run=false to apply, the verification against site-reported status, the transport requirement, and the prod safety flag. It also explains the behavioral effect of each status (publish, return to queue, teach spam filters, recoverable trash). No contradictions; all critical behavioral traits are transparent.

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?

The description is front-loaded with the core action, then expands into essential details without redundancy. Every sentence adds value: allowed statuses, effects, comment_id source, dry_run default, prod safety, transport requirement. No fluff, well-structured, and appropriately detailed for the tool's complexity.

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?

Given the tool's complexity (moderation with dry-run safety, prod restrictions, transport dependency) and the absence of an output schema, the description covers all necessary information for correct invocation: status vocabulary, default behavior, how to apply changes, safety flags, and where to obtain the comment ID. Nothing critical is missing for an agent to use it properly.

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 compensate. It explains status values (with explicit allowed strings and rejected examples), dry_run default and behavior, comment_id source (wp_list_comments), and allow_prod requirement. It does not explicitly describe the 'install' parameter, but it is a common site identifier across sibling tools and likely inferred. Overall, it adds significant meaning beyond the bare schema for 4 of 5 parameters, making it quite helpful.

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 action ('Set one comment's moderation status') and resource (a comment), and enumerates the exact statuses allowed. It clearly distinguishes itself from siblings like wp_delete_comment (which permanently removes) and wp_list_comments (which lists) by focusing on moderation actions. The verb+resource is precise and unambiguous.

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 provides clear context for when to use the tool: to moderate a single comment, with statuses explained. It also gives operational guidance (requires REST transport, prod writes need allow_prod=true, dry_run default). However, it does not explicitly name alternatives or conditions for using a different tool (e.g., when to choose wp_delete_comment over trash), though the recoverable nature of trash is implied. Missing explicit exclusions, but usage context is solid.

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 no annotations, the description carries the transparency burden and does disclose key side effects: copies content onto live_id, purges cache, deletes the draft, and probes the public URL. It also notes the prod guard (allow_prod=true), but it does not mention authentication, error behavior, or what happens if verification 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?

The description is compact and front-loaded, with the main purpose in the first sentence and supporting operational details in the second. It contains no redundant or irrelevant content.

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?

It covers the main workflow and side effects, but it omits output/return behavior, error/verification failure handling, and the meaning of install. Given the absence of an output schema and annotations, these gaps reduce completeness.

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 schema provides no parameter descriptions, but the narrative explains live_id as the target live post, draft_id as the draft being copied/deleted, and allow_prod as a production-write guard. The install parameter remains unexplained, so coverage is not complete.

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 opens with a specific verb and resource: 'Promote a staged draft onto the live post' and clarifies the scope by mentioning draft deletion and verification. It is distinguishable from sibling tools like wp_discard_draft and wp_edit_page, though it does not explicitly name an alternative.

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

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

The description implies the use case ('Promote a staged draft') and describes the sequence of operations, but it does not explicitly state when to choose this tool over alternatives such as wp_edit_page or wp_discard_draft.

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 no annotations provided, the description carries the full burden. It explicitly discloses the non-destructive default (dry_run=true returns a preview), the side effect of removing only the menu item (not the page), and the production safety gate (allow_prod=true).

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?

The description is concise and well-structured, using line breaks to emphasize key points. Every sentence adds value without redundancy, making it easy to parse quickly.

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?

The description adequately covers the tool's behavior and safety considerations, but it omits details about the return value or output format (e.g., what the preview or success message looks like). This is a minor gap given the tool's simplicity.

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 schema has no parameter descriptions, but the tool description explains three of four parameters clearly: item_id (with a crucial disambiguation), dry_run (with its effect), and allow_prod (with its permission role). The 'install' parameter is not explained, leaving a small 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?

The description clearly states the tool's purpose: 'Remove one item from a navigation menu' with a specific verb and resource. It also clarifies a key distinction ('the page it links to is NOT deleted'), which differentiates it from other page-related operations.

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 practical usage instructions such as the defaults for dry_run and allow_prod, and the requirement for REST transport. While it does not explicitly contrast with sibling tools like wp_update_menu_item, the name and description make the appropriate usage evident.

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 no annotations provided, the description carries the full transparency burden and does so well. It discloses that dry_run writes nothing, that apply mode writes and verifies values, that leading-underscore selectors are rejected and reported as skipped, and that prod writes require allow_prod=true.

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?

The description is front-loaded with the core purpose and then adds dense, useful caveats in a logical order. Each sentence earns its place, covering side effects, verification, constraints, and safety guards without unnecessary padding.

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?

The description covers the main behavioral edge cases, prerequisites, and result statuses like 'applied' and 'partial'. It lacks explicit detail about the 'install' parameter and does not describe the full response shape, but since there is no output schema, the most important calling context is still provided.

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 description does a good job explaining fields, dry_run, and allow_prod, but the required 'install' parameter is never described, and post_id is only indirectly implied by 'page/post's'. Since schema coverage is 0%, the description needs to compensate more fully for all parameters.

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 clearly states a specific action ('Set a page/post's ACF field VALUES') and identifies the exact resource, while also distinguishing this from the field-group schema. It is easy to tell this tool writes ACF field values rather than reading them or editing core content.

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 explains important usage constraints such as dry_run defaults, registered-field requirements, and the prod guard, but it does not explicitly state when to choose this tool over alternatives like wp_get_acf or wp_edit_page. The intended use is implied by the name and first sentence rather than directly contrasted with sibling tools.

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?

The description fully discloses the tool's behavior: it writes any option, potential offline consequences, storage cast tolerances, and that the result includes the actual stored value. Since no annotations are provided, the description carries the full burden and does so thoroughly.

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?

The description is well-structured and front-loaded with the critical warning, but it contains some redundancy (e.g., the dry_run default and the siteurl/home warning are repeated). It is slightly verbose, but the complexity of the tool justifies most of the detail, and the repetition reinforces safety without significant confusion.

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?

The description covers all essential aspects for an agent: the action, risks, prerequisite conditions, return behavior, and safety defaults. It doesn't mention error handling, but that is not necessary for a complete understanding of how to invoke the tool. The context is rich enough to make an informed decision.

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 schema defines all five parameters, but the description adds meaningful context for dry_run (default true, writes nothing), allow_prod (required for prod writes), and value (tolerates casts). The 'install' parameter is not explicitly explained but its name and role are straightforward from the context. Overall, the description supplements the schema well, though a minor gap remains for 'install'.

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 clearly states the tool's action: 'Write ANY wp_options row.' It also identifies the resource (wp_options), the potential risk with siteurl/home, and the overall purpose. There is no ambiguity about what the tool does.

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

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

The description provides extensive guidance: it warns about the lack of an allowlist, advises reading the option first with wp_get_option, emphasizes the dry_run default and how to actually write, and specifies prerequisites (REST transport, wp-ops-connect version, admin app password, allow_prod for production). This leaves no doubt about when and how to safely use the 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 no annotations, the description carries full transparency. It discloses replacement semantics, the verification of writes, error behavior on mismatched term IDs, the dry_run default, the need for REST transport, and prod write restrictions (allow_prod).

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?

The description is somewhat verbose and repetitive, with multiple caveats and instructions crammed into a single paragraph. It could be streamlined without losing key details, but the structure is still readable and logically ordered.

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?

Given the tool's complexity, the description covers major behaviors: replacement, error verification, dry_run, and prod safeguards. However, it omits explanation of the install and taxonomy parameters, which are part of the required input.

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 schema has 0% description coverage. The description explains term_ids (complete list, empty clears), post_id (from wp_find_page/wp_get_content), dry_run (default true), and allow_prod (required for prod). It does not explain install or taxonomy, leaving two parameters under-described.

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?

Clearly states the verb and resource: 'Set a post's terms for one taxonomy' and explicitly warns 'REPLACES them, never appends.' This distinguishes it from sibling tools like wp_list_terms or wp_create_term.

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 actionable guidance: 'Read the post's current terms first if you mean to add one' and explains the dry_run default and how to apply. It does not explicitly contrast with alternatives, but the replacement semantics make the appropriate usage 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?

With no annotations provided, the description carries full burden. It discloses that changes are written to the active SEO plugin, verified by readback, default dry_run behavior (preview only), and the allow_prod guard for production. No contradictions with 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?

The description is concise and well-structured, covering essential details in two sentences. It front-loads the purpose and then efficiently conveys behavioral nuances without 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?

Despite lacking an output schema, the description provides sufficient context for correct usage: what is affected (SEO meta), how changes are applied (via specified plugin), safety defaults, and required transport. It answers the key questions an agent would have.

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. It explains the purpose of all parameters: title, description, canonical, noindex are SEO fields; post_id and install are context; dry_run and allow_prod define behavior. It also clarifies that omitted fields are left unchanged, adding meaning beyond the raw 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 clearly states the tool's function: setting a page/post's SEO meta (title/description/canonical/noindex). It is distinct from sibling tools like wp_get_seo, making its purpose unambiguous.

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 implicitly indicates when to use it (when SEO meta needs to be set) and provides critical usage constraints (dry_run default, allow_prod requirement, REST transport). It sufficiently differentiates from alternatives like wp_get_seo by contrast of action.

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?

Discloses important behaviors: dry_run defaults to true, value verification against actual stored value, and the encoding of special characters. No annotations are present, so the description carries the full burden and handles it well.

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?

The description is dense but well-organized, using line breaks and backticks for clarity. Each sentence adds meaningful information without 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?

Covers the essential edge cases (dry-run, production safety, encoding, invalid keys) and the write verification behavior. No output schema is provided, but the description hints at the response shape by mentioning the actual stored value is returned.

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 description explains the semantics of key, value, dry_run, and allow_prod in detail. However, the 'install' parameter is never mentioned in the description, leaving a gap for that required parameter.

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?

Clearly states it changes one site setting, distinguishing from wp_get_settings. The specific verb 'Change' is appropriate and the resource is clear.

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 describes accepted keys, the dry_run default behavior, and the allow_prod requirement for production writes. Sibling tools like wp_get_settings are implied context, though not directly named as alternatives.

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 no annotations provided, the description carries the full transparency burden. It details the write mechanism (core editor), the automatic revert on fatal errors, the verification via re-reading, the return of previous contents, and the limitation on creation. These are critical behavioral characteristics that are fully 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?

The description is relatively long but every sentence conveys essential safety or usage information. The bullet-point format improves readability. It could potentially be trimmed, but given the high risk and number of caveats, the detail is justified and not redundant.

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?

The description covers the most important contextual aspects: risk, safety nets, defaults, constraints (no creation, prod guard), and a comparison to the read sibling. It does not specify the exact success/error response format, but it does mention what dry_run returns, which is sufficient for an agent to anticipate outcomes.

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?

Although the schema has no field descriptions, the tool description explains several parameters: dry_run, allow_prod, allow_create, and allow_other_theme. 'file' and 'contents' are self-explanatory, and 'theme' is implicitly covered by the allow_other_theme note. However, 'install' is not explicitly described, leaving a minor gap in full parameter understanding.

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 clearly states the tool's purpose: 'Write one theme file' and explicitly contrasts it with the reading sibling wp_get_theme_file. It also highlights the high-risk nature of the operation, leaving no ambiguity about what the tool does.

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

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

The description provides concrete usage guidance: defaults to dry_run=true, advises reading before writing, explains the allow_prod and allow_other_theme flags, and explicitly states that file creation is not supported, directing the user to deploy/SFTP instead. This is actionable and prevents misuse.

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?

The description uses the verb 'check', implying a read-only operation, but it does not explicitly state that no changes are made. There are no annotations (e.g., readOnlyHint) to clarify side effects, and the description does not mention permissions, rate limits, or any potential consequences. The agent is left without explicit assurance of non-destructiveness.

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?

The description is concise and free of extraneous information. It conveys the essential purpose and parameter meaning in two short sentences. There is no repetition or unnecessary detail, making it easy for an agent to parse quickly.

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

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

The description covers the basic purpose and parameter, but it lacks details about the output format or the meaning of the results. For a health check tool, an agent might expect to know what kind of response to anticipate (e.g., status codes, success criteria). Without an output schema, this information is missing, which could leave the agent uncertain about how to interpret the result.

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 description explains the 'install' parameter as the WP Engine install name and provides a concrete example ('daytonplas1stg'). This gives the agent enough context to understand what value to pass. However, it does not elaborate on constraints (e.g., format, allowed characters), which could be inferred from the example but is not explicitly stated.

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 clearly states the tool's purpose: checking the reachability of an install via WP REST and SSH/WP-CLI. It identifies the resource (install) and the method of checking. It could be more specific about what 'reachability' entails, but the core purpose is unambiguous.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention any conditions that would make this tool preferable to other tools, nor does it indicate when it should not be used. This leaves the agent to infer usage context from the tool 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?

With no annotations provided, the description carries the full burden. It discloses the dry_run default with its preview behavior, the need for allow_prod for production writes, the REST transport requirement, and the outcome of passing no parameters. These are significant behavioral details that help the agent anticipate 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?

The description is organized into three clear sentences with inline code formatting for parameters. While it is somewhat dense, it avoids unnecessary verbosity and presents all critical information in a scannable way.

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 mutation tool, it covers important context: the dry-run safety default, production-write flag, transport requirement, and parameter-specific notes (position, parent, url). It also clarifies the item_id distinction. No output schema exists, but the description indicates what dry-run returns (a preview), which is sufficient.

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 description explains several parameters that lack schema descriptions: item_id (clarifying it is the menu item id, not page id), position (menu_order, 0=first), parent (nesting under an item id), url (retargets a custom link), dry_run, and allow_prod. However, 'install' and 'title' are not explicitly explained, though their names are suggestive. Overall, it compensates well for the 0% schema coverage but not completely.

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 clearly states the action ('Change one existing menu item') and enumerates specific transformations (rename, move, re-nest, retarget), which distinguishes it from sibling tools like wp_add_menu_item and wp_remove_menu_item.

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 provides helpful guidance on when to use the tool (for existing items), explains behavior when no parameters are passed ('refused rather than reported as a no-op success'), and outlines prerequisites like the REST transport and allow_prod requirement. However, it does not explicitly contrast with add/remove tools, though the 'existing item' phrasing implies the distinction.

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 no annotations provided, the description carries full responsibility and does well: it explains slug changes affect archive URLs, dry-run previews exact changes, production writes require allow_prod, and invalid field sets are refused.

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?

Every sentence serves a purpose and adds critical operational detail. The formatting with backticks and line breaks improves scannability without sacrificing clarity.

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?

The description covers the tool's behavior, safety defaults, production safeguards, and what a dry run returns. Given the absence of an output schema, it provides enough context for an agent to invoke the tool 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 schema has no property descriptions, but the description compensates for most parameters: fields allowed values, dry_run behavior and default, term_id source, and allow_prod guard. It does not explicitly describe install or taxonomy, though taxonomy is inferable.

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 clearly states the tool renames or re-parents one existing term, distinguishing it from creation or deletion tools. It also identifies the resource as an existing term and references wp_list_terms for obtaining the ID.

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 strong usage guidance: allowed field values, no-op refusal, dry-run default, REST transport requirement, and the allow_prod guard. It does not explicitly name alternative sibling tools, but the 'existing term' wording makes the intended use case 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?

With no annotations provided, the description fully carries the burden and does well: it discloses side effects (role replacement, password invalidation), refusal of unknown or empty fields, and dry-run vs. apply behavior. This gives the agent an accurate model of what will happen.

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?

The description is dense but every sentence adds critical operational detail. There is no redundant or irrelevant content, and the information is well-structured.

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?

The description covers behavioral expectations, defaults, permissions, and production safeguards. It does not describe the return value or error conditions, but since there is no output schema, some output guidance would have been helpful for full completeness.

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 schema has zero descriptions, but the tool description compensates for fields, dry_run, and allow_prod. install and user_id are not explicitly explained, though their names are strongly self-explanatory and user_id is clearly the target user. Overall, key parameters are sufficiently covered.

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 clearly states the tool changes an existing user's fields, which distinguishes it from create/delete/list user sibling tools. The verb and target resource are unambiguous.

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 provides concrete usage constraints: field allowlist, username non-editable, roles replacement, password reset behavior, empty-fields refusal, dry_run default, and allow_prod requirement for production writes. It does not explicitly contrast with wp_create_user, but the intent is clear from the wording.

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 no annotations provided, the description carries the full burden. It discloses the default dry_run=true behavior, the filename sanitization and directory drop, file type restrictions (including the refusal of .svg for security), the size limit, the REST transport requirement, and the allow_prod guard. No contradictions.

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?

The description is front-loaded with the main purpose, then uses a compact bullet-like structure for constraints and usage. Every sentence adds value—no filler. The length is justified by the safety and workflow nuances.

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?

Given 5 parameters, no annotations, and no output schema, the description provides all essential context: what the tool does, how to invoke it safely, what the dry_run preview returns, and how to use the resulting URL. It covers file validation, prod protection, and integration points. Only a minor install parameter omission, but that is likely self-evident from the WordPress 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 coverage is 0%, so the description must compensate. It explains file_path (local path, not URL), alt, dry_run (with default), and allow_prod. It does not explicitly explain the install parameter, which is required and likely refers to the WordPress site installation. This is a minor gap given the otherwise rich coverage.

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 (Upload), a precise resource (local image file into a site's media library), and adds the optional alt text. It also names the downstream consumers (wp_create_content / wp_edit_page), distinguishing it from the sibling WordPress tools.

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 states when to use it: to upload a local image, with clear constraints (file types, size, dry_run default). It explains the dry_run vs. real upload workflow and the allow_prod requirement, and implies the alternative (using a URL instead of a local path) is not for this tool. The integration with content creation is explicitly described.

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