GD&T Check

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe read-only calculation. The description adds useful behavioral details: how position offset works (diametral 2*hypot(x,y)), mmc_bonus adds bonus tolerance, and the return object shape. It doesn't disclose edge cases like what happens when actual is null or how datum_refs are used, but the core behavior is transparent.

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 compact and information-dense, front-loading the purpose and then listing controls and key parameter semantics. The control list is long but necessary for a tool with no enums in the schema. The return shape is stated in one line. Slightly dense but efficient.

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?

For a read-only calculation tool with no output schema, the description covers the main inputs and return shape. However, it doesn't explain what 'zone' means precisely, how datum_refs affect the check, or what happens when actual is null. Given the tool's complexity (GD&T logic), a bit more context on interpretation of pass/margin would help, but the essentials are present.

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%, so the description must compensate. It does: it explains control (the GD&T control type), actual (measured deviation), offset (for position, pass {x,y} for diametral 2*hypot(x,y)), mmc_bonus (adds bonus tolerance), and the return fields. It doesn't explain zone or datum_refs in detail, but the core parameters are semantically enriched beyond the bare schema.

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 clearly states the tool checks a measured feature against a GD&T tolerance zone, with a specific verb ('Check') and resource ('measured feature against a GD&T tolerance zone'). It lists the supported control types, which distinguishes it from generic analysis tools. However, it doesn't explicitly differentiate from sibling tools like tolerance_stackup or fit_check, though the GD&T focus is fairly specific.

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 implies usage: it's for checking a measured feature against a tolerance zone, and the control list tells the agent which GD&T controls are supported. It doesn't explicitly state when to use this vs alternatives like tolerance_stackup or fit_check, nor does it mention prerequisites (e.g., needing a measured feature or datum references). The context is clear enough for a domain-aware agent but lacks explicit routing guidance.

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