Limitguard Lead Verification

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds substantial extra context: per-call pricing under x402 vs API key, the verdict taxonomy (block/review/no_findings) with verdict_reasons, per-component status values (ok/unavailable/error), and the important caveat that reputation and domain never change the verdict. That is well beyond what the structured fields 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?

Front-loaded with the one-line purpose, then structured into return semantics and an Args block; nearly every sentence carries information. It is slightly long and repeats parameter facts already implied in the header sentence, but there is no significant 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?

With annotations, an output schema, and a low-coverage input schema, the description fills every gap: cost model, verdict semantics, component coverage and failure statuses, and the non-scoring nature of reputation/domain. An agent has everything needed to call it correctly and interpret 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 0%, so the description carries the full burden and does so: wallet format ('0x + 40 hex characters'), agent_id as an optional decimal ERC-8004 agentId the wallet claims, and domain as an optional self-declared website (e.g. example.com). All three parameters gain meaning the raw schema does not provide.

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 and resource (check a counterparty agent's EVM wallet) and enumerates exactly what is checked: OFAC SDN match, Base USDC/ETH balance, ERC-8004 identity, and open ERC-8004 feedback. It clearly distinguishes itself from generic siblings like check_entity, verify_wallet, or get_risk_score by scoping to agent wallets on Base.

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 opening 'Check a counterparty agent's EVM wallet in one call' and the closing 'Base only; EVM addresses only' tell the agent the situation and the hard limits. It does not, however, explicitly name when to prefer a sibling (e.g. sanctions_screen for a plain address) or state exclusions, so it falls short of a full when/when-not routing statement.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds the set of external sources actually consulted, but it does not explain the idempotentHint=false behavior (whether repeated identical calls can return differing scores) or any rate/cost implications of a live external lookup.

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 purpose and return summary are front-loaded in the first two sentences, followed by a compact Args block. Every sentence earns its place; there is no filler 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?

With an output schema present, the description need not explain return values, and it documents all four parameters despite zero schema coverage. What is missing is the decision context against sibling tools, which matters for a read-only screening call in a dense tool family.

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 must carry the burden, and it largely does: entity_name as full legal name, country as ISO 3166-1 alpha-2, kvk_number as an optional 8-digit Dutch registration, and domain as optional. It adds real meaning (format constraints, optionality) beyond the bare schema types, though it omits any guidance on when kvk_number or domain materially improve the result.

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 ('Company check on a business') and enumerates the actual checks performed (sanctions screening, country risk, Dutch KVK register, website domain). It is clear on its own, but it never distinguishes itself from closely related siblings such as sanctions_screen, get_trust_score, or get_compliance_report.

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 no explicit when-to-use guidance, no prerequisites, and no exclusions. Given the crowded sibling set (sanctions_screen, sanctions_preview, get_trust_score, verify_lead), the agent has no stated basis for choosing check_entity over these alternatives.

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 declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, and the description coherently explains why: the report is 'built from one real check', which is a state-changing, non-idempotent external operation. It also adds behavioral detail the annotations cannot carry, notably 'never stored raw' for IBAN and a per-source status table covering ok/unavailable/error, so the agent knows results can be partial.

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?

Purpose and report contents are front-loaded ahead of the argument list, and the argument block is necessary given 0% schema coverage, so nothing is wasted. The raw docstring-style indentation is slightly awkward but does not impede parsing.

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 duplicates much of that content while also fully documenting all 10 parameters. The one missing piece is explicit sibling routing guidance, but for a complex 10-parameter tool the definition is otherwise complete.

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 all 10 parameters are optional, so the description carries the full documentation burden and does so well: it gives formats (ISO 3166-1 alpha-2, 8-digit KVK, Belgian CBE pattern, EU VAT), constraints (IBAN never stored raw, wallet address format-check only), example chain values, and the check_id-versus-identifiers relationship.

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: it produces a per-entity compliance report and enumerates exactly what the report contains (registry identity, sanctions/PEP screens, risk score, findings, source status table, hash). It is clearly distinguished in kind from atomic siblings like get_risk_score or sanctions_screen, though it never names an alternative sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the entity_name note ('omit when sending check_id') tells the agent the two input paths are mutually exclusive, which is a genuine routing hint. However, there is no guidance on when to call this full report versus the lighter siblings (check_entity, get_risk_score, sanctions_screen), which an agent would plausibly be choosing between.

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/openWorld/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond them: it warns that risk_level is inverted relative to check_entity's trust_level ('high means high risk, the reverse of check_entity's trust_level'), and states what is NOT returned (no recommendation or factors). It does not mention latency or rate limits, but the semantic-inversion warning is high-value.

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, then differentiation, then return semantics, then args; every sentence carries information. The Args block is somewhat redundant with the structured schema, which is the only mild inefficiency.

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 enumerate return fields, yet it usefully flags the semantic inversion that a schema alone would not convey. Combined with the sibling routing advice and full parameter formats, an agent has what it needs to call this correctly; only edge cases (bad name/country input handling) are unaddressed.

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% (parameters carry only titles), so the description must compensate and largely does: entity_name is specified as the full legal name and country as an ISO 3166-1 alpha-2 code, which prevents a country-name vs. code mistake. It doesn't note anything about malformed or ambiguous names, so it falls just short of full compensation.

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 ('quick risk score from sanctions screening and country risk only') and immediately scopes what it does not cover. It explicitly names the sibling check_entity and the difference ('no register or domain lookup'), so an agent can distinguish the two 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?

