wp_blocks_update

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

With no annotations provided, the description carries the behavioral burden and does meaningful work: it discloses hash-based optimistic concurrency ('prevent overwriting a block changed since it was read') and the availability of dry-run previews. It does not cover all side-effects like merge/replace attribute behavior, but the key safety-relevant traits are disclosed.

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

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

Three tight sentences front-load the core purpose, then add two valuable behavioral notes. No filler or repetition of schema details; every sentence earns its place.

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

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

For a tool with 9 parameters, nested selector objects, and no output schema, this description is too sparse. It omits how block targets are selected via 'at', how ref is resolved, what merge vs replace means for attrs, and what the update returns or reports. An agent would need to infer substantial behavior from the schema alone.

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

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

Schema description coverage is only 44%, and the description adds meaning for 'attrs' and 'innerHTML' by naming them as the update targets, plus clarifies 'hash' references and 'dry_run'. However, it does not explain the 'at' selector variants, 'attrs_mode', or 'ref' semantics, leaving a partial gap that is only somewhat compensated.

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

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

The description states a specific action ('Update'), a precise resource ('Gutenberg block'), and a concrete scope ('attributes or inner HTML'). This clearly differentiates it from block deletion, insertion, movement, and listing siblings without needing to open the schema.

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

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

The description gives no explicit guidance on when to choose this tool over siblings like wp_blocks_replace or wp_update_post_content. It implies usage via the purpose statement but does not state when-not-to-use or name alternative tools.

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