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

Annotations only supply readOnlyHint, so the description carries most of the burden and does so well: no alias expansion, 50-event cap with count and truncation on regulatory_events, entity_id_ignored signaling, the explicitly_named vs affiliate_50pct_rule coverage distinction, and the instruction that data_quality_flags is load-bearing. These are real behavioral traits an agent could not infer from structured fields.

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 and scope are front-loaded correctly, but the long parenthetical on OFAC/1260H is dense and the OFAC exclusion is stated twice ('it does NOT cover OFAC SDN' and 'OFAC's SDN list is not ingested, and on_ofac_sdn is null'). The entity_id rules are also duplicated verbatim from the schema, adding bulk without new 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?

For a read-only lookup with no output schema, the description enumerates the returned fields (entity_name through data_quality_flags), explains the provenance tier, and clarifies the semantics of the two non-obvious output attributes (bis_coverage_class, coverage_note). Nothing an agent needs to call or interpret the result is missing.

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 75%, so entity_name and entity_id are already documented, and the description largely restates the entity_id rejection semantics rather than adding new detail. It does add value on matching behavior (substring, no alias expansion) and the entity_name-or-country disjunction, but leaves the limit parameter (default 20, max 50) and country usage unelaborated.

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?

Opens with a specific verb and resource ('Look up BIS Entity List designations for companies or countries') and immediately bounds the scope by naming what it does NOT cover (OFAC SDN, Wassenaar CCL) and which sibling handles adjacent data ('use scrutica_get_company'). An agent can distinguish this from scrutica_get_company and scrutica_search without opening a 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 states the required filter ('Provide entity_name or country'), the failure mode for entity_id-only calls (rejected), the fallback behavior for mixed calls (ignored plus entity_id_ignored: true), and exactly which alternative tool to use for 1260H/NS-CMIC/FASCSA listings. Both when-to-use and when-not-to-use are covered.

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