Gives an explicit use condition ('Use when you only need basic risk evaluation') and an explicit alternative plus the reason to pick it (check_entity for register/domain lookup, recommendation or factors). The trade-off between speed and depth is spelled out rather than implied.

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

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

Goes well beyond the readOnly/openWorld/destructive annotations: it discloses cost ($0), that no data source is called, that only checks made with your key are readable, that another key's or workspace's checks never are, and that OAuth sessions read workspace checks instead. It also enumerates the two possible status outcomes.

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 purpose and the key behavioral distinction before any detail, then structured into return values, scoping rules and args. The issue references (#946, #1062) are terse and the prose has no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still names the returned fields and the found/not_found statuses, and it covers the authorization scoping an agent would otherwise have to discover by failure. Nothing needed 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 description coverage is 0%, so the description carries the burden for the single parameter, and it does: entity_id is 'The entity name, as you sent it to check_entity', clarifying that it is the exact name string previously submitted rather than an internal identifier. It does not restate the type, but that is in 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 ('look up your most recent trust score') and pins the scope precisely: it reads a previously stored check rather than performing one. The clause 'from your stored checks' plus the explicit 'Runs no new check and calls no data source' cleanly separates it from check_entity and the other check/verify siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear condition for use ('an entity you checked before') and an implicit but well-signposted alternative via 'Runs no new check' and 'as you sent it to check_entity'. It does not spell out a when-not rule such as 'use check_entity if you need a fresh score', so it falls just short of explicit routing.

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 read-only/no-destruction safety profile; the description adds the operationally critical traits: exact return surface (possible_match, lists_checked, list_dates, list_note, never an entry), rate limits per caller and per IP, quota sharing with the REST endpoint, and zero cost. This is exactly the value-add structured fields don't 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 the differentiating constraint, and every sentence carries information. The Args block restates two fields but is justified because the schema has no descriptions; formatting is slightly loose (indented block, mixed line breaks) rather than wasteful.

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 need not detail return values, yet it still defines the return scope and its limits. Quota, cost, alternative tool, and both parameter semantics are covered — everything needed to invoke this correctly and know when not to.

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% and the schema titles are bare, so the description carries the full burden. It defines name as a company or person name and, crucially, explains that country is an ISO 3166-1 alpha-2 code that only orders matches and never excludes one — a non-obvious behavior no schema field conveys.

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 (a free yes/no sanctions 'preview' screener) and names the exact lists consulted (OFAC SDN, EU, UN). It also distinguishes itself from the sibling sanctions_screen by declaring it 'never' returns an entry, so an agent can separate the two 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?

Explicitly routes the agent: if matched entries are needed, use sanctions_screen, and it flags cost ($0) and quota (10/caller/day, 50/IP for key holders, shared with the POST endpoint). What's missing is a crisp 'use this when you only need a yes/no decision, before paying for a full screen' rule, but the context is clear enough.

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, openWorldHint, idempotentHint=false, destructiveHint=false) by disclosing match semantics ('exact normalised or word-order-insensitive name match only'), the fields each match carries, the billing rule ('Rejected calls are not charged') and a legal disclaimer. These are exactly the behavioural facts an agent cannot get 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?

Front-loads the core purpose and result shape, then layers semantics, disclaimer and billing. The re-indented 'Args:' block duplicates what a docstring would normally hold and is slightly padded, but no sentence is truly 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?

