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

With no annotations at all, the description carries the full behavioral burden and does most of it well: it discloses the 4,000-transfer scan cap, which transfer types are covered, which counterparties get checked, the payment requirement ($0.01 USDC on Base via x402), and the 'not legal advice' caveat. What it omits is failure behavior — what happens on an unsupported chain, an unreachable node, or when no transfers are found — and whether payment is settled before or after the scan.

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 definition is front-loaded with the core question, then a single dense sentence covering scope, data sources, chains, return contents and cost. Nothing is truly wasted, though 'Not legal advice' and the price tag sit in the same breath as the mechanics and could be segmented for faster scanning by a paying agent.

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 must describe the return shape — and it does, enumerating per-counterparty fields (entity, programs, direction, transfer count, assets, dates). Combined with the disclosed cost and scan limit, the definition is nearly complete; only the empty-result case and error modes 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 description coverage is 100%, so both parameters are already documented in structured form, which sets the baseline at 3. The description reinforces the chain list (Base, Ethereum, Arbitrum, Optimism, Polygon) to match the enum but adds no new semantics such as default-chain behavior or address-format constraints beyond the schema's 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?

The description names a concrete verb and resource — reads a wallet's latest transfers and checks every counterparty against the OFAC SDN address list — so the agent knows exactly what question the tool answers. The opening 'Has this wallet dealt with sanctioned addresses?' and the 'Direct exposure only' qualifier scope it tightly enough to distinguish it from a name-based sanctions lookup, even without naming the 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 interrogative framing and 'Direct exposure only' tell the agent this is an address-level direct-exposure screen, but there is no explicit when-to-use/when-not guidance and no routing to the obvious alternative address_sanctions_screen or sanctions_name_search. The agent must infer that indirect exposure is out of scope and handled elsewhere.

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