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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description does add one genuine behavioral detail beyond the annotations: cross-wallet session IDs yield a not-found result rather than an error or another wallet's data. It still omits what the returned status can be or whether results are terminal.

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?

Three short sentences with the scope stated first and the constraint last; nothing is padded. The opening sentence duplicates the title verbatim, which is minor redundancy but slightly wasteful.

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 should convey what a deposit status lookup returns, yet it never indicates the status values or fields an agent can act on. Combined with an entirely undocumented session_id, the definition is not sufficient for correct invocation.

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 0% and the single parameter session_id is undocumented in the schema, so the description must carry the meaning. It only alludes to a 'session' obliquely via the not-found note, never defining whether session_id is the deposit session from start_deposit or another identifier.

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 title and first sentence identify a read of deposit status scoped to 'my wallet', which an agent can separate from sibling start_deposit (initiation) and payout_status (payouts). The second sentence, 'Where a deposit stands,' restates the same idea rather than sharpening it, so it falls short of 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 clause 'A session on another wallet is reported as not found' gives a real usage constraint (this only works against your own wallet's session), which implies when it is appropriate. However, it names no alternative and does not say when to call this versus start_deposit or topup_wallet, leaving routing to inference.

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