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

No annotations are provided, so the description carries the full burden. It does not disclose any side effects, such as whether the arc is added to the sketch permanently, whether the sketch must be active, or what happens on failure. This is a significant gap for a mutating tool.

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 concise and well-structured: first a one-liner, then a compact list of kinds and their parameters. Every sentence provides necessary information with no fluff.

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?

The description covers the main semantic aspects of the parameters and kinds, but because there is no output schema or annotations, it omits behavioral details (e.g., return value, side effects). For a tool with 9 params and varied kinds, it's adequate but not fully complete.

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?

The description adds significant semantic meaning beyond the bare schema: it explains the three kinds and which parameters are used for each, and notes the meaning of sweep_radians (positive = CCW). The schema has 0% coverage, so this compensation is essential.

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 verb 'Add' and the resource 'arc', with specific kinds and parameters for each. It distinguishes from siblings by specifying arc-specific parameters, though it doesn't explicitly differentiate from other add_* 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?

The description implies usage by listing kinds and required parameters, but doesn't explicitly say when to use this tool vs alternatives like add_circle or add_spline. It provides enough context for selection but lacks explicit 'when not to use' guidance.

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?

There are no annotations, so the description carries the burden of explaining behavior. It does state the side effect ('Add a circle') and the return value ('Returns circle_index'), but it omits details like whether the sketch must pre-exist, coordinate format, or failure behavior. This is adequate but not rich.

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 three short sentences with a clear front-loaded verb, then mode-specific requirements, then return behavior. Every sentence contributes useful information with no filler or redundancy.

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 7-parameter tool with no annotations or output schema, the description covers the main mode dependencies and the return value, which is helpful. However, it leaves the required 'sketch' parameter and point array formats unexplained, making it minimally adequate rather than fully complete.

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 add meaningful semantics by linking kind to required parameter groups and clarifying the center_radius and 3pt variants. However, it does not explain the format of point/center arrays or the required 'sketch' parameter, leaving gaps.

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's action ('Add a circle') and the two construction modes, but it does not explicitly distinguish this from sibling tools like add_ellipse or add_arc. It is specific and unambiguous enough for selection.

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 gives explicit usage context by defining the two kinds ('center_radius' vs '3pt') and which parameters each requires. It lacks explicit exclusions or alternatives like 'use add_ellipse for ellipses', but the mode guidance is clear and actionable.

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?

With no annotations present, the description must carry the burden of disclosing behavioral aspects. It mentions that parameter-name expressions propagate when parameters change and that literal mm creates a baked value, which indicates parametric vs. non-parametric behavior. However, it does not state whether the operation is read-only, modifies the document, or has other side effects, leaving a gap in transparency.

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 succinct yet dense with useful information. It begins with a core purpose, then systematically explains behavior and parameter relationships. Each sentence adds value without redundancy, making it easy to parse and apply.

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?

The description covers essential usage details, including the gotcha about expressions and baked values, which is critical for correct usage. It also clarifies entity requirements per kind. While it omits explicit explanations for 'sketch' and 'text_pos', these are likely inferred from the schema and typical CAD workflows, so the overall completeness is high.

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?

The description provides detailed semantics for the 'kind' parameter and how it shapes the 'entities' parameter (e.g., 2 point refs for distance, 2 line refs for angle). It also explains the 'expression' parameter. However, it does not elaborate on the 'sketch' or 'text_pos' parameters, which are left mostly unexplained beyond schema titles. Coverage is good but not complete.

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's purpose: adding a dimension with an expression. It also lists the supported kinds (distance_h, distance_v, distance, angle, radial, diameter), making the scope unambiguous and distinguishing it from other tools like drive_joint or extrude.

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 gives practical usage instructions, such as how to use parameter-name expressions versus literal values, and how entities depend on the kind. However, it does not explicitly mention when to prefer this tool over alternatives or provide context about typical usage scenarios, which weakens the guidelines.

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?

With no annotations, the description carries the transparency burden. It accurately communicates the creation behavior and specifies mm units, but it does not disclose coordinate frame conventions, whether axis endpoints are radii or semi-axes, sketch prerequisites, or side effects beyond adding the ellipse.

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 a single, front-loaded sentence with no filler. Every phrase adds information: the operation, the geometric definition, and the units.

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 simple creation tool with four required parameters and no output schema, the description provides the core semantics but leaves gaps: the sketch parameter is unexplained, and the array parameters lack structural detail. It is minimally viable but not fully complete.

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 maps three parameters to their geometric meaning and states units, but the sketch parameter is not explained and the coordinate arrays are not described in terms of expected elements or dimensionality.

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 adds an ellipse and defines the exact construction method (center + major-axis endpoint + minor-axis endpoint). This differentiates it from sibling shape tools like add_circle, add_arc, and add_spline.

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 intended use is implied by the operation name and description, but there is no explicit when-to-use guidance or mention of alternatives. The description does not say, for example, to use this tool when an ellipse is needed rather than a circle or spline.

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?

No annotations are provided, so the description must disclose behavioral traits. It only states the operation and parameter values, omitting side effects, failure modes, permission requirements, or reversibility—important for a mutation tool.

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 two concise sentences, front-loaded with the action and immediately providing essential parameter details without redundant or extraneous content.

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 no output schema, no annotations, and 0% parameter coverage, the description is incomplete. It covers only two of three parameters, lacks behavioral context, and gives no indication of return values or effects, making it inadequate for a complex 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?

The schema provides 0% description coverage, so the description must compensate. It explains the 'kind' enum and the 'entities' reference format, but the 'sketch' parameter is left unexplained, leaving partial compensation.

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 'Apply a geometric constraint' and enumerates allowed kinds and entity reference formats, which unambiguously identifies the tool's function and distinguishes it from similar tools like add_dimension.

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 use for adding geometric constraints but offers no explicit guidance on when to use this tool over alternatives (e.g., add_dimension) or any exclusions or prerequisites.

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?

With no annotations, the description must carry the behavioral burden. It adds useful context (top face, +Z normal, z is informational) and notes dependencies, but it does not disclose side effects (e.g., whether it modifies the body in place, requires an existing body, or returns any result). It also omits any requirement details or error conditions, leaving some ambiguity for the agent.

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 concise and well-structured, with a clear opening sentence followed by bullet-like clauses for kind, position, and extent. Every sentence contributes to understanding the tool's behavior, with no fluff or repetition. It is front-loaded with the core purpose and then details the key decision points.

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 (11 parameters, no annotations, no output schema), the description covers the critical decision points: the face, the position semantics, and the parameter dependencies for different hole styles. However, it omits a few items like what the tool returns (if anything), whether a body must already exist, and the significance of the 'name' parameter. These are missing but not critical for basic usage, so it's fairly complete.

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?

The schema has 0% description coverage, so the description must compensate. It explains the meaning of kind (simple, counterbore, countersink) and which parameters are needed for each, describes position_mm (x/y locate, z informational), and clarifies extent_kind (all vs. distance, requiring depth_expression). It does not explain 'body' or 'name' beyond their titles, but these are relatively self-evident. Overall, it adds substantial semantic value for most parameters.

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 action: 'Add a hole on the body's top face (max-Z, +Z normal).' It specifies the resource (body) and the precise location, distinguishing it from other add_* tools like add_circle or add_line. The verb is action-oriented and the scope is unambiguous.

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 gives contextual guidance: it mentions the top face and normal, and clearly states parameter dependencies for kind (counterbore/countersink) and extent_kind (distance). However, it does not explicitly mention alternatives or when not to use this tool versus other feature-creation tools, such as extrude or revolve.

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?

With no annotations, the description must carry the transparency burden. It discloses the core effect (adds a line) and the unit system (mm), but does not mention prerequisites, failure modes, or side effects beyond the addition.

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?

One short sentence plus a parenthetical parameter clarification; every word carries meaning and the main action is front-loaded.

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 simple three-parameter geometric command, the description provides essential semantic details (points and units) and the target resource. It could mention needing an existing sketch or the return value, but the tool's complexity is low enough that this is a minor gap.

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 compensates by specifying p1 and p2 as [x, y] in mm. The sketch parameter is left to its name, but it is straightforward given the context 'to a sketch'.

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 action ('Add'), a concrete resource ('a single line to a sketch'), and the coordinate form p1/p2. This clearly distinguishes it from sibling tools like add_rectangle, add_circle, and add_spline.

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?

No explicit when-to-use or alternative guidance is provided, but the phrase 'single line' implies it is for straight segment creation rather than arcs, splines, or closed shapes. This is usable but only implicit.

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?

With no annotations provided, the description carries the transparency burden. It discloses idempotency, non-overwriting behavior, reserved-name validation, and the Fusion math-binding rationale. It does not describe return or error behavior, but the side effects and gotchas it does reveal are specific and useful.

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 three short, information-dense sentences. It front-loads the core purpose, then adds parameter shape and a non-obvious validation note. No sentence 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?

For a simple one-array parameter tool with no output schema, the description covers purpose, parameter shape, idempotency, and validation behavior. It does not explain what the tool returns or how errors surface, which is a minor gap given no output schema exists.

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?

