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

Annotations cover safety (readOnlyHint, openWorldHint, idempotentHint=false), and the description adds genuinely new behavioral context: the private key is sent once, not stored, but has transited the service, so it is test-grade only. It also names the actual data sources (blockchain.info, an Ethereum RPC node, Solana mainnet RPC), which nothing else discloses. A shadow of doubt remains about whether 'new_wallet' truly fits readOnlyHint, but no direct contradiction.

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?

Two dense sentences with no explicit division between the balance path and the wallet-generation path, so the structure doesn't front-load the two distinct operations. The security caveat is placed mid-sentence rather than as a prominent warning.

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?

For a 3-parameter enum-driven tool with no output schema, the description covers both operations, the data sources, the no-auth model, and a critical security caveat about generated keys. What an agent needs in order to call it correctly is largely present; only the return shape of the balance call is left implicit.

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 33%, so the description must compensate. It clarifies that the address is a public address used for balance, and the enums for chain and operation are self-documenting. However, it never states that 'address' is unused/optional for new_wallet, leaving that to the schema's 'balance only' note.

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 conveys the domain – reading balances of BTC/ETH/SOL addresses and generating a key pair – but does so as an awkward noun fragment rather than a clean verb+resource statement ('The balance of ... or a newly generated key pair'). There are no sibling wallet tools, so differentiation isn't the issue; the gap is that the actual actions (check balance vs. generate wallet) are implied rather than stated.

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 one real usage constraint ('use it for tests and small amounts only' for generated keys) and reassures the caller no API key or account is needed. It does not explain when to pick the 'balance' operation versus 'new_wallet', nor any prerequisites for reading an address, leaving the choice to the schema enums.

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