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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuinely non-redundant behavior: results are "pinned" facts, caller-supplied RPC URLs/chain IDs are rejected, and out-of-scope financial questions are actively declined rather than answered. It does not describe the response shape or caching/staleness of the pinned data, which keeps it from 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?

Core content is front-loaded and the scope disclaimer is well placed, but the sentence "Example QIE ID: yourname.qie" is off-topic for a network-metadata tool (that belongs to qie_resolve_name) and directly after a list of return fields, making it read like a returned value. There is also mild duplication of the chain-ID mapping already in the schema.

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 one optional enum parameter, no output schema, and full annotation coverage, this definition covers what an agent needs: what is returned, which networks exist, and what inputs are refused. The only gap is the absence of return-structure detail, minor here because the value set is small and enumerated in prose.

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% and the single enum parameter already documents mainnet=1990, testnet=1983, and that raw chain IDs or RPC URLs are rejected. The description mirrors that information rather than adding new meaning, so it earns the baseline 3 rather than more.

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 gives a specific verb ("Return") and enumerates exactly what resource is returned: chain ID, name, RPC URLs, explorer URL, native currency, scoped to QIE mainnet (1990) and testnet (1983). An agent can distinguish this from qie_get_balances, qie_get_tx_status, or qie_resolve_name purely on the description, since none of those return static network metadata.

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 states a clear when-not ("does not give price, APY, returns, yield, or investment advice and will decline such questions") and a hard input constraint ("The caller cannot supply an RPC URL or chain ID"), which prevents a common misuse. It stops short of naming sibling tools as the alternative when a caller actually wants balances or name resolution, so routing is left to inference.

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