UK Data: Sanctions screening

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value with the credit cost and the returned fields (EU programme, listing date), but says nothing about match behaviour, fuzzy vs exact name matching, or how minScore affects results.

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?

Three short, front-loaded sentences with no padding; the resource and scope come first and cost is appended last. The middle fragment 'For EU counterparties and EU trade' is slightly telegraphic but earns its place as usage context.

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?

For a 6-parameter screening tool with no output schema, the description covers purpose, return fields and cost but omits match semantics, result ordering, and how to combine name/dob/country for reliable screening. Adequate but leaves an agent guessing on invocation details.

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 baseline is 3. However the schema descriptions are placeholder-quality ('string, optional', 'number 1-100'), and the description does not explain dob matching, the type enum values, or what minScore thresholds mean in practice.

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 and resource: 'Search the EU consolidated financial sanctions list for a person or organisation'. The EU qualifier implicitly separates it from ofac_check, uk_sanctions_check and un_sanctions_check, though it never names those siblings explicitly.

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?

'For EU counterparties and EU trade' gives a positive usage context, but there is no when-not guidance and no explicit routing to the sibling sanctions tools (uk_sanctions_check, un_sanctions_check, sanctions_screen) for other jurisdictions.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-schema information: the exact list coverage (SDN plus Consolidated non-SDN) and a cost of 3 credits. It does not describe result behavior (match scores, false positives, pagination), leaving some behavioral ground uncovered.

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?

Two sentences plus a parenthetical cost, front-loaded with the resource before the use cases. Very little waste, though 'any OFAC compliance check' is a slightly vague catch-all that adds less than the cost note.

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?

For a 6-parameter screening tool with no output schema, the description is adequate on identity and cost but thin on results: nothing about what a hit looks like, how minScore filters matches, or whether results are ranked. An agent can call it correctly but cannot anticipate the response shape.

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 schema carries the parameter documentation and 3 is the baseline. The description only loosely maps 'person, company or ship' onto the type parameter and says nothing about minScore thresholds, dob matching, or limit behavior that the schema names but does not explain.

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 and resource ('Search the US Treasury OFAC sanctions lists (SDN and Consolidated non-SDN)') and the covered subject types (person, company, ship), which implicitly separates it from the EU/UK/UN sanctions siblings. It never explicitly names those alternatives, so the differentiation is inferable rather than stated.

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 concrete when-to-use triggers ('US-dollar payments, US counterparties and any OFAC compliance check'), which is more than most definitions offer. It stops short of when-not-to-use guidance, e.g. deferring to eu_sanctions_check or un_sanctions_check for non-US exposure, or explaining when sanctions_screen is the better entry point.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds meaningful context beyond that: list coverage, handling of trading names and aliases, and a cost of 3 credits. It still omits result semantics such as match/no-match behavior and how minScore affects output.

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?

Two compact sentences: purpose and list scope are front-loaded, followed by use cases and cost. Every sentence carries useful information with 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?

For a four-parameter sanctions tool with no output schema and many overlapping siblings, the description leaves important invocation details implicit. It does not clarify whether all four lists are queried together, what country filters on, what limit controls, or what minScore means.

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. The description clarifies that the name input can include trading names and aliases, but it does not explain the meaning of country, limit, or minScore beyond the schema's terse type/range notes.

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 ('Check') and resource ('COMPANY or organisation') and enumerates the sanctions lists, so the agent can identify it as company sanctions screening. It does not explicitly distinguish this tool from sibling single-list tools such as ofac_check, uk_sanctions_check, eu_sanctions_check, or from sanctions_check_person.

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?

Provides useful context with 'supplier and customer due diligence and approving payments to businesses', which implies when to use it. However, it gives no when-not guidance, prerequisites, or instruction on choosing between this and the many overlapping sanctions-check siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-schema context in the credit cost (3 credits) and the note that DOB/nationality improve match confidence, hinting at fuzzy matching. It says nothing about what a result payload contains (match/no-match, scores) or how false positives are reported, which matters for a screening tool.

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?

Three short sentences: capability first, refinement advice second, use cases third, with cost in parentheses. Every sentence carries distinct information and the most important fact is front-loaded.

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 should ideally say what comes back and how minScore/limit govern results. It covers what the tool does, when to use it, and how to sharpen a match, and annotations cover safety, but the result shape and the two numeric controls remain unexplained for a 5-parameter tool.

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. The description adds real meaning for dob and country by explaining they are match-confidence inputs rather than filters. However, limit and minScore are never explained anywhere beyond bare type/range notes, and minScore is the parameter most likely to change results materially — that gap keeps it at baseline.

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 and resource ('Check whether a named PERSON is on the UK, US (OFAC), EU or UN sanctions lists') and explicitly enumerates the four list sources, which distinguishes it from the single-jurisdiction siblings (ofac_check, eu_sanctions_check, uk_sanctions_check, un_sanctions_check) and from the entity-type siblings (sanctions_check_company, sanctions_check_ship). The capitalized PERSON makes the entity scope 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 concrete when-to-use framing: onboarding a customer, vetting a director or shareholder, approving a payment to an individual. It also advises adding DOB/nationality to firm up or rule out a match. It never names an alternative tool or an explicit when-not-to-use condition, so it stops short of full routing guidance.

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

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

The annotations already declare read-only, idempotent, non-destructive and open-world behavior. The description adds useful cost information (3 credits), but it does not explain match scoring, result interpretation, or how limit and minScore affect behavior.

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?

