Sanctions Screening

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes well beyond them: it states no message is sent, no state changes occur, the check is free and ~15ms, the gate re-runs at send time so results are not permanent, and it discloses the compliance_receipt with offline verification. This adds rich behavioral context without contradicting any annotation.

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?

Although long, the description is well-structured with bolded sections (WHEN TO USE, WHEN NOT TO USE, COST, LATENCY) and front-loads the essential purpose in the first two sentences. The example queries and receipt details are substantive and earn their place given the tool's compliance-audit use case. Every section adds operational value.

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 complex tool with no output schema, the description covers invocation context, behavior, cost, latency, exclusions, examples, and the nature of the returned receipt. An agent has everything needed to decide when to call it, what parameters to provide, and what outcome to expect.

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%, but the description adds meaningful parameter semantics: examples show how recipient_id, content, channel, message_type, and country_code map to concrete calls; it explains auto-inference of channel and country_code; it notes message_type defaults to transactional and that marketing triggers consent checks. This is far more than the schema alone provides.

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 opens with a specific verb-resource pair ('pre-flight for the compliance gate') and immediately clarifies the core behavior: it runs the same regulatory gate as send_message and call_business in preview mode, with no send and no state changes. It clearly distinguishes itself from the send tools and from sibling tools like screen_sanctions by focusing on the exact same gate used for sends.

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?

There is an explicit 'WHEN TO USE' section that says to call it immediately before send_message or call_business in regulated scenarios, plus a 'WHEN NOT TO USE' section that warns against treating legal=true as permanent, using it for voice recording consent, or substituting it for send_message. This is exceptionally clear 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?

Annotations already mark readOnly/idempotent/non-destructive; description adds the required call sequence, what the response contains (cost and reason codes), that no API key is required, and approximate latency. No contradiction with annotations.

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?

Uses a compact one-line summary plus short labeled sections. Every sentence carries distinct guidance; no filler or redundant restatement.

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 one-parameter read-only retrieval, it fully covers when to call, when not to, what the result includes, and cost/latency. Sibling tools are addressed by the get_status distinction; no output schema exists so the description of cost and reason codes is useful.

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 has only operation_id, required, string, with 0% description coverage. The description compensates somewhat by placing the ID within the operation lifecycle: it is the operation whose final receipt is being retrieved after status check. It does not define ID format or how to obtain it, but the low ambiguity of a single id parameter makes this adequate.

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 ('Retrieve') and a specific resource ('final OutcomeReceipt for a completed operation'). It also names the lifecycle condition ('completed') and differentiates the return artifact from a mere status, which helps distinguish from get_status.

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?

Explicit WHEN TO USE and WHEN NOT TO USE blocks. It tells the agent to call after get_status returns success/failure/partial and explicitly tells it not to call for pending/executing operations, naming get_status as the alternative.

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, and destructiveHint, so the safety profile is covered. The description adds valuable operational behavior beyond annotations: ~50ms latency, no API key required, and a 10-second polling restriction, which are genuinely useful for agent invocation.

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?

The description is well-structured and front-loaded: purpose first, then usage guidance, then cost and latency. There is no filler, and every line contributes actionable 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?

For a simple one-parameter polling tool, the description covers purpose, when to use it, when not to use it, rate limits, authentication requirements, and performance expectations. The main gap is the lack of return-state details, but the safety profile is already captured by annotations.

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 0%, so the description carries the burden of explaining operation_id. It only names the parameter in passing ('by operation_id') without describing its format, where to obtain it, or any constraints; this does not significantly add meaning beyond the schema's property name.

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 states a specific action: 'Query the current state of any in-flight async operation by operation_id,' which clearly identifies the resource and the identifier. It does not explicitly differentiate itself from sibling get_outcome, but the wording is specific enough to avoid major ambiguity.

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 has explicit WHEN TO USE and WHEN NOT TO USE sections. It tells the agent to poll pending_async operations when no webhook has arrived or when progress needs checking, and explicitly warns against polling more than once per 10 seconds, directing real-time use to webhook delivery instead.

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 description goes well beyond the read-only/idempotent annotations by revealing non-obvious behavior: a controlled item to an unrestricted destination returns reason_code 'partial' and never 'clear.' It also states that the product argument is only recorded and echoed back, never checked, and that tariff rates are never fabricated. Additional operational details like the 20-party hard refusal, free quota, and ~3000ms latency add valuable transparency.

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?