The input schema is a generic array of objects with no property descriptions, so the 'Each def: {name, expression, units?, comment?}' line adds essential structure. It also notes reserved math names. It could further clarify value types, expression syntax, or unit formats, but it compensates well for the 0% schema coverage.

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: 'Add user parameters.' It also clarifies that existing names are skipped, not overwritten, which distinguishes this from update_parameter and list_parameters. This is a clear, non-tautological purpose statement.

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 provides clear context: it is idempotent, safe to re-run, and will not overwrite existing parameters. It implicitly separates this from update_parameter, but it does not explicitly name alternatives or state when not to use this tool, so it stops short of full guidance.

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?

No annotations are provided, so the description carries full burden. It discloses the meaning of 'inscribed' and the sides constraint, but does not clarify how center and vertex relate, whether the polygon is closed, or any side effects.

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 highly concise—two sentences with no filler. It front-loads the action and directly states the core purpose, making every word earn 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?

Despite being a simple tool, it has 5 parameters and no output schema. The description omits critical semantics for three parameters and does not explain the relationship between center and vertex, making it insufficient for an agent to correctly invoke the 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 0%, so the description must compensate. It adds meaning for 'sides' (>=3) and 'inscribed' (vertices on radius), but leaves 'center', 'vertex', and 'sketch' completely unexplained, leaving 60% of parameters without semantic guidance.

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 identifies the action ('Add') and resource ('regular polygon'), and specifies a key constraint (sides >= 3). It differentiates from sibling tools like add_rectangle or add_circle by focusing on polygons.

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?

There is no guidance on when to use this tool versus alternatives, nor any exclusion criteria. The only contextual hint is the 'inscribed' default, which is behavioral rather than usage-oriented.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It does well by stating the outcome ('Add a rectangle'), the return value ('Returns line_indices for the 4 edges'), and the role of each point in each mode. It does not mention failure conditions, prerequisites, or side effects beyond the added geometry, which keeps it from 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?

The description is three compact sentences, with the main action and key parameters front-loaded. Each sentence earns its place: the first states purpose and kind values, the second gives the return value, and the third explains the point semantics per mode. No filler or repetition.

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 geometry-creation tool with 5 parameters, no annotations, and no output schema, the description is reasonably complete. It explains all three construction modes, the return value, and the meaning of the coordinate parameters. It does not cover error scenarios, units, coordinate-space assumptions, or the requirement that the target sketch already exist, but it is adequate for selecting and likely invoking the 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 0%, so the description must compensate for the bare schema. It substantially does so by defining the meaning of p1, p2, and p3 for each rectangle kind, and by enumerating valid kind values. However, it does not explicitly state that p3 is only used when kind='3pt' or clarify whether p3 is semantically required for that mode, and 'sketch' is only implied as a target container.

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: 'Add a rectangle to a sketch.' It also identifies the three construction modes (center, corner, 3pt) and the return value, clearly distinguishing this from sibling tools like add_line and add_circle.

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 how-to guidance for each kind variant, explaining exactly how p1, p2, and p3 should be interpreted. However, it does not explicitly state when to prefer add_rectangle over a more general alternative like add_polygon, so it lacks explicit exclusion/alternative guidance.

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?

No annotations are provided, so the description carries the full burden. It mentions 'fitted spline' and 'optionally closed' but does not disclose whether the spline is a smooth curve through all points, how the closed option affects the curve, or any side effects like modifying the sketch. It also doesn't mention units or coordinate system beyond mm, which is helpful but minimal.

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 a single sentence that is concise and front-loaded with the core purpose. It includes the key details (points in mm, optional closed) without any fluff. Every word 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?

Given the tool has 3 parameters, no output schema, and no annotations, the description is adequate but not complete. It covers the main purpose and the 'closed' option but does not explain the 'sketch' parameter or the exact structure of 'points'. For a simple spline tool, this is acceptable but could be improved with more detail on the points format and sketch context.

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 explains 'points' as a list of [x, y] points in mm and 'closed' as optional, but does not detail the format of the points array (e.g., nested arrays, objects) or the 'sketch' parameter (which is required but not described). The description adds some meaning but leaves gaps for the required 'sketch' parameter.

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 adds a fitted spline through a list of [x, y] points in mm, with an optional closed parameter. It distinguishes from sibling tools like add_line, add_arc, add_polygon by specifying 'fitted spline' and the point list input.

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 in a sketching context (points in mm, optional closed) but does not explicitly state when to use this vs alternatives like add_polygon or add_arc. No exclusions or alternative tool references are provided, but the context is clear enough for a basic spline creation.

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?

No annotations were provided, so the description carries the full burden of behavioral disclosure. It explains the failure mode it addresses (self-intersecting polygons silently returning profiles=2) and the boolean result format. It doesn't provide exhaustive return-format detail (e.g., whether there's a message field), but it's fairly transparent for a simple assert-type tool.

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, zero filler. The first sentence states the core check and return behavior; the second adds crucial 'when to use' context. 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?

For a compact assert utility with only 2 parameters and no output schema, the description covers the core function, the return outcome, and the motivating use case. It could specify whether 'self-intersecting' creates an exception or a specific return value, but this level of detail is likely beyond what's needed for a validation 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?

With 0% schema description coverage, the description needs to compensate for both parameters. It does explain that 'expected' refers to the expected number of closed profiles and implies how 'sketch' is used (the sketch under test). It could add explicit types/validation, but the meaning is well-conveyed given the simplicity of the parameters.

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 a specific verb+resource+intent: 'Check that the sketch has the expected number of closed profiles' and even describes the return value behavior ('Returns ok=False if not'). The second sentence distinguishes it from sibling sketch tools by explaining its unique role in catching silent self-intersecting polygon behavior.

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 says when to use it: 'Use after building a sketch to catch self-intersecting polygons (which return profiles=2 silently).' It provides a clear, practical trigger scenario and partially explains the alternative (silent behavior) it guards against, which helps an agent decide when to invoke this tool.

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?

There are no annotations, but the description carries the full behavioral burden well. It states the traversal behavior, default exclusion of healthy features, what is returned in the envelope, and why the health state might not match the API/BREP appearance.

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?

Every sentence earns its place: purpose, usage trigger, gotcha, parameters, and return envelope are structured and front-loaded. No filler or redundancy.

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?

Even without an output schema, the description gives the exact return envelope, summary counters, and per-feature fields. It also ties the tool to the broader edit-verify workflow, so an agent can reliably decide when and how to invoke it.

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%, but the description fully compensates: component_name is explained as restricting to a component while still recursing, and include_healthy is explained as including state 0 features or defaulting to broken-features-only.

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 identifies a specific verb-resource pair: sweep the feature tree and report features whose healthState != 0. It distinguishes this as a diagnostic/audit tool, not an editing or transform tool.

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 explicitly states when to call it: after ANY tool that edits sketch geometry, user parameters, or features. It also gives a concrete decision rule based on summary.failed > 0 or summary.warning > 0, including a real-world gotcha about stale Fusion UI cache.

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?

With no annotations, the description must disclose behavior. It states that world position is preserved, which is a key behavioral trait. However, it does not mention side effects such as whether original bodies are deleted, or if the operation is reversible. This leaves gaps in behavioral transparency.

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 two sentences, front-loaded with the action and immediately provides the mapping format and usage justification. There is no fluff; every sentence contributes to understanding the tool.

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 tool with one parameter, no output schema, and no annotations, the description covers purpose, usage timing, and input format. It omits potential side effects (e.g., behavior on original bodies) but otherwise provides a solid operational understanding.

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?

The schema describes only 'mapping' as an object with no additional properties, and schema description coverage is 0%. The description compensates by explicitly defining the format: 'mapping is {body_name: new_component_name}'. This adds crucial meaning and clarity 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 clearly states the action: 'Convert root-level bodies into named components, preserving world position.' It specifies the resource (bodies) and the result (components), and distinguishes from siblings by explaining that joints require components, not bodies.

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 gives explicit usage context: 'Multi-body designs need this before joint/motion work — Fusion's joints operate on components, not bodies.' It explains when it should be used but does not explicitly mention alternative tools or when not to use it.

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?

No annotations are provided, so the description carries the behavioral burden. 'Return' implies a read-only operation, and it discloses optional body_name behavior and occurrence traversal. It stops short of describing error cases or exact output shape, but the key behavior is conveyed.

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 short sentences front-load the main purpose and scope choice, with no filler or repetition. Every word contributes meaning.

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 no output schema and no annotations, the description gives enough for a simple optional-parameter query: units, scope, and traversal behavior. It could specify the exact return structure or not-found behavior, but the description is largely complete for invocation.

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?

The schema has 0% description coverage, so the description must explain the parameter. It does: body_name is optional, used to select a body, and omitting it returns all bodies. It could add name-format details, but the core semantics are covered.

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 uses a specific verb and resource: 'Return mm bbox + extents for a body (by name) or all bodies if name omitted.' It clearly distinguishes this from siblings like measure, volume, and mass by naming the exact geometric output and optional body scope.

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 clearly states when to use the tool: for a named body or all bodies, and adds traversal context with 'Walks root + every occurrence.' It does not explicitly name alternatives or exclusions, but the context is clear enough for selection.

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?

