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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the real behavioral burden and does so: a hard 3/IP/UTC-day rate limit, the HTTP 402 failure mode once exhausted, and the pass/pay-per-download cost structure. This is exactly the non-obvious context an agent needs to avoid misinterpreting a 402 as an error.

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 quota limit is correctly front-loaded and the text is short, but the second half is telegraphic ('then HTTP 402 with per-call + day/month pass options') and the stolen-funds $12 pricing clause is billing detail that does not help select or invoke this tool.

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?

Quota, failure mode, and cost are well covered for a single-parameter tool, but with no output schema the description should say what a risk check actually yields (score, flags, verdict) rather than deferring to 'same engine as intel_risk_check'. The agent knows when it can call it, but not what it will get back.

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?

There is a single required parameter with 100% schema description coverage ('Wallet or contract address to risk-check'), so the schema already does the work. The description only restates 'Requires address' and adds no format, chain, or validation guidance beyond 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 identifies the tool as a free, rate-limited tier of the risk-check for an address and explicitly names the paid sibling (intel_risk_check, $0.0045) whose engine it shares, so an agent can distinguish it from intel_risk_check and intel_risk_batch. It never states in plain terms what a risk check returns, leaning on the sibling reference to convey that.

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 concrete selection context: free for up to 3 calls per IP per UTC day, then HTTP 402, and it explains that day/month passes cover risk-check and batch calls while stolen-funds is pay-per-download only. There is no explicit 'prefer this over intel_risk_check while quota remains' instruction, but the pricing and quota framing makes the tradeoff inferable.

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