The description is long but every section earns its place: the core limitation is front-loaded in caps, return content is enumerated as (a)-(e), and usage guidance is separated into clear WHEN TO USE and WHEN NOT TO USE blocks. The example queries are compact and directly illustrate valid input combinations. Despite its length, the structure makes it easy to scan.

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?

Even without an output schema, the description enumerates the five categories of returned information, names the exact sanctions lists screened, lists covered destinations, and explicitly warns about limitations such as non-fabricated tariffs and lack of product classification. It also covers cost, latency, and hard constraints on parameters. An agent has enough context to select and call this tool correctly in realistic trade scenarios.

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 input schema already documents all parameters well. The description still adds meaningful semantic context, especially for product: 'the product argument is recorded and echoed back, never checked against any export-control list.' It also provides realistic example calls showing how product, destination_country, hs_code, origin_country, and parties combine, which helps an agent understand parameter roles beyond the schema alone.

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 opens with a specific action and resource: 'Free cross-border trade screening of the DESTINATION and the PARTIES.' It immediately clarifies what the tool does not do, 'IT DOES NOT CLASSIFY THE PRODUCT,' and explicitly says, 'This is not an export-control clearance,' which helps distinguish it from related compliance tools. The scope is unambiguous and grounded in concrete examples.

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 contains dedicated 'WHEN TO USE' and 'WHEN NOT TO USE' sections, including a clear pre-flight use case: 'Call this as a pre-flight check before quoting, invoicing, or shipping internationally.' It also gives exclusions such as 'Do NOT use as a substitute for a licensed export compliance review' and 'Do NOT use for purely domestic shipments.' This provides explicit guidance on both when and when not to invoke the 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 mark the tool read-only/idempotent/non-destructive, and the description adds what the tool returns (exact price vs. min/max range), the cost_range caveat, and free/no-key plus ~100ms latency. This is meaningful behavioral context beyond the structured annotations, and nothing contradicts them.

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?

The description is front-loaded with a one-sentence purpose, then uses labeled sections (examples, when to use/not use, cost, latency) so an agent can scan efficiently. Each section carries distinct information and there is no redundancy.

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 simple, well-annotated, two-parameter preview tool without an output schema, the description supplies return behavior, caveats, examples, cost, and latency. The only minor absence is a formal definition of supported operation names, but the examples and 'same request body' instruction make it sufficient.

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?

With only 50% schema coverage (params described, operation not), the description compensates with two fully worked invocation examples using 'send_message' and 'schedule_appointment' with preferred_channel. It clarifies that params are the same request body as the operation, but it does not enumerate valid operation names or per-operation required fields, so compensation is good but not exhaustive.

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 first sentence identifies a specific action ('Return... estimate') for a specific object ('a proposed call before execution'), and the exact-price vs. min/max range detail makes the tool's function unmistakable. No sibling tool (check_compliance, get_outcome, get_status, etc.) appears to overlap with cost estimation, so it is clearly differentiated.

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?

Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections condition the tool on budget constraints and advise caching to avoid hot-loop abuse. Example user queries map natural language to concrete tool calls, making selection unambiguous. No alternative tool is cited because none of the siblings address cost preview.

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 description goes well beyond annotations: it discloses that the UN list is intentionally excluded for licensing reasons, instructs checking lists_screened and sources_unavailable, explains reason_code='partial_screening', and warns that screening_status—not matched—must be branched on because matched:false also occurs when nothing could be screened. It also details the compliance_receipt and states that matches/clears are never fabricated. These behaviors are not visible from readOnlyHint or idempotentHint, and there is no contradiction with annotations.

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?