No annotations exist, so the description must carry the behavior disclosure burden. It does clarify coordinate system and units, but it does not disclose return shape for multiple bodies, whether the tool is read-only, or what happens with invalid/missing body names. This is useful but not fully 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 one short sentence that immediately front-loads the action (`Return center of mass`) and includes every necessary clue without wasting words. There is no filler or repetition.

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 only one optional parameter and no output schema, this description is nearly complete. However, the phrase `for a body or all bodies` is ambiguous as to whether the tool returns a single combined center of mass for all bodies or a collection of centers. It also does not describe the returned vector shape (e.g., x, y, z). Lacking that makes it not fully complete.

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 is the only meaningful note about parameters. The single parameter, `body_name`, is semantically explained by `for a body or all bodies` (implicitly null/omitted means all, provided string means a specific body), adding relevant meaning beyond the plain 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 states a specific action (`Return center of mass`), identifies the resource (`body` or `all bodies`), and adds useful details (`mm`, `world coordinates`) to disambiguate from sibling tools like `mass`, `bounding_box`, and `volume`.

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 phrase `for a body or all bodies` provides context about scope, but there is no explicit guidance on when to choose this tool instead of alternative measure tools, no prerequisites, and no exclusions for cases when the body name may not exist or the assembly is not fully grounded.

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?

No annotations are provided, so the description must carry the full burden. It mentions that 'two_dist' needs distance2 and 'dist_angle' needs angle, which is some behavioral detail, but does not disclose side effects, whether the operation is destructive, or what happens on failure. It does not contradict annotations (none), but is insufficient.

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 very short (two sentences), but it is under-specified rather than concise. The first sentence is clear, but the second lists options without context. It is efficient in length but could be more structured to explain the parameters and usage.

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?

The tool is moderately complex with 6 parameters and no output schema. The description does not cover param semantics or usage context, leaving significant gaps. A description should explain the kind options, parameter relationships, and perhaps the effect on the model, but it does not.

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 0%, so the description must explain all 6 parameters. It only hints at kind and mention of distance2 and angle in the kind line, but does not explain what edge_handles, distance, or name mean. No format or units are given. This is inadequate for a 6-parameter tool.

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 the tool chamfers specific edges by handle, which is a clear verb+resource, but it does not distinguish from sibling 'chamfer_edges_by_geometry' which also chamfers edges. The description mentions 'kind' options but doesn't explain what they mean or when to use them, so it is not fully clear.

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?

No guidance on when to use this tool vs 'chamfer_edges_by_geometry' or when to choose between 'kind' values. The description lacks any context about prerequisites or typical usage scenarios. Sibling tools like fillet_edges exist, but no exclusions or alternatives are mentioned.

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?

No annotations are provided, so the description carries the full burden. It mentions the 'kind' parameter and its sub-options (equal, two_dist, dist_angle) but doesn't disclose what happens with different kinds, whether the operation is destructive, or any side effects. It doesn't explain the geometric filter behavior beyond the kind parameter.

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 very short (two sentences) and front-loaded with the main purpose. However, it's under-specified; the second sentence is a terse list of 'kind' options without context. It's concise but not well-structured for usability.

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 8 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the geometric filter mechanism, how to use 'parallel_to' or 'min_length_mm', or what the result looks like. The tool is complex (multiple chamfer kinds) but the description provides minimal guidance.

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 explains 'kind' values but doesn't explain other parameters like 'parallel_to', 'min_length_mm', 'name', or the relationship between 'distance' and 'distance2'. The description adds minimal value beyond the schema's field names.

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 the tool chamfers edges of a body by geometric filter, which is a specific verb+resource. It distinguishes from the sibling 'chamfer_edges' by adding 'by geometry', though it doesn't explicitly contrast with it. The 'kind' parameter is briefly explained, adding some clarity.

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?

No guidance on when to use this tool versus alternatives like 'chamfer_edges' or 'fillet_edges_by_geometry'. The description implies it's for geometric filtering but doesn't state when to choose it over the simpler 'chamfer_edges' or other edge operations.

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?

With no annotations, the description bears full responsibility for behavioral disclosure. It adds a key behavioral trait: 'Never auto-pick save vs discard for dirty docs; surface the choice to the user.' This clarifies how the tool handles unsaved changes. However, it does not describe the full lifecycle (e.g., what happens after save/discard, whether the document can be reopened, or error conditions). It provides some transparency but not comprehensive.

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 two short sentences with no fluff. Each sentence earns its place: the first states the action, the second clarifies a critical behavioral constraint. It is front-loaded and immediately understandable.

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 simple tool with one parameter, the description covers the essential functionality (close active doc), parameter values, and a key safety behavior. It lacks details on edge cases (e.g., no open document) or side effects of specific confirm choices, but given the simplicity and absence of an output schema, it is reasonably complete.

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?

Since schema description coverage is 0%, the description must elaborate on parameters. It does so by specifying acceptable values ('save', 'discard', 'prompt') and the rule to never auto-pick, which gives meaning to 'confirm'. It doesn't explain each value's effect explicitly but implies it via the warning. This adds substantial value 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 action: 'Close the active document.' It uses a specific verb (close) and a specific resource (active document), distinguishing it from sibling tools like save or open_doc, which serve different purposes. No ambiguity.

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 provides guidance on the 'confirm' parameter values but does not explicitly discuss when to use this tool versus alternatives (e.g., when to save vs. close). It implies usage for closing, but lacks explicit exclusions or comparisons to other tools like save. The behavioral rule about not auto-picking save/discard is more about parameter handling than tool selection.

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?

With no annotations provided, the description carries the full burden of conveying behavioral traits. It only states the operation and keep_tools effect, but does not disclose whether it modifies bodies in place, returns new bodies, or has any destructive side effects. This is insufficient for an agent to understand the impact of calling this tool.

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 extremely concise, using two short sentences, which is efficient. However, it may be too terse for such a complex operation, as it omits essential context about the inputs and behavior, yet as a stylistic choice it is well-structured and front-loaded with the core purpose.

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 (boolean operation on tool bodies) and lack of annotations or output schema, the description is inadequate. It does not explain how target_body and tool_bodies relate, what the result is, or any prerequisites or side effects. This is a significant gap for an agent to correctly invoke the 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?

The description explains the operation parameter with its allowed values (join|cut|intersect) and keep_tools as 'preserve tool bodies after op', which adds semantics beyond the schema. However, it does not describe target_body or tool_bodies at all, and with 0% schema description coverage, these key parameters remain ambiguous. The description covers only a subset of the parameters.

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 'Boolean combine' which clearly indicates applying boolean operations (join, cut, intersect) to tool bodies. It distinguishes from siblings like 'drive_joint' or 'extrude' by focusing on boolean combinations. However, it is somewhat terse and doesn't explicitly mention target_body and tool_bodies as inputs, so there is slight ambiguity but still the purpose is clear.

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 provides no guidance on when to use this tool versus alternatives like 'revolve', 'fillet_edges', or other body operations. There is no mention of scenarios where boolean combine is appropriate or contraindicated, leaving the agent without context for selection.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It usefully explains that the normal_to_face_by_geometry mode 'finds the face whose normal matches' and specifies units in mm. However, it does not describe side effects, failure modes, what document/workspace is affected, or what happens if no matching face is found.

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 front-loaded: a one-line purpose statement followed by two short mode-specific bullet lines. Every sentence adds useful information with no redundancy or filler.

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 6-parameter tool with no output schema and no annotations, the description provides enough detail to invoke both construction modes correctly, including units and face-normal matching behavior. It is slightly incomplete because it omits the purpose of the name parameter and gives no indication of return values or errors, but the core invocation context is well covered.

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, and it does. It defines p1 and p2 as [x, y, z] arrays in mm, defines kind values, and explains body plus face_normal usage for the second mode. It does not describe the optional name parameter, preventing a perfect score.

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 and resource: 'Create a construction axis.' It clearly distinguishes this tool from sibling tools like create_construction_plane and create_construction_point by naming the exact object type. It further clarifies purpose by enumerating the two axis-construction kinds.

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 gives clear context for when to use each of the two kinds: 2_points for point-based axes and normal_to_face_by_geometry for face-normal-based axes. It does not explicitly list exclusions or alternatives, but the mode-specific guidance is sufficient for most selection decisions.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds useful behavior details such as default plane/axis names, point units in mm, and expression examples. However, it does not disclose side effects, document mutation, prerequisite conditions, or failure modes.

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, scannable, and front-loaded with the core purpose. Each line adds distinct value: the kind enum, mode-specific parameter maps, examples, and defaults. There is no filler or repetition.

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 (11 parameters, no annotations, no output schema), the description does a strong job covering all construction modes, required parameter relationships, units, and defaults. It falls slightly short of a 5 because it does not describe the result/return value or any post-creation effects.

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 0% schema description coverage and 11 parameters, the description compensates strongly by mapping each construction kind to its relevant parameters and giving concrete formats for expressions, point coordinates, and defaults. Only the `name` parameter is not explicitly elaborated, but its meaning is reasonably inferable from context and schema title.

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 the specific verb-object pair 'Create a construction plane' and immediately enumerates the four construction modes (offset, midplane, at_angle, 3_points). This clearly distinguishes it from sibling tools like create_construction_axis and create_construction_point.

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 provides clear mode-specific usage context, explaining which parameters apply to each kind of plane. It does not explicitly name sibling alternatives or state when not to use the tool, so it stops short of a 5, but the usage conditions for each variant are unambiguous.

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?

