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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation, covering basic safety. The description adds context about entity referencing by index, which is useful for understanding how to interact with the sketch. However, it lacks details on error conditions, side effects, or what happens if constraints conflict, leaving behavioral gaps.

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

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

The description is a single, efficient sentence that directly states the tool's purpose and key operational detail (entity referencing). It is front-loaded with essential information and has no wasted words, making it highly concise and 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?

Given the tool's moderate complexity (5 parameters, mutation operation) and lack of output schema, the description is adequate but incomplete. It covers the basic action and entity referencing but misses details on usage context, potential errors, or result implications, leaving gaps for an AI agent to infer behavior.

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

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

Schema description coverage is 80%, providing good documentation for parameters like 'entity_one' and 'constraint_type'. The description adds minimal value beyond the schema, only implying entity indexing without explaining parameter interactions or constraints like when 'entity_two' is required. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the action ('Add a geometric constraint') and resource ('in the active sketch'), with specific mention of how entities are referenced ('by index within the sketch'). It distinguishes from siblings like 'create_sketch' or 'draw_line' by focusing on constraints rather than creation or drawing, though it doesn't explicitly differentiate from all constraint-related tools (none listed).

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

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

The description provides no guidance on when to use this tool versus alternatives, prerequisites (e.g., needing an active sketch), or exclusions. It mentions the active sketch but doesn't clarify if other tools might be needed first or when constraints are applicable in a workflow.

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

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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds useful context about units (cm for distances, degrees for angles) which isn't in the annotations. However, it doesn't disclose other behavioral traits like whether dimensions are editable after creation, if they affect sketch regeneration, or error conditions. With annotations covering basic safety, this adds some value but not rich behavioral context.

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

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

The description is perfectly concise with two clear sentences. The first states the core purpose, the second provides crucial unit information. Every word earns its place with zero wasted text, making it easy to parse quickly.

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

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

For a tool with 5 parameters, 80% schema coverage, and no output schema, the description provides adequate but incomplete context. It covers the purpose and units well, but doesn't explain the tool's role in the sketching workflow, how dimensions interact with constraints, or what happens after dimension addition. Given the complexity and lack of output schema, more context would be beneficial.

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 80%, so the schema already documents most parameters well. The description adds unit information (cm/degrees) for the 'value' parameter, which provides helpful semantic context beyond the schema's numeric type. However, it doesn't explain the relationship between 'dimension_type' choices and other parameters (e.g., when 'entity_two' is required), leaving some gaps.

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

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

The description clearly states the tool's purpose: 'Add a driving dimension to constrain sketch geometry.' It specifies the action (add), resource (driving dimension), and context (sketch geometry). However, it doesn't explicitly differentiate from sibling tools like 'add_constraint' or 'create_sketch', which would be needed for a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'add_constraint' or how it relates to 'create_sketch' or other geometry tools. Without any usage context or exclusions, this is minimal 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?

The NOTE discloses a non-obvious and consequential side effect — creating the joint MOVES the components into coincidence — which goes well beyond the supplied annotations and is exactly what an agent needs to know before calling a mutating tool. Gaps remain: no statement of what is returned, what happens on failure (e.g. invalid face index), or whether the move can be undone except generically via the undo sibling.

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?

Front-loaded with the core action, then constraints, then the implicit alternative, with the side effect flagged as a NOTE so it is not buried. Dense but every clause carries information; the parenthetical hinge example is the only borderline addition and it earns its place as a disambiguator.

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

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

For an 11-parameter, non-idempotent CAD mutation with no output schema, the description covers the make-or-break hazards: mandatory face geometry, the component-move side effect, and the as-built alternative. Remaining shortfall is joint_type, which has no description in the schema and no explanation in the description, leaving the agent to infer the difference between rigid, revolute, and the rest.

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 73%, so the baseline is 3, and the description earns the bump by explaining what face_one/face_two actually mean geometrically (a cylindrical face per side, hinge knuckle bore as the canonical case) and by pointing at get_object_info to obtain indices. It does not add anything for joint_type, axis, or body_one/body_two, which are left entirely to 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?

States a specific verb and resource — 'Add a joint between two components' — and immediately narrows it to face-pair geometry, distinguishing it from create_as_built_joint and from component-origin constructions. An agent can pick this tool without opening the schema.

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

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

