Compliance Check

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses meaningful runtime behavior: preview mode causes no state changes, a legal=true result is not a permanent license because the gate re-runs at send time, and the tool attaches an Ed25519-signed, offline-verifiable compliance_receipt. This clearly exceeds what annotations alone provide and does not contradict 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 long but well-structured with clear sections (purpose, examples, when to use, when not to use, cost, latency) and front-loaded with the core distinction. It repeats 'free' and 'preview/no message sent' a few times, but the complexity of the compliance gate and receipt behavior justifies most of the 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?

Despite no output schema, the description explains what the tool returns (whether the send is permitted, the exact blocking rule, remediation guidance, and a signed compliance_receipt), how to use it safely, its cost/latency, and its limitations. An agent has enough context to decide when to call it and what to do with the result.

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 explains all six parameters. The description reinforces the meaning of content, channel auto-inference, and message_type's marketing trigger, but adds little semantic detail beyond the schema; the example queries are helpful but not substantial parameter-level additions.

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 ('check'), names the resource ('the compliance gate'), and explicitly frames itself as a pre-flight preview that 'NO message is sent and NO state changes.' It distinguishes itself from send_message and call_business by naming them as the tools whose gate it shares while remaining read-only.

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 a dedicated 'WHEN TO USE' section specifying concrete triggers (marketing, SMS to US numbers, EU/UK/CAN recipients, uncertain content) and a 'WHEN NOT TO USE' section naming exclusions like two-party voice recording consent. It also gives an explicit alternative chain: check first, then send_message if legal=true.

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 cover readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond this: the response includes cost and reason codes, the operation must be completed, and it is free with ~50ms latency. This enriches the agent's understanding of what calling this tool entails.

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 compact and well-structured: purpose first, then explicit usage guidance, then cost and latency. Every sentence adds value and none is redundant with the schema or annotations.

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 read tool with annotations covering safety, the description is nearly complete. It covers preconditions, sequencing, expected content (cost and reason codes), and performance characteristics. Minor gap: it doesn't elaborate on the OutcomeReceipt structure, but no output schema exists and the mention of cost and reason codes provides enough orientation.

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 schema provides zero description for operation_id. The description compensates by linking it to a completed operation from get_status, implying the ID comes from that prior call. Though it doesn't name the parameter explicitly, the context makes the parameter's role clear enough for correct invocation.

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 the tool retrieves the final OutcomeReceipt for a completed operation, with a specific verb and resource. It distinguishes itself from get_status by focusing on the full result rather than the status, so an agent can immediately tell what this tool does.

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 explicitly says when to use (after get_status returns success/failure/partial) and when not to use (pending/executing state), and names the alternative (get_status). This leaves no ambiguity about sequencing or conditions.

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=true, idempotentHint=true, and destructiveHint=false, so the description is not required to re-state those. It adds useful behavioral context beyond annotations: polling cadence guidance, approximate latency, and cost/auth expectations. No contradictions 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?

The description is well-structured, front-loaded with the core purpose, and uses clear WHEN TO USE / WHEN NOT TO USE sections. Every sentence adds actionable information for call selection or invocation, including cost and latency data.

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 the core purpose, usage policy, and operational constraints. The main gap is that there is no output schema and the description does not describe the response shape or status values, but the agent has enough to invoke the tool correctly and interpret that it returns current state.

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 does identify operation_id as the identifier of the in-flight async operation, which gives basic semantics, but it does not explain the format, provenance, or expected values (e.g., how the operation_id is obtained).

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 identifies the verb ('Query') and resource ('the current state of any in-flight async operation'), keyed by operation_id. This is specific enough for an agent to understand exactly what the tool does and to distinguish it from sibling tools like get_outcome.

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 explicitly states when to use the tool (poll pending_async when no webhook arrived, check progress) and when not to use it (polling more than once per 10 seconds, using webhook for real-time updates). This gives the agent clear decision criteria and mentions the preferred 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 mark the tool read-only and idempotent, and the description adds substantial behavioral context beyond that: the product parameter is only echoed, never checked; the tool never fabricates tariffs, clears, or restricted statuses; >20 parties triggers bad_input; and it unifies OFAC, EU, and UK lists. It also discloses cost and 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?

The description is long, but every section (caveat, examples, when to use/not, cost/latency) earns its place and the critical limitation is front-loaded in uppercase. Minor redundancy in repeated 'never fabricates/not clearance' phrasing keeps it from a 5.

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 still enumerates the five categories of returned information, specifies the three sanctions-list sources, states the 20-party limit and bad_input behavior, and gives usage examples plus operational cost/latency. For a 5-parameter tool with no output schema, this is complete enough for an agent to call 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. The description earns a point above baseline by clarifying the product parameter's actual role (recorded and echoed, never checked against an export-control list), which the schema does not convey, and by showing realistic parameter combinations via example queries.

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 pairing ('screening of the DESTINATION and the PARTIES') and immediately states the critical scope boundary: it does not classify the product and is not an export-control clearance. It also clarifies that controlled items to unrestricted destinations yield reason_code 'partial', which distinguishes this from both general compliance tools and party-only screening. This is more than enough to tell it apart from its siblings without opening schemas.

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 tell the agent to invoke before cross-border trade as a pre-flight check and explicitly exclude use as a licensed compliance review, for authoritative tariff rates, or for domestic shipments. No inference is required.

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=true, idempotentHint=true, and destructiveHint=false, and the description is fully consistent with these. Beyond that, it discloses substantial extra behavior: the exact-vs-range return pattern, the explicit accuracy caveat ('does not promise an accuracy percentage - check cost_range'), the ~100ms latency, the free/no-key requirement, and the 60-second caching recommendation. This is rich behavioral context the annotations do not carry.

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 longer than average but tightly structured with labeled sections: core behavior, examples, WHEN TO USE, WHEN NOT TO USE, COST, LATENCY. Core behavior is front-loaded in the first sentence, and every section carries functional information. The two examples are slightly redundant with each other but still earn their place by demonstrating parameter usage.

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 carries the burden of conveying return values, and it does: cost, latency, and success-probability estimates, plus the cost_range field and exact-vs-range distinction. Operational traits (free, latency, caching) are included. Minor gap: no edge-case behavior described, such as handling of unknown operation names, but for a two-parameter preview tool the essentials are all present.

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 50% (the 'params' field is described but 'operation' is not), so the description must compensate. The two worked examples do exactly that, showing the JSON structure with concrete values like preview_cost({"operation": "send_message", "params": {"preferred_channel": "sms"}}). This clarifies that 'params' mirrors the operation's request body and demonstrates realistic values, adding meaning well beyond the bare 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?

