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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses substantial behavior: pagination in pages of up to 50 ids continued with next_cursor, that issuers linked only through a filing are never counted (a parent never enters an overlap), that sources apply different laws, and that a no-reviewed-match reads as a specific string that is not a clearance finding.

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 purpose is front-loaded, but the content is delivered as one dense paragraph with deeply nested clauses covering outputs, joins, pagination, and caveats, which makes it hard to scan. Content largely earns its place, but structure is weak.

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 carries the return-format burden and does so completely: entity ids in both/one-sided lists, counts, published overlap figures, per-entity source rows (URL, row locator, snapshot date), snapshot dates, and pagination. It also supplies the caveat needed to interpret results responsibly.

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 description coverage is 100%, so the baseline is 3; however, the description adds interpretive meaning by explaining how source_a and source_b are compared ('Lists are reported as a without b and b without a') and what the csl enum value means (rows exactly matching a DHS/CBP name). This goes beyond the raw schema.

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 (compares) and resource (two sources of the MORVS U.S. Forced Labor Company Register), enumerating dhs/cbp/csl as the sources. It is clearly distinguishable from the sibling forced_labor_company_check, which operates on a single company rather than cross-source overlap.

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?

The description implies when the tool applies (source-overlap analysis across DHS/CBP/CSL) and warns that a no-match reading is not a clearance finding, but it never explicitly routes the agent versus alternatives such as forced_labor_company_check or screen_all. Usage is inferable but not stated.

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