Explicit preconditions ('face_one/face_two are mandatory', origins don't work and why), guidance on what geometry to choose ('pass a cylindrical face on each side', hinge/knuckle-bore example), a pointer to get_object_info for face indices, and a named alternative plus its selecting condition: 'use create_as_built_joint when the parts are already positioned.'

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

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

Annotations already declare the tool is mutating (readOnlyHint=false) and not idempotent. The description adds valuable context that result_option=3 may move geometry within tolerance and that the tool aims to fully constrain a sketch, giving insight into side effects beyond the basic mutation. It does not mention potential removal of existing constraints, but the annotations cover the core 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 concise with the purpose front-loaded and the result_option explained in a single line. However, the result_option explanation duplicates the schema's enum descriptions, making it slightly redundant. Still, it is efficient and well-ordered.

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 mutation tool without an output schema, the description is adequate. It clarifies the operation and options, but it does not mention what happens if the sketch is already fully constrained, potential error conditions, or any prerequisites beyond sketch existence. Given the simplicity, it is minimally sufficient but not rich.

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

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

Schema coverage is 100%: both sketch_name and result_option have descriptions, including the full enum meaning for result_option. The description repeats the enum values, which adds no new information beyond the schema. sketch_name is not addressed in the description, but the schema already documents its default behavior.

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

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

The description states a specific verb (add) and resource (geometric constraints and dimensions to a sketch), and clearly distinguishes it from the singular add_constraint/add_dimension tools by being automatic and thorough. It also mentions the Fusion 2026+ API version, leaving no ambiguity about what the tool does.

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 fully constraining a sketch, but it does not explicitly compare against alternatives like add_constraint or add_dimension, nor does it state when not to use this tool. There is no exclusion or condition to guide selection among the many sibling tools.

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

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

Annotations indicate this is a non-readOnly, non-idempotent, non-destructive operation, but the description adds minimal behavioral context. It implies mutation ('combine') without detailing effects like whether the original bodies are modified or new ones created, or any rate limits. With annotations covering basic safety, the description adds some value but lacks depth on 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 a single, efficient sentence with zero waste. It's front-loaded with the core action ('combine') and includes essential details (resources and operations). Every word earns its place, making it highly concise and 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?

Given the complexity of a boolean operation tool with 3 parameters (2 required), 0% schema coverage, no output schema, and annotations that only cover basic hints, the description is inadequate. It fails to explain parameter meanings, expected outcomes, or usage context, leaving significant gaps for an AI agent to understand and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, but it only vaguely references parameters ('two named bodies', 'join/cut/intersect'). It doesn't explain what 'target_body' and 'tool_body' represent, their formats, or the semantics of the operations beyond the enum values. This leaves key parameter meanings undocumented.

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 ('combine') and the resources ('two named bodies'), specifying the operations (join/cut/intersect). It distinguishes from siblings like 'split_body' or 'stitch_surfaces' by focusing on boolean operations between bodies. However, it doesn't explicitly differentiate from all siblings, such as 'extrude' or 'loft', which might also combine geometry in different ways.

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

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

The description provides no guidance on when to use this tool versus alternatives. It lacks context on prerequisites (e.g., existing bodies), exclusions (e.g., when to use 'split_body' instead), or comparisons to siblings like 'stitch_surfaces'. This leaves the agent without clear usage direction.

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

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

Annotations are all false and provide no safety or side-effect context, so the description carries the full burden. It discloses only that an operation is added; it does not mention whether the operation is persisted, whether a matching setup/tool is required, or what happens if required parameters are invalid.

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

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

The description is one focused sentence with no filler and conveys the core action clearly. It is somewhat sparse, but conciseness itself is appropriate.

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?

This is a complex manufacturing operation with 10 parameters, no output schema, and many CAM siblings, yet the description omits workflow context such as prerequisite setup creation, relationship to toolpath generation, and post-creation next steps. The schema covers parameters but not the operational context.

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

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

Schema description coverage is high (90%), so the schema does most of the work. The description adds modest value with 'Strategy determines the toolpath type,' and the schema already clarifies that tool_diameter is unsupported.

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

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

The description states a specific verb ('Add') and resource ('machining operation to a setup') and adds that strategy determines the toolpath type. It is clear and distinguishable from cam_create_setup and cam_generate_toolpath, though it does not explicitly name those siblings.

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

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

No guidance is given about when to use this tool versus cam_create_setup, cam_generate_toolpath, or cam_list_operations. There is no mention that a setup must already exist or that toolpath generation is a separate step.

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

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

Annotations indicate this is a non-readonly, non-idempotent, non-destructive operation. The description adds that it 'defines' setup components, which aligns with annotations. However, it doesn't provide additional behavioral context like whether this creates persistent configurations, requires specific permissions, or has side effects beyond what annotations cover.

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

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

The description is a single, efficient sentence that immediately states the tool's purpose without unnecessary words. It's appropriately sized for a creation tool with 7 parameters.

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 creation tool with 7 parameters, no output schema, and moderate schema coverage (71%), the description adequately covers the basic purpose but lacks information about return values, error conditions, or relationships to other CAM operations. The annotations help but don't fully compensate for missing output documentation.

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 71% schema description coverage, the baseline is 3. The description mentions 'stock, coordinate system, and operation type' which maps to parameters like stock_mode and operation_type, but doesn't add meaningful semantic context beyond what the schema already documents about these 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 verb 'Create' and resource 'manufacturing setup for a body', specifying it defines stock, coordinate system, and operation type. It distinguishes from siblings like 'cam_create_operation' by focusing on setup creation rather than operation creation, but doesn't explicitly contrast with other setup-related tools.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'cam_list_setups' or 'cam_create_operation'. It mentions what the tool does but gives no context about prerequisites, timing, or when other tools might be more appropriate.

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

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

Annotations indicate this is not read-only, idempotent, or destructive, but the description adds minimal behavioral context. It implies a generation process but doesn't detail effects (e.g., whether toolpaths are saved, visible in the UI, or trigger simulations). No contradiction with annotations exists, but the description could better explain the tool's impact beyond the basic hints.

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

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It uses clear language and avoids redundancy, making it easy to parse while conveying essential scope 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 lack of output schema and annotations that only cover basic hints, the description is somewhat incomplete. It doesn't explain what the tool returns (e.g., success status, generated paths) or address potential complexities like error handling for invalid inputs. However, it adequately covers the tool's intent within the context of CAM operations.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description mentions 'specific operation or all operations,' which aligns with the parameters but doesn't add significant semantic value beyond what the schema provides (e.g., clarifying interactions between 'setup_name', 'operation_name', and 'generate_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 action ('Generate toolpaths') and specifies the scope ('for a specific operation or all operations in a setup'), which distinguishes it from general CAM tools. However, it doesn't explicitly differentiate from sibling tools like 'cam_post_process' or 'cam_get_operation_info', which might involve related CAM workflows.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requiring an existing setup or operation), exclusions, or comparisons to siblings like 'cam_post_process' for post-processing or 'cam_list_operations' for listing operations without generation.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds value by specifying the types of details returned (strategy, tool, parameters, toolpath status), which provides context beyond annotations. However, it doesn't disclose other behavioral traits like error conditions, rate limits, or authentication needs.

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

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

The description is a single, efficient sentence that front-loads the purpose ('Get details about a specific operation') and specifies the key details retrieved. There is no wasted wording, and it's appropriately sized for a simple read operation.

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 low complexity (a read operation with 2 parameters), rich annotations (covering safety and idempotency), but no output schema, the description is partially complete. It specifies what details are returned, which helps, but lacks parameter explanations and usage guidelines. For a tool with good annotations but no output schema, this is adequate but has clear 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 description coverage is 0%, so the schema provides no parameter descriptions. The description doesn't add any parameter-specific information—it doesn't explain what 'setup_name' or 'operation_name' represent, their formats, or examples. With 2 required parameters and no schema descriptions, the baseline is 3 as the description doesn't compensate for the coverage gap.

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

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

The description clearly states the verb 'Get' and the resource 'details about a specific operation', specifying what information is retrieved (strategy, tool, parameters, toolpath status). It distinguishes from siblings like 'cam_list_operations' by focusing on details of a single operation rather than listing multiple, though it doesn't explicitly contrast with 'get_object_info' or 'get_parameters' which might overlap in domain.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid setup and operation name), exclusions, or compare it to similar tools like 'cam_list_operations' for listing or 'get_object_info' for general object details. Usage is implied by the name but not explicitly stated.

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

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

Annotations indicate read-only, idempotent, and non-destructive behavior, which the description does not contradict. The description adds context by specifying the scope ('within a setup'), which is not covered by annotations. However, it lacks details on output format (e.g., list structure, pagination) or any rate limits, though annotations cover safety aspects 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?

The description is a single, efficient sentence with zero wasted words. It is front-loaded with the core purpose and avoids redundancy. Every part of the sentence earns its place by specifying the action and scope.

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 low complexity (1 parameter, read-only per annotations) but lack of output schema, the description is minimally adequate. It covers the basic purpose and scope but misses details like output format or error handling. With annotations providing safety context, it meets a baseline but could be more informative for agent 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?

The input schema has 1 parameter with 0% description coverage, so the description must compensate. It implies 'setup_name' is required to scope the listing but does not explain its format, constraints, or examples. The description adds minimal meaning beyond the schema, meeting the baseline for low coverage without fully compensating.

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 'List operations within a setup' clearly states the verb ('List') and resource ('operations'), specifying the scope ('within a setup'). It distinguishes from siblings like 'cam_list_setups' (which lists setups rather than operations) and 'cam_get_operation_info' (which gets details of a specific operation). However, it does not explicitly mention what 'operations' refer to (e.g., CAM machining operations), leaving some ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing setup), exclusions, or comparisons to siblings like 'cam_get_operation_info' for detailed info or 'cam_list_setups' for listing setups. Usage is implied by the name and context but not explicitly stated.

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

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

Annotations already indicate this is a read-only, idempotent, non-destructive operation. The description adds minimal behavioral context beyond this, stating it lists 'all' setups, which implies completeness but doesn't detail format, pagination, or error handling. No contradiction with annotations exists.

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

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

The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.

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

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

Given the tool's simplicity (0 parameters, no output schema, and annotations covering safety), the description is adequate but minimal. It could be more complete by adding details like return format or usage context, but it's not incomplete for a basic list operation with good annotations.

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 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it doesn't introduce any confusion, so it meets the baseline for this scenario.

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

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