The description states a specific verb and resource: 'Return an expected cost estimate, latency estimate, and success-probability estimate for a proposed call before execution.' It clearly explains the exact-price vs min/max-range behavior. The 'before execution' qualifier cleanly separates it from the sibling tools, which all concern compliance, status, and verification rather than cost.

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 guidance is given: before any operation when operating under a budget constraint and needing to decide whether to proceed. WHEN NOT TO USE excludes hot loops and mandates 60-second caching. No specific alternative sibling is named, but none of the siblings (check_compliance, get_outcome, screen_sanctions, etc.) is a cost-estimation tool, so no routing alternative exists to cite.

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. On top of that, the description discloses crucial behavioral traits: lists can fail to load and appear in sources_unavailable, reason_code becomes 'partial_screening', it never fabricates matches or clears, and it attaches an Ed25519-signed compliance_receipt. This materially exceeds what annotations provide.

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 clear headings (WHEN TO USE, WHEN NOT TO USE, COST, LATENCY) and front-loaded purpose. Example queries are useful for an agent. The COST and LATENCY lines are tangential to invocation correctness, and the four examples are slightly redundant, so it loses one point.

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, so the description carries full responsibility for explaining return values. It covers screening_status options, matched, match details (score, program, source URL), lists_screened, sources_unavailable, reason_code, and compliance_receipt. Complex failure modes and offline verification are fully explained, making the definition complete for an agent 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%, but the description adds vital meaning beyond the schema for the country parameter: it 'ANNOTATES AND RANKS results; it never removes any,' preventing the serious mistake of treating a non-matching country as a clean screen. No other dimension of any parameter is left unexplained.

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 the verb ('screening') and resource ('official sanctions lists'), and explicitly names the specific lists included (OFAC, EU, UK) and the one excluded (UN). This precisely distinguishes the tool from any broader or narrower sanctions-checking sibling without needing to open schemas.

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 provides explicit WHEN TO USE and WHEN NOT TO USE sections, detailing appropriate scenarios (onboarding, payments, due diligence) and exclusions (not a full KYC/AML substitute, not for PEP/adverse media/credit risk, not for bulk screening). It does not name a specific sibling tool as an alternative, so it falls just short of a 5.

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?

Beyond the annotations, the description discloses latency (~200ms), cost (free, no key required), the number of checks performed, and the fact that it does not probe individual tools. These details add meaningful behavioral context beyond the readOnly/idempotent hints.

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 included section adds value: example, when to use, when not to use, cost, and latency. It is thorough without being bloated.

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 zero-parameter, read-only health check with no output schema, the description is complete: it states what it does, what it returns ('reports how many passed'), when to use it, when not to use it, and expected performance characteristics. Nothing critical is missing.

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 the input schema is already fully specified as empty, so there is little for the description to add. The example 'call self_test({})' reinforces that no arguments are needed, satisfying the baseline for a zero-parameter tool.

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 verb and resource: 'runs 6 internal checks and reports how many passed.' It also explicitly distinguishes itself from per-tool probes ('it does NOT probe each tool individually'), which helps an agent differentiate it from the sibling 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?

The description includes explicit 'WHEN TO USE' guidance: at agent startup, before high-stakes sequences, and after unexpected errors. It also provides a clear exclusion: 'Do not call more than once per minute in production,' plus a matching example user query.

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, so the bar for added behavioral context is lower but the description still adds significant value: it explicitly states 'Never fabricates' and describes the honest not_found return with queried sources. It also discloses data sources, cost, and latency, giving the agent clear expectations about behavior on failure.

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: core function, examples, WHEN TO USE, WHEN NOT TO USE, COST, LATENCY. Every section contributes unique information, and the core definition is front-loaded. No redundant or tautological content.

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 3-parameter lookup with no output schema, the description is fully complete: it specifies invocation examples, required and optional parameters, data sources, returned fields, not-found behavior, use cases, exclusions, and cost/latency. An agent has everything needed 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?

Schema description coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining the interaction of parameters: 'Accepts a legal name plus optional country filter or a direct LEI for a precise lookup,' and it includes three concrete example calls mapping user intents to parameter combinations. This adds practical semantics not present in 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 verb and resource: 'Free, live lookup of a company official registry record.' It names the exact registries queried (GLEIF and SEC EDGAR) and the returned fields (legal name, LEI, status, jurisdiction, address, registry authority). It also distinguishes the tool from sanction/compliance siblings by positioning it as first-pass existence verification, not a full KYC screen.

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' with concrete scenarios (before signing a contract, qualifying a vendor, validating a counterparty, populating due-diligence records) and 'WHEN NOT TO USE' with clear exclusions (private companies not in GLEIF/SEC, exhaustive fraud detection). These conditions are sufficient for an agent to decide between this tool and the sibling compliance/sanction tools.

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