Compliance Check

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

Even though annotations already mark the tool as readOnly, idempotent, and non-destructive, the description adds valuable behavioral context: preview mode sends nothing, changes no state, is free, runs in ~15ms, re-evaluates at send time, and can cite the exact blocking rule and remediation. It also discloses that legal=true is not a permanent guarantee. This goes well beyond the annotations without contradicting 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 longer than average but well structured with example queries, when-to-use, when-not-to-use, cost, and latency. The first sentence is a crisp, front-loaded summary. The example queries are slightly verbose and reference check_booking_link, which is not in the sibling list, but the overall structure makes the information easy to scan and use.

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, but the description explains what the tool returns: whether the send would be permitted and, if not, the exact rule and remediation. It also mentions a 'legal=true' outcome, which implies the response shape. Combined with cost, latency, edge cases, and exclusions, the description is sufficient for an agent to invoke the tool correctly in context.

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 adds value by showing a full example call mapping recipient_id, content, channel, message_type, and country_code to the tool's inputs, and by explaining that the gate evaluates the (recipient, channel, message_type, content) combination. It does not deeply re-explain each parameter, but the schema already does that.

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: 'pre-flight for the compliance gate.' It clearly names the exact regulations (TCPA/GDPR/CASL/CAN-SPAM/10DLC), states that it runs the same gate as send_message and call_business in preview mode, and explicitly says no message is sent and no state changes occur. This fully distinguishes it from the messaging tools and from sibling tools like get_status or preview_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?

The description contains explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections. It instructs calling this tool immediately before send_message or call_business for regulated sends, and it clearly lists exclusions: not a permanent license, not for voice recording consent, and not a substitute for send_message. This gives the agent unambiguous decision rules.

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 read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: free/no key required, ~50ms latency, and the constraint that only completed operations yield a result. This is good supplementary transparency, though it does not detail failure modes or response shape.

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 tightly organized into purpose, when-to-use, when-not-to-use, cost, and latency sections. Every sentence adds useful information, and the primary action is front-loaded with no fluff.

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-only tool, the description covers purpose, usage conditions, cost, latency, and what the result contains (cost and reason codes). It does not explicitly state where the operation_id comes from or describe error behavior, but the get_status reference largely covers the provenance.

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%, and the description does not explicitly define operation_id or its format. However, it provides implicit context by saying the tool is used after get_status, which lets the agent infer that operation_id identifies the operation whose status was checked. This is minimal but usable guidance for a single obvious parameter.

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: 'Retrieve the final OutcomeReceipt for a completed operation.' It clearly scopes the tool to completed operations and distinguishes it from get_status by saying it is used after get_status reports 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 sections are provided, including the exact condition ('after get_status returns success/failure/partial') and the alternative tool to use instead for pending/executing states. This leaves no ambiguity about sequencing.

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 description correctly does not repeat them. It adds valuable behavioral context beyond annotations: cost is free with no key required, latency is ~50ms, and a rate limit of one poll per 10s to avoid over-polling. This helps an agent call the tool appropriately.

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 concise and well-structured: a front-loaded one-line core statement followed by short WHEN TO USE/WHEN NOT TO USE sections and cost/latency notes. Every sentence adds value with no redundant phrasing.

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 polling tool, the description covers purpose, usage guidance, exclusions, cost, and latency, while annotations cover safety. The only minor gap is the absence of detail about the response format or possible status values, but 'current state' and 'check progress' sufficiently convey what is returned.

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 0%, so the description must compensate. It links operation_id to 'any in-flight async operation' and 'pending_async operation', adding some contextual meaning beyond the raw parameter name. However, it does not explain the format, origin, or constraints of operation_id, leaving the agent to infer from the name 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 states a specific verb and resource: 'Query the current state of any in-flight async operation by operation_id.' The WHEN TO USE section reinforces that it polls pending_async operations, making the tool's purpose unmistakable and distinct from siblings like get_outcome or check_compliance.

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 (poll state when no webhook callback has arrived or to check progress) and WHEN NOT TO USE (do not poll more often than once per 10 seconds; use webhook delivery for real-time updates). This clearly differentiates the polling use case from the alternative and gives actionable constraints.

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 readOnly/idempotent annotations, the description discloses critical runtime behavior: product is never checked against export-control lists, reason_code returns 'partial' rather than 'clear' in that case, tariff rates are never fabricated, and it acts as a middleman over OFAC/EU/UK data. It also adds cost and latency context, which is valuable for an agent deciding whether to call it.

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 tightly structured: core caveat first, then return contract, examples, usage boundaries, and operational facts. Every section contributes to correct selection and invocation, and the critical 'does not classify the product' warning 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?

