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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds value beyond this by disclosing output specifics (entity label, risk level, flags like 'new_account', 'dormant'), auto-detection of chain, and even the API cost (0.25 USDC). This enriches the behavioral model without contradicting the annotations.

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 description is compact and well-structured: a use-case hook, a clear list of outputs, flag examples, cost/REST info, and an args line. Every sentence adds relevant detail, and the length is appropriate for a tool with one parameter and rich output. The only slight redundancy is the 'Args' section repeating the schema, but it adds format specifics.

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 detail all return fields, but it still lists key outputs and flags. It covers cross-chain support, example flags, and cost, making it sufficiently complete for a single-parameter read-only tool. Minor omissions like rate limits or error handling are not critical given the annotations and output schema.

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 full responsibility for the single parameter. It provides the accepted formats: 'address: EVM address (0x...) or Solana address (base58)' and notes auto-detection. This goes beyond the schema's bare string type and gives the agent concrete input guidance.

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 clearly states the tool's function: 'get entity label, risk level, account age, transaction history, and top holdings' for any wallet address. It explicitly covers both EVM and Solana with auto-detection, and the 'REST equivalent' line adds a concrete action. The purpose is distinct from the market-focused sibling tools, making this a 5.

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 phrase 'Before you transact, know who you're dealing with' provides a clear when-to-use context, positioning this as a pre-transaction risk assessment. It does not explicitly name alternatives or when-not-to-use scenarios, but the siblings are all market-related, so the differentiation is implied. The cost and REST reference also give practical usage context.

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