SENTINEL Compliance Intelligence

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

Annotations already flag destructive=true and idempotent=true, but the description adds substantial context beyond them: the operation is permanent and non-resumable, the webhook URL is destroyed, later checks report 'cancelled', the MON- id is the sole credential so anyone holding it can cancel, and there is a 30 calls/minute limit. This is exactly the kind of irreversible-effect and auth disclosure the annotations cannot convey.

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 irreversible effect and its consequences are front-loaded in the first sentence, followed by alternatives, trigger condition, credential note, and rate limit. Every clause carries information, though the sentence is dense and could be broken up for faster scanning.

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 single-parameter destructive tool with an output schema (so return values need no explanation), the description covers effects, irreversibility, alternatives, credential sensitivity, and rate limits. Nothing an agent needs to invoke it correctly 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?

Schema coverage is 100% and the pattern already documents the MON- format, so the baseline would be 3. The description adds genuine semantic value by explaining that monitor_id is the only credential and that possession alone authorizes cancellation — a security-relevant property absent from 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 ('Permanently stop a watchlist monitor') and immediately enumerates the concrete effects: re-screening ends, webhook URL is deleted, status later reports cancelled. It is clearly distinguishable from the sibling create_watchlist_monitor and check_watchlist_monitors without opening either schema.

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?

Explicitly names the two alternatives and the condition selecting each: use create_watchlist_monitor to make a new monitor, use check_watchlist_monitors to read status. It also states the positive trigger ('when monitoring is no longer needed or the webhook endpoint is retired') and the exclusion that the monitor cannot be resumed.

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?

Discloses non-obvious traits beyond the annotations: a single id triggers a live re-screen and may fire a webhook, multi-id calls return cached 6-hourly statuses, unknown ids surface as not found, pricing differs by cardinality, and failed calls are not charged. This explains why readOnlyHint is false and why the call is not free, which the structured fields alone could not convey.

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?

One dense paragraph, front-loaded with purpose before branching into cardinality, alternatives, errors, and pricing. Every sentence carries information, though the payment and failure clauses could be broken out for faster scanning.

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 an output schema present, return values need no explanation, and the description covers the remaining agent-relevant unknowns: pricing, x402 payment failure mode, stale-vs-live semantics, and unknown-id handling. Nothing needed to invoke it correctly 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?

Schema coverage is 100% and the schema description already states the 1-vs-2-20 behavioral split, so the baseline would be 3. The description nonetheless adds value the schema lacks: the cost differential between one and many ids and the freshness/re-screen distinction tied to the same 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?

States a precise verb+resource ('Read the status of watchlist monitors') and immediately ties it to the create_watchlist_monitor lifecycle, so the agent can place it in the watchlist family without opening any schema.

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 routing: one id for a fresh pre-action answer, 2-20 for a periodic sweep, screen_entity/screen_wallet for entities without a monitor, cancel_watchlist_monitor to stop monitoring. This is exactly the when/when-not/alternatives structure the dimension asks for.

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 only cover the mutation/safety profile; the description adds substantial context beyond them: how the applicable threshold is chosen (EU/EEA 0, Japan ~700, FATF 1,000), the 90-day EdDSA attestation validity, that names are keyed-hashed and never returned while addresses are stored, and the $0.005 x402 payment behavior including unpaid/failed call handling.

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?

Dense but front-loaded: the core action and threshold logic lead, with storage, alternative routing, and pricing following. Parenthetical threshold and pricing sentences are information-bearing rather than filler, though the paragraph is long enough that it could be split for scanability.

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 an output schema present, the description needn't explain return fields, yet it still flags the key outputs (packetId, verification URL, signed attestation). Combined with the threshold, pricing, and storage disclosures, nothing an agent needs to invoke it correctly 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?

Schema description coverage is 100%, so the baseline is 3. The description goes further by explaining the semantics of amount_usd (determines whether travelRule.applies) and of the country parameters (they set the applicable threshold), which the schema alone does not convey.

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?

Specifies the exact verb and resource: screens originator and beneficiary of a crypto transfer and stores the result as a Travel Rule packet. It explicitly distinguishes itself from screen_wallet (quick address check) and verify_travel_rule_packet (checking a received packet), so an agent can route correctly 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?

