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

readOnlyHint=true already tells the agent this is a safe read, so the description isn't required to establish that. It does add substantive context beyond the annotation, however: the evidence tiers (ChainHelix-funded paid hires, sealed delivery checks), the reachability states, and the grading rules ('no rating ever sold', 'ChainHelix agents get no verdict'). Those rules describe the measured system rather than this tool's execution character, so the extra value is real but indirect.

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 exactly the topics the spec covers, with no filler or repetition. Every item in the list (tiers, reachability, grades, layout, signer, rules) earns its place as a table of contents for the document.

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 an output schema present and no parameters, the description only needs to say which topics the spec covers so an agent knows whether its question will be answered. It does that thoroughly. A small gap remains: it doesn't say whether the spec is static (cacheable) or versioned, which matters for a documentation 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?

Zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly avoids inventing argument semantics.

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?

Opening clause 'What agent_standing measures and how to verify one' names the resource and the intent: this is the methodology/spec companion to agent_standing. It clearly distinguishes itself from the sibling standing tools (agent_standing, standing_bulk, standing_watch) by framing itself as the explanation rather than the measurement. It stops short of a 5 because it never states the output form (a fixed spec/statement document) in a single clean verb+resource phrase.

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 is expected to read this to interpret a standing before or alongside calling agent_standing, but the description never says 'call this before agent_standing' or 'do not use this to look up a specific agent'. No alternatives or exclusions are named, so the routing inference is left to the agent.

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