The description clearly states the action ('List') and resource ('all manufacturing setups in the document'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'cam_list_operations' or 'list_components', which would require mentioning the specific scope of CAM setups versus other listable entities.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, such as whether it should be used for CAM-specific setups only or how it relates to other list tools like 'cam_list_operations' or 'list_components'.

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

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

Annotations provide only readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so there is no contradiction. The description adds that the operation converts toolpaths to NC code, but it does not disclose side effects such as writing files to output_folder or requiring valid toolpaths, leaving the agent to infer persistence 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 definition is a single front-loaded sentence that states the action and output with no filler. Every word earns its place.

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

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

There is no output schema and the description does not explain what the agent should expect after invocation, such as confirmation, written file paths, or errors. It is adequate for selection but incomplete for reliable invocation of an action with five parameters.

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 80%, and the input schema already documents setup_name, operation_name, output_folder, units, and post_processor behavior. The tool description adds no parameter-level meaning beyond saying the result is NC code, so a baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Post-process toolpaths to generate NC code (G-code)'. This clearly distinguishes the tool from siblings like cam_generate_toolpath by naming the final output artifact.

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

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

The phrase 'post-process toolpaths' implies the tool is used after toolpath generation, but it never explicitly states when to choose it over cam_generate_toolpath or other CAM siblings, and it names no alternatives or exclusions. The usage context is inferable rather than explicit.

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

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

Annotations indicate this is a mutable (readOnlyHint: false), non-idempotent, non-destructive operation. The description adds that it modifies edges of a body, which aligns with annotations but doesn't provide additional behavioral context like whether it creates a new feature, affects model history, or has side effects. No contradiction with annotations exists.

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

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

The description is extremely concise—just four words—and front-loaded with the core action. There's no wasted language, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.

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 CAD modeling tool with four parameters, no output schema, and annotations covering only basic hints, the description is insufficient. It doesn't explain the operation's effect on the model, parameter roles, or expected outcomes, leaving too much for the agent to infer from the schema and context alone.

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 no parameter information beyond what's implied by the tool name. It doesn't explain what 'distance', 'body_name', 'body_index', or 'edge_selection' mean, their units, or how they affect the chamfer operation. This leaves significant gaps in understanding the four 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 'Chamfer edges of a body' clearly states the verb ('chamfer') and resource ('edges of a body'), making the purpose understandable. However, it doesn't differentiate this tool from similar siblings like 'fillet' (which also modifies edges) or 'bevel' operations, leaving some ambiguity about when to choose chamfering over other edge treatments.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing body), when chamfering is appropriate versus filletting, or any context-specific considerations. The user must infer usage from the tool name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds the specific behavioral context of detecting collisions/interference, which is valuable beyond the annotations. However, it doesn't describe what constitutes a 'collision' in detail, how results are returned, or any performance considerations.

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

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

The description is extremely concise - a single sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core functionality and contains zero wasted language. This is an excellent example of efficient documentation.

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

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

Given the tool's moderate complexity (collision detection with 2 parameters), good annotations, and 100% schema coverage, the description is adequate but has clear gaps. The lack of output schema means the description should ideally explain what the tool returns (e.g., boolean result, collision details, interference volume), but it doesn't. For a read-only analysis tool, this represents a significant omission in completeness.

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

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

Schema description coverage is 100%, with both parameters well-documented in the schema itself. The description doesn't add any additional parameter semantics beyond what's already in the schema descriptions. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even without parameter information in the 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 the tool's purpose with a specific verb ('Detect') and resource ('collisions between components/bodies'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'measure_distance' or 'get_physical_properties' that might involve spatial analysis, leaving room for potential confusion about when to choose this specific collision detection tool.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for measurement, analysis, and geometry operations, there's no indication of prerequisites, typical use cases, or comparisons to tools like 'measure_distance' for proximity checks or 'get_physical_properties' for spatial properties. This leaves the agent without context for tool selection.

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

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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation, but the description adds no behavioral context beyond that. It doesn't explain what 'pattern' entails (e.g., creating copies, modifying geometry), potential side effects, or performance considerations. With annotations covering basic safety, the description adds minimal value, scoring a baseline 3.

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

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

The description is a single, efficient sentence that front-loads the core action ('pattern a body'). It avoids unnecessary words, but could be more specific (e.g., 'Create copies of a body arranged in a circle around an axis') to improve clarity without losing conciseness.

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

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

For a tool with 4 parameters, low schema coverage (25%), no output schema, and no annotations explaining behavior, the description is incomplete. It lacks details on what the tool returns, how it interacts with geometry, or error conditions, making it inadequate for an agent to use effectively 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?

Schema description coverage is low at 25%, with only 'total_angle' having a description. The description adds no parameter semantics beyond the schema, failing to explain 'body_name' (what body to pattern), 'count' (number of copies), or 'axis' (rotation axis). Given the coverage gap, the description doesn't compensate, resulting in a baseline 3 due to inadequate parameter clarification.

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 action ('pattern a body') and resource ('around an axis'), which clarifies the basic purpose. However, it's vague about what 'pattern' means (creating copies in a circular arrangement) and doesn't distinguish from sibling tools like 'rectangular_pattern' or 'mirror', which also create patterns but with different geometries.

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

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

No explicit guidance is provided on when to use this tool versus alternatives like 'rectangular_pattern' or 'mirror'. The description implies usage for circular arrangements but doesn't mention prerequisites (e.g., needing an existing body) or exclusions, leaving the agent to infer context from the tool name alone.

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

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

Annotations already mark it read-only, idempotent, and non-destructive. The description adds value by disclosing the computed output fields, units (cm), and the Fusion version requirement. No behavioral trait contradicts the annotations.

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

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

A single, information-dense sentence front-loads the core operation, then states output units, a motivating example, and version compatibility without redundancy. Every clause earns its place.

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

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

For a low-complexity, read-only tool with two fully described parameters, the description supplies the missing output semantics (statistics and units) and a prerequisite, leaving no critical gap in the absence 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 coverage is 100%: both parameters are already described as 'Name of the first mesh body' and 'Name of the reference mesh body.' The description only reinforces the reference-mesh role and adds no syntax, constraints, or format details to the parameters.

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

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

The description opens with a specific verb+resource ('Compare two mesh bodies') and specifies the exact output (deviation statistics: min/max/mean/RMS signed distance in cm). The example clearly differentiates this from generic measurement tools like measure_distance or get_physical_properties.

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 provides a clear use case ('validate an imported STL against a reference mesh') and a compatibility prerequisite ('Requires Fusion 2026+'). However, it does not explicitly state when not to use it or name alternative sibling tools, so it falls just short of full guidance.

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

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

Beyond the annotations (non-readOnly, non-idempotent, non-destructive), the description discloses the key behavioral trait: components are not repositioned, the current pose is captured. It also discloses a type-dependent input requirement (face pair required for every joint type except rigid), which is real behavioral context. It does not mention that repeated calls will create duplicate joints, a notable gap given idempotentHint=false, nor what the tool returns.

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 short sentences, front-loaded with the distinguishing behavior, then the usage rule, then the conditional input requirement. No filler or restatement of the title.

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

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

For an 11-parameter mutation tool with no output schema, the description covers purpose, alternative, and the main conditional requirement. It stops short of describing failure modes (e.g., components not yet positioned, invalid face indices) or what the created joint looks like in the document, which would help an agent recover from errors.

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 73%, so much is already documented, but the description adds a cross-parameter rule the schema does not state: face_one/face_two are needed for every joint type except rigid. The axis/second_axis interplay is already covered in the schema's own description, so this is modest added value rather than a rewrite.

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

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

The description states a specific verb and resource ('Create a joint') plus the defining behavior ('keeps both components exactly where they are, capturing the current pose instead of enforcing a new one'). This immediately distinguishes it from add_joint even before reading either schema.

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

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

It gives an explicit selection rule ('Use this when the parts are already positioned correctly') and names the alternative with its contrasting behavior ('add_joint instead moves components to make the joint geometry coincident'). The condition that selects between the two siblings is fully spelled out.

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

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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation, which the description doesn't contradict. The description adds minimal behavioral context beyond annotations—it implies a geometric modification but doesn't specify effects like permanent model changes, error conditions, or typical use cases in CAD workflows.

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

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

The description is a single, direct sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.

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 CAD modeling tool with 4 parameters, no output schema, and annotations covering basic safety, the description is minimally adequate. It states what the tool does but lacks details on typical outcomes, error handling, or integration with sibling tools, leaving gaps in contextual understanding.

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

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

Schema description coverage is 75% (3 of 4 parameters have descriptions), providing good baseline documentation. The description doesn't add meaningful parameter semantics beyond what the schema already covers (e.g., it doesn't explain relationships between parameters like bend_line_sketch and angle).

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

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

