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

Discloses that activation triggers a rebuild, applies suppressions and dimension values, and returns the previous configuration name. No annotations exist, so the description fully carries the burden.

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?

Concise bilingual description with front-loaded main action, then details, use case, and parameter doc. Every sentence 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?

Fully covers the tool's behavior, return value, and use case. No output schema, but description explains return. Complete for a simple 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?

Describes the single parameter 'name' as 'Name of the configuration to activate', adding meaning beyond the schema's type string. Schema coverage is 0% but the description compensates.

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 verb "activate" and resource "configuration" clearly, and distinguishes from siblings like create_configuration or delete_configuration by specifying the action of switching and the rebuild trigger.

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 mentions the use case: verify a variant built with build_variant_family before saving. Provides context but does not list conditions when not to use or alternatives other than build_variant_family.

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 reveals behavioral traits: it enforces a fixed angle, uses right-hand-rule for rotation direction, and warns about solver rejection for coplanar entities. It also hints at parity with add_concentric_mate. Some details like permissions or side effects are omitted, but the disclosure is substantial.

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 moderately long with bilingual text (Spanish and English), which adds redundancy. It is structured with sections (typical use, args, returns, gotcha, related) but could be more concise by removing the Spanish section or merging it. Every sentence provides value, but the bilingual duplication reduces efficiency.

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 0% schema coverage and no output schema, the description covers the return metadata and mentions a key gotcha. However, it fails to document most parameters (5 out of 6 are vague). It does differentiate from sibling tools adequately. Coverage gaps leave the agent underinformed for 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 coverage is 0%, so description must compensate. It explains angle_deg (degrees, rotation rule). However, it defers other parameters to 'same as add_concentric_mate' without referencing that tool's description. The remaining 5 parameters (component names, entity IDs, align) are not explained, leaving significant ambiguity.

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 adds an angle mate (fixed angular offset) between two entities. It uses specific verbs and resources, and distinguishes from sibling tools like add_coincident_mate and add_concentric_mate through typical use cases and entity type restrictions.

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 provides typical uses (chain-link, hinge angles, etc.), required entity types (planar or axes), forbidden cases (concentric cylindrical faces, coplanar entities), and mentions a related tool (add_mate_by_face_position) for alternative usage. This offers clear when-to-use and 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?

Since no annotations are provided, the description fully discloses behavior: it creates a single sketch with all holes and a single extrude cut, returns feature info, and highlights that it is not parametric. It explains reverse_direction and target_bodies, and the caveat that changing hole_count requires deletion and re-run.

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 brief summary, detailed args, caveats, and an example. It is front-loaded with the main purpose. However, it is somewhat verbose due to the level of detail required for 11 parameters, but it earns its length.

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 is very complete. It explains the return value (single feature info), all parameter constraints, and provides usage context (e.g., alignment, scoping cuts with target_bodies).

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 coverage, the description provides detailed parameter explanations in an Args section, including constraints (e.g., hole_count >=3, circle_diameter > hole_diameter), defaults, and when parameters are required (depth_mm when end_condition='blind'). This fully compensates for the lack of schema descriptions.

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 adds a bolt circle by composing a sketch with N circles placed on a circle and then an extrude cut. It distinguishes itself from feature-pattern-based approaches, noting it's sketch-based and works for any center position.

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 (sketch-based, any center position) and when not to use (not parametric; for parametric counts use circular_pattern). It provides a concrete example and explains parameters like angle_offset_deg for alignment.

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 only describes what it does without mentioning side effects, permission requirements, error conditions, or consequences (e.g., mate suppression). This is insufficient 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 brief and front-loaded with the core purpose. Every sentence adds value, avoiding unnecessary details. The bilingual format is efficient for the 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?

Without output schema, annotations, or parameter descriptions, the description leaves significant gaps. It covers purpose and typical use but lacks behavioral, parameter, and result information. For a tool with 5 parameters and no schema coverage, more is needed.

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 the description does not explain any parameter meaning. It only notes 'same argument shape as add_concentric_mate', which is vague. The 'align' parameter's default is unelaborated. 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 clearly states the tool adds a coincident mate between two planar entities, with concrete examples (flange-to-plate, sub-assembly base plane). It distinguishes itself from sibling tools like add_concentric_mate and add_mate_by_face_position by noting same argument shape and naming a convenience 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?

Provides typical use cases (autopartes, specific scenarios) and references to related tools. However, it does not explicitly state when not to use (e.g., non-planar entities) or provide exclusion 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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It states the tool returns created mate's metadata, but omits details on permissions, side effects (e.g., modification of assembly), or state dependencies. However, for a straightforward mate creation, the basic behavior is implied, earning a mid-range score.

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 summary, typical use, argument details, return info, and related tools. It is slightly long but efficiently front-loaded with the purpose. Every sentence contributes value, though minor redundancy exists (bilingual repetition could be streamlined).

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 (5 parameters, no output schema, 0% schema coverage), the description thoroughly covers all aspects: purpose, parameter meanings, usage context, related tools, and return value. It is fully adequate for correct invocation without requiring external resources.

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 essential. It explains each parameter: component1_name and component2_name with examples ('bracket_L-1'), entity1_id and entity2_id with locale-sensitive string examples, and the align parameter with allowed values. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Mate concéntrico — alinea ejes de dos entidades cilíndricas/cónicas.' It uses a specific verb ('add concentric mate') and resource ('cylindrical/conical entities'), effectively distinguishing it from siblings like add_mate_by_face_position and stack_components.

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 typical use cases ('Uso típico autopartes: alineación de ejes de barrenos') and explicitly references related tools, explaining when to use alternatives ('add_mate_by_face_position for box-style components, stack_components for fully-constrained stacked pair'). This gives clear guidance on when to use this tool versus others.

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. It states 'fixed offset' and 'returns metadata' but does not disclose side effects, permissions, reversibility, or other behavioral traits beyond the basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose but includes redundant Spanish and English versions. It could be more concise without losing essential information.

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 6 parameters and no output schema, the description is incomplete. It explains distance_mm but omits meanings for align, entity IDs, and component names, and only vaguely mentions return value.

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?

Only distance_mm is described ('fixed distance in millimeters'). The description references 'other args: same as add_concentric_mate' without elaboration, leaving 5 out of 6 parameters undocumented. With 0% schema coverage, the description insufficiently compensates.

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 it adds a distance mate (fixed offset) between two entities, and gives specific use cases (parallel plate separation, bearing distance, controlled gap). It distinguishes from siblings by mentioning related tools like add_concentric_mate, add_mate_by_face_position, and stack_components.

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 typical use case context and references sibling tools for comparison (e.g., 'same as add_concentric_mate', 'related: add_mate_by_face_position'). However, it does not explicitly state when not to use this tool or provide clear 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?

