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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial behavioral context beyond that: the result taxonomy (clear/possible_match/strong_match), the rule that a match is a lead to verify rather than a decision, the DOB rule that rules out namesakes, and the SIREN/SIRET criterion that distinguishes strong from possible. That is exactly the interpretive guidance an agent needs.

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 core action and the register scope, then moves into result semantics and match-strength rules. It is dense and slightly long, but nearly every clause carries decision-relevant information rather than 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?

There is no output schema, and the description compensates fully by explaining the returned verdicts, the fields attached to each match (register entry, legal bases, official page), and the limits of the check. An agent can call and interpret this tool without further documentation.

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?

Only one parameter and schema coverage is 100%, so the schema fully documents the accepted identifier formats (SIREN/SIRET/FR VAT, spaces allowed). The description adds nothing about the input beyond what the schema already says, so baseline 3 applies.

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 (screens) and resource (a French company and its officers) against a named register (registre national des gels), with the scope of measures (UN, EU, French) made explicit. It is clearly distinguishable from siblings like check_vat or get_company, which do not perform sanction screening.

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 clearly delimits coverage and explicitly names what is NOT covered (beneficial owners, OFAC/UK foreign lists, politically exposed persons), which is valuable exclusion guidance. It does not name a sibling alternative or state a trigger condition, so it stops short of full when/when-not routing.

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