The description clearly states the action ('Add a bend') and the target resource ('to a sheet metal body'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'create_flange' or 'fold/unfold' operations, which might also manipulate sheet metal geometry.

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

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

No guidance is provided on when to use this tool versus alternatives like 'create_flange' or 'fold' operations. The description lacks context about prerequisites (e.g., needing a sheet metal body and bend line sketch) or when this operation is appropriate in a design workflow.

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

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

Annotations indicate this is a non-readOnly, non-idempotent, non-destructive operation. The description adds that it creates 'non-parametric' geometry via 'TemporaryBRepManager', which provides useful context about the creation method and persistence characteristics. However, it doesn't explain what 'TemporaryBRepManager' means in practice or how the created box interacts with the modeling environment.

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

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

The description is a single, efficient sentence that gets straight to the point. There's no wasted verbiage, though it could potentially benefit from slightly more detail given the complete lack of parameter documentation in the schema.

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

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

For a 6-parameter creation tool with no output schema and 0% schema description coverage, the description is inadequate. It doesn't explain what the tool returns, how the created box integrates into the scene, what coordinate system is used, or provide any examples of typical usage patterns.

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 for all 6 parameters, the description provides no information about what length, width, height, or center coordinates mean. It doesn't specify units, coordinate system, orientation, or how these parameters relate to the resulting box geometry. The description fails to compensate for the complete lack of schema documentation.

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

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

The description clearly states the verb ('Create') and resource ('box primitive'), and specifies it's 'non-parametric via TemporaryBRepManager' which distinguishes it from parametric modeling approaches. However, it doesn't explicitly differentiate from sibling tools like 'create_component' or 'create_cylinder' that also create geometry.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for creating geometry (create_cylinder, create_sphere, create_torus, etc.), there's no indication of when a box primitive is appropriate versus other primitives or modeling methods.

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

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

The description adds meaningful behavioral detail beyond the annotations: it creates a history-based feature using sketch + extrude, accepts expressions referencing User Parameters, and clarifies unit handling. The annotations only indicate non-readonly, non-idempotent, non-destructive, so this additional context is valuable and not contradictory.

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 focused sentences with no filler. The key distinction from create_box is front-loaded, followed by parameter format details and a prerequisite call. Every sentence earns its place.

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

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

The description covers the construction method, accepted value formats, units, expression examples, and the prerequisite create_parameter call. It does not describe the return value or error behavior, but there is no output schema and the schema covers most parameter details. Overall, it provides enough context 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?

The schema already documents each dimension parameter as 'number (cm) or expression', but the description adds important examples and clarifies that expressions can reference named User Parameters with syntax like 'outer - 2 * wall_t'. This goes beyond the schema and helps the agent construct valid inputs.

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

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

The description states a specific operation: create a history-based rectangular box via sketch rectangle + extrude. It also explicitly distinguishes this tool from create_box by noting the different construction method (TemporaryBRepManager vs. history-based). An agent can clearly identify what this tool does and how it differs from a sibling.

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 names create_box as the alternative and explains the fundamental difference. It also provides a sequencing instruction: call create_parameter first to define named parameters. It could be more explicit about when not to use this tool, but the context is clear enough for an agent to decide.

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

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

Annotations already indicate this is a non-readonly, non-idempotent, non-destructive operation. The description adds minimal context beyond this - it specifies 'new component (sub-assembly)' which clarifies the type of object being created, but doesn't address behavioral aspects like permissions needed, what happens on duplicate names, or response 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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple creation tool and front-loads the 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 creation tool with good annotations (readOnlyHint=false, destructiveHint=false) and full schema coverage, the description is minimally adequate. However, without an output schema and with many similar sibling tools, it could benefit from more context about what constitutes a 'component' versus other creatable objects and what the tool returns.

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 100% schema description coverage, the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema - no examples, formatting details, or clarification about the parent-child relationship implied by 'sub-assembly'.

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

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

The description clearly states the action ('Create') and resource ('new component (sub-assembly) in the design'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_box' or 'create_cylinder' that also create objects but of different types.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling 'create_' tools (e.g., create_box, create_cylinder, create_sketch), there's no indication of when a component is appropriate versus other object types, nor any prerequisites or exclusions mentioned.

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

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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation (readOnlyHint: false, idempotentHint: false, destructiveHint: false). The description doesn't contradict these annotations, but it also adds no behavioral context beyond the basic 'create' action. No information about side effects, error conditions, or system behavior is provided, though annotations cover the safety profile adequately.

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

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

The description is extremely concise with just three words. While it's under-specified for the tool's complexity, it's not verbose or poorly structured. Every word serves a purpose, and there's no wasted text, earning full marks for conciseness.

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

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

Given the tool's complexity (7 parameters with conditional dependencies based on 'method'), lack of output schema, and minimal annotations, the description is inadequate. It doesn't explain what a construction axis is, how it's used in CAD workflows, or provide any context about the multiple creation methods. For a tool with this parameter richness, more explanation 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 description coverage is 57% (4 of 7 parameters have descriptions). The description adds no parameter information beyond what's in the schema. It doesn't explain the relationship between 'method' and other parameters (e.g., that 'point_one' and 'point_two' are required for 'two_points' method), nor does it clarify the purpose of construction axes. With incomplete schema coverage, the description fails to compensate.

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 'Create a construction axis' is a tautology that restates the name/title without adding specificity. It doesn't explain what a construction axis is, what it's used for, or how it differs from other construction tools like 'create_construction_plane' in the sibling list. The purpose is stated but lacks meaningful differentiation.

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

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

There is no guidance on when to use this tool versus alternatives. The description provides no context about appropriate scenarios, prerequisites, or how it relates to other tools in the extensive sibling list (e.g., when to create an axis versus a plane or sketch). This leaves the agent with no usage direction.

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

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

Annotations indicate this is a non-readOnly, non-idempotent, non-destructive operation, which the description doesn't contradict. The description adds minimal behavioral context by specifying the plane is 'for sketching', but doesn't explain what happens after creation (e.g., if it becomes active, how it interacts with other features, or any side effects). With annotations covering basic safety, this earns a baseline score for adding some purpose but lacking detailed 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 a single, clear sentence with no wasted words. It's front-loaded with the core action and purpose, making it efficient and easy to parse, which is ideal for conciseness.

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

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

Given the tool's complexity (10 parameters, no output schema) and rich schema coverage, the description is minimal but not incomplete. It states what the tool does but lacks context on usage, output, or integration with other tools. With annotations providing safety hints, it's adequate but leaves gaps in guiding the agent effectively.

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

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

Schema description coverage is high at 90%, with most parameters well-documented in the schema itself (e.g., method enum values, plane references). The description adds no parameter-specific information beyond the general purpose, so it relies on the schema. This meets the baseline for high schema coverage without adding extra value.

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

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

The description clearly states the action ('Create') and resource ('construction plane') with the purpose 'for sketching', which distinguishes it from other creation tools like create_box or create_cylinder. However, it doesn't explicitly differentiate from create_sketch, which might be a related sibling tool for sketching purposes.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., when sketching is needed), or how it relates to sibling tools like create_sketch or create_construction_axis, leaving the agent with no usage direction.

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

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

Annotations indicate this is a mutable, non-idempotent, non-destructive operation, which the description does not contradict. The description adds value by specifying 'non-parametric via TemporaryBRepManager', hinting at creation behavior without persistence or parametric features, but it doesn't detail effects like scene changes or error conditions.

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

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

The description is a single, efficient sentence that front-loads the core action. It avoids unnecessary words, though it could be more structured by separating purpose from technical notes.

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 creation tool with no output schema and low parameter documentation, the description is incomplete. It lacks details on return values, error handling, or how the cylinder integrates into the scene, making it inadequate for full contextual understanding.

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

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

With low schema description coverage (17%), the description does not compensate by explaining parameters. It mentions 'non-parametric' but doesn't clarify what parameters like 'radius', 'height', or 'axis' mean in context, leaving semantics largely undocumented beyond the minimal schema details.

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

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

The description clearly states the action ('Create a cylinder primitive') and specifies the resource ('cylinder'), but it does not explicitly differentiate from sibling tools like 'create_box' or 'create_sphere'. The mention of 'non-parametric via TemporaryBRepManager' adds technical context but doesn't clarify functional uniqueness among siblings.

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

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

No guidance is provided on when to use this tool versus alternatives like 'create_box' or 'create_sphere', nor are there any prerequisites or exclusions mentioned. The description lacks context for tool selection among the many creation tools available.

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

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

Annotations indicate this is a non-readOnly, non-idempotent, non-destructive operation. The description adds that it creates a flange, implying a modeling operation that modifies geometry. However, it doesn't disclose additional behavioral traits like whether it requires specific permissions, how it handles errors, or what the expected output looks like (since no output schema exists).

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly.

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 creation tool with 5 parameters, no output schema, and annotations covering basic hints, the description is minimally complete. It specifies the action and target but lacks details on usage context, error handling, or output format, leaving gaps that could hinder effective tool selection and invocation.

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

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

Schema description coverage is 60% (3 of 5 parameters have descriptions). The description mentions 'on an edge', which hints at 'edge_index', but doesn't add meaning beyond the schema for parameters like 'body_name', 'height', 'angle', or 'bend_radius'. With moderate schema coverage, the baseline score of 3 is appropriate as the description provides minimal additional parameter 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 specific action ('Create a sheet metal flange') and the target resource ('on an edge'), using precise terminology. It distinguishes this tool from siblings like 'create_bend' (which might create bends without specifying flange geometry) or 'extrude' (which creates features from sketches rather than 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 no guidance on when to use this tool versus alternatives like 'create_bend' or 'extrude', nor does it mention prerequisites (e.g., needing an existing body with an edge). It simply states what the tool does without contextual usage information.

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

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

Annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) already convey that this operation mutates state. The description adds one behavioral scope, that the hole is placed on a body face, and is consistent with annotations. It does not disclose further details like requiring an existing body or top/bottom face, but the annotation coverage lowers 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?

The description is a single sentence with no fluff, and the core purpose is front-loaded. It is efficiently worded, even though the brevity leaves important guidance to other dimensions.

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 seven params, no output schema, sparse annotations, and a single-sentence description, this is not sufficiently complete. It lacks clarity on how the body is selected (name vs index), what depth/diameter mean, how top/bottom face selection works, coordinate system details, and what the resulting operation reports back.

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 only 43%, so the description needed to compensate by explaining core parameters like diameter, depth, body_name, or body_index. It only says 'on a body face', which hints at face selection but does not clarify required dimensions or body selection. Schema descriptions cover center and face_selection, but the description itself adds little paramter meaning.

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

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

The description names the verb ('Create') and the exact resource ('hole feature on a body face'), which clearly separates it from positive-feature tools like create_cylinder or boolean_operation. It is not a tautology and leaves little ambiguity about what the tool produces.

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

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

The phrase 'on a body face' gives an implied usage occasion: you want to add a hole to an existing body face. However, the description contains no explicit when-to-use, when-not-to-use, or alternative routing such as versus extrude/boolean subtraction or face selection conditions.

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

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

Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation, and the description does not add behavior beyond that. It does not state what happens on duplicate names, whether existing values are overwritten, or what the response contains. The description is not contradictory, but it provides no extra operational context.

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

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

The description is a single, front-loaded sentence with no filler or repetition. It is appropriately concise, though it borders on being too terse to convey usage context.

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

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

For a mutation tool with no output schema and no behavioral notes, the description is thin. An agent would need to infer or experimentally discover what happens if a parameter with the same name already exists, whether the creation is immediately persisted, and how to confirm success. The schema explains inputs well, but the overall context for safely using the tool is incomplete.

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

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

Schema coverage is 100%, so the parameters are already fully documented in the input schema. The description adds no semantic information about parameters, but since the schema carries the load, the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Create') and a concrete resource ('user parameter'), and the word 'new' helps distinguish this from sibling tools like set_parameter and delete_parameter. It could be slightly more precise about what makes a parameter 'user-defined', but the core purpose is immediately clear.

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

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

The description gives no guidance on when to choose this tool over set_parameter, delete_parameter, or get_parameters. There is no mention of prerequisites, duplicate handling, or whether this is for creating a brand-new parameter versus updating an existing one. The distinction is only implicit in the name.

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

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

Annotations already declare mutation (readOnlyHint=false), non-idempotence and non-destructiveness, and the description adds nothing on top: it does not say whether the polygon becomes a closed profile usable by extrude, what happens if no sketch exists, or whether it lands as a new body or sketch curve. The most valuable behavioral note (curves lie in the sketch plane, use create_sketch z_offset to move the plane) sits in the schema, not the description.

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?

A single front-loaded sentence with zero filler; the scope constraint (most recent sketch) is placed where it matters. Its brevity is efficient rather than padded, though it borders on under-specification rather than crisp economy.

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 5-parameter geometry primitive with no output schema this is close to adequate — the agent knows what is drawn and where. But with 40% schema coverage it should at minimum clarify the center-coordinate frame and the sketch prerequisite, which are exactly the details an agent is most likely to get wrong.

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 only 40% and the description compensates for none of the gaps. It never explains that 'sides' is an integer 3-64 defining edge count, that center_x/center_y position the polygon within the sketch plane (defaulting to the origin), or what coordinate frame those values are in — leaving three of five parameters with no meaning beyond their names.

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

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

Specific verb ("Draw") plus specific resource ("a regular polygon") plus placement scope ("in the most recent sketch"). It is naturally distinguishable from draw_rectangle, draw_circle and draw_line without opening a schema, though it does not explicitly name those siblings as alternatives.

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?

"Most recent sketch" implies a sketch must already exist and that this tool cannot target an arbitrary sketch, which is useful. Beyond that there is no when-to-use/when-not guidance, no mention of create_sketch as the prerequisite step, and no comparison to the other draw_* siblings.

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

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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation, which the description aligns with by implying a creation action ('Lock'). The description adds minimal behavioral context beyond annotations—it hints at grouping behavior but doesn't detail effects like persistence, reversibility, or interaction with other operations. No contradiction with annotations exists.

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

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

The description is a single, efficient sentence with zero wasted words—'Lock multiple components together' directly conveys the core action. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly.

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 no output schema and annotations cover basic safety (non-destructive), the description is minimally adequate. It states the purpose but lacks details on behavioral outcomes, error conditions, or integration with sibling tools. For a creation tool with 2 parameters, it meets a bare minimum but doesn't provide rich contextual guidance.

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

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

Schema description coverage is 100%, with clear parameter documentation: 'component_names' (array of strings, min 2 items) and 'include_children' (boolean, default true). The description 'Lock multiple components together' loosely relates to 'component_names' but adds no specific semantics beyond the schema, such as format examples or grouping implications. Baseline 3 is appropriate given high schema coverage.

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

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

The description 'Lock multiple components together' clearly states the tool's function with a specific verb ('Lock') and resource ('components'), and the 'rigid' aspect is implied. However, it doesn't explicitly differentiate from sibling tools like 'create_component' or 'add_joint', which could also involve component relationships, leaving some ambiguity about its unique role.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'create_component', 'add_joint', or 'boolean_operation' that might handle component interactions, there's no indication of specific use cases, prerequisites, or exclusions for 'create_rigid_group'.

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

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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation, but the description adds minimal behavioral context beyond the action. It implies a creation or analysis outcome but does not detail effects like visual changes, data generation, or interaction with the model. No contradiction with annotations exists, but the description offers limited value beyond them.

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

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

The description is a single, front-loaded sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized for a simple tool, making it efficient and easy to parse for an AI agent.

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

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

Given the tool's moderate complexity (2 parameters, no output schema), the description is minimally adequate but lacks depth. It covers the basic action but omits details on output format, side effects, or integration with sibling tools. With annotations providing safety hints, the description is complete enough for basic use but could be more informative.

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 50% (only 'offset' has a description), and the description does not add meaning for parameters beyond the schema. It mentions 'plane' and 'offset' implicitly but provides no extra details on usage, constraints, or effects. With moderate schema coverage, the baseline score of 3 is appropriate as the description does not compensate for gaps.

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

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

The description clearly states the action ('cut a section plane') and the target ('through the model'), which is specific and distinguishes it from sibling tools like 'create_construction_plane' or 'get_object_info'. However, it does not explicitly differentiate from all siblings (e.g., 'split_body' or 'trim_surface' could involve cutting), so it falls short of a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'create_construction_plane' for reference geometry or 'get_scene_info' for analysis. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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

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

Annotations indicate this is a non-readOnly, non-idempotent, non-destructive operation, which the description doesn't contradict. The description adds minimal behavioral context by mentioning the plane options and offset capability, but doesn't disclose important details like whether sketches are persistent, if they can be edited later, or what happens on failure. With annotations covering basic safety, this earns a baseline 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 extremely concise—a single sentence that's front-loaded with the core action. Every word earns its place without redundancy, making it easy to parse quickly. No unnecessary details or verbose explanations are included.

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 no output schema and annotations cover basic safety, the description is minimally complete. It identifies the action and parameters but lacks depth on usage context, return values, or error handling. For a creation tool with 2 parameters, this is adequate but leaves gaps in practical guidance.

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

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

Schema description coverage is 50% (only 'z_offset' has a description). The description mentions 'plane' and 'offset' but doesn't add meaningful semantics beyond what the schema provides—it doesn't explain what the planes represent, default behaviors, or offset implications. With partial schema coverage, the description doesn't adequately compensate, warranting a baseline score.

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

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

The description clearly states the verb ('Create') and resource ('new sketch'), specifying it occurs on specific planes (xy/yz/xz). However, it doesn't differentiate from sibling tools like 'draw_rectangle' or 'draw_circle' that might also create sketches, leaving some ambiguity about when to use this versus other drawing tools.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'optionally offset' but doesn't explain scenarios where offsetting is beneficial or when other tools like 'create_construction_plane' might be more appropriate. No explicit when/when-not instructions are given.

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

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

Annotations already indicate this is a mutable operation (readOnlyHint: false) that's neither idempotent nor destructive. The description adds some context about being 'non-parametric via TemporaryBRepManager', which suggests a specific creation method, but doesn't elaborate on what this means behaviorally (e.g., whether the sphere can be edited later, if it's temporary, or how it integrates with the CAD environment).

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

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

The description is a single, efficient sentence that gets straight to the point. It could potentially benefit from slightly more context about the sphere's characteristics or usage, but it doesn't waste words and communicates the core purpose effectively.

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 creation tool with no output schema and minimal annotations beyond basic mutability hints, the description provides the essential 'what' but lacks important context. It doesn't explain what happens after creation (e.g., where the sphere appears, whether it's selectable/editable, or what the return value might be). The 'non-parametric via TemporaryBRepManager' hint suggests technical specifics but doesn't make them 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?

With 0% schema description coverage, the schema provides only basic type constraints. The description doesn't add any parameter information beyond what's implied by the tool name. It doesn't explain what 'radius' represents, what units are used, or what the center coordinates mean in the 3D space. However, the parameter names are self-explanatory (radius, center_x/y/z), providing some inherent clarity.

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 ('Create') and resource ('sphere primitive'), specifying it's non-parametric via TemporaryBRepManager. However, it doesn't explicitly differentiate from sibling tools like 'create_box' or 'create_cylinder' beyond the sphere shape, leaving some ambiguity about when to choose this specific primitive creation tool.

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

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

No guidance is provided on when to use this tool versus alternatives like 'create_box' or 'create_cylinder'. The description mentions 'non-parametric via TemporaryBRepManager', but doesn't explain what this means in practical usage or when this approach is preferred over parametric 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?

Annotations already declare this is a write operation (readOnlyHint=false), non-idempotent, and non-destructive. The description adds useful context about the two thread types (cosmetic vs modeled) which isn't captured in annotations, but doesn't provide additional behavioral details like permission requirements, side effects, or what happens if applied to non-cylindrical faces.

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

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

The description is a single, efficient sentence that communicates the essential purpose without unnecessary words. It's front-loaded with the core action and immediately qualifies the thread types, making it easy for an agent to parse quickly.

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 9-parameter CAD modeling tool with no output schema, the description is minimally adequate. It covers the basic purpose but lacks information about return values, error conditions, or practical usage context. The high schema coverage helps, but more guidance would be beneficial given 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?

With 89% schema description coverage, most parameters are well-documented in the schema itself. The description adds minimal semantic context beyond what's in the schema - it mentions 'cylindrical face' which relates to face_index, and 'cosmetic or modeled' which relates to is_modeled, but doesn't provide additional interpretation or usage examples for the 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 specific action ('Add threads') and target resource ('to a cylindrical face'), with explicit qualification of thread types ('cosmetic or modeled'). It distinguishes from sibling tools like 'create_hole' or 'chamfer' by focusing specifically on thread creation functionality.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or constraints. While it specifies the target must be a cylindrical face, it doesn't explain how this differs from other face modification tools or when threads are appropriate versus other features.

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

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

Annotations indicate this is a mutable (readOnlyHint: false), non-idempotent, non-destructive operation. The description adds that it creates a 'primitive' and uses 'TemporaryBRepManager', which suggests it might be a temporary or intermediate geometric representation, but doesn't clarify persistence, side effects, or error conditions. No contradiction with annotations exists.

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

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

The description is a single, efficient sentence that front-loads the core action ('Create a torus primitive') and adds technical context without redundancy. Every word serves a purpose, making it appropriately concise.

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

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

Given the complexity of a 3D modeling tool with 6 parameters, no output schema, and annotations covering basic safety, the description is minimal. It states what the tool does but lacks details on return values, error handling, or integration with sibling tools, leaving gaps for an AI agent to infer usage.

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

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

Schema description coverage is low (33%), with only 'major_radius' and 'minor_radius' described. The description adds no parameter details beyond what's in the schema, such as explaining 'axis' enum choices or default center values. With 6 parameters and poor schema coverage, the description fails to compensate adequately, resulting in a baseline score.

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

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

The description clearly states the action ('Create a torus primitive') and specifies the method ('non-parametric via TemporaryBRepManager'), which distinguishes it from potential parametric creation methods. However, it doesn't explicitly differentiate from sibling tools like 'create_box' or 'create_sphere' beyond the geometric shape.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'create_sphere' or 'create_cylinder', nor does it mention prerequisites, context, or exclusions. It lacks any usage context or comparison to sibling tools.

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

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

The description discloses a meaningful side effect beyond the annotations: a hidden reference sketch is created to anchor the UCS and should not be deleted. This is valuable behavioral context that the annotations do not convey. It does not contradict the provided 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 two sentences, front-loads the core action, and includes all essential caveats (API preview and hidden reference sketch). Every sentence earns its place with 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?

Given the high schema coverage, the description provides enough context for an agent to invoke the tool correctly. It covers the action, coordinate inputs, optional rotation, API status, and an important side effect. It could be slightly more complete by stating what the tool returns, but the rest is 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 input schema already documents all 7 parameters with full descriptions, default values, and units. The description adds minimal extra meaning by summarizing the (x, y, z) origin and optional rotation, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Create a UCS at (x, y, z) with optional rotation.' It clearly identifies what the tool does and is unambiguous among the sibling tools, especially since no other sibling creates a coordinate system.

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

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

The description implies when to use the tool by explicitly naming UCS creation, and the 'Fusion 2026+ UCS API, preview' qualifier gives some context. However, it does not provide explicit when-to-use vs. alternative guidance or state exclusions, so the guidance is only implied.

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

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

Annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds value by clarifying the scope ('all timeline items') and the action ('Clear'), which aligns with annotations and provides context on what gets destroyed. No contradiction exists.

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

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

The description is a single, efficient sentence that front-loads the core action ('Clear the design') and specifies the target ('delete all timeline items') without any redundant information. Every word serves a purpose.

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

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

Given the tool's destructive nature, annotations cover safety (destructiveHint=true), and the description adds scope. However, with no output schema, it lacks details on return values or confirmation messages, leaving a minor gap in completeness for such a high-impact operation.

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

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

With 0 parameters and 100% schema description coverage, the baseline is 4. The description confirms no inputs are needed by specifying the action applies to 'all timeline items', adding clarity beyond the empty 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 verb ('Clear'/'delete') and resource ('design'/'timeline items'), specifying the scope as 'all timeline items'. It distinguishes from siblings like 'delete_parameter' by targeting the entire design rather than a specific parameter.

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 when clearing all timeline items is needed, but does not explicitly state when to use this tool versus alternatives (e.g., 'delete_parameter' for specific deletions) or provide exclusions. It offers basic context without detailed 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?

Annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false, covering key behavioral traits. The description adds minimal context beyond this, as 'Remove' aligns with destructive but doesn't elaborate on effects (e.g., irreversible deletion, impact on dependent features) or permissions needed. No contradiction with annotations exists.

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

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

The description is a single, direct sentence with zero wasted words, making it highly efficient and front-loaded. Every word contributes to understanding the tool's purpose without unnecessary elaboration.

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 destructive nature (per annotations) and lack of output schema, the description is minimally complete but lacks depth. It doesn't explain what happens post-deletion (e.g., error if parameter doesn't exist, return value) or dependencies, though annotations cover safety aspects. For a simple deletion tool, this is adequate but not comprehensive.

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

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

