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

With readOnly/idempotent/closed-world annotations already covering the safety profile, the description still adds substantive context: the 53-record corpus is spec ranges rather than lot CoA, rCB records carry vs-N550 gap analysis, and the ash gap caveat (8-15% vs <=0.5%) limits rCB use. The record math (29+6+2) does not sum to the stated 53, which slightly muddies the corpus claim.

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?

Labeled Purpose/Guidelines/Limits/Ex sections make it scannable and the scope lands first. It is dense—long parenthetical enumerations of grade codes and brand names—but nearly every clause carries filtering or constraint information.

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?

Output schema exists and annotations carry the safety profile, so the description's job is scope and caveats, which it covers well: record types, the six comparative parameters, and the ash-content limitation. The internal inconsistency in the record count and the absence of any pointer to a sibling for full single-grade specs are the remaining gaps.

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 all eight parameters including enums are already documented; the description reinforces the type/category/keyword combination pattern and supplies example values. It says nothing about limit/offset pagination, language, confidence, or response_format, so it stays at the high-coverage baseline rather than exceeding it.

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 a precisely scoped resource (the carbon black grade benchmark library), then enumerates the three record families and the six standard parameters. An agent can distinguish it from siblings like get_grade, get_grade_spec, or compare_rcb without opening any 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?

Explicitly instructs how to drive the tool ('combine type/category/keyword') and where it sits in a workflow ('use as the anchoring benchmark layer before any rCB vs native comparison'). It stops short of naming when a sibling is the better choice, e.g. get_grade_spec for one grade's full spec or compare_rcb for the comparison itself.

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