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

Beyond the annotations, the description discloses the key behavioral consequence: after activation, catia_create_sketch/catia_pad/catia_pocket/etc. create features inside this body instead of MainBody. It also maps the operation to the CATIA GUI 'Define In Work Object' action, which helps an agent understand the state change.

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

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

The description is three sentences, front-loads the core purpose, then immediately states the downstream effect and the prerequisite call. Every sentence adds actionable information, and there is no redundant or filler text.

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

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

For a simple state-setting tool with a single documented parameter and no output schema, the description covers what it does, when to use it, and how it affects subsequent operations. Nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100% and the single body_name parameter already has a clear example in the schema. The description adds no syntax or format 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 names a specific verb and resource: 'Set a Body as the active in work object.' It distinguishes this state-changing action from sibling tools by naming catia_new_body as the predecessor and catia_create_sketch/catia_pad/catia_pocket as the affected followers. An agent can identify exactly what this tool does 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?

It gives clear usage context: call this right after catia_new_body so subsequent feature-creation tools work inside the newly active body. It does not explicitly state when not to call it, but the sequencing and effect are sufficiently clear for correct invocation.

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

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

Annotations already declare the mutation safety profile (writable, non-destructive, non-idempotent, closed-world), so the description need not repeat that. It adds useful behavioral context by stating that the tool returns the new instance name(s) and that those names are intended for later constraints, which helps the agent understand the workflow.

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 tight sentences with the core action front-loaded. Every clause earns its place by covering insertion target, optional parent, and return value 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 mutation tool with no output schema, the description covers the essential return value and the active-assembly context. It does not explain error conditions or prerequisites such as ensuring the file is accessible, but it is complete enough for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents both file_path and parent. The description reinforces that file(s) are inserted and that insertion may optionally target a sub-assembly, but it adds little parameter syntax or format meaning beyond what the schema provides. 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?

States a specific verb (Insert) and resource (existing CATPart/CATProduct file(s)) with the target context (active assembly) and optional sub-assembly placement. The word 'existing' helps distinguish it from siblings like catia_add_new_part, so an agent can identify the operation 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?