Schema description coverage is 100% with one parameter ('name') clearly documented. The description doesn't add any meaning beyond the schema, such as format examples or constraints (e.g., case sensitivity). With high schema coverage, a baseline score of 3 is appropriate as the schema handles parameter documentation adequately.

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 'Remove a user parameter' clearly states the action (remove) and resource (user parameter), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_all' (which might delete all parameters) or 'set_parameter' (which modifies rather than removes), missing full sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., parameter must exist), exclusions (e.g., cannot delete system parameters), or compare to siblings like 'delete_all' or 'set_parameter', leaving usage context unclear.

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

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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation, which the description doesn't contradict. The description adds context about the purpose (mold release/injection molding) but doesn't disclose additional behavioral traits like whether the operation is reversible, has specific failure modes, or affects related geometry beyond the selected faces.

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

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

Single sentence that is front-loaded with the core action and purpose, with no wasted words. Efficiently conveys the tool's function in a compact form appropriate for its 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 geometric modeling tool with 5 parameters, no output schema, and annotations covering basic safety, the description is minimally adequate. It states the purpose but lacks details on geometric constraints, error conditions, or output expectations, leaving gaps for an AI agent to infer behavior.

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

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

With 80% schema description coverage, the schema already documents parameters well (e.g., 'angle' as draft angle in degrees, 'face_selection' options). The description adds no parameter-specific semantics beyond implying 'faces' are targeted, aligning with the baseline for high schema coverage without extra value.

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

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

