wp_blocks_find

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

The description discloses that the tool returns paths and hashes and frames itself as a precursor to edits, which suggests a read-only operation. However, with no annotations provided, the description does not explicitly state the absence of side effects, any authentication requirements, or how matching behaves. It gives a partial behavioral picture but not a complete one.

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, focused sentence. It front-loads the action and outcome, and every phrase adds value — 'all matching Gutenberg blocks' defines scope, while 'return paths and hashes for safe follow-up edits' conveys the key output and purpose 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?

For a tool with a nested query object, no output schema, and no annotations, the description is too sparse to be complete. It omits details about how matching works, the format of the returned paths/hashes, the meaning of include_html, and whether the operation is fully read-only. The one-line description leaves too much for the agent to infer.

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 low at 25% — only ref has a description in the schema. The description itself does not compensate by explaining the nested query object (block, contains, attrs_match) or the post_type and include_html parameters. An agent must rely on parameter names and infer semantics, which is risky for the query object.

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 ('Find') and resource ('Gutenberg blocks'), and it is clear that this is a search/locate operation rather than a list/get/delete/modify operation. The mention of returning 'paths and hashes' further clarifies its purpose. However, it does not explicitly distinguish itself from sibling tools like wp_blocks_list or wp_blocks_get.

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

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

The phrase 'for safe follow-up edits' implies this tool should be used before modifying blocks, providing some contextual guidance. But it does not explicitly state when to choose this tool over alternatives such as wp_blocks_list or wp_blocks_get, nor does it give any when-not-to-use guidance.

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