Inspection Plan

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

The description goes well beyond the readOnlyHint/openWorldHint annotations, explaining the 10:1 gauge-maker's ratio rule, the per-family instrument ladder, the GD&T/datum routing logic, and exact failure modes (no_tolerance, no_instrument) with the `unmeasurable` field. It also enumerates the full return payload, so an agent knows exactly what will happen.

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 description is dense but not padded: the first sentence states the deliverable, the middle paragraph justifies the method, and the final paragraph defines the return envelope and failure codes. It is front-loaded and every sentence earns its place.

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?

No output schema exists, and while the description lists all return keys and thoroughly explains ok=False and `unmeasurable`, secondary keys like by_method, retired, next_balloon, band_pct, and basis are left to inference. For a complex planning tool this is almost complete, but a brief clarification of those remaining fields would remove all ambiguity.

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?

Schema description coverage is 0% and there are only two parameters, so the description must carry the load. It interprets `ratio` as the gauge-maker's resolution ratio with a default of 10:1 and clarifies that the mapping is exact arithmetic; `page` is identified as the drawing page being characterized, though its exact identifier format is left implicit.

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 opens with a precise definition: 'The characteristic list for a drawing page as data' and enumerates exactly what is included: every dimension, feature control frame, feature note, ballooned, with nominal, limits, and a suggested measurement method per row. This clearly distinguishes it from report/annotation-style sibling tools like fai_report or balloon_drawing.

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?

The description does not explicitly name alternatives or say 'use this instead of X,' but it gives strong contextual signals about when this tool is appropriate: it applies to a drawing page, follows a tolerance-to-instrument mapping, and returns a plan with unmeasurable reasons. This is clear context, though explicit exclusions would earn a 5.

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