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

Although annotations already mark this as a safe read-only operation, the description adds substantial behavioral context: how unresolved values arise, why basic dimensions are not-applicable, why angles and location callouts need a frame, how unlocated datums affect checkability, and that entity IDs are revision-bound. This goes well beyond the annotations.

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 purpose is front-loaded in the first sentence and the rest is dense with necessary domain guidance. It is longer than typical, but most sentences carry checkable behavioral rules; a small amount of repetition around unresolved callouts could be trimmed.

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 the complexity of PMI/GD&T semantics, the description is complete enough for an agent to interpret the output correctly, especially alongside the existing output schema. It covers value resolution, frame dependence, datum location, pmi_kind distinctions, and unit assumptions.

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 coverage is 100%, so both parameters are already documented. The description reinforces that the URI should come from inspect and that entity IDs are valid only for that revision, but it adds little about the include parameter beyond the schema's own enum values.

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 specific verb and resource: 'Report the dimensions, geometric tolerances, and datums that a STEP artifact declares, as data.' It clearly distinguishes this from sibling tools like inspect and measure by emphasizing declared PMI data rather than file discovery or measurement.

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 explicit usage guidance throughout: check value_resolved before comparing, treat unresolved callouts as not checkable, interpret pmi_kind before saying a file declares nothing, and use the artifact reference from inspect. These are direct when/when-not instructions tied to the tool's domain.

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

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

Beyond the readOnly/idempotent annotations, it discloses what is returned (deltas expressed in the baseline's declared unit, PMI counts, document facts) and adds interpretive caveats the annotations cannot carry: PMI counts show presence of callouts, not whether any is satisfied, and file-level facts do not explain design intent. That is real behavioral context an agent needs to avoid misreporting results.

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 core action and accepted input forms come first, then the return contents, then the interpretation caveats. Four dense sentences, each adding a distinct fact, with no redundant restatement of the name or schema.

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 both parameters documented, the description covers the remaining gaps: unit conventions for deltas, what is and isn't included in PMI counts, and the scope limit of the comparison. Nothing needed to call it correctly is absent.

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 100% and already documents that each uri is a file: URI or absolute path, so the description's repeat of that phrasing adds little. Baseline 3 applies since the schema carries the parameter burden.

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?

States a specific verb and resource ('Compare baseline and candidate STEP artifacts') plus the accepted input forms. The comparison framing clearly separates it from siblings like inspect, measure, and describe_pmi, which operate on a single artifact.

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 comparison intent implies when to use it, but the description never explicitly routes the agent: it doesn't say to use diff instead of running inspect twice, or state prerequisites (same unit system, both files must exist). Usage is inferable but not spelled out.

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

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

Beyond the annotations, the description discloses revision-bound ID validity, producer/server scoping, pagination behavior, occurrence ID semantics, and the distinction between distance and other measure inputs. These are important behavioral constraints that are not captured by readOnlyHint, idempotentHint, or destructiveHint.

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 generally front-loaded, starting with what the tool finds and when to use it. Most sentences earn their place, though the final measure-related guidance is tangential enough to keep it from being maximally concise.

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 the 14 parameters, nested artifact object, output schema, and annotations, the description provides enough context to call the tool correctly: it covers filters, pagination, revision binding, component scoping, and downstream use by measure. No critical agent-facing behavior appears missing.

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 coverage is 100%, so the schema already documents all 14 parameters. The description adds useful semantic context by explaining face and edge filter combinations, giving an example such as { surface_type: "cylinder", min_radius: 2 }, and clarifying component_name occurrence scoping.

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 states a specific verb and resource: find faces, edges, vertices, or solid bodies in the revision-bound artifact returned by inspect. It also distinguishes the tool from its sibling measure by explaining that find_entities should be used first because measurements name entity IDs rather than coordinates.

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 explicit usage guidance: use before measure, follow pagination until has_more is false when counts or minimums matter, scope by component_name when needed, and never reuse IDs after the file changes or in another tool. It also explains that distance measurements use sources/targets while every other measure kind uses entity_ids, and points to cad://help for required fields.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real behavioral context beyond them: unit labelling on every result, bounding boxes being conservative envelopes rather than tight fits, and volume returning null when there is no solid material. It does not mention failure modes for unreadable or missing paths, which keeps it short of a 5.

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?

Five sentences, none wasted, with the primary action and ordering constraint front-loaded before the caveats about units, bounding boxes, and null volume. Each sentence conveys a distinct fact an agent needs.

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?

An output schema exists, so return values need not be re-explained, and the description covers the non-obvious cases that output schemas typically do not convey: which unit lengths use, that bounding boxes are conservative, and when volume is null. Complete for a two-parameter read-only inspection tool.

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 100%, so both parameters are already documented, including the enumeration of size/counts/health. The description's 'use include to request only size, counts, and/or health sections' restates the schema rather than adding new semantics. Baseline 3 applies when the schema carries the parameter burden.

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?

States a specific verb and resource ('Inspect a local STEP artifact') plus the accepted input forms (filesystem path or file: URI). It also names what is returned (content revision, dimensions, counts, B-rep validity), so an agent can distinguish it from find_entities or measure without opening the schema.

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?

Explicitly sequences the tool ('Call this first') and routes follow-up work to siblings by saying to use the returned artifact reference 'for entity searches and measurements.' That is a clear when-to-use signal tied to concrete alternatives rather than an inference.

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

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

The annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond annotations: units are declared and labelled on every result, ray grids report their grid size, max_rays can be raised to 20000, and the tool deliberately returns geometric measurements rather than engineering judgments.

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 front-loaded with the measurement kinds and then adds only operational constraints, units, ray-grid behavior, help-resource guidance, and output scope. Every sentence contributes useful selection or invocation context without becoming a parameter manual.

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 the tool's complexity, the full input schema, the output schema, and the read-only annotations, the description provides enough context for correct selection and invocation. The cad://help pointer is especially important for the kind-specific argument sets, and the output schema can carry return-value details.

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 100%, so the input schema already carries most parameter meaning. The description adds some useful context, including that artifact and entity IDs should come from find_entities, that lengths use the declared unit, that max_rays can reach 20000, and that cad://help documents per-kind required fields, but it does not substantially explain the 22-parameter surface beyond the 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 starts with a specific verb, "Measure", and enumerates the exact measurement kinds the tool performs: distance, thickness, draft, rays, point geometry, sections, and continuity. It also clarifies the boundary that results are geometric measurements only, not engineering acceptance or design recommendations, which helps distinguish it from downstream analysis 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 clear prerequisite guidance: use the artifact reference and entity IDs from the same find_entities result, and fetch cad://help for the required fields of each kind. It does not explicitly compare when to use measure versus siblings like inspect, diff, or describe_pmi, so it stops short of full when/when-not guidance.

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