Two sentences, front-loaded with the core purpose and identifiers. Every element, including the cost note, earns its place.

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?

For a three-parameter read-only sanctions check, the description supplies the key context: covered jurisdictions, identifier forms, use cases, and cost. It remains slightly incomplete around minScore/limit behavior and result interpretation, but the annotations and schema cover much of the rest.

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 schema already documents all three parameters. The description adds meaning by saying name can be a vessel name, former name, or 7-digit IMO number, but it does not clarify limit or minScore beyond their schema ranges.

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 description uses a specific verb/resource combination: checking whether a ship or vessel is sanctioned. It names the jurisdictions covered and the identifier forms, making it clearly distinguishable from person/company sanctions siblings.

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?

It explicitly lists suitable contexts: shipping, chartering, freight and maritime insurance checks. It does not name alternatives such as sanctions_check_company or sanctions_check_person, nor does it state when not to use this tool.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: fuzzy matching tolerates transliteration and spelling variants, dob and country re-rank but 'never hide a name match', the response contains the listed record, why it matched, and which lists were checked, and it discloses a 3-credit cost. That is exactly the behavioral context an agent needs before calling a screening service.

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-loaded with the action and coverage, then matching behavior, then exclusions, then cost — a sensible order with no filler sentences. It is dense and slightly run-on (multiple clauses separated by semicolons), but every sentence carries information.

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 takes on the burden of describing returns ('the listed record, why it matched and which lists were checked') and does so. Combined with the stated list coverage, PEP exclusion, matching tolerance and cost, an agent has everything needed to call this correctly for a 7-parameter tool.

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 schema already documents all seven parameters including lists, minScore, limit and the IMO-number option for name. The description adds only the re-ranking semantics of dob and country and the fuzzy-name behavior; it says nothing about how minScore or lists interact with results, so it stays at the baseline.

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 and resource: 'Screen a person, company or ship by name' against four named sanctions regimes 'in one call'. The multi-list scope implicitly separates it from the single-regime siblings (ofac_check, uk_sanctions_check, eu_sanctions_check, un_sanctions_check), but it never names those siblings or the typed variants (sanctions_check_person/company/ship), so the differentiation is inferable rather than explicit.

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?

'Use for supplier, customer and payment screening' gives a concrete when-to-use context, and 'does not cover politically exposed persons (PEPs)' gives an explicit exclusion. It stops short of naming an alternative tool for PEP or for single-regime lookups, so the agent must infer routing to the per-list siblings.

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

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

Annotations already establish readOnly, idempotent, openWorld and non-destructive behavior, so the description's main added value is the operational cost disclosure ('cost: 3 credits'), which helps an agent budget calls. It still omits whether authorization is required, whether results are fuzzy-matched or exact, and any rate 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?

Two compact sentences, front-loaded with the action and data source, and the cost note is parenthetical rather than buried. Minor redundancy in repeating 'UK' three times and the trailing audience clause could be trimmed without loss.

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 usefully previews the returned fields (regime, measures, designation date) and the entity types covered, which is enough to call it correctly. It stops short of describing result ordering, how matches are scored, or what an empty result means for a six-parameter screening tool.

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 all six parameters are already documented in the schema; baseline 3 applies. The description reinforces the type dimension by naming 'person, company or ship', but says nothing about dob, country, limit, or how minScore affects matching, so it adds little beyond the 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 and resource ('Search the UK Sanctions List') plus what the results carry (regime, measures such as asset freeze or travel ban, designation date). The 'UK' qualifier and FCDO/OFSI attribution implicitly distinguish it from eu_sanctions_check, un_sanctions_check and ofac_check, but it never names those siblings explicitly.

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 clause 'For UK firms meeting their UK sanctions obligations' gives a usage context, so the agent knows this is a compliance-screening call. However, it offers no when-not guidance and no routing among the crowded sibling set (sanctions_screen, sanctions_check_person/company/ship, eu/un/ofac checks), leaving selection to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile needs no restatement. The description does add one genuinely useful behavioral fact not in the annotations: the call costs 3 credits. It says nothing about matching behavior, false-positive handling, or whether a 'no match' result is authoritative.

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?

Two short sentences: the scope and covered regimes are front-loaded and the cost tag is appended compactly. No filler or repetition of the title.

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?

For a 6-parameter screening tool with no output schema and only formal (non-informative) parameter descriptions, the definition leaves the agent guessing at return shape and match semantics (scores, thresholds, pagination via limit). It is adequate to trigger the call correctly, but not to interpret or tune it.

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 those schema descriptions are nearly vacuous ('string, optional', 'number 1-100', 'person|entity|any'). The description adds no meaning beyond them, notably omitting what minScore controls (fuzzy-match threshold) and how name/dob/country combine to produce a match.

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 ('Search') and resource ('UN Security Council consolidated sanctions list'), and enumerates the covered regimes (ISIL/Al-Qaida, Taliban, DPRK, Iran-related), which naturally separates it from siblings like eu_sanctions_check, uk_sanctions_check and ofac_check. It does not, however, clarify how it relates to overlapping generic siblings such as sanctions_screen or sanctions_check_person, leaving the jurisdictional routing implicit.

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?

Usage is only implied by the resource named: an agent can infer this is a UN-list screening call. There is no explicit guidance on when to prefer it over eu_sanctions_check/uk_sanctions_check/ofac_check, nor whether it should be combined with them for full coverage, and no statement about prerequisites or when not to use it.

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