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

With no annotations the description carries the full burden and does well: it reveals the decision policy (BLOCK on sanctioned/drainer/phishing/scam/mixer or BLOCK risk verdict, SCREEN as default for unknowns), the return components (reasons[] plus a confidence flag), and that the call is free. It does not explicitly state the call is read-only/no-side-effect, which is the only notable gap.

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 question, then context, then behavior, then params – a sensible order with no filler. The 'Params:' clause duplicates the schema, which is the one economical ding.

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 must cover returns and does: verdict enum, reasons[], and confidence flag, plus the decision thresholds behind them. For a two-parameter screening call this is close to complete, missing only explicit read-only/side-effect framing and latency or rate-limit expectations.

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 the schema already states 'default base' and '0x EVM address. Required.', so the description's param sentence largely restates structured data. Baseline 3 applies; it adds no format, validation, or chaining detail 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?

Opens with a concrete decision question ('Should this wallet be answered?') and names the resource (EVM wallet) plus the exact verdicts it produces, which tells the agent this is a composite risk/attribution decision tool rather than a raw lookup. It differentiates implicitly from lookup_wallet/check_entity by describing the composed signals, but never names a sibling outright.

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 domain trigger: 'For wallet messaging (XMTP, Push), which has no spam filter', so the agent knows the scenario this is built for. It stops short of naming when to prefer check_entity or lookup_wallet instead, so sibling routing 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.