The description is long but well-structured with sections for purpose, caveats, return behavior, examples, when/not-to-use, cost, and latency. Every sentence serves a purpose; there is no filler. The four example queries are slightly repetitive but pragmatically useful, which prevents a perfect 5 given the overall length.

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?

Without an output schema, the description compensates by enumerating all returned fields (screening_status, matched, matches with score/program/source URL, lists_screened, sources_unavailable, compliance_receipt) and explaining failure semantics. It also covers the partial-screening reason_code, the instruction to branch on screening_status, and offline verifiability of the receipt. Combined with the detailed input schema, nothing essential is missing for correct invocation.

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% and the schema already documents all three parameters thoroughly, including the critical behavior of country (annotates/ranks results, never removes them). The description adds example queries and framing for country_match, but it mostly relies on the schema to carry parameter meaning. Per the baseline rule for high schema coverage, a 3 is appropriate.

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 opens with 'Free screening of a name or entity against official sanctions lists' and enumerates specific lists (OFAC SDN, EU consolidated, UK Sanctions List). It names the resource precisely, the action clearly, and distinguishes itself from broader compliance by stating it covers sanctions only. It is not a tautology and differentiates from siblings like check_compliance by scope.

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 'WHEN TO USE' section lists concrete scenarios (onboarding, payment, vendor engagement, due-diligence) and the 'WHEN NOT TO USE' section gives exclusions (not a KYC/AML substitute, no PEP/adverse media/credit risk, no bulk screening). While it does not name sibling tools directly, it provides unambiguous conditions that let an agent decide when to apply this tool and when to avoid it.

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 indicate read-only, idempotent, and non-destructive behavior, and the description adds useful context: it runs 6 internal checks, does not probe individual tools, has ~200ms latency, and requires no key. The rate-limit caution also adds operational transparency beyond annotations.

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?

The description is well-structured with clear sections, front-loads the core purpose, and every part adds value. It is slightly longer than minimal but each section earns its place with operational guidance.

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?

Despite having no output schema, the description explains what the tool does, what it returns, when to use it, when not to use it, and operational characteristics. This is complete enough for an agent to select and invoke the tool 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?

The tool has zero parameters and an empty input schema, so there is little for the description to clarify. The example call self_test({}) reinforces that no arguments are needed, which is sufficient.

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 clearly states that self_test is a service health probe that runs 6 internal checks and reports how many passed. It explicitly distinguishes itself from per-tool probes, which helps an agent differentiate it from sibling health-adjacent tools.

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 explicit WHEN TO USE and WHEN NOT TO USE guidance, including startup, pre-high-stakes checks, and unexpected errors, plus a clear rate-limit warning. The example user query also demonstrates a realistic invocation scenario.

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?

Goes well beyond the readOnly and idempotent annotations by disclosing the queried registries (GLEIF and SEC EDGAR), the exact data fields returned, and the honest not_found behavior with source attribution. Cost and latency are also disclosed, and there is no contradiction with the annotations.

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?

Organized with clear sections and front-loaded with the core purpose, examples, and key constraints. The example block is slightly redundant with the WHEN TO USE text, but overall every section contributes to correct invocation and expectation-setting.

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?

Covers what the tool returns, which sources it queries, failure behavior (not_found), cost, latency, and all accepted parameter combinations. Since there is no output schema, the description's explanation of return values and not_found behavior is sufficient for an agent to invoke it 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 practical meaning through example queries (e.g., LEI for precise lookup, country to narrow GLEIF results to a jurisdiction). This enriches the schema's parameter descriptions without being redundant.

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 clearly states a specific action (verify) on a specific resource (company official registry record) and names the actual data sources (GLEIF, SEC EDGAR). It also differentiates from related uses by explicitly stating it is not a fraud-detection or KYC tool, which helps an agent distinguish it from siblings like screen_sanctions.

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 explicit WHEN TO USE scenarios (before signing a contract, qualifying a vendor, validating a counterparty, due-diligence) and WHEN NOT TO USE exclusions (private companies not registered with GLEIF/SEC, not an exhaustive fraud-detection or full KYC screen). However, it does not name a specific sibling tool as an alternative, so it falls just short of full alternative routing.

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