Although no annotations are provided, the description fully discloses behavioral traits: caveat about feature tree representation (Cortar-Extruir instead of Hole Wizard), no cosmetic threads, and details on return values including hole_count, diameters, and counterbore depth.

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 long but well-structured with sections for parameter details, return dict, caveats, and examples. Every sentence provides necessary context; however, some repetition (e.g., ISO standards mentioned twice) could be trimmed slightly. Still, it's efficient for the complexity.

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 8 parameters, 0% schema coverage, no output schema, and no annotations, the description is comprehensive: covers purpose, parameters, return format edge cases, and usage examples. No gaps remain for an AI agent to misuse.

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 description carries full burden. It explains every parameter with constraints: hole_type options, size ISO range and limitations, positions_mm format and uniqueness, plane vs. face_centroid_mm mutual exclusivity, end_condition and depth requirements, counterbore_depth_mm default. This adds significant 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 tool 'drills N holes at specified positions using ISO Metric standards.' It specifies action (drill pattern), resource (holes), and distinguishes from sibling hole_wizard by noting multi-position capability vs. single-hole per call.

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 (multi-position patterns) and when not (single hole needing proper Hole Wizard styling, direct user to hole_wizard). It also provides two concrete examples for different use cases (tap holes on plane, counterbore on face).

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, description fully discloses internal steps, the critical reverse_direction flag, axis assumption, resolution of end position, and return fields including warnings. No contradictions.

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?

Well-structured with overview, workflow, critical note, parameter list, returns, and caveat. Every sentence adds value; front-loaded with purpose. Appropriate length for complexity.

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, description covers input, output, side effects, constraints, and verification fields. Complete for a tool with 6 parameters and internal steps.

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 has 0% coverage, but description adds complete semantic meaning for all 6 parameters: defaults, constraints, standard DIN width table, and specific usage notes for each.

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?

Describes specific verb (add) and resource (axial keyway cut into shaft end), includes junior workflow example, and distinguishes from siblings like extrude_cut and build_stepped_shaft. 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?

Explicitly states when to use: after building a shaft with build_stepped_shaft, and provides a caveat for arbitrary orientation suggesting alternative primitive chain. Includes critical parameter behavior.

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 fully carries the burden. It discloses the internal storage (meters/radians), the equation manager's behavior (accepts dim-paths on LHS), and the warning against re-adding. It also describes the return value in detail, ensuring the agent understands 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 well-structured with clear sections (purpose, usage, parameters, return, additional notes). It is front-loaded with the primary purpose. While slightly lengthy, every sentence adds value, so it earns a 4 rather than a 5.

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 parameters, return value, and usage context thoroughly. It includes an example of binding a dimension. However, it lacks error handling details or edge cases, which would make it complete given the lack of an output schema.

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 compensates fully. It explains each parameter: name (LHS with constraints), value (numeric), units (options and default). It gives SW conventions and examples, adding significant meaning 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 tool's purpose: to add a global variable (equation) as a named parameter. It specifies the verb 'add' and the resource 'global variable', and distinguishes from siblings like set_global_variable and modify_dimension. The context of parametric parts is also provided.

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 (parametric parts like CSWA Tool Block) and when-not (do not call again with same name; use set_global_variable for modification). It also explains how to bind dimensions to the variable and lists related 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 carries full burden. It thoroughly explains how face positions are resolved to actual faces based on local coordinate frames, including axis mapping for each keyword. It also describes default behavior and mate types. It does not mention side effects or undo capacity, but this is acceptable for a creation 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 yet comprehensive, using clear sections (intro, args explanation, example). Every sentence adds value, no wasted words. The structure aids quick scanning for key information.

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 7 parameters and no output schema, the description covers all aspects: parameter semantics, relationships, coordinate frame interpretation, and a practical example. It is complete enough for an agent to invoke correctly without additional 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?

With 0% schema description coverage, the description fully compensates by detailing each parameter: component names from get_active_assembly_info, face positions with axis mappings, mate_type with options, distance_mm condition, and align with defaults. The example ties everything together.

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 mate between two components using relative face positions (top/bottom etc.), differentiating it from other mate tools that require entity names or indices. The verb 'creates a mate' and specific resource handling are explicit.

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 explains the tool is a convenience wrapper to avoid locale-sensitive face naming, and provides an example for stacking. It implies when not to use (if you have exact entity names or need precise face selection), but does not explicitly list alternatives or when to use other mate tools. However, the context is clear.

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, description carries full burden. Discloses behavior: replaces vertex with line, requires edit mode, adjacent lines, potential API failure, and workaround. No contradictions.

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?

Bilingual (Spanish/English) adds length, but structure is clear with sections. Could be more concise by deduplicating languages, but still well-organized.

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 6 params, no output schema, no annotations, description covers purpose, prerequisites, gotchas, workaround, and return type. Slight gap: no detail on return format, but sufficient for agent 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 coverage is 0%, but description fully explains each parameter: line points, z default, distance along each line. Adds meaningful context beyond schema 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?

Clearly states it cuts a sketch corner with a 45° equal-distance chamfer, distinguishes from sibling 'chamfer' (3D edge chamfer) and 'add_sketch_fillet'.

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 when-to-use (e.g., CSWA Tool Block), prerequisites (sketch in edit mode, adjacent lines), and workaround if API fails. Also notes distinction from 3D chamfer.

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 fully compensates. It explains that SW selects the closest entity, infers dimension type, overrides the value, and returns the dim name. It also includes a gotcha about forcing dimension type.

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 front-loaded action and bullet points, but includes Spanish content that is redundant for an English-language AI agent. Still, every English sentence 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 the tool's complexity (6 parameters, required edit mode, return value), the description covers all aspects: prerequisites, behavior, gotchas, and follow-up usage with modify_dimension and global variables. It is 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 coverage is 0%, but the description explains each parameter in detail: entity point must lie on the entity, value_mm overrides, text_offset defaults to (20,10). It adds meaning far beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds a driving dimension to a sketch entity at a given point, with auto-naming. It distinguishes well from sibling tools like add_sketch_relation and add_sketch_fillet by focusing on dimensioning.

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 context: typical use after creating sketch entities in CSWA, and a strict prerequisite requiring sketch edit mode. It also warns about dimension type inference. It doesn't explicitly name when not to use, but the context is clear.

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?

Discloses that it replaces vertex with arc, requires sketch edit mode, and that lines must be adjacent. Mentions it returns metadata. No annotations provided, so description carries the burden and does it well.

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?

Description is bilingual (Spanish and English) which adds length, but is well-structured and front-loaded with key information. Every sentence 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 no output schema, the description mentions it returns metadata. It covers preconditions (edit mode, adjacent lines), differentiates from siblings, and provides typical usage example.

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 has 0% coverage, so description fully explains each parameter: line1_x_mm and line1_y_mm are points on the first line near the corner, similarly for line2, radius_mm is the fillet radius, and z_mm is Z-coordinate with default 0.

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 rounds a sketch corner with a tangent arc, replacing the vertex. It distinguishes itself from create_arc and add_sketch_chamfer, and mentions typical use (CSWA Tool Block).

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?

Describes when to use (rounded corners, CSWA Tool Block) and compares to alternatives (chamfer, manual arc). Does not explicitly list exclusions or when not to use, but provides sufficient 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, the description fully discloses behavioral traits: sketch edit mode required, no rebuild until exit, relation makes sketch fully defined and prevents drifting. Also explains return format. Comprehensive for a tool without 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?

