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

With no annotations, the description carries the full burden and does so: it discloses read-only chain state (no prices), the first-50 truncation limit with separate counts of remaining token and empty accounts, frozen-flag presence, error behavior (400, not charged), and the x402 price and payment chains. That's unusually complete behavioral disclosure for a bare definition.

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 use case, then Input/Output/Errors/Example/Price in a scannable telegraphic style with no filler sentences. The fragmentary label-value format is dense but slightly harder to read than flowing prose, keeping it just below top marks.

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?

There is no output schema, so the description must describe returns — and it does, enumerating slot, SOL balance, per-token fields, truncation limit, and aggregate counts. Combined with error and billing details for a one-parameter read tool, nothing an agent needs to call it correctly is missing.

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 100%, so both the type and base58/mainnet constraints are already documented, and a single parameter puts the baseline at 3-4. The description adds a concrete example address in query-string form (?address=...), which usefully demonstrates invocation shape beyond the raw 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?

States a specific verb and resource: what a Solana address holds in one call, explicitly covering SOL plus every SPL and Token-2022 token account. That scope distinguishes it from sibling base_wallet_balances (different chain) and sol_token_info (token metadata rather than holder balances) without needing to name them.

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?

"Use when an agent needs what a Solana address holds in one call" gives a clear trigger, and "Chain state only, no prices" sets a boundary that implicitly routes valuation needs elsewhere. It stops short of naming a specific alternative tool or an explicit when-not condition, so it's clear context rather than full routing guidance.

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