No annotations are provided, so the description carries the full transparency burden. It communicates that a construction point is created at specified coordinates, but it does not disclose whether a document context is required, what coordinate frame is used, whether the operation fails if a point already exists at the location, or what is returned.

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 a single, front-loaded sentence containing exactly the needed information: action, object, coordinate format, and units. There is no redundant or filler text.

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 simple creation tool, the description covers the core invocation adequately, but it omits some useful operation context such as the coordinate frame, active document requirements, and behavior when an invalid coordinate is provided. Since there is no output schema, this missing context is costlier than it would otherwise be.

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?

The schema provides almost no semantic information (0% coverage), but the description adds essential meaning by specifying that coords is an explicit [x, y, z] array expressed in mm. This goes well beyond the bare array type in the input schema. The optional name parameter remains inferable from the schema directly.

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 action (create) and a specific resource (construction point) at explicit [x, y, z] coordinates in mm. This clearly distinguishes it from related tools such as create_construction_plane, create_construction_axis, and delete_construction.

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?

There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites such as an active document or sketch context. The description defines what the tool does but not the circumstances under which the agent should select it.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It indicates a creation action but does not mention side effects, whether bodies must already exist, whether the contact set is persistent, or how it affects motion analysis.

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 a single, front-loaded sentence with no filler. Every word contributes to the core purpose and the key constraint.

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?

The tool is simple, but with no annotations and no output schema, the description leaves important operational details unstated: what happens on success, what body references are valid, and how the contact set integrates with physics/motion analysis.

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 0% and body_names has no item type or description. The description adds the '2+ bodies' constraint, but it does not specify the expected format, whether items are names or IDs, or how the array maps to actual bodies.

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 uses a specific verb and resource: 'Create a contact set' for 'physics / motion analysis between 2+ bodies.' It clearly distinguishes this from sibling tools like create_joint or create_rigid_group, though it does not explain what a contact set is or how it behaves.

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?

No guidance is provided on when to use this tool versus alternatives such as create_joint or create_rigid_group. There are no prerequisites, exclusions, or context about when a contact set is the appropriate choice.

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?

Without annotations, the description discloses behavior comprehensively: explains return values, error cases with conditions, and specific Fusion behaviors (e.g., ball motion ignores axis, accepts only pitch=Z, yaw=X). It also notes persistence of offset_mm across user-param changes.

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 well-organized with bullet-like structure and headers (motion_type, axis, offset_mm, angle_deg, name, Errors). It's slightly long but each sentence adds value; no fluff.

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 (7 params, no annotations, no output schema), the description is exceptionally complete: covers usage, parameter semantics, return format, error modes, and integration with other tools. It enables an agent to invoke correctly without external references.

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 0%, but description covers all 7 parameters with practical details: geometry handles and kinds, motion_type values and DOF, axis relative to local frame, offset_mm with example usage, angle_deg for specific motions, and name. This fully compensates for the schema gap.

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 creates a joint between two entity handles, specifies supported entity kinds and motion types, and provides detailed examples. It effectively distinguishes from sibling tools like drive_joint and set_joint_limits by noting the joint_name is used for downstream calls.

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?

Provides explicit guidance on when to use: specifies handle formats, which tools to get handles from, and explains motion types with analogies (e.g., revolute for hinges). It also mentions when not to use (e.g., Axis ignored for ball) and how offset_mm is preserved unlike Move-based positioning.

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?

With no annotations, the description carries the full transparency burden. It honestly discloses the core effect and the 'move as one' behavior, but it does not mention side effects, reversibility, prerequisites, or how the group interacts with existing joints/constraints.

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 a single front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and core behavior.

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 simple two-parameter operation, the description is workable, but it lacks caveats around reversibility, failure modes, or relationship to sibling joint/constraint tools. With no annotations and no output schema, a bit more context would make it fully complete.

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?

The description adds meaning to component_names by specifying '2+' components and the rigid-group behavior. However, because schema description coverage is 0%, the optional 'name' parameter is left completely unexplained, and the item schema for component_names is empty.

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 uses a specific verb ('Lock') with a clear resource ('2+ components') and explains the result ('they move as one'). This clearly distinguishes it from sibling tools like create_joint or drive_joint.

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 phrase 'Lock 2+ components together' implies when to use it, and the 2+ constraint is helpful. However, there is no explicit guidance on when not to use it or how it differs from alternatives such as create_joint or ground_component.

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?

There are no annotations, so the description carries the full burden. It discloses the uniqueness constraint and allowed planes, but it does not explain what happens on duplicate names, whether the tool returns a reference, or any other postconditions/error behavior for a mutating operation.

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 two short, front-loaded sentences with no filler. Every clause earns its place by conveying either the action or a required constraint.

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 simple two-parameter creation tool, the description is adequate to invoke it with valid values. However, with no output schema and no mention of return behavior or how the created sketch is referenced by subsequent operations, there are clear gaps for an agent relying solely on this description.

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 by enumerating valid plane values ('plane in {xy, xz, yz}') and clarifying the name constraint ('name must be unique'), which adds meaning beyond the bare string type definitions.

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 action ('Create a new sketch') and the resource ('sketch') plus a location constraint ('principal plane'). It also specifies valid plane values, adding useful scope beyond the name, though it does not explicitly distinguish itself from sibling creation tools like create_construction_plane.

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 gives constraints but no guidance on when to use this tool versus alternatives, prerequisites, or follow-up steps. It does not mention that a sketch must be created before adding lines/rectangles or how it relates to sibling geometry tools.

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?

No annotations are provided, so the description must carry the behavioral burden. It only says 'Delete', which implies destructive intent, but it does not disclose whether deletion is permanent, what happens to dependent features, what errors occur for unknown names, or any authorization requirements.

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 a single front-loaded sentence with no filler. It communicates the verb, resource, and parameter in a compact, scannable way.

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 one-parameter destructive tool with no annotations and no output schema, the description is minimally viable but incomplete. It covers what is deleted and how it is identified, but omits side effects, error behavior, and any preconditions, leaving meaningful gaps for an agent invoking a deletion operation.

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%, but the description partially compensates by saying 'by name', clarifying that the single 'name' parameter identifies the construction entity to delete. It does not add format details, naming conventions, or behavior for invalid/missing names, so the compensation is only partial.

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 ('Delete') and resource ('construction plane / axis / point'), and states the selection mechanism ('by name'). It clearly differentiates from sibling create_construction_* tools and there are no competing delete tools in the sibling list.

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 the tool is used when you have a named construction entity to remove, but it does not explicitly state when to use it versus alternatives or mention prerequisites such as whether the entity must exist first. No exclusions or alternative tool referrals are provided.

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?

With no annotations, the description carries the behavioral burden. It conveys that this is a summary/read-only operation, and it proactively discloses that direct designs return parameters_count and timeline_count as None with those listed in result.unavailable. This adds meaningful edge-case behavior without contradicting 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 description is concise, front-loaded with the core purpose, and uses a compact list of fields. The direct-design edge case is stated in one extra sentence without unnecessary filler.

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?

Despite no output schema, the description clearly enumerates all returned fields and covers a special-case behavior for direct designs via result.unavailable. For a zero-parameter introspection tool, this is sufficiently complete.

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?

The tool has zero parameters, so parameter semantics are straightforward and the baseline is 4. The description adds helpful context by enumerating the output fields even though no input parameters exist to document.

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 identifies the tool as a summary of the active Fusion document and enumerates the exact state aspects returned: design_type, counts, units, dirty flag, components, parameters, timeline. This distinguishes it from sibling mutation and measurement 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?

The description implies usage for inspecting the active document state, but it does not explicitly state when to choose this tool over alternatives or mention any exclusions. The direct-design caveat is useful context but not replacement for explicit usage guidance.

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?

