find_reusable_block

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 searches for standard blocks by capability and explains how they are applied (interfaces: vs addIns:). It does not mention any side effects, permissions, or rate limits, but given it's a read-only search operation, the transparency is adequate.

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, using only three sentences. It front-loads the purpose and provides actionable usage guidance without unnecessary detail. Code formatting and clear structure enhance 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?

Given the tool's simplicity (single parameter, no output schema, no annotations), the description covers everything needed: what it does, how to use it, and when to prefer it. It is complete for the tool's complexity.

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 describes the parameter 'query' with examples. The description adds meaning by specifying it is a 'member name or capability keyword' and that it returns blocks that 'expose it'. This enriches the schema definition, which already has 100% coverage, so a score above baseline is warranted.

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 it finds reusable Interfaces/AddIns by capability (member name or keyword). It distinguishes itself from sibling tools like list_types or search_types by focusing on standard blocks that expose a capability, with specific examples like 'SerialNumber' or 'DeviceHealth'.

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 applying/composing an existing block over redefining members inline, and provides concrete guidance on when to use Interface vs AddIn: a single property uses Interface, a whole sub-object uses AddIn. This helps the agent make correct decisions.

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