There is no output schema, so the description carries the full burden of explaining what the tool returns. It does so explicitly with categories (a)–(e), including exact risk-level enumerations and the specific sanctions lists checked. With 5 parameters, 2 required, and no output schema, this description leaves no essential gap for an agent to call 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?

Although the schema already covers all 5 parameters, the description adds important semantic detail: product and hs_code are only echoed back, product is not classified, parties are screened against specific sanctions lists, origin_country feeds tariff guidance, and destination_country determines embargo/advisory status. Example calls demonstrate realistic parameter combinations.

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 names a specific verb and resource: it screens the destination and parties for cross-border trade restrictions. It also draws sharp boundaries, explicitly stating what it does NOT do ('IT DOES NOT CLASSIFY THE PRODUCT') and that it is 'not an export-control clearance,' which differentiates it from compliance-review siblings. The returned outputs are enumerated, so an agent can form an accurate operational picture.

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 tool has explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections. It directs use as a pre-flight check before quoting, invoicing, or shipping internationally, and prohibits use as a substitute for licensed export compliance review or for authoritative tariff rates. This gives clear decision criteria and boundaries.

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 read-only/idempotent annotations, the description adds behavior: exact price vs min/max range depending on channel/outcome, no accuracy promise, and free/no key required. It also gives latency and caching expectations, aligning with and enriching 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 with purpose, examples, usage, and cost/latency metadata. Every section adds value and the main purpose is front-loaded; no fluff or 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?

Despite the lack of an output schema, the description explains the return shape (fixed cost vs range) and warns about accuracy, plus gives latency and cost. It is nearly complete, though it doesn't address error behavior for unknown operations or invalid params.

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 documents params as the same request body but leaves operation undescribed, giving 50% coverage. The description compensates with concrete examples mapping operations (send_message, schedule_appointment) to params, clarifying the relationship, though it doesn't enumerate all valid operations.

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 it returns expected cost, latency, and success-probability estimates for a proposed call before execution, with a specific verb and resource. It is unambiguous but does not explicitly differentiate from sibling tools; however the function is distinct from compliance/status 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?

There are explicit WHEN TO USE and WHEN NOT TO USE sections, including budget-constraint context and hot-loop caching guidance. It does not name alternative tools, but no sibling appears to offer the same pre-execution estimation capability.

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 (readOnlyHint, idempotentHint, destructiveHint false), the description discloses partial-screening semantics, reason_code 'partial_screening', lists_screened vs sources_unavailable, branch-on-screening_status guidance, and the guarantee not to fabricate hits. It also reveals it is a live API with quota and ~2000ms latency.

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 organized with clear sections and front-loaded caveats. Some repetition exists between the prose and the COST section, but every major section earns its place given the tool's behavioral complexity.

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 compensates by spelling out all return signals: screening_status values, matched, match fields, lists_screened, sources_unavailable, and reason_code. It also covers failure behavior, cost, latency, and exclusions, so an agent has enough to 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 coverage is 100%, so the schema already documents name, type, and country. The description adds value by showing concrete call examples for each query type and by clarifying that country annotates/ranks matches rather than filtering them.

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 screening of a name or entity against official sanctions lists,' and then narrows the scope to OFAC SDN, EU, and UK lists while explicitly excluding the UN list. This clearly distinguishes the tool from generic compliance checks.

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?

Dedicated WHEN TO USE and WHEN NOT TO USE sections state exactly when the tool fits (onboarding, payments, vendor due diligence) and when it does not (KYC/AML, PEP, adverse media, credit risk, bulk screening). The example user queries also show how to route natural-language requests to 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?

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.