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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description still adds real behavioral context the annotations cannot: KeyVex 'republishes the lists; it is not a screening service', which tells the agent not to treat results as an authoritative screening determination. It also enumerates the returned record fields, though it says nothing about pagination or result-size limits.

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 usage triggers are front-loaded in the first sentence, and the sibling routing sits at the end where it is easy to find. The twelve-list enumeration is long but each entry is a compressed code-plus-name pair rather than prose, so it earns its space as a decode table.

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, but the description compensates by describing what each record carries ('name + alt_names, the source list, sanctions programs, addresses, distinct countries, and identification documents'). Combined with the source-code legend and cross-tool pairing notes, an agent has everything needed to call this 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 description coverage is 100%, so the baseline is 3, but the description goes beyond it by expanding the source_short codes into their full list names (SDN = Specially Designated Nationals/Treasury, EL = Entity List/Commerce, MEU, UVL, CMIC, etc.), which the schema only lists as bare codes. That mapping genuinely helps the agent pick the right filter value.

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 sentence gives a specific verb and resource ('Returns entries from the US Consolidated Screening List') and immediately scopes it as the combined feed of twelve federal lists. It explicitly contrasts itself with the sibling get_ofac_sdn ('Broader than get_ofac_sdn'), so an agent can distinguish the two without opening either 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?

Concrete trigger phrases are listed ('whether a company or person is on a US screening / sanctions / denied-party list', 'BIS Entity List members', 'Military End User designations'), and the alternatives are named with their selecting conditions: get_ofac_sdn for the SDN deep view, get_federal_contracts and get_foreign_agents for cross-source pairing.

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