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

Annotations already declare readOnlyHint=true, idempotentHint=true and non-destructive, so 'Read-only' in the description is largely redundant. What the description does add is the shape of the returned data and the implicit behavior that the address parameter scopes the response to per-address stake, while omitting it presumably yields global staking state — a useful distinction that is hinted rather than stated.

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?

A single front-loaded sentence that enumerates fields efficiently with no filler. The list is dense but each clause carries information; the trailing 'Read-only' is the only element that does little work.

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 and no parameter documentation, the description must convey return contents, and it does list the concrete values returned plus the address scoping. The remaining gap is the omitted-address behavior and the format of claimable WETH (raw vs. formatted), which are minor for a read-only one-parameter tool.

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% for the single optional 'address' parameter, so the description must carry the meaning, and it does: supplying an address yields that address's active stake, pending stake and claimable WETH, whereas the preceding global fields (total staked, epoch, last rewards) read as address-independent. It stops short of saying explicitly what happens when address is omitted or that only per-address metrics change.

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 names a specific resource ('Staking state') and enumerates the exact fields returned: total $KYTE staked, current epoch and end time, last epoch rewards, per-address active/pending stake and claimable WETH. It is clearly a read of staking state rather than a preparation step, though it does not explicitly name the sibling prepare_stake it complements.

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 only implied: an agent can infer this is the read path for staking data before or after calling prepare_stake, but no explicit when-to-use or when-not-to-use guidance is given, and no alternative such as get_rewards or get_protocol_stats is contrasted.

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