Although an output schema exists, the description still summarises the match payload and its scoring, and it covers input semantics, disclaimer and billing. Nothing an agent needs to call this correctly appears to be 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 0%, so the description carries the full burden and does: 'name' is defined as company or person, and 'country' is documented as an optional ISO 3166-1 alpha-2 code that 'orders matches, never excludes one' — a non-obvious ranking semantic not expressible in 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 ('Sanctions screen against the local OFAC SDN, EU and UN lists') plus the scope of results ('matched entries'), which is far more than a restatement of the name. It does not, however, distinguish itself from nearby siblings such as sanctions_preview, wallet_sanctions_preview or check_entity, so the agent must infer the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the name-screening context and reinforced by 'A name match is not a determination', but the description never says when to pick this over sanctions_preview or check_entity, nor states prerequisites. No explicit when-not guidance is given.

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 past the annotations: discloses per-call pricing ($0.10 via x402, $0.27 with API key), that rejected calls are not charged, that omitted inputs are never counted against the lead, and privacy behavior (IBAN reduced to country/bank/BIC/last 4; phone never echoed). These are exactly the operational facts an agent cannot get from readOnlyHint/openWorldHint.

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 purpose and well-structured Args block; nearly every sentence carries information. It is somewhat long, and the detailed return-value paragraph partially duplicates what the output schema already provides, which is the only real inefficiency.

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 an 11-parameter, open-world verification call with an output schema, the definition covers inputs, output verdicts, cost, and edge-case prerequisites thoroughly. The one gap is sibling-relative positioning, which is minor since an output schema already carries the return contract.

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 carries the full burden and does: it documents formats and semantics for nearly every arg (8-digit KVK vs 10-digit KBO, VIES for VAT, email domain-only check, address sub-keys {street, house_number, postcode, city}, SBI/NACE prefixes or whole words for target_industries, inclusive {min,max} for target_size) and marks the ideal-customer inputs as information-only.

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 ('Verify a NL/BE sales lead against the registers') and enumerates exactly what is checked (registry status, VAT, mail server, IBAN, sanctions) plus the composite lead score. This scope is clearly distinct from siblings like check_entity or sanctions_screen, which cover narrower slices.

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 conditional usage rules ('BE needs company_number', 'phone ... rejected until website phone lookup is switched on', 'An input not given is not checked') which is genuine guidance. However it never states when to prefer this tool over the adjacent check_entity, get_risk_score, or sanctions_screen siblings, leaving alternative-selection to inference.

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

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

Annotations only cover the safety profile (readOnly/openWorld/idempotent=false), but the description adds non-obvious behavior: $0.005 via x402 vs $0.11 with an API key, that rejected calls are not charged, and that ERC-8004 agent/reputation data is descriptive only and never folded into risk_score or advice. None of that is recoverable 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?

Purpose and cost are front-loaded and the Args block is tidy, but the return-value paragraph restates the output schema and the ERC-8004 'descriptive only, never scored' caveat is repeated in both paragraphs, adding redundancy an output schema could already imply.

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 screening tool with rich annotations and an output schema, the description still covers everything the agent needs: chain defaults and aliases, accepted address formats, pricing/charging rules, scoring composition, and the sibling for a cheaper sanctions-only path. No material gaps remain.

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 carry the burden; it explains chain_id is a CAIP-2 ID with default eip155:8453 and that base/eth/solana/btc aliases are accepted, and states accepted address formats (EVM 0x..., Solana base58). The wallet_address gloss itself is thin ('Blockchain wallet address'), so it is strong but not maximal.

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

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

States a specific verb and resource ('Screen a wallet') and enumerates exactly what is checked (OFAC SDN, contract check, balances, tx count, first-seen-on-Base, named risk rules). It also names the free sibling, wallet_sanctions_preview, so an agent can distinguish the full screen from the sanctions-only path.

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 routing rule to an alternative: 'The sanctions match alone is free: the wallet_sanctions_preview tool,' plus pricing to inform cost-based selection. It lacks guidance against the other risk siblings (get_risk_score, check_entity, sanctions_screen), so it is clear context without full exclusions.

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/open-world annotations, it discloses cost ($0), quota (10 per caller per UTC day, shared with the POST endpoint and separate from the name preview), key-holder ceiling (50 per IP), and that status may be 'ok' or 'stale' with as_of reflecting the list's publication date. That is unusually rich operational context.

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?

Purpose and the upgrade path are front-loaded, and the rate/cost facts are compactly stated. It is somewhat verbose, restating the free price and enumerating return fields already covered by the output schema, but no sentence is truly 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 need not explain return values, yet it still flags the notable ones (sanctioned, lists, as_of, status, source) and fully covers cost, quotas, defaults and the alternative tool. An agent has everything needed to call 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 0%, so the description carries the burden: it documents both parameters, giving chain_id's CAIP-2 format, its default (eip155:8453 for Base) and the accepted aliases base/eth/solana/btc, plus the required wallet_address. The wallet_address gloss itself is thin, which keeps this from a 5.

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 names a specific verb (check), resource (wallet address) and dataset (OFAC SDN list), and scopes it as a free yes/no preview. It also explicitly distinguishes itself from siblings by pointing to verify_wallet as the fuller screen and noting it is separate from the name preview.

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 makes clear this is the free, narrow sanctions-only check and routes the agent to verify_wallet (with pricing) when balances, activity, delegation and risk scoring are needed. There is no explicit 'do not use this when...' exclusion, but the free-vs-paid split is unambiguous.

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