Contains redundant bilingual text (Spanish and English versions). While the English part is well-structured, the duplication adds unnecessary length. Could be more concise by removing one language section.

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 covers purpose, usage constraints, parameter details, return info, and related tools. Fully adequate for the tool's complexity.

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 description adds crucial meaning: relation values are listed (horizontal, vertical, etc.), entity_points_mm explained as points on segments with closest-segment picking. Also specifies which relations take 1 or 2 points. Greatly enhances 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 adds geometric constraints (horizontal, vertical, coincident, tangent, equal, fix) to sketch segments. It uses specific verbs and resources, and distinguishes from sibling tools like add_sketch_dimension and add_sketch_fillet.

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 context: sketch must be in edit mode, used after drawing geometry and before extrusion. Mentions typical CSWA workflow and combination with add_sketch_dimension. Lacks explicit exclusion of alternatives but sufficiently guides when to use.

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 fully carries the transparency burden. It discloses that the operation is not parametric, creates sub-edges affecting subsequent operations, and explains parameter defaults and behaviors (e.g., min_edge_length_mm filter skips circular edges). It also specifies the return structure.

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 summary, context, args, returns, caveats, and examples. It is not overly verbose given the complexity, though the length could be slightly trimmed (e.g., the Spanish phrase could be more concise). Overall, every sentence 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?

Despite no output schema, the description explains the return type and fields. It covers parameter details, edge cases (circular edges skip filter), and caveats. Examples illustrate typical and advanced use. The tool is complex, but the description is fully sufficient for 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 has 0% description coverage, but the description adds extensive semantics for all five parameters: distance_mm (with recommended values), angle_deg (default), min_edge_length_mm (filter logic for linear vs circular), body_name (scope), and include_arcs (linear-only option). Each parameter is given practical context.

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 chamfers every edge (linear and circular by default) for deburring autoparts. It specifies the verb 'chamfer' and resource 'all edges', and distinguishes from siblings like fillet_all_edges and single-edge chamfer tools by noting it replaces three steps.

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 context: universal edge-break for autoparts where deburring is required. It contrasts with manual three-step process, warns about non-parametric nature and interaction with fillet_all_edges, and gives examples for standard, single-body, and linear-only 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 fully discloses behavior: validates loop closure before SolidWorks call, leaves sketch open, explains exact mode to avoid drift, and notes it's call-count atomic but not SW-transactional. All important traits are covered.

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 lengthy but well-structured with clear sections, bilingual text, and bold headings. It is front-loaded with the core purpose and typical use. Minor redundancy from bilingual 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?

Given no output schema, the description explains the return value (dict with sketch_name, plane, etc.) and mentions related tools. All aspects of a complex tool are adequately 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 coverage is 0%, so the description carries the full burden. It provides detailed explanations for all 6 parameters, including format, defaults, valid values, and usage notes. The segments parameter is thoroughly described with sub-fields.

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 builds a sketch from a single ordered list of segments, distinguishing it from the many separate create_line/create_arc calls. It also emphasizes the validation of loop closure, making the purpose very specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a typical use case (CSWA Tool Block) and contrasts with primitives. However, it does not explicitly state when not to use this tool or list alternatives beyond create_line/create_arc.

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. It discloses the parametric expression capability, but lacks details on side effects (e.g., does it merge automatically? What if the profile is not closed?), error behavior, or prerequisites. Essential behavioral traits are omitted.

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 (two sentences) and front-loaded with purpose. However, it lacks structural formatting (e.g., bullet points) that could improve readability, especially for a parameter-heavy 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?

Given the tool's complexity (8 params, no output schema, no annotations), the description is incomplete. It explains only the variable expression aspect, leaving out parameter semantics, output details, and workflow integration. A more complete description would address the purpose of each parameter and the expected result.

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 adds meaning for 'segments' and 'depth_mm' (accept expressions over variables), but ignores the other six parameters (exact, merge, plane, end_condition, reverse_direction, variables). The description is insufficient for an 8-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 clearly states the tool's action: 'Build an exact closed profile and extrude it as one composite.' It uses specific verbs and resources, and distinguishes from siblings like 'build_closed_profile' which only builds, and 'extrude_sketch' which extrudes an existing sketch.

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 parametric designs by mentioning string expressions over variables, but does not explicitly state when to use this tool versus alternatives (e.g., building a closed profile then extruding separately). No when-not or exclusion criteria 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?

No annotations are provided, so the description carries full burden. It details the composite operation, default direction, through_all behavior for the bore, and caveats about unintended cuts. It also explains the colinear construction and return format.

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 summary, example, parameter list, returns, caveat, and usage example. It is front-loaded and every sentence adds value. Though lengthy, it is justified for the tool's complexity.

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, the description includes return format. It thoroughly covers all 8 parameters with constraints and examples, plus caveats. This provides complete context for an AI agent to use 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%, but the description fully documents each parameter with conditions (e.g., bore_diameter_mm > 0 and < outer_diameter_mm, reverse_extrude effect, bore_target_bodies scoping). This adds significant meaning beyond the schema's bare 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 it creates a cylindrical boss with optional through bore, using specific verbs like 'crear' and 'composes'. It distinguishes from sibling tools by describing its composite nature (sketch+extrude for boss and optional bore). The example clarifies the purpose.

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 a junior workflow example and explicit exclusion: 'For blind bores, call extrude_cut separately after this composite.' It also advises when to use bore_target_bodies. However, it does not contrast with similar sibling tools like build_stepped_shaft or build_threaded_boss.

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, but the description is extensive: it details the internal composition steps, the return dictionary, geometry orientation contract, and a caveat about a sharp inside corner. This fully compensates for the lack of 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 well-structured with sections, but the junior workflow example and detailed step composition could be considered slightly verbose. However, it remains clear and front-loaded with the 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 complexity (8 parameters, no output schema, no annotations), the description is comprehensive. It covers purpose, parameters, geometry, return values, and provides an example, making it complete for agent 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?

The input schema has 0% description coverage, but the description provides detailed explanations for all 8 parameters, including defaults, constraints, and units. It adds significant meaning beyond the schema 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 the tool builds an L-shaped autoparts bracket with bolt holes, and distinguishes it from siblings by specifying it wraps multiple steps into one call. The verb 'build' and resource 'L-bracket' are 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 indicates it is for the most common stamped autopart and wraps a multi-step flow, but does not explicitly state when to use this tool versus alternatives like build_plate_with_hole_pattern or build_flange_boss. However, the specificity makes usage clear.

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 fully reveals behavioral traits: closed grammar, no code execution, rollback all-or-nothing, deferred redraw/rebuild, single approval, clear error messages, and return structure (execute_batch result + compiled_ops + summary).

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 detailed and well-structured with examples, method list, and English summary. While a bit long, each sentence adds value given the complexity of the DSL grammar.

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 complex DSL tool with no output schema, the description covers the entire API: grammar, supported methods, edges, parameters, return value, and error handling. It's fully self-contained.

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?

Input schema has 0% description coverage, but the description fully compensates by explaining 'script' as the fluent expression with examples, 'dry_run' as compile-only without touching SolidWorks, and 'rebuild' as a rebuild upon batch close.

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 builds a part from a fluent build123d-style script in one call. It distinguishes from siblings like execute_batch by explaining it compiles to an op-list and runs as a batch, and from other build tools by emphasizing the closed grammar and no-code-execution nature.

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 states when to use (fluent script, one call), what not to use (NO sketch-on-face, use create_sketch_on_face separately), and mentions fallback to execute_batch or standalone tools. It also provides a list of methods and constraints on grammar.

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?

Even without annotations, the description fully discloses behavior: opens files read-only in series, saves locally, no network/telemetry, incremental based on mtime+size, rebuild and max_parts limits, and that it opens/closes documents requiring SolidWorks idle.

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?

