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

Annotations already declare readOnlyHint and openWorldHint=false, so safety is covered; the description adds genuinely new behavioral detail beyond them: the cost ('spends one search'), and the two-tier coverage model — exhaustive counting for all sellers but detailed classification only for up to 10 named refs and top listers. That sampling limit is exactly the kind of thing an agent needs to interpret results correctly. It stops short of describing pagination or response shape.

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?

It is compact and the core scope leads, but the prose is dense and telegraphic, cramming counting behavior, detail tiers, certificate categories, and cost into two overloaded sentences. The cost note ('Spends one search') is buried at the very end where it is most likely to be skimmed past.

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?

There is no output schema, so the description carries the burden of indicating what comes back, and it largely does: per-rule counts, per-exhibitor classification (matching certificate, claimed only, foreign mark or lab name only), and which rules fall on the importer. Enough to call it correctly and interpret the gist, though the exact result shape stays loose.

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 both parameters are already documented, and the schema itself explains the refs fallback ('Leave out to check the ones that list the most'). The description reinforces this by noting 'up to 10 named exhibitors and the others that list the most,' but adds no new syntax, format, or constraint information beyond the schema. Baseline 3 is appropriate.

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 is specific about the operation and its scope: it matches each US rule's required paperwork against every exhibitor selling a product, returning per-rule counts plus a detailed subset. The verb and resource are identifiable (check exhibitor paperwork coverage for a product), though the opening sentence ('Who lists the paperwork each US rule for a product asks for') is grammatically tangled and slows comprehension. It implicitly distinguishes itself from us_requirements (the rules themselves) but never names that sibling.

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?

Usage context is implied rather than stated: 'Spends one search' signals this is a costly call to use deliberately, and the schema's mention of refs from search_listings implies a prerequisite workflow. However, the description never says when to use check_fit versus us_requirements, nor what to do when results are empty. The agent must infer the call sequence from the schema.

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