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

With no annotations, the description carries the full behavioral burden. It does disclose the return shape (state, jurisdiction, information page URL) and that results are matching bonds, which is useful and beyond structured data, but says nothing about pagination, result caps, or ranking of the 6,900 records, which matters for an unbounded keyword search.

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

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

Four compact sentences, front-loaded with the scope and corpus size, then return fields, then the optional filter and a concrete example. Nothing is wasted.

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

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

For a two-parameter search tool with no output schema and no annotations, the description gives enough to call it correctly: corpus, query semantics, optional state filter, and returned fields. It only lacks pagination/result-limit behavior.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds a concrete worked example ('auto dealer', state 'Texas') that shows how the keyword and state filter combine, going slightly beyond the schema's prose.

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

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

States a specific verb (search) and resource (Surety Bond Encyclopedia, 6,900 U.S. surety bond requirements) plus the return payload (bonds with state, jurisdiction, URL). It is clearly distinguishable from get_bond (single-record fetch) and list_jurisdictions/list_states (enumerations), though it never names those siblings explicitly.

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

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

The example ('auto dealer' / 'Texas') and the note that state is an optional narrowing filter imply when to use the keyword query vs. the state filter, but there is no explicit when-to-use or when-not-to-use guidance relative to get_bond or the list_* siblings. Usage has to be inferred.

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