Well-structured: summary sentence, then process details, then args list, then return fields. Every sentence adds value, no fluff. 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?

Given no output schema, the description lists return fields. It fully covers how the tool works, what it produces, and edge cases (incremental, rebuild, max_parts). Complete for a file scanning/indexing 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 all three parameters (folder, rebuild, max_parts) in detail, providing meaning beyond the bare schema. It clarifies folder recurses and ignores temporary files, rebuild forces re-read, and max_parts is a cap per run.

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 (index), resource (folder of .SLDPRT parts), and result (local catalog in mcp_cad_index.sqlite). It distinguishes from siblings by being a local indexing tool vs. modeling or query 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?

Provides clear context for when to use (indexing parts locally), includes conditions (SolidWorks idle), and explains incremental behavior and rebuild option. Lacks explicit comparison to siblings like search_part_catalog, but the use case is well-defined.

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 explains the plate geometry and hole modes but omits critical behavioral details: it does not state whether the tool creates a new part or modifies an existing sketch, whether the holes are destructive (through-cuts) or additive, or what the output is. The phrase 'drawing-grounded through holes' is ambiguous. Missing: required document context, effect on existing features, and return value.

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, each delivering essential information. The first sentence states the core function; the second explains the hole pattern alternatives and coordinate system. No redundant or extraneous text. Well-structured and front-loaded with the most important action.

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 (14 parameters, no output schema, no annotations), the description is insufficient. It does not explain the broader build context (e.g., requires an active part document? affects existing geometry?), nor does it describe the result type. Sibling tools exist for similar operations, but no guidance is provided on when to use this tool over composing smaller steps. The description leaves many agent decisions unaddressed.

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 compensates partially. It adds meaning for `hole_positions_mm`, `bolt_circle_diameter_mm`, `bolt_count`, and the rectangle coordinate system (origin, width, height). However, many parameters remain undocumented: `plane`, `angle_offset_deg`, `reverse_direction`, `bolt_circle_center_x_mm`, `bolt_circle_center_y_mm`. The description covers about 6 of 14 parameters, which is adequate but not comprehensive.

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 'Build a rectangular plate and drill drawing-grounded through holes,' specifying the action (build, drill) and resource (plate with holes). It further distinguishes two hole pattern modes (explicit positions vs. bolt circle), which differentiates it from sibling tools like add_bolt_circle or add_drill_pattern that only handle hole patterns without creating the plate.

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 explains the two modes of hole creation ('Use either explicit `hole_positions_mm` or a bolt circle'), giving clear context for parameter usage. However, it does not explicitly state when to use this compound tool versus alternative tools (e.g., build_rectangular_pocket plus add_bolt_circle), nor does it mention any prerequisites or 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?

Without annotations, the description carries full burden. It details parameter effects (e.g., reverse_direction flips cut, target_bodies restricts bodies, end_condition ignored if through_all) and notes that the pocket may cut into air if the parent body is on the wrong side. Return value is described as 'Cut-Extruir Feature info'.

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 moderately long but well-structured, with a clear intro, workflow breakdown, and parameter list. It is front-loaded with the core purpose and example, though some sentences could be tightened.

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 and no output schema, the description covers parameter usage thoroughly, includes an example invocation, and describes the return value type. It could be improved by detailing the structure of the returned feature info, but is largely 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%, but the description adds comprehensive meaning for all 9 parameters. It includes examples for plane (English/Spanish), units for dimensions, constraints (e.g., width_mm > 0), defaults, and special behavior (e.g., depth_mm ignored when end_condition='through_all').

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: 'Hacer un vaciado rectangular en una sola operación' (Make a rectangular pocket in a single operation). It also provides a concrete example workflow, distinguishing it from generic cut tools like extrude_cut.

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 a junior workflow example and explains it composes create_sketch, create_rectangle, extrude_cut, implying it is a shortcut. However, it does not explicitly state when to use this tool over alternatives 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?

With no annotations, the description carries full burden. It mentions a 'safe chain' and the steps involved, but lacks details on permissions, error handling, or side effects. It adds useful context about string expressions in coordinates but is 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 concise at 4 sentences, each adding value. It front-loads the main purpose, then provides usage context and a noteworthy feature (string expressions). No extraneous information.

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 9 parameters, no output schema, and 0% schema coverage, the description is incomplete. It covers only purpose and two parameters, leaving many behavioral and parameter details unaddressed, which is inadequate for an AI agent to use 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%. The description adds meaning to 'segments' (ordered line/arc) and 'variables' (string expressions), but does not explain parameters like exact, merge, plane, angle_deg, or axis references. It compensates partially but not enough for 9 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 builds an axisymmetric profile by creating a reference axis, closed profile, and revolving. It explicitly distinguishes this as the preferred path for turned parts with known ordered segments, differentiating it from siblings like revolve_sketch and build_closed_profile.

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 a clear context for when to use: 'for turned parts where the sketch profile is already known as ordered line/arc segments.' It implies this is the recommended approach but does not explicitly state when not to use or list alternative 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 provided, so the description carries full burden. It fully discloses the composition (creates axis, sketch, lines, revolve), orientation (along +X, Front plane), square shoulders (no fillets), and output structure. Limitations (v1 no taper, fixed orientation) are clearly 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 well-structured with title, workflow, args, returns, caveats, and example. It is front-loaded with the purpose. While slightly long, every sentence adds value; no 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?

No output schema or annotations present. The description covers purpose, parameters, internal behavior, output structure, caveats, and example. For a tool with 4 parameters and moderate complexity, this is 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 coverage is 0%, so the description must explain all parameters. It does so thoroughly: diameters_mm as list of step diameters, lengths_mm same length, angle_deg sweep angle (0,360] default 360, merge boolean default true. Constraints (1..20 entries, >0) are provided, adding significant 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 explicitly states 'Flecha escalonada — build a stepped (multi-diameter) cylindrical shaft in one call.' It clearly identifies the resource (stepped shaft) and verb (build), and distinguishes from siblings like revolve_sketch by noting it is a composite 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 provides a junior workflow example, caveats for orientation, transitions, and no taper, and explicitly mentions when to use revolve_sketch directly for tapered shafts or custom orientation. It includes a concrete example, giving strong guidance on when and how to use 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?