No annotations are provided, so the description must carry the burden. It covers key behaviors: the order of trying jointMotion attributes, silent ignoring of over-limit drives, and the need to check the applied flag. However, it does not disclose other side effects (e.g., whether the joint is moved physically, any undo implications) or auth/permission needs.

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 concise and well-structured: a one-sentence purpose, then a line on the value expression, then a note on attribute order, and finally a crucial behavioral warning and response hint. Every sentence adds value, and it is front-loaded with the main purpose.

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 2-parameter tool with no output schema, the description covers the key usage points: value expression, attribute order, and response field. It does not describe the full return body (e.g., whether it returns only `applied`), but the mention of `applied` is enough for basic use. The complexity is moderate, so this is fairly complete.

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 0% schema description coverage and only parameter names in the schema, the description partially compensates by explaining the value parameter (what it means for different joint types). It does not explain joint_name but that is fairly self-explanatory; the description adds meaningful context for value.

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 action (drive), the target (an existing joint), and the goal (to a target value). It distinguishes itself from sibling tools like create_joint or set_joint_limits by focusing on motion of existing joints.

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 explains the value parameter is an expression (e.g., angle for revolute, distance for slider), which provides usage context. It also warns about silent ignore of limits and advises checking the response, but it does not explicitly mention when to use this tool versus alternatives (e.g., set_joint_limits).

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the tool triggers `design.computeAll()` before returning, which is a significant side effect. It also reveals that on `dim_not_found`, the response includes available dimensions, helping the agent recover. This is exactly the kind of behavior that is not inferable from schema and is well-disclosed.

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 well-structured with a clear first sentence stating the core purpose, followed by important behavioral warnings, error recovery info, and then a clean Args section. Every sentence adds value; no fluff. The formatting with sections and examples makes it easy to scan.

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 moderate complexity (4 params, no output schema), the description is complete: it covers purpose, parameter details, side effects, error recovery, and post-conditions. It even references a known failure mode and a follow-up tool. There is no missing critical information for an agent to use it effectively.

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 thoroughly explains each parameter: `sketch` (searches root + sub-components), `dim_name` (parameter name, find via `probe_sketch_dimensions`), `new_expression` (with detailed format rules: numeric literals, user param references, expressions, units required unless bare), and `component_name` (disambiguation). This far exceeds the minimal schema titles and provides essential semantic detail.

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 changes a sketch dimension's expression by parameter name, with specific examples (e.g., `d278`). It distinguishes from siblings like 'add_dimension' (which adds dimensions) and 'probe_sketch_dimensions' (which reads them), and from parameter management tools like 'update_parameter'. The action is specific and unambiguous.

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 provides explicit when-to-use guidance: it mentions using `probe_sketch_dimensions` to find parameter names, and explicitly recommends running `audit_feature_health` after the edit to check for downstream breakage. It also mentions a specific known pitfall (fillets on moving edges, see G11). This gives the agent clear context on when and how to use it, and what to do after.

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?

With no annotations, the description must carry the burden of disclosure. It reveals the entry point requirement and the stdout-to-response mechanism, which are important behavioral traits. However, it omits critical details such as side effects, security considerations, available libraries, or execution environment, leaving the agent with an incomplete picture of the tool's behavior.

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 exceptionally concise, consisting of two sentences that deliver the core contract: execution model, entry point, and output handling. Every word serves a purpose, and the most critical information is front-loaded with the 'Raw Python passthrough' label.

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?

Despite the tool's potentially high complexity (arbitrary Python execution), the description covers the essential execution contract. However, it lacks information about interaction with the CAD environment, error handling, timeouts, or available APIs, which are likely relevant given the sibling tools. The absence of an output schema makes this gap more noticeable, as agents cannot rely on structured output descriptions.

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?

The schema only defines 'script' as a string with 0% coverage, so the description must compensate. It does so by explaining that the script must define a `run(_ctx)` function and that print output is captured as the response. This adds meaningful context about the expected content and structure of the script parameter, going 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 it is a raw Python passthrough, which is a specific and distinct purpose compared to the many CAD-specific sibling tools. It explicitly identifies the verb (execute) and the resource (Python script), leaving no ambiguity about its function.

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 provide any guidance on when to use this tool versus alternatives. It neither suggests appropriate scenarios nor warns against misuse. The name 'execute' implies it is for advanced scripting, but that is not stated explicitly, leaving the agent without clear decision criteria.

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?

With no annotations, the description carries the full burden. It discloses important behaviors: STEP/IGES/SAT/SMT/F3D ignore the body parameter, refinement applies only to STL/OBJ, units are limited to STL/OBJ, and path constraints (absolute, no relative or Windows reserved names). It does not mention file overwriting or return values, but the disclosed format-specific details are strong.

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 concise and well-structured, with each line dedicated to a specific parameter or behavior. It avoids redundancy and fluff, using a clear label-and-explanation format that is easy to scan.

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 tool with 5 parameters and format-specific quirks, the description covers all core aspects: formats, path, body, refinement, and units with constraints. It lacks mention of file overwriting or directory existence, but these are edge cases. Overall, it is complete enough for correct usage.

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%, but the description thoroughly explains every parameter: format with allowed values, path constraints, body behavior, refinement values, and units values. It adds significant meaning beyond the bare schema, giving format applicability and default behaviors.

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 'Export geometry to a file' and lists supported formats, making the action and resource unambiguous. It distinguishes from sibling tools like save_as (likely for saving design documents) and import_geometry (importing geometry).

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 gives clear context on when to use the tool (to export geometry to a file in a specific format) and provides format-specific behavior (e.g., STEP/IGES ignore body). However, it does not explicitly mention alternatives like save_as or conditions when not to use this tool, so it misses some exclusionary guidance.

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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It does disclose operation kinds, extent options, direction handling, participant requirements, and return values, which is substantial. However, it does not state side effects such as body modification for cut/join, prerequisites for the sketch, or what happens with the original bodies, leaving important behavioral context implicit.

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 tightly structured and front-loaded with the purpose statement, followed by a compact parameter legend. Every line contributes value and there is no wasted prose, making it easy to scan despite the dense technical content.

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 9 parameters, no annotations, no output schema, and no parameter descriptions in the schema, the description is not complete enough. It covers core behavior and return values but omits several parameters, side effects, prerequisites, and alternative-tool context, leaving an agent to guess important aspects of correct invocation.

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 for the schema's lack of parameter explanations. It adds real semantics for operation, extent_kind, direction, and participants, but leaves name, profile_index, is_full_length, and the precise meaning of expression only partially or entirely unexplained. This is meaningful but incomplete coverage for a 9-parameter tool.

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 first sentence clearly states the action ('Extrude') and the target resource ('a sketch profile') and the result ('into a feature'), which distinguishes it from related tools like revolve or shell. The dense domain-specific parameter list reinforces the tool's core behavior without ambiguity.

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 for converting sketch profiles into features and documents internal operation choices, but it never explicitly says when to prefer extrude over alternatives like revolve or shell, nor does it state contraindications. The guidance is useful for selecting parameters within the tool, not for selecting the tool itself.

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?

No annotations are provided, so the description carries the burden. It explains the edge_handles source (list_body_entities) and radius format, but does not disclose whether the operation is destructive, reversible, or any side effects (e.g., feature creation, rebuild requirements). The description is minimal on behavior beyond usage.

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 concise with three bullet-like lines, front-loading the primary purpose and then detailing key params. No wasted words, but the lack of explanation for 'name' and 'is_tangent_chain' is a minor gap in completeness.

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 no annotations and no output schema, the description must explain more fully. It covers the primary inputs but misses important behavioral details like mutation impact, prerequisites (e.g., must have a document open?), and effects on geometry. For a tool that modifies geometry, this is incomplete.

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?

The schema has 0% description coverage, so the description must compensate. It explains edge_handles (list from list_body_entities) and radius (expression format), but does not explain 'name' or 'is_tangent_chain' parameters, which are not described in the schema either. This is a partial compensation, leading to a middle score.

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 that the tool fillets specific edges by handle, using UI-selection style. It mentions the input types (edge_handles, radius) and distinguishes from sibling tools like fillet_edges_by_geometry, though it doesn't explicitly name them.

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 indicates when to use this tool: for filletting specific edges by handle, implying geometry-based selection would use a different tool. It doesn't explicitly list alternatives, but the context of 'handle' vs geometry is clear from the sibling names.

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 are absent, so the description carries the full burden. It explains the geometric filter logic but omits behavioral details such as side effects (e.g., the body being modified in place), whether the operation is destructive/reversible, or potential failure modes. For a mutation tool, this is a notable gap, but the description does not mislead; it accurately describes the fillet action and parameter effects. Adding return value or error behavior would increase transparency.

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 extremely concise, with a one-sentence purpose followed by three bullet-like parameter notes. No wasted words; every line adds unique information. The front-loaded purpose sentence immediately clarifies what the tool does, and the parameter lines follow logically.

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 has 6 parameters, no annotations, and no output schema, the description is somewhat minimal. It covers the main function and three parameters but leaves out context for other parameters, fails to mention that the operation modifies the body, and lacks guidance on prerequisites (e.g., does the body need to be selected? what happens if no edges match?). Comparable sibling tools like chamfer_edges_by_geometry likely have similar patterns, but this description could be richer.

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?

