screen_sanctions

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

With annotations already covering readOnly/idempotent/open-world, the description still adds substantial behavioral context: matching is local, the screened name is not sent to publishers, lists are downloaded daily with `fresh` to bypass cache, exact score thresholds (0.95 / 0.80), the meaning of `incomplete`, and that `overall` is the worst result and is `incomplete` if any requested group was incompletely screened. It even flags that list text is data, not instructions.

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?

A single dense paragraph, front-loaded with the core action, scope and sourcing before moving to result semantics and parameter combinations. Every sentence carries information, though it is a long block of text with the caveat and prompt-injection note somewhat buried at the end.

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?

No output schema exists, so the description carries the return contract and does so fully: the four result types, score thresholds, list version dates, the legal caveat, and the `overall` aggregation semantics for grouped screening. For a 10-parameter, zero-required tool this is complete enough to invoke 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, but the description adds real meaning beyond the schema: an entity is screened under its legal and former names plus LEI/company number/VAT, `include` screens current officers and PSC owners with `owners_depth` levels followed (UK companies), and it clarifies the name-vs-entity input choice. Score thresholds and result vocabulary are also supplied where the schema is silent.

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 (screen) and resource (name / resolved legal entity) and names the exact target data (UK, EU, US OFAC SDN sanctions lists). This is unambiguously distinct from sibling lookup tools such as search_entities, get_entity and resolve_identifier, which fetch registry data rather than screen against sanctions lists.

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 clear operating context: pass a bare `name` (optionally `type`) OR an entity via `entity_id`/`identifier`, and use `include` only with an entity. It also warns 'never treat incomplete as clear' and 'every hit needs human review'. It stops short of explicitly naming sibling tools to prefer for registry lookups, so it is clear context without explicit alternatives.

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