With no annotations, the description fully discloses the tool's behavior: it composes an extrude_sketch and an extrude_cut, notes that the tap hole is not a Hole-Wizard feature, and explains limitations (no cosmetic threads). It also describes the return dict and provides caveats about v1.

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 into clear sections (overview, workflow, args, returns, caveats, examples), but it is somewhat verbose with extraneous details like the Spanish phrase. However, it is front-loaded with the core purpose and remains informative without 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 (10 parameters, no output schema, no annotations), the description is exceptionally complete. It covers all parameters, constraints, return values, usage examples, and caveats. It leaves no significant gaps for an AI agent to misinterpret.

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 compensates fully by explaining each parameter in detail: plane with examples, center coordinates, outer_diameter_mm with constraint, height_mm, thread_size with ISO metric mapping, thread_depth_mm with default, end_condition options, reverse_extrude, and tap_target_bodies. This adds significant 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 the tool creates a cylindrical boss with a centered tap hole. It distinguishes from alternatives like hole_wizard by noting that this tool does not produce cosmetic threads, and it explicitly positions itself as a standard autoparts pattern. The purpose 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 guidance on when to use this tool (for threaded bosses in autoparts patterns) and when not to (when cosmetic threads are needed, use hole_wizard). It includes a junior workflow example and constraints on parameters (e.g., outer_diameter_mm must be > tap-drill diameter).

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 includes a 'Caveat' section detailing partial failure behavior and the lack of auto-rollback, which is useful. It also explains the composition order and single save at the end. However, it could be more explicit about side effects like saving the document.

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 purpose line, args section, returns, caveat, and example. Each section adds value, though the arg descriptions could be slightly more concise. The caveat is particularly important and 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 no output schema and the tool's complexity (composing multiple operations), the description is highly complete. It covers purpose, all parameters with constraints, return format, failure behavior, and provides an example. The caveat addresses real-world usage concerns.

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 has 0% description coverage, so the description must compensate. It provides detailed semantics for each parameter: constraints for variants (non-empty, >0), meaning of parent_config, and requirement that activate_at_end must be a key of variants. This far exceeds the schema's basic type info.

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 ('Crear una familia de configuraciones') and resource (cambiando una sola dimensión). It distinguishes itself from siblings by explaining it composes create_config, activate, and modify_dimension into a single macro, which is a higher-level operation than individual tools like create_configuration.

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 a junior workflow example but lacks explicit when-to-use vs when-not-to-use guidance. It implies usage for multi-variant creation along one dimension, but does not explicitly contrast with using individual tools for a single variant. More directive guidance would improve agent decision-making.

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 full burden. It discloses privacy risks (images may contain confidential data, sent to client/host), cadence advice, behavior of parameters (with_dims is a no-op, section creates cut planes), return format (list of images + summary), and caveats (requires open part, temp files not deleted). No contradictions.

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 lengthy but well-structured with clear sections (privacy warning, cadence, args, returns, caveat, example). Each part adds value, though it could be slightly tightened. The front-loading of purpose and privacy warning is 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?

Given no output schema, the description covers return values (list of images + summary dict with resolved views, paths, with_dims, privacy note) and handles edge cases (unknown view raises ValueError, section behavior, with_dims no-op). Includes an example showing integration with other tools. All essential context for correct use is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage; the description fully explains all three parameters. views: acceptable subset of view names, default, error on unknown. section: optional dict with plane and offset_mm, how it works for internal cuts. with_dims: accepted but no-op, rationale. Provides concrete examples and constraints.

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 renders the active part or assembly to PNG for visual verification. It uses specific verbs and resources (render, PNG, visual verification) and distinguishes itself from sibling tools by emphasizing its role in visual checks, not modeling or other operations.

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 guidance: use at checkpoints and end of build, not after every feature; trust cheaper signals in between; per-feature renders only for debugging; mandatory final render. It also mentions an alternative (verify_build_report capture_view_names) for bundling renders.

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. It discloses parameter behavior, typical values, and the return type. It mentions the batch-all-identical-edges rule and failure modes are identical to fillet, but doesn't detail side effects or nesting limitations.

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 opening, followed by detailed parameter explanations and an example. It is slightly verbose but every sentence adds value, and it is front-loaded with the main action.

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 7 parameters, no output schema, and no annotations, the description covers most critical aspects: typical use cases, parameter constraints, and references to fillet for common patterns. It lacks details on edge_circles and the full selector schema, but overall provides sufficient context for an AI 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 description adds meaning beyond the schema for 6 of 7 parameters, explaining distance_mm, angle_deg, flip, edge_midpoints_mm, edge_indices, and selector with typical values and use cases. However, it misses edge_circles entirely, and the selector is only briefly described via reference to fillet.

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: 'Chaflán — bevel one or more edges (distance + angle).' It also distinguishes from fillet by referencing it for common details and provides an example use.

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 usage context with standard autoparts applications, default angles, and deferred features. It directs users to fillet for the selector schema and failure modes, but doesn't explicitly state when not to use or alternatives beyond fillet.

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 description carries full burden. It explains parameter behaviors (equal_spacing, reverse, total_angle_deg) and mentions the return value (a new Feature with name). It does not discuss side effects or destructive actions, but the tool is a pattern creation which is typically non-destructive.

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?

Well-structured with clear sections, bullet points for arguments, and examples. While verbose, every sentence adds value for a parameter-heavy tool. Could be slightly more concise, but overall 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?

Given 6 parameters and no output schema, the description covers all parameters, explains the return value, and provides two complete examples. It also notes the prerequisite, making it fully actionable for an AI 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?

Schema coverage is 0%, but the description provides detailed semantics for all 6 parameters, including types, defaults, and usage (e.g., count includes original, total_angle_deg default 360, equal_spacing behavior). This adds significant 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 'repeat features around an axis' and provides specific use cases like bolt circles and fan blades. It distinguishes from siblings like linear_pattern by describing the circular axis-based repetition and the prerequisite create_reference_axis call.

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 mentions the prerequisite create_reference_axis call and provides examples for common use cases. It does not explicitly state when not to use, but the context and examples imply appropriate scenarios, and it guides the user on parameter settings for partial arcs.

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 fully shoulders behavioral disclosure. It details return structures for match and miss, caveats about Mexican-Spanish specificity, terms that are generic or ambiguous, and mentions version limitations (v1 vs v1.1). No contradictions.

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 longer but well-structured with sections for use case, return values, caveats, and example. Information is front-loaded with the core purpose in Spanish and English. Every sentence adds value, but the dual-language nature slightly increases length.

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 1 parameter, no output schema, and no annotations, the description covers purpose, parameters, return structures (both match and miss), caveats, and example usage. It is fully complete for the tool's complexity and context signals.

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% (no description in schema), so description adds all meaning. It thoroughly explains the 'term' parameter: case- and accent-insensitive, and specifies the context (Spanish/Spanglish autoparts term). This far exceeds baseline and compensates for lack of schema description.

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 returns curated geometric interpretations for informal Spanish/Spanglish autoparts terms, specifying the verb 'look up' and resource 'autoparts terms'. It distinguishes itself from sibling CAD/modeling tools by being a disambiguation/interpretation step before proposing a plan.

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 in Phase 2 / Layer 2 when a user uses an informal term and interpretation is needed before proposing a plan. Provides example terms and emphasizes the need to confirm geometric archetype via the disambiguation question. Though no explicit 'do not use', the context and caveats effectively guide appropriate usage.

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 description carries full burden. Explains default behavior (refuses dirty doc) and force behavior (discards unsaved changes), underlying verb distinction (CloseDoc vs QuitDoc), return dict fields (closed, name, was_modified), and error conditions. Highly 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?

Well-structured with sections (Args, Returns, Raises, Examples) and front-loaded purpose. However, includes both English and Spanish translations which may be slightly redundant. Generally clear but could be more concise.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description covers return dict and errors. Provides examples, explains error conditions, and gives canonical use cases. Complete for a simple tool with one parameter.

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 has 0% description coverage (no param descriptions), so description must add meaning. It does: explains default (False) raises error if dirty, True silently discards, with use case (throwaway doc). Adds significant value beyond 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?