The description explains three of six parameters (parallel_to, radius, min_length_mm) with concrete details (e.g., radius expression format, parallel_to allowed values, min_length_mm purpose). However, body, name, and is_tangent_chain are not explained. Schema coverage is effectively 50% (3/6), which is not high, so the description partially compensates but leaves ambiguity for the remaining parameters. The value added for the covered parameters is solid.

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 fillets edges of a body using a geometric filter, distinguishing it from the sibling fillet_edges by noting 'no UI selection needed.' The verb 'fillet' and resource 'edges of a body' are specific, and the geometric filter approach is unique among siblings.

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 when to use this tool: when geometric filtering is desired instead of UI selection. It does not explicitly name alternatives or say when not to use it, but the contrast with 'no UI selection needed' and the presence of sibling tools like fillet_edges and chamfer_edges_by_geometry provides clear context. Could be improved by explicitly stating 'use this instead of fillet_edges when...' but current guidance is adequate.

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?

No annotations are present, so the description carries the burden. It discloses the result shape (top-N matches with slug/title/namespace/etc.) and the filter semantics for kind and namespace. It doesn't state read-only guarantees or error behavior, but the search verb and return description make the operation's behavior reasonably clear.

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 short sentences/lines, front-loaded with the core purpose and immediately followed by usage and filter details. Every sentence provides information; no filler.

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 search tool with no annotations or output schema, the description covers the return payload, filter parameters, and a clear use case. It omits edge cases like matching strategy and pagination, but the provided information is sufficient for basic invocation and selection.

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 property descriptions are absent (0% coverage), so the description must add meaning. It explicitly explains `kind` and `namespace` with value examples and filter behavior, and 'top-N matches' maps to `limit`. `query` is left to inference from the tool name and the required field, and `limit` is not directly described.

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 action ('Search') and a precise resource ('local Fusion API help corpus'), then lists the returned fields. This clearly distinguishes it from sibling find_* tools by pointing to the API help corpus rather than general tool/pattern/gotcha lookup.

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 instructs to use it BEFORE writing a script that touches an unfamiliar method or class. No alternative tools or when-not cases are mentioned, so it provides a clear context without exclusions.

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?

No annotations are provided, so the description carries the full burden. It clearly indicates that the tool searches a documentation file and returns known causes and fixes, which implies read-only behavior. However, it does not disclose details such as search semantics, result limits, missing-match behavior, or whether results are snippets or full entries.

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 short and front-loaded with the core action, then immediately gives the intended use case. Every sentence earns its place with no wasted wording.

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?

The description is adequate for a simple search-type tool with a single required parameter and no output schema. It covers the primary scenario and approach. However, it could be more complete by explaining the role of `limit` and what the returned results look like.

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 for the input schema. It indirectly explains the `query` parameter through 'search by symptom or keyword,' but it does not mention the `limit` parameter at all or explain how many results may be returned. The description adds minimal value 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 begins with a specific verb ('Search') and a clear resource ('gotchas.md'), and it explains what the search is about ('known failure modes'). It is distinct from sibling search-like tools such as find_api and find_pattern because it targets a specific documentation file.

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 explicitly states when to use the tool: when something behaves unexpectedly, check here for the documented cause and fix before debugging from scratch. This gives clear context and implicitly positions it as an early diagnostic step.

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?

With no annotations, the description must carry the full burden. It adds useful behavioral details: direction is normalized by Fusion and component_name scopes the search. However, it does not disclose other behaviors like whether the ray is infinite, what happens if no intersection occurs, or if there are any side effects. The 'NEW May 2026' note adds negligible value. Overall, it provides some context but is not exhaustive.

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 concise: a heading line plus three short parameter explanations. It is front-loaded with the purpose and does not waste words. The 'NEW May 2026' tag is a minor addition but not intrusive. Each 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?

Given there is no output schema, the description partially explains the return value ('return MeshBody objects intersected'). It does not mention potential empty results or ordering, but the core functionality is clear. For a simple geometric query with 3 parameters, it is reasonably complete, though it could note that the ray is infinite or that multiple objects may be returned in any order.

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 fully compensates by explaining all three parameters: origin in mm with format, direction with normalization rule, and component_name as optional with default behavior. This adds significant meaning beyond the bare schema types and titles.

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 'cast a ray and return MeshBody objects intersected', which is a specific verb (cast) and resource (ray) with an explicit return type (MeshBody objects). It distinguishes from siblings like ray_collision_with_mesh by its focus on returning meshes rather than collision points or measurements.

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 state when to use this tool versus alternatives like ray_collision_with_mesh. It implies usage by describing how parameters work ('optional component to scope the search; omit for whole root'), but there is no direct comparison or exclusion guidance. It only covers the mechanics, not the use cases.

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?

With no annotations, the description carries the burden of behavioral disclosure. It mentions patterns are 'verified' which implies curated content, but it doesn't state if the tool is read-only, return format, or any side effects. For a search tool, the read-only nature is implicit but not explicitly stated.

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 two sentences, front-loaded with the purpose, and includes a usage guideline. No redundant information, every word 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?

For a simple search tool with no output schema, the description does enough to identify purpose and usage, but it omits what the search returns (e.g., matching patterns) and parameter details. It's adequate but not rich in context.

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 description must compensate. It provides examples of intents for query (constrained rectangle, etc.) but doesn't explain the exact syntax, what limit controls, or how results are returned. Minimal compensation for undocumented parameters.

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 searches patterns.md for verified Fusion MCP patterns and helpers by intent. It specific verb 'search' and resource 'patterns.md', and it distinguishes from siblings like find_api, find_tool, and find_gotcha by focusing on patterns.

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 explicitly says to use when looking for the canonical idiom for a common operation, giving examples (constrained rectangle, fillet by geometry, screenshot fit-view). It lacks explicit when-not-to-use or alternative suggestions, but the context is clear enough.

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?

With no annotations, the description carries the full burden. It discloses that it returns matching sections including signatures, enum values, return keys, and error codes. It also mentions it works with Fusion closed, implying no dependency on Fusion state. It doesn't mention side effects because it's a read-only search, which is fine. It could benefit from noting any rate limits or auth, but not essential.

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 concise and well-structured: first sentence states the action and target, second lists return contents, third gives usage scenarios. No fluff, each 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?

The tool is moderately complex with no output schema, so the description should explain returns, which it does. It covers the main use cases and constraints (works with Fusion closed). It's not exhaustive but sufficient for an agent to understand what the tool does and when to use it. Missing details like query syntax or limit behavior slightly reduce completeness.

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 explain the parameters, but it doesn't. It doesn't describe what 'query' should contain or how 'limit' behaves beyond the schema's default. The description only mentions 'by intent or symptom' but doesn't provide examples or clarify the query format. This is a significant gap given the coverage.

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 searches the server's tool reference (tools.md) by intent or symptom. It names the specific resource and action, and distinguishes it from sibling search tools like find_api, find_pattern, and find_gotcha by focusing on how to call tools and interpret errors.

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 explicitly says when to use: to look up how to call a tool instead of guessing arguments, and to check error codes. It also notes it works with Fusion closed, which is a useful context. It doesn't explicitly mention alternatives, but the 'instead of guessing' gives clear use case.

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?

No annotations are provided, so the description carries the burden. It discloses the primary behavioral effect ('lock its world position') but doesn't mention side effects, reversibility, or whether it affects child components. The description is adequate but not rich.

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 a single, concise sentence that front-loads the action and effect. No wasted words.

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 simplicity (one parameter, no output schema), the description is mostly complete. However, it lacks context on how grounding interacts with other operations (e.g., moving, joints) and whether the operation is reversible. The sibling 'unground_component' suggests reversibility, but the description doesn't state it.

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?