The description clearly states the action ('Add a draft angle') and target resource ('faces of a body'), with specific context ('for mold release / injection molding'). It distinguishes from siblings like 'chamfer' or 'fillet' by focusing on draft/taper functionality, though it doesn't explicitly compare to similar tools like 'offset_faces'.

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

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

No guidance on when to use this tool versus alternatives like 'offset_faces' or 'chamfer' for similar geometric modifications. The description mentions the application context (mold release/injection molding) but doesn't provide explicit usage scenarios, 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is known; the description correctly does not contradict them. It adds the important behavioral detail that the arc is written into the most recent sketch rather than a newly created one, which matters for side effects. It does not cover what happens when no sketch exists, whether repeated calls stack arcs, or what the tool returns.

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?

A single front-loaded sentence with the action first and the required inputs in a compact parenthetical; nothing is redundant. It is arguably over-compressed for a 7-parameter mutation tool, but every word carries meaning and there is no filler.

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

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

For a non-idempotent geometry mutation with 7 parameters and no output schema, the description covers the essential shape of the call (center, start, sweep) but omits coordinate units, the prerequisite sketch state, and failure behavior. Because the schema already documents sweep_angle degrees/CCW and the ignored z parameters, the remaining gap is moderate rather than severe.

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 only 43%, and the undocumented parameters are the coordinate values (center_x/center_y, start_x/start_y) plus start_z/center_z. The description maps these to 'center' and 'start point', giving conceptual meaning and showing that center, start, and sweep fully define the arc. It adds no units for the coordinates and no plane semantics beyond what the schema's z-parameter notes already state, so it only partially compensates for the coverage 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?

States a specific verb and resource ('Draw an arc') and enumerates the geometric inputs (center + start point + sweep angle), which cleanly separates it from draw_line, draw_circle, and draw_rectangle. It also names the target container, 'the most recent sketch', so an agent knows where the geometry lands. It does not explicitly distinguish itself from a spline or polygon tool, but the arc-specific construction is unambiguous.

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

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

'In the most recent sketch' implies the prerequisite that a sketch must already exist and that this is a sketch-edit operation, but the guidance is implicit rather than stated. There is no instruction to call create_sketch first, no statement that an already-active sketch cannot be targeted, and no mention of alternatives or when-not-to-use. The agent must infer the workflow ordering from other 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the mutate-but-non-destructive profile is covered. The description adds the useful fact that geometry lands in the implicit most-recent sketch, but says nothing about what happens when no sketch exists or about units of the radius.

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?

A single short sentence with zero filler, and the scope constraint is front-loaded where it matters. It is terse to the point of under-specification, but nothing is wasted or padded.

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 4-parameter geometry mutation with low schema coverage and no output schema, one sentence is thin: the coordinate frame, units, required preconditions (active sketch, create_sketch with z_offset to move the plane), and differentiation from draw_circles are all absent.

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

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

Schema description coverage is only 25%: center_z is well documented, but radius and center_x/center_y are bare. The description adds no meaning at all - no units, no indication that center_x/center_y are coordinates in the sketch plane - so it fails to compensate for the coverage 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 states a specific verb and resource ("Draw a circle") plus a scoping constraint ("in the most recent sketch"), so an agent knows the target is the active sketch rather than an arbitrary one. It does not distinguish itself from near-siblings like draw_circles or draw_arc, which prevents a 5.

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?

Implicit guidance: the phrase "most recent sketch" tells the agent a sketch must already exist and that the target is not selectable. It never states when to use this versus draw_circles (plural) or create_polygon, and gives no prerequisites or failure conditions.

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

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

Annotations only declare it is a non-idempotent, non-destructive write; the description adds real context — it targets the most recent sketch, defers the re-solve across all inserts, and restores prior state afterwards. 'Restores the previous state' is left ambiguous (undo state vs sketch state) and nothing is said about partial-failure rollback, which keeps it off a 5.

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

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