The description gives clear context for what the tool does and notes the optional sub-assembly placement, but it does not explicitly say when to use this versus alternatives such as catia_add_new_part, catia_add_sub_assembly, or catia_duplicate_component. Usage is implied rather than guided.

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 write (readOnlyHint=false), non-idempotent, non-destructive. The description adds real context beyond that: storage location ('user's lessons file, not in the package') and dedup behavior ('duplicates are refused'), which are not derivable from annotations or schema.

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

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

Four dense sentences, all load-bearing, with the primary action front-loaded. Slightly long but no filler or repetition.

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

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

Covers purpose, trigger, storage, and dedup for a 9-param write tool with no output schema. Minor gaps remain (what a duplicate returns, whether the lesson is immediately live), but nothing critical is missing.

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

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

Schema coverage is 78% (baseline 3), but the description adds meaning the schema lacks: error_patterns must be the 'exact observed error text (regex)' and proof must state 'how it was proven', clarifying the intent of two non-obvious fields.

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

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

States a specific verb ('Record') and resource ('a NEW pitfall or rule'), plus the effect ('every future session ... is warned automatically'). The write intent clearly contrasts with the read-only sibling catia_lessons, even without naming it.

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

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

Gives explicit timing/trigger: 'Use it as soon as you find something that failed, surprised you, or needed a workaround.' No when-not guidance or named alternative, but the invocation context is unambiguous.

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

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

Annotations already declare non-readOnly, non-destructive, non-idempotent, so the safety profile is covered. The description adds genuinely non-structured context: the created part starts empty, and it must be saved via catia_save_all before faces become constrainable — a real behavioral dependency an agent must respect.

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

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

Two sentences, no filler, and the core action ('Create a new empty Part...') is front-loaded before the workflow caveat. Every clause carries 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 two-parameter creation tool with no output schema and adequate annotation coverage, the description supplies the essential prerequisite chain (create → model → save → constrain). The only gap is the absence of disambiguation from the near-identical sibling catia_new_part.

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% (both 'parent' and 'part_number' are documented inline with an example), so the schema carries the parameter burden. The description only echoes 'with its part number' and implies the assembly/sub-assembly target, adding no syntax or format detail 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?

States a specific verb and resource ('Create a new empty Part') plus scope ('inside the assembly (or a sub-assembly), with its part number'). Clear on its own, but it never distinguishes itself from the sibling tools catia_new_part and catia_add_sub_assembly, which an agent could easily confuse with this one.

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 a valuable sequencing rule ('must be modelled and then saved (catia_save_all) before faces can be designated for constraints'), which tells the agent where this step sits in the workflow. However, it never says when to pick this over catia_new_part or catia_add_component, so the selection 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 cover the safety profile (not read-only, not idempotent, not destructive, closed-world), and the description does not contradict them. It adds the structural context that a Product is nested inside an existing assembly, but omits whether the parent must already exist, whether the new sub-assembly becomes active, and the duplicate-creation risk implied by idempotentHint=false.

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 sentence that front-loads the action and resource, then supplies one compact clarifying example. Nothing is redundant and nothing is missing for its length.

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

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

For a creation tool with no output schema and only annotation-level behavioral coverage, the description is adequate but thin: it does not say what is returned or what state changes on success. Given a simple 2-parameter schema with full coverage, this is acceptable but not complete.

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

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

Schema description coverage is 100%, so both parameters (parent, part_number) are already documented, including the root default. The description adds no syntax, format, or path-convention 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 and resource ('Create a new sub-assembly (Product) inside the assembly') and clarifies the concept with an example (Wheel / Shaft sub-assemblies). It distinguishes itself reasonably from sibling creation tools like catia_add_component and catia_new_product, though it never explicitly contrasts them.

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

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

The parenthetical rationale ('the way to structure a big assembly') implies when this is useful, but there is no explicit when-to-use guidance or routing against alternatives such as catia_add_component or catia_new_product. Usage is implied 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, destructiveHint=false, so the agent knows this is a non-destructive write. The description adds nothing beyond that: it doesn't say it appends a constraint to the assembly tree, that it triggers an expensive solve, or how the deferred-update behavior works (that detail lives only in the schema).

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

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

It is a single tight sentence with no filler, and the core subject (angle between two elements) is front-loaded. It is arguably too short rather than bloated, so it does not lose points for verbosity.

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

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

For a 7-parameter assembly-mutation tool with nested geometry objects and no output schema, a one-line fragment is inadequate. It says nothing about the assembly context, the interaction with the solve/defer_update mechanism, or what happens to the model on success.

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

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

Schema description coverage is 100%, so the schema already documents component paths, the element geometry objects, the angle, and defer_update in detail. The description only restates 'in degrees' and the element types, adding no syntax or format meaning beyond the schema. 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?

The fragment names the resource (angle constraint between two components' planes/faces/axes) but omits the verb entirely – it never says it *creates/adds* a constraint. An agent can infer the action from the name `catia_angle_constraint` and the sibling set (coincidence/contact/offset constraints), but the description itself does not commit to it.

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

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

No when-to-use guidance, no prerequisites (e.g. must be in an assembly, components must be positioned), and no reference to the sibling constraint tools (catia_fix_coincidence/contact/offset_constraint) that an agent would choose among. The reader gets zero routing help.

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 readOnlyHint=true and openWorldHint=false. The description goes well beyond: it does not modify the document, ranks issues error>warning>info, returns a structured issue shape (code, where, message), supplies fix tool calls with args or a 'manual' fallback, and discloses 'not_checked' limits of the API (e.g. sketch degrees of freedom). This is rich behavioral disclosure for a read-only tool.

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

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

Front-loaded with the core action and read-only guarantee, then dense but informative enumeration of checks and return shape. Every clause adds value (checks per Part vs Assembly, the fix/manual contract, not_checked). It is somewhat long as a single block but not 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?

With no output schema, the description carries the burden of describing returns, and it does so thoroughly (severity ranking, issue fields, fix tool+args, manual instruction, not_checked). For a complex audit tool this is complete enough for an agent to invoke and interpret results correctly.

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

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

Schema coverage is 100% with an enum on min_severity, so the schema already documents the parameter. The description adds meaning by explaining the severity ordering (error>warning>info), which is exactly the scale the min_severity filter operates on, giving the agent context beyond the raw enum.

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+resource+scope: 'Audit the ACTIVE document's tree WITHOUT modifying it.' This clearly distinguishes it from sibling tools like catia_get_tree (raw tree fetch), catia_drawing_check (drawing-specific), and catia_describe_model (description). An agent can tell what it does and what it doesn't.

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 read-only 'WITHOUT modifying it' constraint and the extensive list of what it checks give strong context for when to invoke it. It implies that remediation is a separate step via the returned 'fix' tool calls, but it never names a sibling as an alternative or gives explicit when-not-to-use guidance.

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

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

Annotations only provide safety flags; the description adds substantial operational behavior: pre-execution validation against tool schemas, ordered execution, stop-on-error, dry-run, non-nestability, and a compact report with timings. It also clarifies failure behavior during validation ('CATIA is left untouched'). No contradiction with 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?

Front-loads the core purpose, then behavior, then usage in a tightly packed paragraph. Each sentence adds a distinct fact (validation, execution order, failure, dry-run, report, nesting, usage) with 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 complex batch meta-tool, the description covers purpose, validation, execution flow, failure semantics, nesting constraint, report format, and usage routing. With full schema coverage and safety annotations already present, remaining omissions (e.g., maximum steps) are minor and do not impede correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining that the steps array is validated for unknown tools, misspelt/missing arguments, wrong types, and bad enum values, and clarifies dry_run and stop_on_error as validate-only and halt modes. It does not expand on the args object structure beyond the schema example.

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

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

States a specific verb and resource: running many catia_* tool calls in one round trip. Explicitly distinguishes itself from sibling tools by telling the agent to prefer it for known sequences and keep separate calls when values must be read first. An agent can identify it 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?

Gives explicit when-to-use ('Prefer it for any sequence you already know') and when-not ('keep separate calls for steps that depend on a value you must read first'), with a concrete example. Also names dry_run for validation-only usage. No inference 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 already flag destructive=true, idempotent=false, but the description adds genuine behavioural context: assemble respects feature nature, add always adds material, remove is target minus tool, intersect keeps common material, and union_trim requires in-face points. It also notes target_body defaults to the active body. No return/error behaviour is described, keeping it at a 4.

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 a compact per-mode bullet list where every line earns its place. The GUI aside is brief and aids recognition; nothing is wasted.

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

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

For a 6-parameter destructive mutation tool with no output schema, the description covers operation semantics and the tricky union_trim points adequately, and annotations carry the safety profile. Minor gaps remain around failure modes and the result of the operation, but nothing essential for invocation is missing.

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

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

Schema coverage is already 83%, so baseline is 3, but the description adds real meaning: it explains that faces_to_remove_points/faces_to_keep_points apply only to union_trim and require one [x,y,z] point inside each tool-body face, and points the agent to catia_list_faces. This complements the schema rather than repeating it.

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+resource (combine two Bodies with a boolean operation) and enumerates all five operation modes so the agent knows exactly what each does. This clearly distinguishes it from siblings like catia_new_body or catia_pad, and even frames the multi-body modelling workflow.

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?

Explains the context in which the tool is used ('model each functional zone in its own Body, then combine them here') and clarifies the subtle difference between assemble vs add for a Pocket-first tool body. It lacks an explicit 'when not to use / use alternative' statement, so it stops short of a 5.

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 safety profile (readOnly=false, destructive=false, non-idempotent). The description adds real behavioral context beyond that — the single-feature grouping behavior and the edge-identification convention shared with catia_fillet — but says nothing about failure modes, required active container, or whether re-running with the same points creates a duplicate feature.

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 the core action ('Chamfer one or more edges as ONE feature') before the edge-addressing and mode details. No filler and no repetition.

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

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

For a feature-creation tool with no output schema and full schema coverage, the description covers the essentials: what is created, how edges are addressed, and the available modes. It stops short of naming the active-body/selection prerequisite or the resulting feature name, which slightly limits 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 coverage is 100%, so the schema already documents every parameter including defaults and the 'ignored if length2 is given' rule. The description's mode sentence largely restates that, adding only light framing of the two accepted combinations; 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?

Specific verb (chamfer) plus resource (one or more edges) and an explicit scope qualifier ('as ONE feature') that tells the agent this produces a single specification-tree feature rather than one per edge. It also anchors itself to the sibling catia_fillet for edge designation, so it is distinguishable from other modeling 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 explains the two chamfer modes and their interaction with the parameters, which is genuinely useful selection guidance, but it never states when to prefer this over catia_fillet or what preconditions must hold (e.g. an active body, existing solid). Usage is implied rather than instructed.

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 readOnly=false, idempotent=false, destructive=false, so the safety profile is already known. The description usefully adds that count includes the original and that spacing defaults to a complete crown, but it does not disclose tree/specification side effects of creating the pattern or any prerequisites about an active feature.

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 dense sentence pair with the operation and axis choice front-loaded and no filler. Some parenthetical asides (the French term, the zx=Y example) make it slightly packed, but nothing is wasted.

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

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

For a 7-parameter mutation tool with no output schema, the description covers the key calls an agent must get right: which axis variants exist, that count includes the original, and the spacing default. Remaining gaps are about selection prerequisites and post-creation behavior rather than the core 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 100%, so the schema already documents every parameter including the axis_plane→Z/Y/X mapping. The description restates that mapping and the default spacing, adding consistency but little information beyond the structured fields; the baseline of 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 operation (circular pattern of a feature) plus the precise axis semantics, and the parenthetical French name mirrors the CATIA UI term an agent or user would recognize. It is clearly distinguishable from sibling operations like catia_rect_pattern and catia_mirror.

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?

Explains the two mutually exclusive ways to define the rotation axis (origin-plane normal via axis_plane, or cylindrical face via axis_face_point) and the count/spacing defaults, which is strong context. It stops short of explicit when-to-use vs when-not guidance (e.g. linear pattern or mirror 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 cover the read-only, closed-world safety profile, and the description adds genuine behavioral context: the analysis object is removed afterwards so the product tree stays clean, and it defines what constitutes a clash and the coordinate frame of 'at' points. It does not discuss runtime cost on large assemblies, but the extra side-effect disclosure is substantive.

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?

Compact and front-loaded – the core purpose leads, followed by result semantics and the cleanup side effect. The parenthetical UI navigation is arguably extra, but it aids disambiguation at low cost.

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 usefully describes what is returned (clash list with interference points in assembly coordinates, plus a contact count) and the post-run state. That covers the essentials for a simple check tool, though it omits details like whether clashes are ordered or capped by max_list.

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% for the single max_list parameter, so the schema already documents its meaning and default. The description adds no hints about truncation or ordering behavior, so the baseline of 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 action (interference check) on a specific resource (whole assembly), and clarifies the two outputs: a list of CLASHes and a count of CONTACTS. It also anchors the operation to the CATIA UI path, making it clearly distinct from siblings like catia_measure_distance or catia_get_bounding_box.

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?

Explains how to interpret results ('A correct assembly has 0 clash, except intended press fits / cosmetic threads'), which implies the intended use, but never explicitly says when to run this versus alternatives or what prerequisites exist. Usage 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 idempotentHint=true and destructiveHint=false; the description adds the important non-obvious fact that the change is display-only and nothing is persisted, plus ordering relative to saving. It does not say how to restore the original display state or whether it affects the saved model, but the key behavior is disclosed.

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

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

One front-loaded sentence enumerating what gets hidden, followed by a short caveat sentence. No filler; 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 one-optional-param, no-output-schema tool, the description covers what is hidden, the purpose, and the persistence caveat. It could mention how to undo the cleanup, but otherwise an agent has enough to invoke it 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 100% and the single hide_tree parameter is fully documented in the schema, including its default and the window Layout effect. The description adds nothing about the parameter, so 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+resource (hide planes, sketches, axis systems, constraint symbols) and frames the intent as preparing a presentation view before screenshots. This distinguishes it from catia_hide_show_body (which toggles bodies) and catia_screenshot itself.

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 timing guidance ('before screenshots', 'call it AFTER saving') and a persistence caveat. It does not name an alternative tool or state when-not to use it, but the context of use is unambiguous.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutating nature is known; the description adds the key behavioral detail that documents are closed WITHOUT saving and that unsaved work is permanently lost, plus the fresh-session end state.

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, front-loaded with the action and scope, then the use case, then the risk warning. 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 parameterless, non-returning mutation, the description covers action, scope, purpose, and data-loss warning — everything an agent needs to decide to call it.

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

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

The tool takes zero parameters, so the schema carries no semantics to supplement and no parameter explanation is needed. Per the baseline for 0-param tools, a 4 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?

Names a specific verb+resource (close EVERY open document) with explicit scope ('ALL', 'without saving') that distinguishes it from the sibling catia_close_document, which closes one.

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?

Clearly states when to use it ('before starting a new piece/assembly') and gives concrete failure symptoms it prevents (Save As fails, ambiguous product file). It stops short of naming the alternatives (catia_save_all, catia_close_document) as explicit choices.

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 and idempotentHint=false, so the description is not contradicting them, but it adds no behavioral context of its own. The critical fact for a destructive close — that unsaved changes are discarded unless save=true is passed — is never stated.

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

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

One short, front-loaded sentence with no filler. It is efficient, though the brevity comes at the cost of the safety information an agent actually 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?

For a destructive, non-idempotent tool with no output schema, the description omits the one thing that matters: unsaved work is lost when save is left at its false default. That omission makes it incomplete for safe 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 100% and the single 'save' parameter is documented in the schema with its default, so the schema carries the semantics. The description adds nothing beyond it, which is the baseline 3 for a fully covered 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 (Close) and a specific resource (the active CATIA document), which implicitly separates it from catia_close_all, catia_close_sketch and catia_drawing_close. It stops short of naming any alternative explicitly, so it is clear but not sibling-differentiating.

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 when-to-use or when-not-to-use guidance. An agent cannot tell from this sentence whether it should prefer catia_close_all, catia_save_document + close, or catia_disconnect, nor what happens to a document with unsaved edits.

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, destructiveHint=false, idempotentHint=false, so the mutation profile is covered. The description adds useful workflow context (mode transition back to Part Design), but does not disclose failure behavior when no sketch is open or the consequence of the non-idempotent nature.

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

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

Two short sentences, zero padding, with the action front-loaded and the prerequisite second. 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 zero-parameter, no-output-schema lifecycle tool this is nearly complete: it covers the action, the resulting state, and the workflow position. It could state what happens if there is no active sketch, which is the one plausible edge case an agent would hit.

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

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

The tool takes zero parameters, which is the baseline-4 case: there is nothing for the description to clarify beyond the empty schema. No parameter-level guidance is needed or missing.

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 ('Close') plus resource ('the active sketch') and the resulting mode switch ('return to Part Design'), so it is distinguishable from the catia_create_sketch / catia_sketch_* family. It stops short of naming a sibling alternative, but the action 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?

Explicitly gives the sequencing rule: called after finishing sketch geometry, before applying 3D features such as catia_pad or catia_pocket. Clear context for when to invoke, though it does not say what happens if no sketch is active or whether it can be safely skipped.

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 mark this as a non-read-only, non-idempotent mutation, so the agent knows it changes state, but the description itself adds nothing about the effect: it does not state that a constraint is added to the assembly tree, whether a solve is triggered, what happens on failure, or how it interacts with existing constraints. With no output schema, the description carries the full behavioral burden and does not meet it.

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?

It is a single compact sentence with the supported pairings front-loaded, which is efficient. But the trailing ellipsis signals an unfinished enumeration, so the brevity reflects under-specification rather than disciplined concision.

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 multi-parameter assembly-mutation tool with nested geometry objects and no output schema, the description is too thin: it does not explain the resulting tree entry, solve behavior, or how defer_update/update_assembly fit the workflow (that context lives only in the schema). It leaves the agent without enough surrounding context to invoke the tool confidently in a sequence.

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

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

Schema description coverage is 100% and the nested element objects are richly documented (coordinates, units, plane enums, reference to catia_list_faces). The description only adds the pairing-to-parameter mapping ('use axis_point on both'), a marginal gain over 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?

The description names the specific constraint type (coincidence) and enumerates the element pairings it supports (axis/axis, plane/plane, face/face, point/axis), which distinguishes it from sibling constraint tools. However, it omits an explicit action verb (it never states that it CREATES/ADDS a constraint) and trails off with an ellipsis, leaving the full set of supported pairings ambiguous.

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 one embedded usage hint ('axis/axis (use axis_point on both)'), which tells the agent how to supply a pairing, and the pairing list implies where coincidence applies. But it never says when to choose coincidence over the sibling constraints catia_contact_constraint, catia_offset_constraint, or catia_angle_constraint, and there is no explicit when/when-not guidance.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds genuinely new behavioral detail: the dual attach-or-launch mode and the mandatory ordering constraint. It leaves out what happens on failure (no instance, CATIA not installed) and whether multiple calls are safe, which keeps it below 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?

Three short sentences, zero waste, with the action stated first and the critical prerequisite placed at the end where it reads as a rule rather than an afterthought. 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 zero-parameter bootstrap tool with no output schema, the description supplies the essentials: what it connects to, how it obtains an instance, and when it must run. Error/edge-case behavior is the only real gap, and it is a minor one at this complexity level.

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

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

The tool takes zero parameters, so the schema imposes no documentation burden and the baseline of 4 applies. The description correctly does not fabricate parameter detail.

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

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

Specific verb+resource ('Connect to CATIA V5') with the exact behavioral scope spelled out: it either attaches to an existing instance or launches a new one. This distinctively separates it from sibling catia_disconnect and from every operation tool that assumes a live session.

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?

States a hard prerequisite — 'Must be called before any other CATIA tool' — which is exactly the sequencing guidance an agent needs for a session-bootstrap tool. It does not name catia_disconnect as the teardown counterpart or describe re-connect behavior, so it stops short of full when/when-not coverage.

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 non-destructive, non-idempotent mutation, and the description adds nothing behavioral beyond a numeric type ID. It does not state that a constraint feature is added to the tree, that the model is solved, or what happens if the geometry does not resolve.

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 padding, giving the constraint kind and the type constant. It is efficient, though the parenthetical type ID is arguably noise for an 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?

For a mutation tool with no output schema, the one-line description leaves gaps: whether the constraint is committed immediately, how the deferred solve interacts with catia_update_assembly (that detail lives only in the schema), and what a failure looks like. The rich schema compensates partially but not fully.

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

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

Schema description coverage is 100%, so the schema already documents component/element encoding and the defer_update solve behavior; the description adds nothing about parameters. Baseline 3 applies when the structured schema carries the parameter burden.

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

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

The description names a specific verb+resource: a surface contact constraint between two faces of two components, and even pins the internal constraint type (catCstTypeSurfContact = 20). It clearly differentiates from the sibling constraint tools (coincidence, offset, angle) by naming 'surface contact', though it never explicitly contrasts 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?

There is no guidance on when to choose this over catia_coincidence_constraint or catia_offset_constraint, nor any stated prerequisites (e.g. components must already be placed in an assembly). Usage is only implied by the tool name and the parameter shape.

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 mutation with no global side effects; the description adds real behavior the agent needs: the sketch lands in the active body, it is opened for editing, an offset plane is inserted into the tree, and axis orientation is defined relative to the support.

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 action and the support-selection priority before the axis-alignment detail. Dense but every clause carries information; the axis-mapping sentence is the most expendable but is still useful orientation 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 zero-required-param mutation tool with no output schema, the description covers creation, support resolution, editing state, tree effects, and the closing step. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds genuine meaning: what face_point really selects ('the top face of the boss'), that plane is auto-detected from the face normal and can be omitted, and how the sketch axes map to the chosen origin plane.

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 ('Create a new 2D sketch ... and open it for editing'), scopes it to the active body, and distinguishes itself from the many catia_sketch_* geometry siblings that add content rather than create the sketch container itself.

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 an explicit priority order for support selection (face_point, else plane + offset, else origin plane) and names the follow-up tool (catia_close_sketch). The agent knows both how to choose a support and how to end the 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 already declare destructiveHint=true, readOnlyHint=false, and non-idempotency; the description adds useful context beyond them — that the target must be in the active Body and that the tool 'never guesses which feature to delete', implying failure rather than a blind default. It does not say whether deletion is reversible or how the tree reacts, so it is strong but not complete.

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

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

Two sentences with no filler: the action and scope come first, followed by the recovery workflow. 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 simple two-parameter mutation with no output schema, the description covers scope, intent, and the failure mode that motivates it. It is nearly complete; only the post-deletion state (return value or tree effect) is left implicit, which is minor here.

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% and both parameters, including the enum values for 'kind' and the example name, are already documented. The description's mention of 'feature or sketch' largely restates what the kind enum encodes, so it adds little beyond the schema; 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 and resource ('Delete a feature or sketch') plus the exact scope ('from the active Body'), which separates it cleanly from siblings like catia_rename_feature, catia_list_features, or catia_get_tree. The GUI equivalence (right-click > Delete) anchors the action unambiguously.

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 an explicit when-to-use scenario and names the alternative it replaces: clean up a broken feature left by a failed Shaft/Groove UpdateObject rather than closing and recreating the whole document, then fix the sketch and retry. The agent knows both the trigger and the competing strategy.

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 readOnlyHint and openWorldHint, and the description goes well beyond them: it confirms no document mutation, discloses the 'opaque' fallback with replay.complete=false and 'nothing is guessed', and lists precise coverage limits (patterns, shell, draft, thickness, surfaces). This is the honest behavioral envelope an agent needs before trusting a spec-driven replay.

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 and scope, then organized by CATPart / CATProduct / Limits / side effects. Dense and slightly long, but nearly every clause carries distinct information (units, file names, opaque handling) rather than restating the name.

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 must carry the return-value burden, and it does: it enumerates the spec contents per document type, states units, and explains the opaque/replay.complete mechanism. An agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value the schema does not: it names the concrete artifacts written ('<name>_spec.json', '<name>_replay.py') and clarifies that files are written to output_dir regardless of the include_* flags. That extra artifact-level detail lifts it above baseline.

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 ('reverse-engineer') and resource ('the ACTIVE document') and then enumerates exactly what is produced for CATPart versus CATProduct. This clearly separates it from siblings like catia_get_tree, catia_audit_model, and catia_measure_model, which the agent can rule out without opening schemas.

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 strong usage context ('without modifying it', active document only, output_dir to persist artifacts) and an explicit limits section naming what is described vs opaque. It does not name an alternative sibling or state when-not-to-use, so it stops short of a 5.

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 idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations cannot express: the session-level effect is a disconnect, not a document/session teardown, which reassures the agent that open documents survive.

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

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

One short sentence with zero waste; the most load-bearing fact (does not close CATIA) is bolted directly onto the verb rather than buried.

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 parameterless, side-effecting session tool this is essentially complete: the scope boundary is stated and annotations cover idempotency and safety. No output schema exists, so there are no return values to explain.

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

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

Zero parameters, so there is nothing for the description to disambiguate and the baseline applies. No param guidance is missing or needed.

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

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

States a specific verb (disconnect) and resource (CATIA V5 session), and immediately distinguishes itself from the closing siblings by clarifying it does not close CATIA. An agent can tell this apart from catia_close_document or catia_close_all 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 parenthetical scoping note ('does not close CATIA') implicitly tells the agent when to reach for this rather than a close tool, which is the main ambiguity in this sibling set. It stops short of an explicit when-to-use statement, but the contrast with the close family is clear.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false. The description adds only 'Verified live,' which does not disclose mutation side effects, required workbench/selection state, or how the feature is committed. It does not contradict annotations, but it contributes almost no behavioral detail 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?

A single dense sentence front-loads the operation and key inputs. 'Verified live.' is extraneous and the parenthetical nesting makes parsing harder, but overall there is little waste.

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 feature-creation tool with no output schema and only 33% schema coverage, the description covers the core geometric recipe but omits prerequisites (active body/geoset, face selection state) and any result/return context. With annotations covering safety flags, this is minimum viable but not complete.

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

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

Schema coverage is 33%, so the description must compensate for undocumented parameters. It explains angle is in degrees, direction is pulling direction, face_points define drafted faces, and neutral_face_point/neutral_plane provide the neutral reference. It still leaves face_points' expected geometry (points-on-face? coordinates?) and neutral_plane enum semantics largely implicit, so compensation is partial.

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

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

States a specific modeling operation: creates a draft (Dépouille) on faces using angle, neutral reference, and pull direction. It is not a tautology and clearly names the CATIA feature. It does not explicitly distinguish itself from other feature-creation siblings such as fillet/chamfer, but 'draft' is a distinct operation.

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

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

No explicit when-to-use, prerequisites, or alternative-tool guidance is given. The agent is told what inputs to supply, not when to choose catia_draft over neighboring feature tools. 'Verified live' does not function as usage guidance.

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

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

Annotations already declare it is a write, non-idempotent, non-destructive operation. The description adds useful context: the exact line type, that extension_mm is measured in paper space beyond the circle, and that the return value is a count of created lines. It does not mention duplicate creation on repeat calls, though the non-idempotent annotation covers that 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?

Three short sentences/fragments, front-loaded with the action and line standard, followed by parameter semantics and return value. No redundant or filler text.

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

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

For a write tool with no output schema, the description covers the operation, the centre coordinate meaning, extension behavior, and return count. It omits explicit clarification of the required 'view' parameter's expected format and the drawing default, but these are minor given the schema and 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?

Schema coverage is only 25%, so the description must compensate. It explains centres as [{u, w, radius}] in view coordinates and extension_mm as paper-space extension beyond the circle, but leaves the required 'view' and optional 'drawing' parameters unspecified.

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 ('Draw centre lines'), the resource (view circles), the line standard (thin chain, ISO 128-2 type 04.1), and the extension behavior. Clearly distinguishable from siblings such as catia_drawing_add_dimension or catia_drawing_add_view.

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 usage for adding centerlines to circles in a drawing view, but gives no explicit when-to-use/when-not-to-use guidance or named alternatives. The agent must infer the operational context from the name and description.

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?

Adds substantial behavioral context beyond the annotations: it discloses the JSON return shape, a precise failure mode (value differs by >0.005 mm removes the dimension and fails), and the key limitation that the dimension displays the supplied value rather than attaching to generated edges. These details materially help an agent predict outcomes and handle errors, while the annotations already cover mutability and idempotency.

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-loads the core action ('Add ONE dimension') and organizes remaining details by dimension type and constraint. It is dense and somewhat run-on, but every sentence adds operational information for a complex 14-parameter tool, so there is little waste.

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?

Complete for a mutation tool with no output schema: it describes the return value, failure behavior, source-of-truth requirement, coordinate system, and relevant drafting standards. An agent has enough context to call the tool correctly without needing to inspect other structured fields.

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

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

With 14 parameters and 79% schema description coverage, the description contributes meaningful semantics for many parameters, including coordinate meaning (u,w in model scale), orientation behavior, side placement, leader angle for radius/diameter, and ISO spacing rules for offset_mm. Some parameters, such as drawing and allow_duplicate, rely mainly on the schema, so it does not fully compensate for every 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: 'Add ONE dimension to a view' and enumerates the supported dimension types (linear, diameter, radius) with their required geometry. It distinguishes itself from related tools by referencing catia_list_faces for source values, catia_drawing_check for verification, and catia_drawing_add_view for coordinate 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?

Gives clear procedural guidance: values must be taken from the model, not from memory, and it cites ISO 129-1 placement rules and the offset default. However, it does not explicitly state when to use this manual dimensioning tool versus the sibling catia_drawing_generate_dimensions, leaving that alternative to inference.

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

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

Annotations declare the safety profile (non-readOnly, non-destructive, non-idempotent), and the description adds real behavioral context: overlapping/out-of-frame views are refused and removed, CATIA prints scale labels, CATIA appends A-A/A to section/detail names. It does not cover auth/preconditions or response side effects beyond the return JSON note.

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 and kind list before the deeper placement/coordinate mechanics, and virtually every sentence carries necessary information. It is dense and long, but justified by the 16-parameter, multi-mode nature of the tool; a slightly lighter structure would be ideal.

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 compensates by naming the returned JSON fields (view name, kind, scale, centre, paper box, origin, axes for catia_drawing_check). Combined with the placement, coordinate and section/detail rules, an agent has everything needed to call it correctly.

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

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

Schema coverage is 81% (baseline 3), but the description goes well beyond it: it explains the ISO 5456-2 auto-placement rule and first/third-angle behavior, the sheet-mm centre-based position override, the (u,w) model-scale coordinate system with per-view_from axis mapping, and the section cut_direction/cutting_line semantics. This is substantive meaning the schema does not convey.

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 one view of the 3D source to the drawing and place it') and enumerates the exact kind options, so it is clearly distinguishable from siblings like catia_drawing_create or catia_drawing_add_dimension. The scope is unambiguous.

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

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

Gives a clear ordering constraint ('front (the base view, create it first)'), and the kind list effectively documents which kind to pick for which purpose. It does not explicitly name alternative tools or when-not-to-use, so it stops short of a 5.

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 goes well beyond the sparse annotations: it discloses the closed-loop workflow, the tolerances applied, the error behavior of fail_on_mismatch (exit code 1), the return shape (JSON with ok and per-view details), and two real limits (blind holes only visible from the open side, sub-2mm circles ignored). readOnlyHint=true is not contradicted since it only exports a temporary PDF.

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 critical framing ('CLOSED-LOOP CHECK') is front-loaded, followed by what is checked, the data source, and the limits. It is dense and slightly overpacked into a few long sentences, but nearly every clause carries 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?

For a 9-parameter verification tool with no output schema and minimal annotations, the description is substantially complete: it covers inputs, data sources, tolerances, limits, and the failure mode. It could still say more about when the check is appropriate relative to sibling QA tools, but nothing needed to invoke it correctly is missing.

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

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

With 67% schema coverage, the description compensates by explaining the semantics of `source` (catia_list_faces + catia_get_bounding_box of the active body), `expected` (the override structure), `views` (which views a blind hole appears in), and the tolerance defaults (0.02 mm diameter, 0.05 mm centre). This adds real meaning over the raw schema.

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

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

The opening line names a specific verb chain and resource: 'export the drawing to PDF, read it back and compare it with the 3D model.' It is immediately distinguishable from siblings like drawing_render, drawing_overlay, or drawing_extract_geometry, which do not perform a 3D-vs-PDF comparison.

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 tells the agent what the check covers, what the defaults are (export temp PDF, check all views) and the condition that switches the 3D side ('unless `expected` is given'). It stops short of explicitly contrasting with alternatives such as catia_audit_model or drawing_overlay, so no 'when not to use'.

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

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

Annotations already declare readOnly=false, idempotent=false, destructive=false; the description adds genuine behavioral detail beyond that — save=false silently discards changes, save=true persists, the 3D source is untouched, and saving demands a prior file name. The one tension is that 'discards changes' has a mildly destructive flavor against destructiveHint=false, though this is a reasonable design choice rather than a clear contradiction.

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 and scope, then the save semantics and prerequisite. Dense but every clause (scope, source-stays-open, save default, file-name requirement) carries information the agent needs; only the nested parenthetical is slightly heavy.

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

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

For a 2-parameter, no-output-schema tool this is close to complete: default resolution, save behavior, preconditions, and blast radius are all covered. A brief word on failure mode (e.g., what happens if save=true without a file name) would close the last 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?

With 50% schema coverage the description must carry part of the load, and it does: it explains the resolution order for 'drawing' (named, else this session's last used) and the full semantics of 'save' including its default and its file-name prerequisite. This exceeds the schema's bare 'default: the active document' note.

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 (close) plus precise resource (ONE drawing, named or session-last-used) and an explicit negative scope ('without touching any other document'), which separates it cleanly from catia_close_document and catia_close_all. The added note that the 3D source stays open removes the main ambiguity an agent would otherwise have.

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 context is clear: defaults to the last-used drawing, and save=true requires a pre-existing file name, routing the agent to catia_save_document with a path first. It does not explicitly state when to prefer catia_close_document or catia_close_all instead, but the 'ONE drawing / nothing else' framing makes the boundary inferable.

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 a non-read-only, non-idempotent but non-destructive mutation; the description adds meaningful state effects beyond that — the drawing is left open and active and nothing is saved — plus the warnings field in the return and the plan-then-add_view handoff. It does not specify required permissions or license prerequisites, which keeps it short of a 5.

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

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

The first sentence is front-loaded with the core capability; the second gives the workflow; the third explains the auto behavior; a short tail covers units, return shape, and open/unsaved state. It is dense and longer than most, but nearly every clause carries distinct information rather than restating 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?

With no output schema, the description compensates by naming the returned JSON keys ({drawing, sheet, scale, projection, frame, plan, warnings}) and the open/unsaved side effect. Given 10 parameters and the auto-planning complexity, this is close to complete, though it omits permission/auth requirements and whether an existing open drawing affects the call.

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 already 90%, so the baseline is 3, but the description adds real meaning for the auto path (sheet/scale='auto' needs source, measures views, picks smallest sheet and largest scale >= min_scale) and notes that source is 'remembered for add_view' and that the returned plan drives position='auto'. Units (mm) and the view_from convention are also clarified.

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?

Opens with a specific verb+resource and immediately enumerates the distinguishing attributes (ISO 5457 sheet A0-A4, ISO 5455 scale, projection method, 0.7 mm frame with 20/10 mm margins). It also situates itself in the workflow by naming the follow-up drawing tools, so an agent can tell catia_drawing_create apart from catia_drawing_add_view or title_block without opening schemas.

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?

Prescribes the exact downstream sequence (add_view, title_block, export_pdf, check) and states the prerequisite for the 'auto' path: source must be an OPEN CATPart/CATProduct. It does not name an alternative drawing-creation tool or explicitly say when not to use it, but for a creation entry point the sequencing guidance is clear.

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

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

The description discloses useful behavior such as file existence checking, optional PyMuPDF verification, return fields, and overwriting an existing file. However, overwriting an existing file contradicts the destructiveHint=false annotation, which claims only additive updates. This is an annotation contradiction.

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

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

The description is compact and front-loaded, starting with the core action. Each sentence adds operational value: checks, return shape, and overwrite note.

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 two-parameter export tool with no output schema, the description supplies return fields, verification behavior, and overwrite behavior. It is nearly complete for invocation, though it lacks sibling routing guidance and the overwrite/destructiveHint conflict is misleading.

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 already 100%, and the description adds no parameter-level semantics beyond what the schema documents. The path and drawing parameters are fully described in the schema, 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 states a specific verb and resource: export the drawing to a vector PDF, and even names the underlying API. It distinguishes the operation from generic export/screenshot siblings by specifying vector PDF output.

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

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

The intended context is implied by the PDF export purpose, but there is no explicit guidance on when to use this instead of siblings like catia_export, drawing_render, or drawing_overlay. No when-not conditions 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 readOnlyHint=false and idempotentHint=false, so the agent already knows this mutates state; the description adds genuinely new context — that the generated set is incomplete (overall sizes and hole positions missing), that dimensions are drawn green, and that a JSON summary is returned per view with type/value/mm. It does not mention undo/reversibility or whether rerunning duplicates dimensions, which is the main remaining gap.

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 action and outcome, with the caveat and the sibling hand-off following in a logical order. It is dense but each clause carries information; the parenthetical return-format note is slightly compressed but not wasteful.

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 helpfully explains the return shape (JSON per view with type, value, mm) and warns about incomplete output, which an agent needs to plan around. Prerequisites and idempotency/duplicate-run behavior are unaddressed, keeping it below a 5.

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

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

Only one optional parameter ('drawing'), and its schema description already documents the default-to-active-document behavior at 100% coverage. The description adds no syntax or format detail beyond the schema, so the baseline of 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 and target ('Run CATIA's Generate Dimensions on the active sheet') and immediately describes what it produces (dimensions driven by 3D constraints such as pad lengths and hole diameters). It also explicitly distinguishes itself from the sibling catia_drawing_add_dimension, which handles the dimensions this tool leaves out.

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?

Clearly frames the workflow: this tool auto-generates a partial set, and 'complete the drawing with catia_drawing_add_dimension' names the follow-up alternative. It could go further by stating prerequisites (an existing sheet/view must be active) or when to skip auto-generation entirely, so it stops short of a 5.

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 and openWorldHint=false, so the trailing 'Read-only' is largely redundant. What earns credit is the rich disclosure of what is returned (view geometry, dimension values), which, with no output schema, gives the agent real behavioral context about the read operation.

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

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

A single dense sentence with the primary action front-loaded and the payload inventory following. No filler, no repetition of the name or 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?

With no output schema, the description carries the burden of describing returns and does so thoroughly. It is nearly complete for a one-parameter read tool; only minor gaps remain, such as error behavior when the drawing is missing.

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

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

Only one parameter and schema description coverage is 100%, so the schema already documents the 'drawing' name and its default to the active document. The description adds nothing beyond that, which is the expected baseline when the schema does the work.

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 precise verb+resource ('read the drawing back') and enumerates the exact content returned: sheet format, scale, projection, views (kind, scale, centre, paper box, origin) and dimensions (type, value). This inventory distinguishes it from siblings like catia_drawing_check (validation) and drawing_extract_geometry without needing to name them.

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

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

Usage is implied by the verb and the read-only nature, but there is no explicit when-to-use guidance and no mention of the nearby alternatives (catia_drawing_check, drawing_extract_geometry, drawing_render) or the conditions that select this tool over them.

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

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

Annotations declare a safe (non-readonly, non-destructive) mutation, but the description adds real value beyond them: 'missing ones are refused' documents validation behavior, 'Nothing is invented: only what you pass is written' rules out defaulting/inference, and the return payload including ISO warnings is disclosed. Only minor gaps (e.g., error modes when no drawing is active) remain.

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 drawn artifacts, then constraints, then behavior and return value — a sensible ordering. It is dense and slightly run-on, but every clause (mandatory vs optional, tolerance codes, no-invention rule, warnings) 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 mutation tool with no output schema, the description covers inputs, validation, write semantics, and the returned structure, which is close to complete. It omits what happens if no drawing document is open or which drawing the block attaches to by default, a minor gap.

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

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

Schema coverage is 67% and the nested 'fields' object is opaque ('ISO 7200 field key -> text'), so the description carries the load by enumerating the eight mandatory keys and eight optional keys plus their semantics. It also states the general_tolerance values and default, which the schema only lists as an enum.

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?

Opens with a specific verb+resource ('Draw the ISO 7200:2004 title block') and enumerates the exact artifacts produced (block table, scale, ISO 2768 tolerance note, ISO 5456-2 projection symbol). This is unmistakably distinct from drawing siblings like catia_drawing_add_view or catia_drawing_add_dimension.

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

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

Usage context is implied (a drawing must exist, mandatory fields are refused if missing) but there is no explicit when-to-use statement or routing against alternatives such as catia_drawing_create or the other drawing_* tools. The agent must infer that this is a post-creation annotation 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 declare non-readonly, non-idempotent, non-destructive, so the mutation profile is known. The description adds real context beyond that: duplicates share the same reference, each is offset by the step vector, and they arrive unconstrained (requiring follow-up constraint work). It still doesn't mention failure/rollback behavior, but the added detail is meaningful.

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 compact sentences, front-loaded with the core action and ending with the follow-up imperative. No padding. Slightly terse to the point where the follow-up clause reads as an aside rather than grounded guidance.

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 3-parameter mutation tool with annotations covering the safety profile and no output schema, the definition gives what an agent needs to call it correctly: what gets created, how it is spaced, and that constraint work follows. Missing only edge-case behavior (invalid component reference, negative counts, mode/context requirements).

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% (only 'step' is documented in the schema), so the description must compensate. It does: 'N more instances' maps count, 'existing component' maps component, and the step shift is described, matching the schema's [dx, dy, dz] default. The default [0,0,50] is left 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 (Insert N more instances) on a specific resource (an existing component) and names the native CATIA behavior it mirrors ('Définir une multi-instance'). It is clearly distinguishable from siblings like catia_add_component (new instance of a reference) and catia_move_component (repositioning).

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 trailing 'Constrain them afterwards' implies a workflow step (duplicate, then constrain with catia_coincidence_constraint etc.), which is useful. However, it never says explicitly when to prefer this over catia_add_component or catia_add_new_part, nor any prerequisites such as the component existing in the active assembly.

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, destructiveHint=false, idempotentHint=false, so the mutation/safety profile is partly covered, and the description adds the format surface. However, it omits key export behavior: whether an existing target file is overwritten, whether the output directory must pre-exist, and whether export modifies the live document. The listed

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

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

Two sentences, zero waste, with the core action front-loaded and the format enumeration kept compact. Nothing needs to be cut.

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 should carry more of the burden for an export tool. It never says what is returned (success flag, written path, error behavior), nor how it handles overwrites or missing directories, and it advertises PDF which the format enum does not contain.

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

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

Schema description coverage is 100% and both parameters are fully documented, including the enum and the extension-overrides-format rule, so the baseline is 3. The description's format list merely restates part of the enum, adding no syntax or precedence detail 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?

States a specific verb (export), a specific resource (the active document), and a destination (a file), then enumerates the supported formats. An agent can distinguish it from catia_save_document (which persists the native document) without opening 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?

Usage is implied by 'active document' and the format list, but there is no explicit guidance on when to use this versus catia_save_document or catia_drawing_export_pdf, and no prerequisites (e.g., an active document must exist). No when-not guidance or alternatives are named.

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 cover the safety profile (non-readOnly, non-destructive, non-idempotent), and the description adds meaningful behavior beyond them: tangent edges are propagated automatically, edges are searched in the active body, and multiple edges collapse into a single feature. It does not describe failure behavior when a point misses an edge.

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 operation and scope, then the edge-identification rule and the sibling pointer. The parenthetical dialog analogy is slightly verbose but genuinely aids recognition; no wasted sentences.

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, it covers the essentials: what is created, how edges are targeted, tangent propagation, and the search body. Missing only failure/validation behavior and whether the resulting feature name is returned, which the name parameter partly implies.

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 baseline is 3, but the description adds practical meaning: edges are specified by a 3D point lying on each edge (midpoint hint), and the active body is the search scope. That is more than the schema alone conveys about how to supply edge_points.

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+resource ('constant-radius edge fillet on one or more edges') and clarifies the key semantic that multiple edges yield ONE fillet feature, paralleling the Congé d'arête dialog. This clearly distinguishes it from siblings like catia_chamfer or catia_shell.

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

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

Explicitly routes the agent to catia_list_edges when edge endpoints are unknown, which is exactly the prerequisite an agent needs. It lacks an explicit when-not (e.g. variable-radius or face fillets, or chamfer-vs-fillet choice), so it falls short of a 5.

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 idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the agent knows this is a safe, repeatable operation. The description usefully adds that the effect is scoped to the current 3D view rather than the model, but it does not clarify that geometry/model data is untouched, which is the main thing an agent would want confirmed given readOnlyHint=false.

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 the action front-loaded and the clarifying gloss appended; no wasted words.

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

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

For a no-parameter view tool with no output schema, the description covers what the agent needs, though a brief note that it does not modify model data would fully close the gap left by readOnlyHint=false.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 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 (fit) and resource (all geometry) plus the scoped target (current 3D view), and the parenthetical 'zoom to fit' removes any ambiguity about what 'fit' means. An agent can distinguish this from view-manipulation siblings such as catia_set_view or catia_clean_display without opening a 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 never states when to call this versus alternatives like catia_set_view or catia_clean_display, nor any prerequisite (e.g. an active document). Usage is only weakly implied by 'current 3D view'.

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, destructiveHint=false, idempotentHint=false. The description adds one behavioral rule (first component must be fixed) but doesn't disclose reversibility, whether prior constraints are modified, or the solve cost — that detail lives in the schema's defer_update description, not here.

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 the operation and followed by the constraint rule. No wasted words, though it is arguably terse relative to the complexity of the tool.

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

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

For a mutation tool with no output schema and full schema coverage, the description is minimally adequate. It omits what the fixer changes, whether it can conflict with existing constraints, and how it interacts with the assembly solve workflow it references nowhere.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters in detail (including the defer_update solve-cost explanation). The description adds no parameter-level meaning beyond the schema baseline.

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+resource: fix a component in space via a 'Fixer' constraint. This distinguishes it from the other assembly-constraint siblings (coincidence, contact, offset, angle). It doesn't explicitly name those siblings, so sibling differentiation is implied by constraint type rather than stated.

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 one usage rule: the first/reference component of an assembly must be fixed. That is useful context, but there's no guidance on when to use a fixer vs. other constraints, no exclusion criteria, and no explicit mention of an alternative.

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 and openWorldHint=false, so the safe-read profile is covered. The description adds that output covers document identity and structure, but says nothing about behavior when no document is open, nor about return format or size.

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 naming the subject before the field list. The trailing 'etc.' is slightly loose but costs little.

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 carries the burden of indicating what comes back and does so by listing document name, type, path, part bodies and features. It stops short of noting error conditions (e.g. no active document), which is a minor gap for a no-arg read tool.

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

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

Zero parameters, so there is nothing to document beyond what the schema (empty object) already conveys; the baseline for a no-param tool 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 (get) and resource (active CATIA document) and enumerates the kinds of data returned (name, type, path, part bodies, features). It implicitly contrasts with catia_list_documents by scoping to the active document, but never names a sibling explicitly.

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 when-to-use guidance and no routing to alternatives such as catia_list_documents, catia_get_tree, catia_describe_model, or catia_get_parameters. The agent must infer from the name alone when this introspection call is the right one.

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 and openWorldHint=false, so safety is covered. The description usefully adds that the result is exact, in mm, includes curved geometry, and reports min/max plus size, but says nothing about performance, precision limits, or behavior on empty/invalid bodies.

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 compact sentences with the output shape (x/y/z [min,max] and size) front-loaded ahead of the usage hint. 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?

With no output schema, the description carries the burden of describing the return value and does so explicitly (min, max, size per axis, in mm, curved faces included). Completeness is good; only measurement caveats and edge-case behavior are 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?

Only one parameter and schema coverage is 100% – the schema already documents body_name and its active-body default. The description adds no syntax or naming guidance beyond what the schema provides, 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+resource (bounding box of a body's solid) and is precise about scope and units ('Exact ... (mm)', 'curved shapes included'). It does not explicitly contrast with siblings like catia_measure_distance or catia_get_inertia, which is the only thing keeping it from 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?

Offers one concrete use case ('check a piece against its drawing') but gives no when-not conditions and never names an alternative measurement tool among the many siblings. Usage is implied rather than routed.

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 and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: it discloses the exact result set and the conditional that mass is only returned 'if density is defined', which is important for interpreting results. It stops short of saying what happens when no part is active or in what units results are returned.

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

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

A single sentence, front-loaded with the operation and immediately followed by the return set. Every clause earns its place; nothing is redundant 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?

The tool is a read-only measurement with no output schema, so the description correctly enumerates the returned values in place of a schema. Parameters are fully covered by the input schema. Minor gaps remain (units of measure, failure mode with no active body), but nothing essential for invoking it is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description only echoes the density-massing relationship already stated in the density parameter description, adding no new syntax or constraint information; baseline 3 applies when the schema does the heavy lifting.

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+resource ('Get inertia properties of the active part') followed by an enumeration of exactly which properties are returned (volume, surface area, center of gravity, mass, moments of inertia). It doesn't differentiate itself from nearby measurement siblings such as catia_measure_distance, catia_get_bounding_box, or catia_measure_model, so it falls 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 description contains no when-to-use guidance, no prerequisites (e.g. a part must be active/density must exist), and no mention of alternative measurement tools. Usage is only implied by the phrase 'of the active part'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully clarifies that both user-defined and computed parameters are returned and that formulas and design tables are included, which is real content context. It says nothing about return format, ordering, or behavior when no part is active, so it is adequate but not rich.

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

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

Two short sentences, zero filler, with the core action front-loaded and the content enumeration second. Every clause contributes information an agent can act on.

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

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

For a one-parameter read-only listing tool with no output schema and annotations covering safety, the description is largely sufficient: it defines scope and returned content. Minor gaps remain around whether an active part must exist and how the result is structured, but neither is critical for correct invocation.

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

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

Schema description coverage is 100% and the single 'filter' parameter is fully documented in the schema as an optional partial-match name filter. The description adds no example syntax, matching semantics, or scope notes 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 (List) and resource (parameters) with clear scope: 'of the active part'. The inclusion of dimensions, formulas, and design tables sharpens what constitutes a parameter here. It does not, however, name or contrast itself with siblings such as catia_set_parameter (the write counterpart) or catia_get_tree, which also expose model metadata.

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 when-to-use guidance, prerequisites (e.g. an active part/documented open), or alternatives are given. An agent must infer that this is the read counterpart to catia_set_parameter rather than being told so. The scoping phrase 'active part' hints at context but is not framed as usage guidance.

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

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

readOnlyHint=true and openWorldHint=false already establish this as a safe local read, and the description is consistent with that. It adds genuine value by defining the safety model itself: read = inspect only, write = model and save, dangerous = may also delete features and close documents. This tier semantics is the substantive behavioral context an agent 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?

A single front-loaded sentence with no padding; the tier list is the payload and is placed immediately. The trailing 'and what each tier allows' is slightly redundant given the parentheticals that follow it, but costs little.

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 trivial zero-parameter getter with no output schema, the description supplies enough to know what it returns (the current tier) and what the returned tiers mean. It could note the return format (e.g., a string value) but the enumeration makes the output shape evident.

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

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

The tool takes no parameters, so there is nothing for the description to explain beyond what the empty schema already conveys. Baseline for a zero-parameter tool 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 (get) and resource (safety state/tier of the session) and enumerates the three possible tier values with parenthetical glosses. It implicitly contrasts with the set_safety sibling by returning rather than mutating state, though it never names that sibling or explicitly frames itself as the read counterpart.

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

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

No explicit when-to-use statement or mention of alternatives, but the purpose (checking the current tier) makes the natural usage—inspecting permissions before destructive operations—reasonably inferable. There is no when-not 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real content-level behavior: the tree includes absorbed bodies, and the result carries a naming AUDIT flagging default names with concrete patterns ('Extrusion.3', 'Esquisse.2', 'Corps principal'). It says nothing about output format or cost, which keeps it from a 5.

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

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

Front-loaded with the core purpose, then density of examples (default-name patterns) that an agent can act on. Slightly long and example-heavy, but every clause carries information; no filler.

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

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

With no output schema, the description carries the burden and does so well: it describes the tree's composition and the audit payload, plus the corrective action to take. An agent can call it and interpret the result without further 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?

The tool takes zero parameters, so the baseline is 4; there is no parameter surface for the description to clarify, and it correctly focuses on output content instead.

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 ('Specification tree of the active Part') and enumerates exactly what the tree contains: bodies (including those absorbed by boolean ops), sketches, features, planes, and geometrical sets, plus a naming audit. It is clearly distinguishable from siblings like catia_list_features or catia_list_bodies that return narrower slices.

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 explicit timing guidance ('Run it after each piece and fix every flagged name before saving'), which tells the agent when this belongs in a workflow. It does not name alternatives or exclusions (e.g., when to prefer catia_audit_model or catia_list_features), so it stops short of the 5 tier.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower. The description earns credit by disclosing genuinely non-obvious behavior: a Groove can serve as the first feature of an empty body, holds the removed volume, and must be assembled into the main body to actually cut — behavioral context the annotations cannot convey.

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 sentences, each load-bearing: the definition, the axis cross-reference, and the first-feature behavior. The core verb+resource is front-loaded with zero preamble or filler.

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

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

For a mutation tool with no output schema and full schema-coverage on parameters, the description supplies the key behavioral facts an agent needs (first-feature usage, removed-volume assembly). It does not explain prerequisites such as whether a sketch must exist first, a minor omission given the schema and annotations already carry substantial detail.

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

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

Schema description coverage is 100%, so the schema already documents axis, name, angle, and sketch_name in detail (including the enum for axis and a strong name-convention note). The description only adds 'Same axis rules as catia_shaft', which cross-references semantics but adds no new parameter detail. 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 opens with a specific verb+resource ('Create a Groove') and immediately qualifies it as a '(revolution cut)', which cleanly distinguishes it from the additive sibling catia_shaft. An agent can route between material-removal and material-adding revolve operations 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?

It states a concrete usage context — 'Works as the FIRST feature of an empty body' — and names the 'Machined' body pattern, giving clear guidance on a non-obvious scenario. However, it never explicitly contrasts itself with catia_pocket (extruded cut) or states when a Groove is preferred over those alternatives, so the alternative-routing is implied 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 declare a non-readonly, non-idempotent, non-destructive write operation, but the description adds nothing about what gets created/destroyed, whether it needs an active geoset, or persistence behavior. For a surface-creation tool with no output schema, this leaves significant 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?

A single, front-loaded sentence with zero waste. Every word earns its place.

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

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

For a GSD surface-creation tool with no output schema and no annotations covering side effects, the description omits prerequisites, active-geoset context, and behavioral implications. It is too thin to fully guide correct invocation.

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

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

Schema coverage is 100%, so parameters are fully documented in the schema. The description repeats 'two curves' but adds no format or naming details beyond what the schema already provides, so 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 (Create) and resource (Blend surface) with the connecting inputs (two curves). It is clearly distinct from siblings like gsd_fill or gsd_sweep, though it doesn't explicitly contrast against 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?

No when-to-use guidance, no prerequisites (e.g., curves must exist, active geoset requirement), and no mention of alternatives like multi_section_surface or fill. The agent must infer context entirely.

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-read-only, non-destructive, non-idempotent creation. The description adds the intended downstream role (multi-section surface section) but says nothing about which geoset the circle lands in, whether an active geoset must be set first, or what happens on name collision.

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, no filler, with the create action and its inputs front-loaded. The second sentence is a genuinely useful orientation hint rather than padding.

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 feature-creation tool with no output schema and a moderate schema, the definition is adequate but leaves the container/target question open (geoset placement, naming), which matters given siblings like catia_gsd_set_active_geoset.

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 75% and the schema already documents center (element name or [x,y,z] that creates a point), radius in mm, and the 'xy'/'yz'/'zx' plane options. The description only restates those three inputs, adding no syntax, units, or defaults 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?

States a specific verb (create) and resource (full 3D circle) along with the three inputs that define it. '3D' implicitly separates it from the sketch-level sibling catia_sketch_circle, but the description never names or contrasts that alternative explicitly.

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?

'Useful as a section for multi-sections surfaces' gives one downstream usage context, hinting when the tool is relevant. It offers no when-not guidance and does not point to catia_gsd_multi_section_surface or catia_sketch_circle as the alternative path.

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 not read-only and not destructive, so the safety profile is covered. The description adds useful context that the solid is created in the active body and that the surface must be closed, but it does not state what happens if the surface is open or whether the source surface is consumed.

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 are front-loaded with the core operation and include only necessary context: the watertight prerequisite and the active-body result location. No filler or repetition.

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

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

For a mutation tool with no output schema, the description gives the essential input condition, the operation, and where the result is created. It omits failure behavior and return information, but the annotations and full schema coverage make the definition largely complete for correct invocation.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds the watertight constraint for the surface parameter but does not provide additional syntax or format details beyond what the schema supplies. 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 states a specific verb and resource: turning a closed watertight surface into a solid via Part Design CloseSurface. It clearly distinguishes this from general solid creation siblings like pad or thick_surface, though it does not explicitly name an alternative 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 prerequisite that the input surface must be closed/watertight implies when this tool is appropriate, but the description offers no explicit when-not guidance or named alternatives such as thick_surface. Usage context is implied 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 flag a non-readonly, non-idempotent, non-destructive write. The description adds meaningful stateful behavior beyond that: the new set becomes the active target for subsequent GSD elements. It omits any prerequisite (e.g., that an active Part must exist), but the state side effect is a useful addition.

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

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

A single sentence with zero waste. The creation action is front-loaded and the side-effect consequence follows immediately.

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 single-parameter creation tool with no output schema, the description covers what is created, where, and the consequential state change. It is complete enough to call correctly, though it could note the active-Part precondition more explicitly.

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% and the single 'name' parameter is fully described with a default ('GSD_Set'). The description adds no naming convention or format detail beyond the schema, so it sits at the baseline for high-coverage schemas.

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 (Create) and resource (Geometrical Set/HybridBody), plus its location (in the active Part). It also names the resulting state change, making it clearly distinguishable from the sibling catia_gsd_set_active_geoset, which manipulates an existing set.

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 clause 'make it the active target for subsequent GSD elements' implies this is the tool to reach for before adding new GSD geometry, versus catia_gsd_set_active_geoset for switching to an existing set. However, it does not explicitly name that alternative or state exclusion/precondition 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 declare the safety profile (not read-only, not destructive, not idempotent), so the agent knows this creates rather than mutates geometry. The description adds the symmetric limit1/limit2 scoping model but says nothing about which geoset/body the new surface lands in or what side effects accompany creation; with annotations present, a 3 is fair.

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 tight sentences with no filler; the core action and output type come first, and the limit clarification follows. Every clause carries 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?

With full schema coverage and no output schema, the essentials for calling the tool are documented, and annotations cover the safety profile. It is slightly thin on where the resulting surface is placed and what happens to the source profile, but nothing critical is missing for basic 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 100%, so the baseline is 3. The description restates limit1/limit2 as extents on each side in mm, which lightly reinforces the bidirectional framing but adds little beyond the schema's own 'Length along direction (mm)' / 'Length opposite to direction (mm)' descriptions.

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

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

States a specific verb (extrude), the input (profile curve/sketch), and the output type (surface) along a direction vector. Specifying 'surface' implicitly separates it from the solid-extrude siblings catia_pad/catia_pocket, so an agent can pick it without opening 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?

There is no guidance on when to choose this over catia_gsd_sweep, catia_gsd_revolve, or catia_pad, nor any prerequisite stated (e.g., an active geoset or an existing profile in the document). The reader must infer usage entirely.

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, establishing a non-destructive creation operation. The description adds the constraint that boundaries must form a closed contour, which is useful, but it does not cover error behavior, required permissions, or where the result is created.

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 that states the action, the result, and the geometric constraint without any wasted words or redundancy.

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

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

For a creation tool with no output schema, the description lacks context about where the surface is placed (e.g., active geoset) or what happens on failure. Annotations cover safety, and the schema is fully documented, but this contextual gap keeps it at a minimum viable level.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: the boundaries must form a closed contour and can be one closed curve or several connected curves. This clarifies how to use the boundaries parameter beyond the schema's 'in contour order' note.

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 (Create) and resource (Fill surface) with a precise geometric constraint (bounded by a closed contour of curves). It clearly conveys what the tool does, but does not explicitly differentiate itself from similar siblings like catia_gsd_close_surface or catia_gsd_blend.

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 on when to use this tool versus alternatives. It simply states the operation without mentioning prerequisites, appropriate contexts, or any sibling tools to consider instead.

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 and destructiveHint=false, so the mutation profile is covered structurally, but the description adds nothing behavioral — it does not say whether the result is placed in the active geoset, whether inputs are consumed, or what happens if the elements do not intersect. No contradiction with 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 front-loaded sentence with zero filler; the verb+resource leads and the example clarifies immediately.

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

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

For a geometry-creation tool with no output schema and no annotations on result placement, the description is adequate but thin: it omits where the result lands, how it is named if 'name' is omitted, and what failure modes exist. An agent could call it, but not confidently.

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

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

Schema description coverage is 100%, so both required parameters are already documented, including the 'xy'/'yz'/'zx' plane options for element2. The description only adds an illustrative example of the operand types, which is marginal value over the schema baseline.

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 ('Create the intersection of two elements') and gives a concrete example ('surface ∩ plane') that pins down the operation. It is distinguishable from siblings like catia_gsd_trim or catia_boolean_operation, though it never names them explicitly.

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 when-to-use guidance, no prerequisites, and no routing to alternatives. An agent must guess whether intersection is preferred over catia_gsd_split, catia_gsd_trim, or catia_boolean_operation for a given modeling situation.

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-readonly, non-destructive, non-idempotent operation, so the safety profile is covered. However, the description omits genuinely useful behavior: whether the source elements are consumed or preserved, whether the result is a new named element, and what happens if the inputs are non-contiguous or of mixed type.

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

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

A single front-loaded sentence with the verb leading and no filler; nothing is wasted. It is slightly under-specified rather than over-long, but structurally clean.

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 GSD operation with no output schema, the description should explain the return (is the joined element returned or just created?) and the fate of the inputs. Neither is addressed, leaving the agent unable to predict the effect of a non-idempotent operation.

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

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

Schema coverage is 100% and both parameters (name, elements) are fully documented in the schema, so the baseline of 3 applies. The phrase 'two or more' loosely mirrors the minItems constraint but adds no syntax, ordering, or format detail 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?

States a specific verb ('join/assemble') and resource ('curves or surfaces') with the output shape ('into one element'), which distinguishes it from siblings like catia_gsd_trim and catia_gsd_split. It stops short of naming the closest alternative operators (e.g., catia_gsd_close_surface) that an agent might confuse it with.

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 reach for join versus trim, split, close_surface, or boolean operations. There is no statement of prerequisites (e.g., curves must be contiguous) or when-not-to-use conditions; the agent must infer usage entirely from 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 readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the mutation profile is largely covered. The description does add one non-obvious behavioral fact — passing coordinates creates a new point element as a side effect — but omits what the line is attached to (active geoset) and what the call 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?

Two short sentences with zero filler; the action comes first and the point-input duality follows immediately. Nothing redundant 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 non-read-only geometry-creation tool with no output schema, the description covers the core input contract but leaves gaps: the containment context (which geoset/body receives the line), the effect of the optional 'name', and any return value or failure mode are unaddressed.

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

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

Schema coverage is only 33%, but the description's statement that each point is 'an existing element name or [x, y, z] coordinates' essentially restates the oneOf branches already documented in the schema, and says nothing about the optional 'name' parameter. It neither compensates for the coverage gap nor adds syntax 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?

States a specific verb and resource ('Create a 3D line between two points') with scope indicators ('3D', GSD context) that separate it from the 2D catia_sketch_line sibling. An agent can identify the operation 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?

No when-to-use guidance, no prerequisites (e.g. does it require an active geoset?), and no routing to alternatives such as catia_gsd_spline or catia_sketch_line. The second sentence is parameter detail, not usage context.

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

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

The description says 'List', which implies a read-only operation, but the annotations declare readOnlyHint=false and idempotentHint=false. This contradiction is not explained, and the description gives no side-effect or state-change context to reconcile it.

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

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

Two sentences, front-loaded with the listing scope and then the use case. No filler or repetition.

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

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

With no output schema, the description should clarify what is returned and whether listing has side effects. It only implies element names are returned and leaves the readOnlyHint=false annotation unexplained, which could mislead an agent about state changes.

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

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

The tool takes zero parameters, so there are no parameter semantics to document. The baseline for a zero-parameter tool is 4.

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: list geometrical sets with wireframe/surface elements and sketches, plus sketches in solid bodies. It distinguishes itself from GSD creation tools by noting its role in finding element names, though it does not explicitly contrast with other listing tools like catia_get_tree.

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

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

Provides clear context: use this to find element names for other GSD tools. It does not state when not to use it or name alternative listing tools, but the intended usage is easy to infer.

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 that this is a non-read-only, non-destructive, non-idempotent, closed-world creation operation. The description adds that at least two sections are needed and that order matters, but it does not add much beyond the annotations and schema, such as failure behavior beyond what the guide parameter already states.

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

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

Two tight sentences that are front-loaded with the primary operation and then the essential ordering constraint. No filler or redundant explanation.

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 surface-creation tool with detailed schema descriptions and annotations covering safety and world assumptions, the description is nearly complete. It omits mention of the orientations parameter, but the schema fully covers that, and no output schema exists so return values need not be explained.

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

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

Schema description coverage is 100%, so the schema already documents every parameter in detail, including the guide-intersection failure condition and per-section orientation. The description repeats the 2+ sections requirement and ordering but adds no semantic detail beyond the structured fields.

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

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

States a specific verb (Create) and resource (Multi-sections Surface / loft), with the key input condition of 2+ section curves and optional guide curves. It is clear what the tool does, but does not explicitly distinguish this loft operation from sibling surface tools such as sweep, fill, or blend.

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 usage through the required 2+ section curves and the note that sections should be listed in lofting order. However, it gives no explicit when-to-use guidance, no alternatives, and no exclusions relative to sibling surface-creation 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, destructiveHint=false, idempotentHint=false, and openWorldHint=false, covering the safety profile. The description adds only that the input is an existing surface, which is already implied by the schema, and does not disclose side effects such as where the new surface is placed or whether an active geoset is required.

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?