States the triggering condition ('when a transfer needs a Travel Rule record') and names both relevant alternatives with their distinct purposes. It also notes that each call stores a new packet, which warns against redundant invocation.

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 annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false): screening cadence (every 6 hours), the status transitions that trigger a webhook (clear/review/alerted), HMAC signing, that each call creates a new monitor (justifying non-idempotency), that ids/secrets are shown once, and the full payment model ($0.010 USDC via x402, PaymentRequired on unpaid, no charge on failure). This is exactly the extra context annotations cannot 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?

Front-loaded with the purpose and behavior, then alternatives, then cost — a sensible order with no filler sentences. It is a long single block, but each clause carries distinct operational information, so length is justified by tool complexity rather than padding.

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 non-idempotent, billable, webhook-producing creation tool with a rich schema and an output schema present, the description covers everything an agent needs: cadence, trigger conditions, one-time secrets, mutation semantics, and payment failure handling. Nothing material is left to inference.

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 already 100%, so the baseline would be 3, but the description adds real meaning: it defines the wallet-vs-entity semantics of 'type', describes the webhook as an HMAC-signed public HTTPS endpoint, notes 'chain' is informational, and explains that 'label' is echoed in results and webhooks. It enriches rather than repeats 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+resource+scope ('Start 30 days of watchlist monitoring for one wallet address or one person/company name') and immediately disambiguates itself from siblings. An agent can distinguish it from screen_entity, screen_wallet and check_watchlist_monitors without opening any schema.

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?

Explicitly routes the agent: 'Use it for ongoing monitoring after onboarding; use screen_entity or screen_wallet for a one-off check, check_watchlist_monitors to read statuses, and cancel_watchlist_monitor to stop.' Both the when and the alternatives are named with the condition that selects each.

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, but the description adds material behavior beyond them: an unknown code returns found=false with risk_level unknown as a successful charged call, the price is $0.001 USDC per successful call via x402 on Base, unpaid calls yield a PaymentRequired result, and failed calls are not charged. This is exactly the billing and edge-case context an agent needs before invoking a paid 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?

The description is dense but front-loaded: purpose and returned fields first, then routing guidance, then the no-data edge case, then pricing. Every sentence carries distinct, actionable information with no restatement of the title or schema.

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 an output schema present, return values need not be spelled out, yet the description still covers the non-obvious found=false path, the cost/charging model, and routing to the sibling tool. Nothing an agent needs to select or call this tool correctly 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?

Schema coverage is 100% and the schema itself provides the ISO 3166-1 alpha-2 pattern plus examples, so the baseline is 3. The description adds the operational constraint that it takes one country code per call and that corridors must be checked end by end, which is meaningful semantics 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?

