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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the full return payload (level low/medium/high/unknown, flags, raw checks, market data, swapUrl), mandates showing the `display` markdown with images to the user, requires passing on a disclaimer, and warns that heuristics can miss scams. These are operational obligations an agent cannot derive from any structured field.

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 per-chain source list, then the return shape, then the caveats and display requirement — a sensible priority order. It is dense but each clause carries information; the closing playbook pointer is the one mildly promotional sentence.

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 carries the burden of describing returns and does so concretely (risk level, flags, raw checks, market data, swapUrl, display markdown). Combined with the scam caveat and the display/disclaimer obligations, an agent has everything needed to call and present results 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 only 50% (chain has an enum but no description; only address is documented), so the description must compensate — and it does partially by explaining that the chain value selects entirely different audit providers (Solana vs EVM). It adds real semantics about why the chain parameter matters, though it says nothing about accepted address formats per chain.

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 ('Deep automated risk check for one token') and enumerates exactly which checks run per chain (Jupiter/RugCheck on Solana, GoPlus on EVM, DexScreener heuristics). It is clearly a risk/scam-audit tool rather than a metadata lookup, but it never explicitly contrasts itself with the closest sibling, token_info, so the boundary is only inferable.

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 (pre-swap due diligence, token-safety workflow) and it routes to swapchan_playbook for 'token-safety' and related workflows, which is useful. However there is no explicit when-to-use statement, no when-not-to-use (e.g. for tokens on unsupported chains), and no stated alternative for simple metadata needs.

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