Purpose is front-loaded in the first clause and the performance benchmark justifies its length rather than padding it. The middle clause on superlinear re-solve is somewhat technical but earns its place as the rationale for using the bulk variant.

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

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

For a 6-parameter geometry mutation with no output schema and thin schema coverage, the description is silent on the resulting geometry (where the row starts, how it is oriented relative to the requested centre) and on return values or error behavior. The performance rationale is strong, but an agent still cannot predict the produced layout from the text plus 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 only 33%, so the description must carry parameter meaning — and it mentions no parameters at all. It never explains the row's origin (center_x/center_y), whether spacing is edge-to-edge or centre-to-centre, or how axis interacts with the layout, leaving half the parameters undocumented in both places.

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

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

States a specific verb and resource ('Add several equally spaced circles'), names the target ('the most recent sketch'), and the bulk scope cleanly separates it from the single-shot draw_circle sibling. An agent can tell what will be produced without opening the schema.

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

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

Implies the when-to-use rule clearly: use this instead of one call per circle when entity counts are high, backed by the 68 ms vs 912 ms comparison. It never explicitly names draw_circle as the alternative for a single circle, so the routing rule is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds only the targeting rule (most recent sketch) and says nothing about the non-idempotent implication that repeated identical calls create duplicate lines, whether constraints are auto-added, or what happens on failure. Beyond the annotation set, it contributes very little behavioral context for a mutating tool.

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

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

A single short sentence with zero filler and the target scope front-loaded. It is efficient, though the brevity is partly under-specification rather than disciplined compression.

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

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

For a 6-parameter mutating geometry tool with no output schema and only 33% schema coverage, the description is too thin. An agent cannot learn from it what the coordinate system is, what the tool returns, or how errors (no sketch present) surface — all of which the description would need to carry given the absent 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 only 33%: start_z and end_z carry inline notes explaining they are ignored and that create_sketch(z_offset=...) should be used instead, but start_x, start_y, end_x, and end_y have no schema descriptions at all. The tool description does not compensate — it says nothing about coordinate units, origin, or that the coordinates are interpreted in the sketch plane, leaving the four required parameters semantically unexplained.

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

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

"Draw a line in the most recent sketch" names a specific verb (draw) and resource (line) plus the target container (most recent sketch), which is concrete enough to act on. It does not differentiate from adjacent curve-drawing siblings such as draw_arc, draw_spline, or draw_rectangle beyond the geometry type itself, so it stops short of a 5.

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

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

The phrase "in the most recent sketch" implicitly tells the agent the prerequisite context (a sketch must already exist and be the newest one) and implies that create_sketch should be called first. However, there is no explicit when-to-use statement, no named alternatives (draw_arc, draw_spline, draw_rectangle), and no stated behavior when no sketch exists.

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

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

Annotations already declare this is a non-idempotent, non-destructive write, so the safety profile is covered. The description adds one behavioral trait — geometry is placed in the most recent sketch rather than a new one — but omits what happens if no sketch exists, what units width/height use, and whether the rectangle is origin-anchored or centered.

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?

A single front-loaded sentence with no filler. It is efficient, though the terseness leaves purpose-critical details unstated rather than wasted.

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

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

With five parameters, low schema coverage, a mutation annotation set, and no output schema, the description should carry more weight. It leaves unresolved the origin/centering semantics, units, failure behavior with no active sketch, and what the call returns.

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 only 20%: only origin_z is documented (as ignored), while width, height, origin_x, and origin_y carry no explanation. The description does not compensate by clarifying whether origin is a corner or center point, what units apply, or how width/height are measured — the most consequential ambiguity for a geometry call.

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

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

States a specific verb and resource (draw a rectangle) and scopes it to the most recent sketch, so an agent can distinguish it from create_sketch or draw_line. It stops short of explicitly contrasting with sibling drawing tools such as create_polygon or draw_circle.

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

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

The phrase 'in the most recent sketch' implies a precondition (an active/existing sketch) but gives no explicit when-to-use guidance, no alternative recommendations, and no statement about what to do when no sketch exists. Usage must be inferred.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the mutation profile is known. The description adds the useful scoping fact that geometry lands in the most recent sketch, but it does not disclose the consequence of non-idempotency (repeated calls stack duplicate splines) or what happens when no sketch exists.

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

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

Two short sentences, front-loaded with what the tool does and followed immediately by the decision rule for spline_type. There is no redundant restatement of the title or padded phrasing.

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 three-parameter drawing primitive with annotations covering the safety profile and a schema covering most parameters, the description is adequate. It still leaves the sketch-precondition and error behavior implicit, which matters for an agent operating on a CAD document model.

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 documents degree and points thoroughly (67% coverage), and spline_type carries no schema description, so the description's explanation of 'curve through points' versus 'control-polygon spline' fills the one real semantic gap. It adds nothing about points or degree, but those are already well covered in 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?

States a specific verb and resource ('Draw a spline') plus its target scope ('in the most recent sketch'), and disambiguates the two spline modes (fit_points vs control_points). It is easy to separate from drawing siblings like draw_arc or draw_line, though it never explicitly contrasts with them.

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

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

Gives clear context for use: it draws in the most recent sketch, and it tells the agent which spline_type to pick depending on whether the points should be interpolated or used as a control polygon. It lacks explicit when-not guidance and does not state the prerequisite that a sketch must already exist and be active.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds genuinely new behavior: REPL-style return of the last expression and the pre-defined names (app, ui, design, component, adsk, math) available in scope. It stops short of mentioning error handling, timeouts, or whether document state persists between calls.

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 short sentences, front-loaded with the core action, then return semantics, then available globals. No filler; every sentence adds information an agent needs.

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

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

With no output schema, the description correctly explains the return value (last expression, REPL-style), and it discloses the injected globals. For a one-parameter tool this is nearly complete, though a note on failure behavior or execution scope would close the remaining gap.

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

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

There is a single required 'code' parameter with 0% schema description coverage, so the description must carry the load. It partially compensates by enumerating the pre-defined names the code can reference, which is real semantic value, but it never states the expected format, size limits, or that the code runs in the active document 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?

States a specific verb and resource ('Run arbitrary Python in Fusion 360') and implicitly positions itself as the general-purpose escape hatch distinct from the many narrow modeling siblings like extrude or fillet. An agent can immediately tell this is not a specialized geometry tool.

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

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

Usage is only implied: 'arbitrary Python' suggests a fallback when no dedicated tool fits, but the description never says when to prefer a sibling tool (e.g. use extrude instead of scripting an extrusion) or when this is inappropriate. No exclusions or prerequisites are given.

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

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

Annotations declare non-read-only, non-idempotent, non-destructive, which aligns with an export operation. The description adds useful behavioral details: auto-detection of format from file extension, and the conditional requirement for body_name. This goes beyond annotations without contradicting them.

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 concise sentences that front-load the main purpose and include all critical routing and requirement information. No fluff, every sentence earns its place.

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

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

For a wrapper with 3 parameters and no output schema, the description covers the essential behavior: what it does, how it routes, and key constraints. It doesn't mention error handling or return values, but that's not required for a simple export tool. The default path is in the schema, so that's 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 100%, so all parameters are already documented. The description adds value by clarifying the body_name condition ('F3D exports the whole design') and reiterating the auto-detection logic. It doesn't fully compensate for any gaps, but it enhances understanding beyond the schema.

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

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

The description clearly states it's a unified export wrapper that dispatches to specific export tools (export_stl, export_step, export_f3d) based on format or extension. It names the exact resources and behavior, distinguishing it from siblings. The verb 'dispatches' is specific and the scope is well-defined.

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

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

It explains the routing logic (format or extension) and explicitly states the requirement for body_name for STL/STEP and that F3D exports the whole design. This gives clear when-to-use context and parameter conditions. It doesn't explicitly contrast with the specific export tools, but the wrapper concept implies it can be used interchangeably, which is sufficient.

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

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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds that it exports to a specific file format (.f3d), which is useful context beyond annotations. However, it doesn't mention potential side effects like file system changes or authentication needs.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and format.

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

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

For a tool with one parameter (fully documented in schema), no output schema, and annotations covering key behavioral hints, the description is minimally adequate. It explains what the tool does but lacks details on usage context or output behavior.

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

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

Schema description coverage is 100%, with the single parameter 'file_path' fully documented in the schema. The description doesn't add any additional parameter details beyond what the schema provides, so the baseline score of 3 is appropriate.

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 specific action ('Export') and the resource ('the design'), specifying the output format ('native Fusion 360 archive (.f3d)'). It distinguishes from sibling tools like 'export_step' and 'export_stl' by specifying the .f3d format.

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

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

No guidance on when to use this tool versus alternatives like 'export_step' or 'export_stl' is provided. The description states what it does but not when it's appropriate or what prerequisites might be needed.

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

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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation, which the description aligns with by implying a file creation action. However, the description adds minimal behavioral context beyond this—it doesn't specify if the export overwrites existing files, requires specific permissions, or has rate limits, leaving gaps in understanding 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 a single, clear sentence with no wasted words, making it easy to parse and understand quickly. It's front-loaded with the core action and resource, which is ideal for efficient comprehension.

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

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