Description uses specific verb 'Close' and resource 'active document in SolidWorks', with additional context about its role in iterative workflows. Clearly distinguishes from siblings like save_as and open_document.

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 describes when to use (iterative build→save_as→close→new_part→rebuild flows) and why (prevents window pile-up and save_as collisions). Mentions default vs force behavior but doesn't explicitly state when not to use.

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 full burden. It discloses that the tool is advisory-only and does not mutate SolidWorks, and that it returns MCP tool names and parameters. Supported archetypes are listed. Missing details on error handling or behavior for unsupported archetypes, but overall 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?

Two short sentences that convey all essential information without redundancy. The first sentence is a clear action statement; the second adds critical behavioral context. 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?

For a simple tool with one parameter and no output schema, the description covers purpose, non-mutating behavior, and supported archetypes. It hints at output (tool names+params). Minor gap: no mention of error states or behavior when archetype is not supported, but overall sufficient.

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 for its single parameter. The description implies 'drawing_spec_id' is an identifier for a stored DrawingSpec, but adds no additional meaning, format, or usage context beyond the name.

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 compiles a DrawingSpec into a FeaturePlan, uses a specific verb-resource pair, and distinguishes itself by being advisory-only and non-mutating. It also explicitly lists supported archetypes, making its scope 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?

Usage is implied: use when you have a DrawingSpec and want a plan. However, there is no explicit guidance on when to use vs. alternatives (e.g., run_feature_plan), nor any when-not conditions. The advisory nature is mentioned but not contrasted with execution 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 provided, so description carries full burden. Explains angle convention (CCW), direction flag with counter-intuitive example, returns dict with fields, and troubleshooting tip (flip direction if revolve fails). Missing some error cases but overall 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?

Well-structured: purpose first, then parameters, returns, use cases, examples, caveat. Front-loaded and efficient, though slightly long. Every sentence 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 8 parameters, no output schema, and no annotations, the description covers parameter conventions, examples, use cases, and a key caveat (active sketch needed). Does not cover all edge cases but is sufficient for typical use.

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 has 0% description coverage; the description explains all 8 parameters in detail: meanings, defaults, constraints (radius positive, start/end different), long-form aliases, and direction behavior. Fully compensates for 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 'draw a center-defined arc on the active sketch' with specific parameters (center, radius, angles). It distinguishes from siblings like create_circle (full circles) and create_slot (slot end-caps).

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 clear context: requires active sketch, common use cases (slot end-cap, 2D fillet, curved profiles), and explicitly says to use create_circle for full circles. Lacks explicit when-not-to-use but gives good 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 fully discloses behavior: requires active sketch, geometry is non-parametric (cannot resize post-hoc), returns center/radius/diameter, and suggests rebuilding from fresh part for resize. This goes beyond basic 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 well-structured with a clear header, parameter list, return, common uses, example, caveats, and related tools. It is front-loaded and every section adds value without 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?

Despite having no output schema, the description covers return values. It includes prerequisites, limitations, and alternative tools. For a simple drawing tool, it is comprehensively 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 coverage is 0%, so the description compensates by explaining all 5 parameters: cx_mm, cy_mm, radius_mm, and aliases center_x_mm, center_y_mm. It clarifies the constraint to pass one name per axis and that radius must be positive, with an example.

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 'Draw a circle on the active sketch' with a specific verb and resource. It distinguishes itself from siblings by mentioning add_bolt_circle as an alternative for bolt patterns, and provides common autoparts uses.

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 explains the prerequisite (requires active sketch) and explicitly names an alternative tool (add_bolt_circle). It implies when to use via common uses, but does not explicitly state when not to use (e.g., for parametric circles).

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 description fully covers behavioral traits: it discloses that creating a configuration activates it, warns to read active_config before relying on scoped operations, and notes idempotency. This is thorough and honest.

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-organized with clear sections (purpose, args, gotcha, related) and is bilingual which adds some length but is acceptable. It is informative without being overly verbose, though the 'verificado en vivo' note could be more concise.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description states it returns the configuration name. It covers behavior, parameters, side effects, and alternatives thoroughly. For a tool with 3 parameters, this is complete and leaves no obvious 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?

Schema has 0% parameter descriptions, but the description provides clear explanations for each parameter: name (unique, idempotent), parent (optional for derived configs), description (optional). This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a new configuration on the active part or assembly, explains what a configuration is (metadata sharing geometry but allowing variations), and distinguishes from the sibling build_variant_family which creates multiple configs in one call.

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 states when to use (v1 path for variants without duplicating files) and names an alternative tool (build_variant_family) for creating multiple variants. Also includes a gotcha about activation side effect, guiding the agent on proper usage.

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 full burden. It discloses return value (geometry with endpoints and length) and includes a critical caveat about the line not being parametric (modify_dimension cannot adjust endpoints or length). This reveals important behavioral limits beyond the simple 'draw' action.

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 first sentence front-loads the purpose. The structure includes args, return, usage, and caveats. The bilingual caveat adds length but is reasonable for international users. Could be slightly more concise, but overall well-organized.

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 or annotations, the description covers purpose, parameters, return value, prerequisite, and an important behavioral caveat. It does not mention whether the line is immediately visible or if there are constraints, but this is sufficient for a simple tool given sibling 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 coverage is 0%, so the description must add meaning. It explains x1_mm, y1_mm as 'Start point in mm (sketch-local frame)' and x2_mm, y2_mm as 'End point.' This provides units and frame context that the schema lacks, though coordinate system orientation or bounds are omitted.

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 'Draw a line on the active sketch.' It distinguishes the tool from siblings like create_rectangle, create_circle, and create_arc by noting it is used for non-rectangular profiles before extrusion. The verb 'Draw' and resource 'line' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly requires an active sketch via 'requires an active sketch (call create_sketch first).' It also implies usage as a building block for non-rectangular profiles, but does not explicitly exclude alternatives (e.g., use create_rectangle for rectangles). Clear context but lacks explicit 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?

Describes that rectangle is added to most recent sketch, returns geometric properties, and crucially warns that rectangle is not parametric (modify_dimension cannot resize; only extrude depth is parametric). No annotations provided, so description fully bears 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?

Well-structured with args, example, caveat, and related tool. Front-loaded purpose. No filler; every sentence 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?

Covers purpose, parameters, example, behavioral caveats (non-parametric), prerequisites, and sibling alternative. No output schema needed since return value is simple geometric properties. Complete for safe agent 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?

Explains param meaning: 'One corner of the rectangle in mm' and 'The opposite corner.' Provides example (0,0,50,30) to clarify usage. Input schema has 0% description coverage, so description compensates fully.

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?

Clearly states 'Draw a corner-defined rectangle on the active sketch.' Distinguishes from sibling build_rectangular_pocket by noting it is sketch-only vs sketch+cut.

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 requires an active sketch ('create_sketch first'). Provides alternative build_rectangular_pocket for rectangular pockets, guiding when to use this primitive vs a combined operation.

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?

Despite no annotations, the description fully discloses behavior: creation operation, modes available, limitations of single-reference mode (face/edge names not supported), and world-axis mapping. No contradictions.

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 bullet points, a table, and a code example. It is lengthy but every section adds value; no redundancy. Minor deduction for length but fully justified by complexity.

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 2 parameters, no output schema, and no annotations, the description is exceptionally complete: covers return value format, use cases, limitations, examples, and edge cases. No 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?

