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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description instead contributes genuinely new semantics — that an UNMEASURED axis is a published gap rather than an error or a zero, and the 'never a certification' caveat. That interpretation guidance is worth more than the annotations alone and is the single most valuable part of the definition.

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?

The identity and the no-argument fact are front-loaded, followed by the field list and the unmeasured-result rule. The dense middle sentence cramming seven field names together and the trailing fragment 'Never a certification.' cost a little readability, but there is no 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?

With an output schema present and 100% schema coverage, the description needn't document return shapes, and it sensibly focuses on the semantic edge case (unmeasured axes) instead. What remains missing is its relationship to the near-identically named axis_* siblings and to get_axis, which an agent would still need to resolve.

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?

There are zero parameters, so the baseline is 4. The description reinforces this explicitly by stating the tool takes no argument and that the axis itself is the resource, which removes any doubt about how to call it.

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 the specific resource it exposes (the serving-fidelity axis of the live GSPC board) and enumerates the fields it carries, so an agent knows exactly what it is getting. It falls short of a 5 because it never positions itself against the many closely named siblings such as axis_harness-fidelity or the generic get_axis, leaving the agent to infer which one to reach for.

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?

'This tool IS the axis, so it takes no argument' implies a zero-configuration read and the note that unmeasured results are first-class tells the agent how to read the answer. However, there is no explicit when-to-use framing and no mention of when to prefer get_axis, measurement_index, or board_totals instead.

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