Given the tool's moderate complexity (2 parameters, no output schema) and annotations covering basic safety, the description is minimally adequate. It states the purpose but lacks details on usage, behavioral nuances, or parameter specifics, making it incomplete for fully informed tool selection and invocation.

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

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

Schema description coverage is 50%, with 'file_path' documented but 'body_name' lacking a description. The tool description mentions 'a body or component' which clarifies the semantics of 'body_name' slightly, but it doesn't provide details on format, constraints, or examples. This adds some value but doesn't fully compensate for the schema's gaps.

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

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

The description clearly states the action ('Export') and the target resource ('a body or component as a STEP file'), making the purpose immediately understandable. It distinguishes itself from other export tools like 'export_f3d' and 'export_stl' by specifying the STEP format, though it doesn't explicitly contrast with those siblings.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'export_f3d' or 'export_stl', nor does it mention prerequisites or context for exporting STEP files. It simply states what the tool does without indicating appropriate scenarios 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?

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation, but the description adds value by specifying the action (export to STL) and implying file creation. However, it does not disclose additional behavioral traits like error handling, file overwriting, or performance considerations, leaving gaps beyond the annotations.

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

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

The description is a single, direct sentence with no wasted words, clearly front-loaded with the core action. It efficiently conveys the essential information without unnecessary elaboration.

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

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

Given the tool's moderate complexity (export operation with 2 parameters), lack of output schema, and annotations covering basic safety, the description is minimally adequate. It states what the tool does but lacks details on output format, error cases, or integration with sibling tools, leaving room for improvement in completeness.

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

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

Schema description coverage is 50%, with 'file_path' documented but 'body_name' lacking a description. The description mentions 'a named body', which adds some context for 'body_name', but does not fully compensate for the missing schema details or explain parameter interactions, aligning with the baseline for partial coverage.

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

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

The description clearly states the verb 'Export' and the resource 'a named body as an STL file', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling export tools like 'export_f3d' or 'export_step', which would require mentioning format distinctions or use cases.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'export_f3d' or 'export_step', nor does it mention prerequisites like needing an existing body. It lacks explicit context for selection among export or other sibling tools.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the write nature is partly covered there. The description adds genuinely new context beyond annotations: the artifacts produced (PNGs + self-contained HTML), that it opens in any browser, and the notable side effect that it 'Restores the viewport camera after rendering' — an important state-restoration disclosure.

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 tight sentences with the core output front-loaded, followed by consumption instructions and the side-effect note. No filler, and the most decision-relevant information (what is produced and how it is shared) comes first.

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

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

With no output schema, the description does carry the burden of describing returns and does so well (PNGs plus a self-contained HTML artifact, browser-viewable, PDF-convertible). The viewport-camera restoration side effect is also covered, leaving only minor gaps such as naming/location of produced files, which the output_dir default in the schema partly addresses.

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

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

Schema description coverage is 100%, so every parameter (notes, title, views, image_size, output_dir) is already documented with defaults and semantics. The description only alludes to 'canonical orthographic + isometric views' and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb pair ('Render ... and emit') with the exact resource: orthographic + isometric views as PNGs plus a self-contained HTML sheet. This is clearly distinguishable from siblings like render_view (single render) and export_stl/export_step (single-format geometry exports) without opening any schema.

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

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

The description gives context ('suitable for sharing with a mechanical engineer', 'Print -> Save as PDF') which implies the sharing/documentation use case, but never says when to choose this over render_view, export_stl, or export_step, and offers no exclusions or prerequisites.

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

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

Annotations indicate this is a non-readOnly, non-idempotent, non-destructive operation, which the description aligns with by implying mutation ('extend') without contradiction. However, it adds minimal behavioral context beyond annotations—no details on error conditions, rate limits, or what happens if no intersection exists—leaving gaps in understanding the tool's full 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 highly concise and front-loaded, using two clear sentences with zero wasted words. Every phrase ('extend a sketch curve', 'to the nearest intersection', 'The end nearest to the given point') directly contributes to understanding the tool's function efficiently.

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

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

Given the tool's moderate complexity (mutation without annotations covering all behaviors) and lack of output schema, the description is adequate but incomplete. It explains the core operation but omits details like return values, error handling, or interaction with other sketch tools, leaving the agent to infer some aspects from 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 75% schema description coverage, the schema documents three parameters well, but 'sketch_name' lacks a description. The description adds value by explaining the purpose of 'point_x' and 'point_y' ('near the end to extend') and implying 'curve_index' selects the target, though it doesn't fully compensate for the missing 'sketch_name' documentation, keeping it from a perfect score.

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

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

The description clearly states the specific action ('extend'), target resource ('a sketch curve'), and precise behavior ('to the nearest intersection') with the end selection logic ('The end nearest to the given point is extended'). It distinguishes from siblings like 'trim_curve' or 'offset_curve' by focusing on extension rather than cutting or offsetting.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'trim_curve' or 'offset_curve', nor does it mention prerequisites such as needing an existing sketch or intersecting geometry. It lacks explicit context for tool selection among the many sibling CAD operations.

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

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

Annotations indicate the tool is not read-only, idempotent, or destructive, but the description adds minimal behavioral context. It does not explain what extrusion entails (e.g., creating new geometry, modifying existing bodies based on the 'operation' parameter), potential side effects, or performance considerations. While not contradicting annotations, the description fails to provide meaningful behavioral insights beyond the basic 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 description is extremely concise—a single phrase—with no wasted words. It is front-loaded and efficiently states the core action, though this brevity contributes to gaps in other dimensions. Every word earns its place by directly addressing the tool's function.

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 (4 parameters, including enums for 'operation' and 'direction'), lack of output schema, and minimal annotations, the description is incomplete. It does not cover parameter meanings, expected outcomes, or integration with sibling tools, leaving significant gaps for an agent to understand and use the tool effectively in a 3D modeling 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 input schema lacks parameter explanations, and the description does not compensate by detailing any parameters. It mentions 'sketch profile' but does not clarify how parameters like 'height', 'profile_index', 'operation', or 'direction' affect the extrusion process. This leaves key semantics undocumented, failing to add 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 'Extrude a sketch profile' clearly states the action (extrude) and target (sketch profile), providing a basic understanding of the tool's function. However, it lacks specificity about what extrusion does (e.g., creating 3D geometry from 2D profiles) and does not distinguish it from similar sibling tools like 'revolve', 'sweep', or 'loft', which also create 3D geometry from sketches. This makes the purpose somewhat vague in 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing sketch), compare it to sibling tools like 'revolve' or 'sweep' for different 3D modeling approaches, or specify scenarios where extrusion is preferred. This absence of usage context leaves the agent without direction on tool selection.

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

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

Annotations indicate this is a non-readOnly, non-idempotent, non-destructive operation, but the description adds minimal behavioral context. It implies a geometric modification ('round edges') without specifying permanence, side effects, or what happens to the original body. No contradiction with annotations exists, but the description doesn't enrich understanding beyond the basic 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 description is extremely concise with just four words, front-loading the core action. There's no wasted language, though this brevity contributes to gaps in other dimensions. Every word earns its place in conveying the basic purpose.

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

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

For a 4-parameter tool with low schema coverage, no output schema, and annotations that only cover basic hints, the description is insufficient. It doesn't explain what 'round edges' means in practice, what the radius parameter does, how edge selection works, or what the tool returns. The context demands more detail for effective 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?

With only 25% schema description coverage (only 'body_name' has a description), the description doesn't compensate for the undocumented parameters. It mentions 'edges' generally but doesn't explain the 'edge_selection' enum options or clarify the relationship between 'body_name' and 'body_index'. The description adds little semantic value beyond what's implied by the tool 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 action ('round edges') and target ('of a body'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'chamfer' (which also modifies edges) or 'shell' (which might involve rounding), so it doesn't fully distinguish from alternatives.

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

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

No guidance is provided on when to use this tool versus alternatives like 'chamfer' or other edge-modification tools. The description only states what the tool does, not when it's appropriate or what prerequisites might be needed for successful 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?

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation, but the description does not add behavioral context beyond this. It mentions creating a flat pattern, which aligns with the annotations, but fails to disclose details like potential side effects, error conditions, or performance considerations, resulting in moderate transparency.

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

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

The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick understanding.

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 (creating a flat pattern from sheet metal), lack of output schema, and minimal annotations, the description is somewhat incomplete. It does not explain the result format, potential errors, or dependencies, but it adequately states the basic purpose, meeting a minimum viable level for 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 for the single parameter 'body_name', the description does not provide any additional semantic information about this parameter, such as what constitutes a valid body name or examples. However, since there is only one parameter, the baseline is set to 4, but the lack of compensation for the coverage gap reduces the score to 3.

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

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

The description clearly states the action ('create') and the resource ('flat pattern from a sheet metal body'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'unfold' or 'create_bend', which might have related sheet metal functions, leaving room for improvement in sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'unfold' or other sheet metal-related siblings. It lacks context on prerequisites, constraints, or specific scenarios for application, offering minimal usage direction.

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