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

Annotations only provide readOnlyHint=true, so the description carries the burden of behavioral disclosure. It goes far beyond by disclosing dataset anchoring (Federal Register), authority tier (Tier 1), coverage classes, the 50% affiliates rule, and the load-bearing nature of data_quality_flags. No contradiction with annotations.

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?

The description is dense but purposeful; each segment covers a distinct aspect: scope, exclusions, matching semantics, return fields, coverage classification, and data-quality caveats. It is front-loaded with the core purpose and main alternative. Slight redundancy around 'Federal-Register-anchored' and the lack of visual structure keep it from a perfect score.

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?

With no output schema, the description enumerates returned fields and their semantics, including source_url and data_quality_flags. It also resolves practical questions an agent would have: what dataset, what exclusions, how entity_name matches, and what coverage_note/bis_coverage_class mean. This is complete for a read-only lookup tool.

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?

The description adds important operational meaning for entity_name — case-insensitive substring match, no alias expansion — but this directly contradicts the input schema's entity_name description ('fuzzy matched against aliases'), creating ambiguity. It does not add parameter guidance for limit, country, or entity_id beyond what the schema already states. The contradiction makes the parameter semantics less reliable.

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 opening line names a specific verb ('Look up') and a specific resource ('BIS Entity List designations') for companies or countries, and the following sentence distinguishes it from adjacent OFAC/Wassenaar coverage by naming scrutica_get_company. It clearly identifies the US Commerce Department Entity List dataset.

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 when this tool is relevant, lists what it does NOT cover (OFAC SDN, Wassenaar CCL), and directs the agent to scrutica_get_company for OFAC/NS-CMIC/1260H status. It also defines the matching semantics, helping an agent decide whether this lookup is the appropriate one.

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