The description names a specific verb and resource ('look up one country's anti-money-laundering risk') and enumerates the exact data returned (FATF status, Basel AML Index, CPI, EU/US designations, tax-haven flag, derived risk level). It also distinguishes itself from the sibling run_due_diligence, which handles named persons/companies, so an agent can route correctly without opening either schema.

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 states concrete use cases ('assess a counterparty's country or a payment corridor') and an explicit exclusion with the alternative named ('For a named person or company use run_due_diligence, which already assesses the countries found in its hits'). It even handles the corridor edge case by telling the agent to check each end separately.

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 safety (readOnly, idempotent, non-destructive), but the description adds substantial non-obvious behavior: 10 calls/min rate limit, $0.010 USDC x402 payment with PaymentRequired on unpaid and no charge on failure, forex inclusion tied to include_forex, lists_as_of freshness reporting, and a triage-not-legal disclaimer. Matching semantics (case-insensitive substring, exact >> partial) are also disclosed.

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 core capability before caveats, alternatives, and payment mechanics, and almost every clause carries information. It is dense and long for a 2-parameter tool, but no sentence is redundant 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?

An output schema exists, so return values need no explanation. Given a low-complexity two-param tool, the description covers cost, rate limits, failure charging, matching behavior, optional-parameter effects, freshness metadata, and a disclaimer — nothing an agent needs to call it correctly 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?

Schema coverage is 100%, so the two parameters are already documented, establishing a baseline of 3. The description goes beyond the schema by explaining the matching algorithm behind 'name' (case-insensitive substrings with exact matches weighing far more, partials only reaching review level) and the country-detection condition governing include_forex.

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?

Names a specific verb (profile) and resource (one person or company) and enumerates the concrete capabilities: watchlist screening, AML country risk, Mauritius registry records, and a composite risk score. It explicitly separates itself from screen_entity and screen_cross_border_payment, so an agent can route without opening a schema.

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?

States when to use it (onboarding KYC/KYB or enhanced due diligence) and names the two alternatives with the exact conditions that select them ('when a list check is enough', 'for both parties of a payment'). This is explicit when/when-not/alternative 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 declare readOnly, idempotent and non-destructive, but the description adds substantial context beyond them: the $0.008 USDC x402 cost per successful call on Base, that unpaid calls return PaymentRequired, that failed calls are not charged, and the lists_as_of freshness signal. These are exactly the operational traits an agent cannot infer from the schema or 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?

Front-loaded with purpose and routing, then outcomes, then cost. It is dense and mostly earns its length, though the outcome-threshold sentence and the cost sentence are packed with clauses that could be trimmed without losing meaning.

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?

An output schema exists, so return structure need not be described, yet the description still conveys the decision semantics (PROCEED/REVIEW/FLAG/BLOCK and their score bands) and escalation guidance. Combined with cost and list-freshness behavior, an agent has everything needed to invoke and interpret this 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 the operational rule that setting currency_from is what triggers the Bank of Mauritius corridor rate and that currency_to defaults to MUR. That interpretation goes slightly beyond the schema text, which already mentions the corridor rate for currency_from.

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 opening sentence states a specific verb (screen), resource (both parties of a cross-border payment) and the exact inputs checked: names against watchlists, country AML risk, and the optional corridor rate. It is immediately distinguishable from screen_wallet (wallet addresses) and create_travel_rule_packet (Travel Rule record), which are named 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?

It gives the positive case ("use it for fiat or crypto payments where you have names") and two named alternatives with the conditions that select them (screen_wallet for wallet addresses only; create_travel_rule_packet for a stored, verifiable record). This leaves nothing 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?

Beyond the annotations (which only declare read-only/idempotent/non-destructive), the description discloses matching semantics (case-insensitive substring, exact vs partial labelling, partials needing human review), list freshness via lists_as_of, and the payment model ($0.002 USDC via x402, PaymentRequired on unpaid calls, no charge for failures). This is substantive behavioral context the agent could not infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph, but it is front-loaded with purpose and list coverage before the routing and pricing details. It is longer than typical, yet nearly every clause carries information an agent needs; only the pricing sentence could arguably be trimmed for brevity.

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 full schema coverage, an output schema covering return values, and annotations covering the safety profile, the description fills the remaining gaps: scope of lists, alias handling, match labelling, freshness signalling, and cost. Nothing needed to call or interpret the tool correctly 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?

Schema description coverage is 100% and all three parameters are fully documented in the schema, so the baseline is 3. The description adds no parameter-level syntax or defaults of its own; its useful detail (aliases, matching behaviour) is behavioral rather than parameter-specific.

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 (screen) and resource (a person/organisation name, including aliases) and enumerates the exact list groups covered, from sanctions and PEPs to OFAC-listed vessels. It is immediately distinguishable from siblings like run_due_diligence and screen_wallet.

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 states its own use case ('a quick list check of a name') and explicitly routes the agent elsewhere: run_due_diligence for a scored profile, search_mauritius_registry for Mauritius licences/offshore/local PEPs, and screen_wallet for blockchain addresses. When-to-use and alternatives are both explicit.

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/destructive annotations, it discloses matching semantics (exact, case-insensitive on the full address), the negative scope of a 'clear' result (counterparties not covered), freshness signaling via lists_as_of, and the full payment profile: $0.001 USDC ($0.003 with owner_name) via x402 on Base, PaymentRequired on unpaid calls, and no charge for failures. This is exactly the context annotations cannot 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?

Front-loaded with purpose and list coverage, and every clause carries information (routing, matching semantics, pricing, failure behavior). It is dense in a single block; light structural separation of routing vs. semantics vs. billing would improve scannability, but nothing is wasted.

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?

Given an output schema exists, the description does not need to detail return fields, yet it still names the composite risk levels and lists_as_of. Combined with the safety annotations, the payment mechanics, and the explicit sibling routing, an agent has everything needed to call this correctly and interpret a 'clear' result honestly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: owner_name 'screens the owner's name and returns a composite risk (critical when the address is listed, elevated when only the name matched)' and doubles the cost. The address parameter's matching rule (exact, case-insensitive, full address) is also clarified beyond the regex.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (screen) and resource (blockchain wallet address) and enumerates the concrete list sources checked (OFAC SDN, OpenSanctions, UK, Circle USDC, Tether USDT, Ransomwhere). It explicitly distinguishes itself from screen_entity, create_travel_rule_packet, and verify_agent_identity, so an agent can route without opening sibling 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?

Gives a clear when-to-use ('before sending or accepting funds'), a conditional variant (owner_name for combined name screening), and names three alternatives with the exact condition that selects each ('for names alone use screen_entity', 'for a Travel Rule record create_travel_rule_packet', 'for an EVM agent's on-chain reputation verify_agent_identity'). Nothing is left 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, yet the description adds substantial context beyond them: case-insensitive substring matching semantics, the lists_as_of freshness signal, and the x402 payment model ($0.005 USDC per successful call, PaymentRequired on unpaid, no charge for failures). It also cautions that offshore/adverse-media hits are leads, not proof of wrongdoing.

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 purpose and routing before behavioral detail. Every sentence earns its place, though the inline enumeration of five category meanings in a single sentence makes it dense and slightly long.

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?

Complete: an output schema exists so return values need no explanation, and the description still notes the lists_as_of freshness field. Cost, matching semantics, category meanings, and sibling routing are all covered.

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% (baseline 3), but the description goes further by defining what each enum value means (fsc_licensee, licensed_entity, offshore_entity, pep, adverse_media) and stating that omitting category searches all — information the schema's terse 'Optional record type filter' does not convey.

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 (Mauritius-specific records), then enumerates exactly what record types are covered by each category value. An agent can distinguish this from screen_entity and run_due_diligence without opening any schema.

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?

Explicitly gives when-to-use ('Mauritius counterparties or to confirm a licence') and names two alternatives with their distinguishing conditions: screen_entity for global sanctions/watchlists and run_due_diligence to combine both with a risk score.

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 the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds operationally important context beyond them: a 60 calls/minute client rate limit, live public-blockchain reads that take several seconds, and the caveat that results change as the wallet transacts. This is exactly the extra context annotations cannot express.

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?

One dense paragraph that front-loads the operation and its outputs before usage, exclusions, and operational caveats. Every clause carries information, though the long output enumeration makes it a slightly heavy read compared with a tighter split into purpose/usage sentences.

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 tool with full schema coverage, annotations covering safety, and an output schema handling return values, the description covers purpose, routing, latency, rate limits, and data volatility. Nothing an agent needs in order to call it correctly 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?

Schema coverage is 100% and the single parameter is fully documented with its regex pattern, so the baseline is 3. The description adds real meaning by constraining the address to an EVM 0x wallet and by naming the sibling to use for non-EVM chains, which the schema pattern alone only implies.

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+resource ('Run a Know-Your-Agent check on an AI agent's EVM wallet') and enumerates the exact outputs: registry lookup, sanctions screening, on-chain behaviour, risk score bands, and a signed VC plus Merkle proof. It explicitly distinguishes itself from the sibling screen_wallet, so an agent can route correctly without opening either schema.

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 gives an explicit trigger ('before paying, hiring or accepting payment from an autonomous agent') and an explicit exclusion with an alternative ('for an address on another chain, or a list-only check, use screen_wallet'). Both the when and the when-not are stated.

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 the safety profile (readOnly, idempotent, non-destructive), yet the description adds real context beyond them: privacy behavior (names compared but reported only as true/false, never revealed), a 60 calls/minute rate limit, that it is free, and the not-found error for unknown packet_id.

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 outcome, then inputs, then usage routing, then operational constraints. Efficient overall, though 'Free, no payment needed' partially duplicates the title's '(Free)'.

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?

An output schema exists so return values need not be explained, yet the description still summarizes them. Combined with usage routing, privacy behavior, and rate limits, nothing an agent needs to call this correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds semantic meaning beyond the schema: it explains that the optional name/address params are compared against screened values and returned only as match true/false, clarifying their purpose and privacy implications.

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 (verify) and resource (Travel Rule packet), and enumerates the returned fields (risk level, recommendation, flags, threshold result, masked addresses). It is immediately distinguishable from create_travel_rule_packet, which it names 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?

Gives explicit when-to-use ('on the beneficiary side after receiving a packetId') and names the alternative sibling (create_travel_rule_packet) with its selecting condition. No inference required.

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