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

Annotations already carry readOnlyHint/idempotentHint/openWorldHint, but the description adds real context beyond them: no signature required, amounts denominated in SOL, the WithdrawExcessLamports vs CloseAccount distinction, and the external signUrl fallback with named wallets. This meaningfully informs behavior for a mutation-adjacent workflow.

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 core purpose is front-loaded in the first clause, and the long enumeration of return fields is dense with distinct information rather than filler. It is a single long sentence plus a fallback sentence, which is slightly heavy but every clause carries weight.

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 return values, and it does so comprehensively (excess rent, empty accounts, mint excess, fee, net, forecast, dust, signUrl). Safety and signature requirements are also covered. Only the relationship to the sibling build/submit tools is left unstated.

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 the schema already documents both parameters (wallet, ref). The description adds only the SOL unit convention and does not explain the referral code semantics shown in the schema, so it neither compensates nor detracts. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

Clearly states a specific verb and resource: it reads a Solana wallet's token accounts and mints and returns reclaimable SOL. It elaborates exactly what is returned (excess rent, empty accounts, mint excess, service fee, net, forecast, dust), which is unusually precise. It does not, however, explicitly differentiate itself from siblings like get_rent_status or build_reclaim, so an agent must infer the read-vs-build-vs-submit split.

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: it is a read-only scan that returns a signUrl for when 'you cannot sign for the wallet yourself,' which hints at a browser fallback flow. But there is no explicit guidance on when to prefer this over get_rent_status, or that this is the discovery step preceding build_reclaim/submit_reclaim, so the agent must infer the ordering.

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