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

With no annotations, the description carries the burden and does well: 'Live' signals a read of current state, and the parenthetical about 'how much of the stake it was read from' discloses a data-quality caveat an agent would otherwise miss. It does not state permissions, freshness/latency, or caching behavior, which keeps it short of a 5.

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 sentences, front-loaded with what is returned and backed by a concrete use case. The first sentence is dense with a long comma-separated field list, but each listed item is informative rather than filler.

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 tool with a rich, multi-field return and no output schema, the description enumerates the return contents thoroughly enough that an agent knows what it will get. It stops short of describing the response shape or units (e.g., how stake weight is expressed), a minor gap for a single-optional-parameter read 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 100%, including the enum and the 'both when omitted' default, so the schema already does the work. The description implies both networks are reported by default but adds no format or selection guidance beyond that, which matches the baseline 3 for high-coverage schemas.

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 (live NEAR protocol state for mainnet and testnet) and enumerates the exact payload: protocol versions, nearcore version, epoch progress, stake-weighted upgrade vote, threshold, vote start, and pending deprecations. That level of detail separates it cleanly from siblings such as get_network_state, get_validators, and check_deprecation.

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 concrete when-to-use triggers, naming two real questions (whether DelegateV2 removal or the gas rebate is live, and when the next upgrade lands). It does not explicitly say when a sibling like check_deprecation or get_network_state would be the better call, so routing is clear but not fully exclusive.

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