With 0% schema description coverage, the description provides complete parameter semantics: explains reference_name and reference_2 inputs, naming rules (English/Spanish, custom planes), and default values. This fully compensates for the lack of schema descriptions.

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 reference axis from two planes or a single feature, with explicit verb 'Create' and resource 'reference axis'. It distinguishes this from related sibling tools like create_reference_plane by specifying the output and usage context.

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 the two-plane mode (recommended) vs single-reference mode (limited), gives detailed mapping of plane pairs to world axes, and includes an example with a specific use case for circular patterns. No ambiguity about alternatives.

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 description fully covers behavior: signed offset with positive/negative directions, zero rejected, return value (plane name, parent reference, signed offset), and even mentions tested offset limits from live verification (2026-06). This gives the agent a clear understanding of 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?

Well-structured with headings, bullet points, and code examples. Each sentence provides essential information without redundancy. Front-loaded with core purpose, then details. Efficient use of space.

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 3 params and no output schema, the description is comprehensive: covers both modes, parameter details, return value, examples, caveats, and use cases. No gaps remaining for an agent to invoke 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 coverage is 0%, but description adds rich semantics: explains `offset_from` default plane names in English and Spanish, `offset_mm` as signed distance with zero rejection and practical limits, and `face_centroid_mm` as array from list_faces(). Code examples further clarify usage. Adds significant value beyond 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?

Clearly states it creates a reference plane parallel to a default plane or a face, with two distinct modes described. The verb 'Create' and resource 'reference plane' are specific. No sibling tool duplicates this purpose, so the description effectively distinguishes it.

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 pass exactly one of `offset_from` or `face_centroid_mm`, and describes when to use each mode: 'Default-plane mode' for rib offsets, 'Face mode' for counterbore-on-flange-top. Also includes a caveat about deferred angled/through-3-points planes, indicating when not to use 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?

The description discloses that the sketch is left in EDIT mode after creation, and returns the sketch name and resolved plane name. With no annotations, it carries full burden; some minor aspects like error handling on invalid plane names are not covered, but overall it's good.

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: one sentence for purpose, a bullet list for parameter values, and clear flow instructions. Every sentence adds value without 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 single-parameter tool with no output schema or annotations, the description covers input, behavior (edit mode), return values, prerequisites, and post-creation steps. It is sufficiently complete for an agent to use 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 coverage is 0%, but the description fully explains the plane_name parameter: lists valid values ('front', 'top', 'right' and Spanish equivalents) and notes case-sensitivity. This adds complete meaning beyond the schema that only defines type 'string'.

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 'Start a new sketch on a named reference plane' with specific verb and resource. Among siblings like create_sketch_on_face, it correctly distinguishes by specifying the starting reference is a plane, not a face.

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 (requires a part document, not assembly) and provides a workflow sequence: create_sketch first, then add geometry with create_rectangle, then extrude_sketch. It also warns about the prerequisite of opening a fresh part.

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 description carries full burden. Discloses two methods for specifying face (selector vs face_centroid_mm), return structure with sketch_axis_mapping, failure modes (centroid mismatch, hidden face), and behavioral nuance that extrude_sketch defaults to inward direction. No contradictions with any 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?

Well-structured with sections (purpose, comparison, args, returns, gotchas, failure modes, example), front-loaded with key info. Length is justified by tool complexity, though some repetition (e.g., gotchas restated) could be trimmed. Slightly verbose but efficient overall.

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 low schema coverage, description covers all essential aspects: parameters, return values, failure modes, axis mapping, extrusion direction, and an example. Addresses real failure modes (LLM assumption about axes). Comprehensive for a complex geometry 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 coverage is 0%, so description must compensate. It does so extensively: explains selector with closed schema and example, explains face_centroid_mm sourced from list_faces, notes mutual exclusivity, and describes return fields including sketch_axis_mapping schema. Adds meaning far beyond bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a sketch anchored to a face on an existing body, and distinguishes it from create_sketch which only works on default planes. The verb 'start a new sketch on a face' is specific and the resource is clearly identified.

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 when to use (face-based sketch) vs alternative (create_sketch for default planes). Outlines workflow with other tools (create_circle, extrude_sketch) and includes common use cases (counterbore, hole pattern). Also gives gotchas about extrude direction and axis mapping, guiding correct usage.

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 key behavioral traits: the sketch geometry is not parametric, modify_dimension cannot resize slot width or move endpoints, and rebuilding from a fresh part is required for changes. This provides good transparency beyond the schema.

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 opening sentence, bullet-style parameter explanations, and separate caveats. The bilingual section adds useful context but could be trimmed slightly; overall, every sentence 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?

For a tool with 5 required parameters, no annotations, and no output schema, the description covers shape definition, parameter roles, usage caveats, and a common use case. It lacks explicit output specification but is otherwise thorough.

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?

All five parameters are explained in the description: endpoints (x1_mm,y1_mm and x2_mm,y2_mm) and width (width_mm) as slot width. The shape semantics are clarified (semicircular end-caps). Given 0% schema description coverage, this compensates effectively.

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 draws a straight slot on the active sketch, describes its geometry, and distinguishes it from sibling tools like create_line or create_rectangle by specifying the slot's rounded-rectangle shape and intended use.

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 mentions a common use case (adjustable bolt slots) and a prerequisite (requires active sketch), but does not explicitly guide when to use this tool over alternatives 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 provided, so description carries full burden. Discloses up-front validations (existence, not active, not only), notes reversibility (configs are pure metadata, no broken geometry), and specifies return value. Lacks mention of permissions or error handling, but covers key behavioral traits.

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?

Well-structured with purpose first, then scope, validations, and use case. Slightly verbose due to bilingual content, but each sentence adds value. Front-loaded key information.

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?

Comprehensive coverage for a deletion tool: explains preconditions, edge cases (active/only config), return value, and typical use cases. No output schema, but return value is described. Sibling reference enhances 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?

Input schema has one required string 'name' with 0% field description coverage. Description adds 'The configuration to delete' which clarifies purpose but is minimal. For a simple single-parameter tool, this is adequate but not exceptional.

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?

Clearly specifies that the tool deletes a configuration from the active document. Distinguishes itself as the only deletion tool in v1 MCP, explicitly contrasting with component/feature deletion which is not exposed.

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 states when to use (cleanup of obsolete trim variants, removing test/scratch configurations) and when not to use (not for components/features). Provides prerequisites (not active, not only configuration) and references sibling tool activate_configuration for switching active config.

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 behavioral disclosure weight. It reveals that COM driver may return None for through/depth, indicating a degradation in capability. It does not mention idempotency or auth, but for a read-only feature inspection tool, the provided details are sufficient.

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 mostly concise but includes a Spanish fragment at the start which may confuse some agents. The key information is front-loaded and each sentence adds value, but the bilingual aspect slightly reduces 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?

