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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new semantics: an UNMEASURED axis is a first-class declared slot with no run behind it, 'never an error and never a zero.' That is useful anti-misinterpretation context an agent could not derive from structured fields. It stops short of describing freshness, caching, or how the board URL relates to live vs. snapshot data.

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?

Identity is front-loaded in the first clause, and the long field enumeration earns its length by telling the agent what the row contains. The sentence structure is slightly convoluted around the colon list, but there is no filler or repetition.

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 covers the essentials: what the axis is, that it needs no input, how to read UNMEASURED results, and a caveat that it is not a certification. The one meaningful gap is the relationship to get_axis and the other axis tools, which affects routing rather than calling.

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 the baseline is 4. The description correctly reinforces this by stating the tool takes no argument, which matches the empty schema with additionalProperties: false and prevents an agent from inventing inputs.

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 says this is 'the labour-components axis of the live GSPC board' and enumerates what the axis carries (n, accuracy, interval, MEASURED/UNMEASURED, family, kind, artifact URL, dates). That tells an agent roughly what comes back, but 'this tool IS the axis' largely restates the name, and with ~30 near-identical axis_* siblings plus get_axis and board_totals, there is no statement of what distinguishes this axis from the generic accessor.

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?

No when-to-use, when-not-to-use, or alternative is named. The presence of a sibling called get_axis makes the omission material — an agent cannot tell from this text whether to call this axis tool directly or go through get_axis. The 'no argument' note is a calling fact, not usage guidance.

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