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

Annotations only cover readOnly and openWorld; the description adds substantial context beyond them: the data comes from fishersci.com's public search through a residential proxy, prices are list prices as shown to logged-out visitors with account-specific pricing excluded, pages are capped at 10, and billing is $0.002 USDC per successful call via x402 with failures not charged. These are exactly the behavioral facts an agent needs before spending money.

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 is front-loaded and the field list is compact; payment and proxy caveats follow in short clauses with little filler. It is dense — one long enumerative sentence plus two caveat sentences — but nothing is redundant enough to cut outright.

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, output-schema-backed search tool, the description covers everything an agent needs: what is returned, paging limits, data provenance and its pricing limitation, and the paid-call cost model. No material gaps remain.

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%, with both q and page already documented (including examples and the 1–10 range), so the schema carries the parameter burden. The description's only parameter-relevant additions are the page cap and the 15-per-page yield, which the schema largely restates; it adds no query syntax or matching-behavior detail.

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 and resource (Fisher Scientific US lab product search) and enumerates exactly what each result contains: family title, description, leaf category, list price, catalog numbers, specs, link. The vendor is named explicitly, which is how this tool is told apart from the sibling supplier tools like ecommerce_avantor_vwr_international and ecommerce_chemist_warehouse.

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?

Gives clear operating context: US site, public search via residential proxy, logged-out list prices only, 15 families per page, pages 1–10, and a concrete per-call cost so an agent can weigh it against alternatives. It does not, however, name an alternative tool or state when *not* to use this one (e.g. for non-lab categories or account-specific pricing).

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