Given a single parameter, no output schema, and no annotations, the description fully covers the tool's behavior: return fields, usage scenario, parameter specification, and limitations. It is complete for agent 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 coverage is 0%, so the description must compensate. It provides detailed semantics for feature_name: exact name, verbatim requirement, locale-sensitivity, and source (get_active_part_info). This is critical for proper invocation and far exceeds basic schema repetition.

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 reads a built feature's definition and lists the returned fields. It also mentions its use by verify_build_report, providing a specific use case that distinguishes it from sibling tools like get_feature_inventory.

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 explains when to use the tool (e.g., for distinguishing through-hole vs blind features) and provides conditions for accurate results (rich path vs COM driver, locale-sensitive feature names). This gives clear guidance beyond the basic purpose.

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 that the sketch stays open, must be exited to save changes, and that a rebuild while open will exit it on SW 2026 ES. It also notes that other sketch tools work as on a fresh sketch. Missing error handling (e.g., sketch not found) slightly reduces score.

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 fairly concise and front-loaded with the purpose. It includes both Spanish and English, which may be redundant but adds clarity for bilingual users. Key sections: purpose, usage, args, returns, caveat.

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 (1 param, no output schema, no annotations), the description is thorough: explains purpose, usage, behavioral nuances, return value, and related tools. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description compensates by specifying the parameter 'sketch_name' as an exact name with an example ('Croquis1'). This adds meaning 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 tool's purpose: reopening an existing sketch for editing (dimensions, relations, geometry) without rebuilding the part. It distinguishes itself from sibling tools by specifying it's for editing, not creating.

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 a typical CSWA usage example and explicitly mentions when to use alternatives like create_sketch or modify_dimension. It also instructs that after editing, the user must exit with a sketch-consuming operation to lock changes.

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?

Describes the all-or-nothing semantics with rollback on failure, suppressed redraw/rebuild, and verification options. Without annotations, this fully discloses behavioral traits.

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 somewhat verbose due to bilingual text (Spanish and English), but it is well-structured with sections. Information is valuable and front-loaded with the core concept.

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, no annotations, and no output schema, the description covers all essential aspects: purpose, usage, parameters, return values for success and failure, and behavioral guarantees. It is fully informative for an 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?

With 0% schema coverage, the description extensively documents all parameters: ops format (tool and args with examples), rebuild default, and verify options. This compensates fully for the schema's lack of parameter descriptions.

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 executes an ordered list of low-level operations in one pass, using a 'compile once, build once' approach. It distinguishes from making separate calls and explicitly notes it is not for composite or perception/IO 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?

Provides explicit guidance on when to use (batch instead of individual calls) and what not to include (no nested batch calls, no composite tools). Also clarifies that human approval on this call is approval for the entire batch.

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 description carries full burden. Discloses requirement for active sketch and intersecting material, failure behavior (sketch re-opened), return format (Feature with name/type/dimensions), and a known bug with up_to_surface and reference planes.

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?

Long but well-structured with sections (Args, Returns, Caveat, Failure recovery, Example). Every sentence adds value. Front-loaded with purpose. Slightly verbose due to complexity but justified.

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?

Completely covers all 9 parameters, return value, caveats, failure recovery, examples, and even a known bug. No output schema, but description provides sufficient behavioral and semantic context 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?

Zero schema description coverage, but description provides rich parameter details: conditional meaning of depth_mm, locale-sensitive reference_name, target_bodies as scope, offset_reverse only for offset_from_surface, start_condition/start_offset_mm, etc. Adds value well beyond schema types.

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?

Clearly states the tool cuts/subtracts material from a part after exiting an active sketch. Provides a SolidWorks analogy and common use cases. Distinguishes from siblings like extrude_sketch (additive) and other cut tools by focusing on linear extrude cuts.

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?

Extensive guidance on when to use each end_condition, target_bodies, and other parameters. Includes failure recovery and related composites. Could be more explicit about when not to use this tool vs. revolve_cut, sweep_cut, etc., but the detail is thorough.

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 description carries full burden. It discloses extrusion behavior, parameter effects (including reverse_direction gotcha for face sketches), merge behavior, return values, sketch closure, and failure recovery. 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 thorough and well-structured with sections (Args, Returns, Caveat, etc.) and front-loaded action. While somewhat lengthy, every sentence adds value with no redundancy. Could be slightly tighter.

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, 4 parameters, and no annotations, the description covers all critical aspects: parameters, return info, prerequisites, error handling, multiple examples, and sibling tool relationships. Nothing missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage; the description fully compensates. Each parameter (depth_mm, end_condition, reverse_direction, merge) is explained with constraints, defaults, and behavioral effects. Examples illustrate usage.

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 exits the active sketch and extrudes it as a boss feature. It uses a specific verb (extrude) and resource (active sketch). It distinguishes from siblings like build_flange_boss and revolve_sketch.

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 provides when to use vs alternatives: mentions build_flange_boss for combined sketch-extrude, advises against using extrudes for revolve/sweep features, and notes loft is not available. Also covers failure recovery and examples.

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 carries full burden. It discloses that the tool creates a non-parametric feature (re-radius requires delete+re-run), but notes that parametric edits via modify_dimension work for simple cases. It also surfaces failure modes and side effects like body name shifts, but lacks explicit mention of whether the operation is reversible or what 'Redondeo' implies.

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 detailed and well-structured with paragraphs, bullet points, and examples, but it is verbose (over 30 lines). While thorough, it could be more concise by trimming redundant explanations (e.g., repeating failure modes). Not minimal, but organized and 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?

Given the tool's complexity (6 parameters, no output schema, no annotations), the description is remarkably complete. It covers all aspects: parameter purpose, failure modes with hints, typical usage values, and return value (Redondeo feature). It also warns about caveats like non-parametric behavior and body name shifts.

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 must compensate. It extensively documents most parameters (selector, edge_midpoints, edge_indices, radius_mm, tangent_propagation), including nested schemas and usage examples. However, it fails to explain the 'edge_circles' parameter in the schema, leaving a gap. Overall, adds significant meaning but 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 rounds one or more edges with a constant radius. It specifies the resource (edges) and the action (fillet/round). It distinguishes from variable-radius fillets by noting they are deferred, and from sibling tools like 'fillet_all_edges' by implication (this tool targets specific edges).

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 guidance on when to use each edge-addressing method (selector recommended vs. edge_midpoints vs. edge_indices), including failure modes and recovery strategies. It also gives typical radius values for different autoparts contexts and warns against batching fillets that cause body name shifts, effectively guiding correct invocation.

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 fully discloses key behaviors: non-parametric nature, tangent propagation collapsing edges, filtering rules for min_edge_length_mm, and include_arcs effect.

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?

Well-structured with clear sections for args, returns, and examples, though slightly long; every sentence 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?

Covers all aspects: purpose, parameters, return format, behavior notes, and examples. Output schema is implicitly provided in 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?

Despite 0% schema coverage, the description provides detailed, meaningful explanations for each parameter including typical values, behaviors, and edge cases.

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 'fillet every edge' and provides specific use cases for autoparts, distinguishing it from siblings like 'fillet' and 'break_all_edges'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use contexts (cast/forged parts, brackets, plastic parts) and includes examples, but lacks direct when-not-to-use or alternative tool mentions.

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?

Describes return content in detail. No side effects noted; 'get' implies read-only. Could mention error handling for no open assembly, but sufficient for 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?

Three concise sentences with purpose first, then content, then usage guidance. No waste, well-structured.

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?

Provides full return details without output schema, plus usage context. Complete for a metadata retrieval 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?

No parameters exist, schema coverage 100%. Baseline 4 appropriate as description adds no parameter info, but none needed.

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?

Clearly states it returns metadata about the active assembly, listing specific content (name, modified flag, configs, components, mates). Distinguishes from sibling manipulation 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?

Explicitly instructs 'Call this before any mate / suppression / configuration operation', providing clear when-to-use 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?

No annotations provided, so description carries full burden. It discloses the return contents (part name, modified status, features, bodies) and implies read-only behavior, but doesn't mention potential limitations like performance impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.