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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the description earns credit for adding semantics beyond them: an unmeasured axis is 'a declared slot with no run behind it, published so the gap is visible — never an error and never a zero.' That is genuinely non-obvious behavior an agent would otherwise misread as failure or as a null metric, and 'Never a certification' bounds interpretation. It stops short of describing pagination, freshness, or failure modes for the live HTTP endpoint.

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?

Two sentences, front-loaded with the identity and the no-argument guarantee before the interpretation rules. Every clause carries information — the field list, the URL, the unmeasured semantics, the certification caveat — with no filler or restatement of the title.

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, the description need not explain return values, yet it still sketches the row shape, which helps the agent decide whether to call. For a zero-param read-only tool this is nearly complete; the only omission is what an agent should do next when the axis is unmeasured or how this differs from get_axis.

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 reinforces this by explicitly stating the tool takes no argument, which prevents an agent from inventing an axis-name argument. No further parameter detail is possible.

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 (the claim-maintenance axis of the live GSPC board at a concrete URL) and enumerates exactly what a row carries: n, accuracy, interval, status, family, kind, artifact URL, dates. That is far more than a restatement of the name. It does not, however, contrast itself with the many sibling axis_* tools or with get_axis, so an agent cannot tell from this text alone which of the two to reach for when it wants 'the claim-maintenance axis'.

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 implied rather than stated: 'this tool IS the axis, so it takes no argument' tells the agent this is the zero-argument direct fetch, and the unmeasured-axis paragraph tells it how to interpret a gap result. There is no explicit when-to-use/when-not, no mention of get_axis, measurement_index, or any sibling as an alternative, and no statement of what to do if the agent actually wants a different axis.

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