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

Adds real value beyond the readOnly/idempotent annotations: KEYLESS with no credential required, an explicit enumeration of returned fields plus the total-match count, and the important caveat that investigation_type/active_only filter only the returned page (server-side filtering is unreachable upstream). The pagination-suppresses-filtering warning prevents a silent correctness error.

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?

Front-loads the purpose and subtype definitions before the operational guidance, and every sentence carries information (subtypes, sort default, keyless access, alternative routing, return fields, filter caveat). It is somewhat dense with multiple parentheticals, but there is no filler.

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?

Although there is no output schema, the description enumerates the returned fields and the total count, explains how to link to the detail tool, discloses credential requirements, and warns about the page-scoped filtering limitation. An agent has everything needed to call it and interpret results correctly.

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 the baseline is 3, and the description earns above it by explaining that investigation_type/active_only are same-page-only filters that require paging to scan broadly — semantics the schema hints at but does not fully motivate. It otherwise mirrors the schema rather than adding new field-level detail.

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 ('List') and resource ('USITC investigations'), and disambiguates the two subtypes (Section 337 vs Title VII) an agent would otherwise conflate. It names the sibling it feeds into (itc_investigation_detail) via the returned investigation_id, so the tool's role in the workflow is unambiguous.

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?

Gives a concrete 'use this instead of' directive with example queries ('PREFER OVER WEB SEARCH for "what Section 337 investigations are active"'). It stops short of stating when not to use it or how it differs from the sibling itc_investigation_types, so it is clear context but not full exclusion guidance.

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