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

No annotations are provided, so the description carries the full burden, and it does deliver one real signal: the trailing 'Read only' declares the tool is non-mutating. It also discloses a domain constraint (hard cap of 300 bps). However, it says nothing about permissions, whether data is live or cached, per-chain scope, or how the three optional parameter combinations behave when mixed or omitted.

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?

There is no filler, but the prose is aggressively compressed into two run-on sentences with cryptic fragments ('Global: is it on, are guards on...'), which slows parsing. The definition is front-loaded correctly, yet the parameter routing is buried mid-sentence in clause form rather than broken out.

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 four-parameter, no-output-schema, no-annotation read tool in a jargon-heavy domain, the description covers the return shape and parameter routing but omits the interaction with the prepare_* sibling, default behavior with zero arguments, and any indication of data freshness. Adequate to attempt a call, not complete enough to call confidently.

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 100%, so baseline would be 3, but the description adds genuine mapping value the schema does not: wallet returns the edge per game for the fighter that wallet brought, fighterId returns that fighter's rarity/rest/post, and assetKind+assetId returns that asset's guard. That tells the agent which parameter combination produces which response slice, beyond the schema's flat field notes.

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 states concretely what the tool returns: the capped Muscle bonus (never above 300 bps), the vehicle/apartment guard value, global on/off flags, per-rarity bonus and per-game share. That is specific enough to separate it from prepare_fighter_edge (which would perform the transaction). It never uses a clean verb like 'returns' or 'reads', so the purpose is inferred from the payload listing rather than stated outright.

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 implicitly tells the agent how to pick a slice by naming which parameter yields which data ('Pass wallet for...'), which is useful selection guidance. But it never says when to call this rather than prepare_fighter_edge, fighter_info, or my_fighters, and never states what happens with no parameters. Usage is implied rather than prescribed.

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