get_calibration_observations

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

Annotations already declare read-only, idempotent, non-destructive, but the description adds real operational context beyond them: it explicitly states it runs no test, explains that stale reports arise when the definition or test vehicle changed, and discloses the empty-result behavior ('returns no checks when nothing was recorded').

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 scope statement is front-loaded and the follow-up sentences are short and purposeful, covering usage timing and empty-result behavior. The first sentence is dense with a parenthetical definition, but nothing is wasted.

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?

Given a single well-documented parameter, an output schema, and full annotation coverage, the description supplies everything an agent needs: what evidence is returned, when to consult it, that no tests execute, and what an empty response means.

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?

With a single parameter at 100% schema coverage, the schema already carries the meaning ('Definition id the player tested, e.g. "rudder"'). The description's 'for one part' reinforces the scope but adds no format or syntax detail beyond the schema, so baseline 3 applies.

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 a specific verb and resource — 'Read the player's recorded in-game checks for one part' — and enumerates exactly what is returned (latest result per test case, stale counts, contradictory checks). This clearly separates it from sibling read tools like get_part_definition or get_part_orientation, and the line 'runs no test' distinguishes it from validation tools.

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 gives an explicit trigger: 'Use it before relying on an orientation or mounting rule for that part.' That is clear situational guidance, though it does not name a specific alternative tool for when the caller wants to actually re-run or apply checks.

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