The schema has only one parameter 'name' with 0% description coverage, so the description must compensate. The description doesn't explain what 'name' refers to (occurrence name? component name?) or its format. However, with a single parameter, the tool name and description imply it's the occurrence to ground, so the gap is moderate.

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 action ('Set the ground flag') and the target resource ('an occurrence'), and adds the key effect ('lock its world position'). It distinguishes from the sibling tool 'unground_component' by implying the opposite action, though it doesn't explicitly name the alternative.

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 when to use it (when you want to lock an occurrence's position) but provides no explicit guidance on when not to use it or alternatives. The sibling 'unground_component' is an obvious counterpart, but the description doesn't mention it or any prerequisites.

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?

With no annotations, the description carries the behavioral transparency burden. It discloses that geometry is added to the active design and reports counts of bodies and occurrences added to the root component. It could go deeper on error behavior or requirements, but gives useful side-effect and return-value context.

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, front-loaded with the core action, and uses short parallel lines for the parameter details. No filler or repetition.

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 tool without an output schema or annotations, the description covers the main needed context: formats, path, design target, and return meaning. It could be more complete about failure modes or exact response shape, but it is sufficient for basic correct invocation.

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?

The input schema only lists 'format' and 'path' with no additional meaning. The description compensates fully by enumerating the exact supported format values and by explaining that path must be an absolute path to an existing file.

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 first sentence clearly states the action and target: 'Import geometry from a file into the active design.' The supported formats and return description add useful scoping. However, it does not explicitly differentiate from sibling tools like open_doc or export, so it stops short of full sibling distinction.

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 gives clear context: use this when importing one of the listed formats into the active design, with an absolute path to an existing file. It does not explicitly say when not to use it or direct the user to alternatives among the sibling tools.

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?

With no annotations, the description carries the burden of disclosing behavior. It states the output is per-pair volume and that empty list means no interference, which is useful. However, it does not disclose whether it is read-only or mutating, or any side effects like logging or affecting the document state, leaving ambiguity for a potentially analysis-only tool.

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 two sentences, front-loaded with the main purpose, and the additional detail about return value is crucial. Every sentence earns its place with no fluff.

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 (interference analysis) and lack of output schema, the description explains the return value but misses key context: no mention of operating on the active document, whether entities must be in the same component, or error conditions. This meets the minimum but leaves gaps for an effective agent.

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?

The schema has only one parameter 'entity_names' with no description and 0% coverage, so the description must clarify its meaning. The description says '2+ bodies or occurrences', implying entity_names is an array of names for bodies/occurrences, but it does not specify the format (e.g., strings, IDs) or whether they must be in the active document. It provides minimal added value 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 clearly states it runs an interference analysis on 2+ bodies or occurrences and returns per-pair interference volume, which is a specific verb+resource. It distinguishes from siblings like 'measure' and 'volume' by focusing on pair-wise interference, though it could be more explicit about how it differs from those.

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 implies usage for checking interferences between bodies/occurrences but does not state when to use it versus alternatives like 'measure' or 'volume' for distance or volume calculations. There is no explicit when-not-to-use or mention of prerequisites like needing an active document or selected entities.

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?

Without annotations, the description carries the burden of disclosing behavior. It clearly indicates that this is an enumeration operation (read-only by nature) and describes the output format (lists with handle, index, geometric info). It also explains filtering options. However, it doesn't address potential edge cases like errors on nonexistent bodies or empty results, which would be minor additional transparency.

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 concise and well-structured. It starts with the core purpose, then provides context, then parameter explanations, then return values, then usage guidance. Every sentence adds value with no redundancy or fluff, making it easy to scan and act upon.

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 that there is no output schema, the description must explain return values, which it does (lists with handle, index, geometric info). It also covers all parameters, including defaults and typical uses, and mentions downstream usage. For a tool with moderate complexity (5 params), this is complete coverage without leaving critical gaps.

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?

The schema has zero descriptions for parameters, so the description must explain them. It does so thoroughly: kinds (with default), face_normal_filter (with example), edge_parallel_to, and min_edge_length_mm (with typical use). Each parameter's meaning and purpose are clearly defined, adding significant value beyond the raw 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 enumerates faces/edges/vertices of a body and returns their handles. It further distinguishes itself by positioning as the bridge between name-addressing (bodies) and handle-addressing (sub-entities), which sets it apart from sibling tools that operate on bodies or handles directly.

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 explicitly tells the agent to use the returned handles in downstream tools like measure, fillet_edges, etc., implying when this tool is needed. However, it does not explicitly mention alternative tools or when not to use it, but the context is clear enough for typical scenarios.

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?

No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states a read operation ('List') with no mention of side effects, ordering, scope limitations, or return format, providing minimal context.

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 a single sentence with no filler, front-loading the verb and resource. It is efficient and to the point, earning a high score for conciseness.

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 simple read-only list tool, the description is adequate but incomplete. It fails to define 'recently' (e.g., session vs. all time), mention the output format (especially since no output schema exists), or note any limitations. Given the low complexity, this is a minor gap, but more context would improve the score.

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?

The tool has zero parameters, so the schema trivially covers everything. Per the baseline for zero parameters, a score of 4 is appropriate since the description does not need to add parameter detail, but it also does not enhance understanding of any hidden inputs.

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 lists recently-open documents, using a specific verb and resource. This distinguishes it from siblings like search_docs (search) and list_projects (projects), making its purpose unambiguous.

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?

No guidance on when to use this tool versus alternatives. It does not mention exclusions or alternatives, leaving the agent to infer that this is for recent docs only, without explicit direction.

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?

No annotations are provided, so the description carries the burden. It states the tool lists parameters with resolved values, expressions, units, and comments, which gives some behavioral context. However, it doesn't disclose whether this is a read-only operation, any side effects, or performance implications. Since it's a listing operation, the behavior is fairly predictable, but the description could be more explicit about the read-only nature.

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 a single sentence that is concise and front-loaded with the action 'List all user parameters'. It includes the key details (resolved values, expressions, units, comments) without any fluff. Every word 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?

Given that the tool has no parameters and no output schema, the description is quite complete for a listing operation. It tells the agent what the tool does and what information will be included. It could potentially mention the return format or any limitations, but for a simple list operation, this is adequate. The sibling tools suggest a CAD environment, and this tool fits well.

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?

The tool has zero parameters, and the schema description coverage is 100% (vacuously). The description adds meaning by specifying what is included in the listing (resolved values, expressions, units, comments), which is useful for the agent to know what to expect. Since there are no parameters, the description's role is to clarify the output content, which it does.

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 lists all user parameters with resolved values, expressions, units, and comments. It specifies the resource (user parameters) and the action (list), which is clear. However, it doesn't explicitly distinguish from sibling tools like add_parameters or update_parameter, but the verb 'list' and the scope 'all user parameters' make it distinct enough.

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 for retrieving all user parameters, but it doesn't provide explicit guidance on when to use this tool versus alternatives. There are no exclusions or alternative tool mentions. Given the context of sibling tools like add_parameters and update_parameter, the description could benefit from stating that this is for read-only listing, but it's not misleading.

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?

No annotations provided, so the description carries the burden of behavioral disclosure. 'List' implies read-only, but it does not explicitly state safety or side-effect-free operation. No conflicts, but minimal additional transparency beyond the obvious.

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?

Single sentence, front-loaded with the verb, no wasted words. Every word earns its place, making it highly concise and effective.

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 simple list tool with no parameters and no output schema, the description is sufficiently complete. It could optionally mention what the response contains (e.g., IDs, names) or when to use it, but these are more about usage guidance. The core behavior is covered adequately.

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 baseline 4 applies. The description adds no parameter-specific details, but none are needed since the schema is empty. Perfectly adequate for a parameterless tool.

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?

Description clearly states verb 'List' + resource 'projects' with clarification '(hubs / folders)' and scope 'the user can see'. This distinguishes it from sibling tools like list_open_docs (documents) and search_docs (search), making its purpose unambiguous.

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?

No guidance on when to use this tool vs alternatives. It doesn't mention scenarios like fetching project IDs for other operations, nor does it contrast with list_open_docs or search_docs. The description is purely declarative with no contextual cues.

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?

With no annotations, the description carries full burden and does add value: it discloses units (kg), the computation source ('uses Fusion's physical-properties calc'), and material provenance ('whatever the body has been assigned'). However, it never explicitly confirms this is a read-only, side-effect-free query, and the null-body_name behavior is only implied.

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 front-loaded sentences with no wasted words. The first sentence delivers the core purpose and scope; the second adds behavioral detail on material and computation. Appropriately sized for a simple query tool.

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 only one parameter, no annotations, and no output schema, the description explains the return values (mass in kg, material name, density, volume), the scope, and the computation source — covering the essentials for a simple getter. Minor gap: no explicit handling of the null body_name case, though 'all bodies' implies it.

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 0%, so the description must compensate. It implicitly maps body_name to the scope ('for a body or all bodies'), suggesting null targets all bodies. This adds meaning beyond the schema, but the mapping is implied rather than explicit (e.g., 'if body_name is null, returns all bodies' is never stated).

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 uses a clear resource ('mass (kg), material name, density, and volume') with explicit scoping ('for a body or all bodies'). It distinguishes from sibling tools like volume and center_of_mass by bundling material/density with mass, though 'Return' is a generic verb and the overlap with the volume sibling is not fully clarified.

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?

No guidance on when to use this tool versus alternatives. The scope ('for a body or all bodies') gives context on invocation, but there is no mention of when to prefer this over sibling query tools like measure, volume, or center_of_mass, and no when-not-to-use exclusions.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It describes what each kind returns: distance includes minimum distance plus nearest points, min_distance gives only a value, and angle is supported. It does not mention units or exact return shape, but for a simple read-only measurement tool this is reasonably 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 only two sentences and front-loads the operation, then concisely lists the supported kinds. Every sentence adds actionable information without repetition or filler.

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 that there is no output schema and no annotations, the description covers the essential usage path: entity source, allowed kinds, and what each kind returns. It could go further by specifying units or fully describing angle results, but it does not leave the agent guessing about the core behavior.

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 explains that entity_a and entity_b are handles from list_body_entities or tool output, and it gives concrete meaning to the 'kind' property. It still leaves angle output details somewhat underspecified, but the critical parameter semantics are provided.

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 uses a specific verb and resource: 'Measure between two entities using their handles.' It also lists the supported kinds ('distance', 'min_distance', 'angle'), which clearly distinguishes it from sibling inspection tools like bounding_box, volume, mass, or center_of_mass.

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 context for when to call this tool: any time the agent needs pairwise measurement between two entities. It even points to where entity handles can be obtained ('from list_body_entities or other tool returns'). It does not explicitly name alternatives or exclusions, but the 'between two entities' framing is sufficient guidance.

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?

With no annotations, the description bears full responsibility for behavioral disclosure, but it omits key details: whether the original is kept or modified, whether new geometry is created, or if the operation is destructive. It also doesn't mention any side effects like feature dependencies or invalid states.

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 a single sentence, front-loaded with the core action. It is appropriately concise and easy to read. However, the brevity sacrifices necessary detail, so while it is efficient, it is not optimally structured for comprehension.

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 absence of annotations and output schema, the description is far from complete. It fails to explain the behavior (e.g., whether a new feature is added), the need for an existing construction plane, or the nature of the mirrored result. The tool has 3 parameters but only one is partially explained.

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 clarify parameters. It does explain the allowed values for 'plane' (xy, xz, yz, or construction plane name), which adds value beyond the schema. However, it leaves 'feature_or_body' and 'name' unexplained; 'feature_or_body' is critical and its format is unknown.

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's action: 'Mirror a feature or body across a plane.' It specifies the resource (feature or body) and the operation (mirror), and gives plane options. This distinguishes it from sibling tools like pattern_circular or pattern_rectangular, which handle pattern replication, not mirroring.

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?

No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description simply states the operation and plane choices without explaining context, such as whether a construction plane must be created first or if mirroring is preferred over other symmetry methods.

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?

No annotations are provided, so the description carries the burden. It does disclose that the operation creates a parametric timeline feature, which is useful. However, it does not disclose side effects, prerequisites, required coordinate systems, or behavior when the body is constrained or referenced elsewhere.

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 two short sentences, front-loaded with the core action, and contains no filler. Every word adds value.

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 six parameters, no annotations, no output schema, and 0% schema description coverage, the description leaves important gaps. It explains the main transform parameters but not rotation origin, which is critical for rotation semantics, nor any expected result or failure modes. A richer description is needed for an agent to use this correctly in complex cases.

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 adds meaning for translation_mm (mm) and rotation (axis + angle_deg), including the 'and/or' relationship. But it omits meaning for rotation_origin_mm and name, and does not explain array shapes or units for origin, so the compensation is incomplete.

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 moves a body via a parametric Move feature in the timeline. This distinguishes it from sibling move_component by specifying 'body' and 'parametric in the timeline'.

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 use for moving bodies with translation and/or rotation, but it does not explicitly compare against alternatives like move_component or state when not to use this tool. There is no when/when-not guidance, only an implied usage context.

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?

With no annotations provided, the description carries the full burden and does so excellently. It discloses that the move silently reverts if the ground-to-parent flag is set, that the flag gets broken, and that the agent should verify the 'moved' and 'after_translation_mm' fields because results may be overridden.

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 front-loaded: the main purpose appears in the first sentence, followed directly by the most critical caveats. Every sentence adds meaningful information with no filler or repetition.

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 lack of annotations and output schema, the description covers the essential behavioral context: expected inputs, default behavior, silent failure mode, and response fields to check. This is sufficient for an agent to safely invoke the tool and understand the likely outcome.

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 0%, so the description must compensate. It adds units for translation (mm), describes rotation as axis plus angle in degrees, and specifies the default for rotation_origin_mm. However, it does not explain what 'name' refers to or the exact expected array shapes for translation and axis vectors.

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 moves an occurrence via translation and/or rotation with units, which is specific and actionable. The word 'occurrence' distinguishes it from the sibling tool 'move_body', and the rotation/translation details further define its scope.

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 provides important usage context, including the ground-to-parent flag interaction and the warning that a joint solver can override the requested move. However, it does not explicitly name alternatives like 'move_body' or 'create_joint' or specify when this tool should be preferred over them.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions fuzzy matching and optional project scope, but does not disclose what happens on multiple matches, missing documents, or whether opening changes the active document or has side effects.

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 two short sentences with no filler. It front-loads the core action and immediately provides the most important qualifier ('fuzzy') and optional parameter context.

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 simple open-by-name tool, the description is adequate but incomplete. It lacks guidance on alternatives, error behavior, and return value, and there is no output schema or annotations to fill those gaps. Still, the core purpose and primary parameter semantics are conveyed.

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 add meaning by explaining that 'name' is fuzzy-matched and that 'project' is an optional scope. However, it does not clarify the expected format or behavior of the project parameter beyond 'optional scope'.

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 uses a specific verb ('Open') with a clear resource ('document') and adds the key qualifier 'by name (fuzzy)', which distinguishes it from sibling tools like search_docs or list_open_docs. The optional project scope further clarifies the tool's intended operation.

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 this tool is for opening a document when you know its name, with optional project scoping. However, it does not explicitly state when to prefer this over search_docs or list_open_docs, nor does it mention any exclusions or prerequisites.

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?

No annotations are provided, so the description carries the full burden. It only mentions the axis options and does not disclose side effects (e.g., modifying the model), requirements (e.g., needing an existing feature), or behavior around invalid inputs like count or total_angle.

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 a single concise sentence, front-loaded with the core purpose and axis options. It is appropriately short though it omits useful details, but it earns a high score for brevity and clarity.

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 5-parameter tool with no output schema and no annotations, the description is significantly incomplete. It fails to explain the required 'feature_or_body' parameter or the effect of 'count' and 'total_angle', leaving the agent uncertain about how to invoke the tool correctly.

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 the description only explains the 'axis' parameter with its allowed values. It does not clarify 'count', 'total_angle', 'feature_or_body', or 'name', leaving most parameters semantically unexplained.

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 it creates a circular pattern around an axis, specifying the axis options (x|y|z|<construction_axis_name>). This is a specific verb+resource and distinguishes from sibling pattern_rectangular.

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 for circular patterns but does not explicitly state when to use this over alternatives (e.g., pattern_rectangular) or provide exclusions. The axis specification gives some context but lacks guidance on prerequisites or conditions.

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?

No annotations are present, so the description must disclose side effects itself, but it never states that a pattern is created or that the model is modified. It only explains axis and distance syntax, not what the operation does to the selected feature_or_body.

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 front-loaded: 'Rectangular pattern' first, then only the two parameter groups most likely to be ambiguous. There is no filler or repetition of schema defaults.

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 an 8-parameter modeling operation with no annotations, no output schema, and no schema description coverage, this description is not complete enough. It omits the meaning of feature_or_body, count behavior, and any result or error context, leaving too much for the agent to infer.

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 schema descriptions at 0%, the description adds real meaning to x_axis/y_axis via allowed axis values and to x_distance/y_distance via total-extent expression examples. The remaining parameters are mostly inferable from their schema names and defaults, so the added coverage is adequate.

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 identifies the tool as a rectangular pattern operation, which clearly separates it from the sibling pattern_circular. It lacks an explicit verb like 'creates' or 'patterns', but the axis/distance details make the intended operation clear.

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?

There is no guidance about when to use this tool versus pattern_circular or other pattern-related tools. The description provides parameter syntax but no prerequisites, exclusions, or alternate tool recommendations.

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?

With no annotations, the description must fully disclose behavior. It states that the tool 'walks root + every sub-component' to find the sketch, which is useful, and details the per-dim payload, including entity coordinates. However, it does not mention potential error conditions (e.g., sketch not found), whether it modifies anything (it does not, but that is not explicit), or any permission/read-only guarantees. The description is transparent about its search scope and output structure but not exhaustive regarding edge cases or side effects.

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 four sentences, front-loaded with the core purpose and output details. Every sentence contributes: purpose, use case, search behavior, and payload specification. No filler or redundancy, making it efficient and easy to parse.

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 two parameters, no annotations, and no output schema, the description adequately covers the tool's behavior and return payload (per-dim fields). It explains the search behavior across components and the disambiguation parameter. It stops short of listing error scenarios or confirming read-only status, but for a read-type inspection tool, this is largely sufficient. The description effectively compensates for the missing output schema by detailing the returned fields.

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 explains the component_name parameter: 'pass component_name for disambiguation when the same sketch name exists in multiple components,' which adds meaning beyond the bare schema. It also implies sketch is a name, but does not define its format (e.g., name vs. ID) or whether it must match exactly. The description adds some value but not enough to fully compensate for the lack of schema documentation.

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 'Dump' and clearly states the resource: 'every dimension in a sketch' with detailed outputs (parameter name, expression, value, entity coordinates). This distinguishes it from sibling tools like edit_sketch_dimension or add_dimension, which focus on modification rather than inspection.

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 explicitly states when to use the tool: 'to identify which literal-named dim controls which geometric feature' when sketches use baked-in numbers. It also provides disambiguation guidance via component_name and mentions walking root and sub-components. It lacks explicit when-not-to-use or alternatives beyond implied read-only purpose, but the guidance is clear and actionable.

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?

Since no annotations are provided, the description carries the full burden. It implies a mutating operation (projection) but does not disclose side effects such as whether existing sketch geometry is modified, whether the projection is associative, or whether it requires specific permissions. It adds some context (the relation to body geometry) but lacks detail on side effects or prerequisites.

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 a single sentence (plus a short sentence for usage context), front-loaded with the primary purpose. It is concise and contains no fluff; every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.