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

No annotations are provided, so the description carries full behavioral burden. It discloses that the chamfer is symmetric and defaults to all edges, but says nothing about mutation/destructiveness, required part state, units, reversibility, or interaction with existing features.

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

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

A single front-loaded sentence with no filler. It is efficient, though arguably too terse for a CAD mutation with an unexplained required parameter.

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

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

Given a 3-parameter CAD mutation tool with no annotations and zero schema description coverage, the description is incomplete. An output schema exists so return values needn't be covered, but offset semantics, edge targeting, and prerequisites are all 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 0%, so the description must compensate. It implies body_id identifies the body and edge_indices selects edges, but never explains the required 'offset' parameter — no units, meaning (distance vs. angle), or relation to edge selection.

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

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

The description states a specific verb and resource: 'Create a symmetric chamfer on edges of a body.' This is clearly distinguishable from most siblings, though it never explicitly contrasts with nx_edge_blend, the closest alternative.

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

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

It notes the default behavior ('all edges') but gives no guidance on when to use this versus nx_edge_blend, what prerequisites must hold (open part, existing body), or how to target a subset of edges beyond the optional parameter.

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

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

With no annotations, the description carries the full burden and delivers the critical side-effect semantics: the original body is kept, new instances are independent bodies, and they are NOT united. It also clarifies that count includes the original and that angle is the total sweep, preventing the most common modeling mistakes.

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 paragraphs, front-loaded with the operation, then the two parameters most likely to be misused, then the unite alternative. No filler 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?

An output schema exists, so return values need not be described, and the behavioral and count/angle semantics are covered. The main omissions are the undocumented 'reverse' flag and any note on required preconditions (e.g., an open part, valid body_id).

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

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

Schema coverage is 0%, so the description must compensate, and it does for two parameters: 'count' (total including original, count=4 yields 4 bodies) and 'angle' (total sweep in degrees, 360.0 distributes evenly). However, 'reverse', 'axis', and 'body_id' get no treatment beyond their titles, leaving real gaps at 0% coverage.

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

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

States a specific verb and resource ('Pattern a body') plus the exact manner ('circularly about an axis through center'), so the agent can distinguish it at a glance from nx_linear_pattern and nx_mirror. Nothing about the operation's intent is left 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?

Explicitly routes the agent to a sibling when merging is needed ('use nx_unite if merging is required'), which is the key decision point for this tool. It does not spell out prerequisites such as an open part or how to pick circular vs. linear patterning, but the operational context is clear.

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

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

With no annotations provided, the description must convey behavioral traits itself. It states the action and the save option, but does not disclose that closing without saving (save=false) discards unsaved changes, that the operation may fail if no part is active, or that it is a destructive action. These are significant gaps for a state-changing tool.

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

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

The description is a single, compact sentence that leads with the primary action and immediately clarifies the optional behavior. Every word serves a purpose, with no redundancy or filler, making it highly efficient for an agent to parse.

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

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

For a tool with one parameter and no annotations, the description is too sparse. It does not cover error conditions (e.g., what happens if there is no active part), side effects (e.g., unsaved data loss when save=false), or any confirmation/return behavior. While the tool is simple, the description should disclose at least the destructive implication of not saving, which it fails to do.

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 single 'save' parameter is well-named and its type (boolean) and default (true) are self-explanatory. The description references the option to save, which maps directly to the parameter, but adds no further meaning beyond the schema. With 0% schema description coverage, the tool description partially compensates, but the semantics are still evident from the schema itself, so a baseline of 3 is appropriate.

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

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

The description uses a clear verb ('Close') and a specific resource ('active work part'), and states the optional save behavior. It distinguishes itself from siblings like nx_save_part (which only saves) and nx_open_part (which opens), making the purpose unambiguous.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention that it is for ending work on a part, nor does it contrast with nx_save_part or nx_open_part. There is no explicit when-to-use or when-not-to-use context, leaving the agent to infer 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?

No annotations are provided, so the description carries the full behavioral burden. It describes the hole geometry and its independence from nx_hole, but it does not disclose mutation side effects, required permissions, or how it affects the target body.

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

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

The definition is two tight sentences with no wasted language. The core operation and the sibling differentiation are front-loaded.

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

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

For a 7-parameter CAD mutation tool with no annotations and 0% schema description coverage, the description is too sparse. It explains the resulting shape but omits parameter meaning and behavioral details; the output schema covers return values but not the input semantics an agent needs.

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

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

Schema description coverage is 0% across 7 parameters. The description conceptually maps the hole and counterbore diameters/depths to the resulting geometry, but it leaves body_id, center, and start_offset unexplained, so it only partially compensates for the schema gap.

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

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

The description states a specific verb and resource: "Create a coaxial counterbore hole." It explains the geometry precisely as a smaller deep through hole plus a larger shallow counterbore from the top face, and it distinguishes this from the sibling nx_hole by saying it is "Independent from nx_hole."

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

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

The phrase "Independent from nx_hole" signals a relationship to an alternative, but it does not explicitly say when to use this tool instead of nx_hole or nx_countersink_hole. The intended usage is implied by the geometry description, but there are no clear exclusions or prerequisites.

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

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

With no annotations, the description carries the burden and it does describe the resultant shape, which is genuinely useful. However it never states that this is a subtractive feature applied to an existing 'body_id', whether the operation is undoable, or any relationship constraints between the two diameters or the depth/offset — meaningful gaps for a geometry-mutating tool.

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

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

Two sentences, zero filler, and the shape definition is front-loaded before the sibling disambiguation. Every clause adds information an agent needs.

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

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

An output schema exists, so return values need not be explained, and the geometry semantics are covered well for a 7-parameter feature-creation tool. The remaining shortfall is that a mutating operation with no annotations says nothing about body modification side effects or parameter interdependencies.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate and largely does not. The phrase 'smaller deep through cylinder plus a conical countersink' hints that hole_diameter < countersink_diameter and that hole_depth is the through-depth, but hole_diameter, hole_depth, countersink_diameter, countersink_angle, and start_offset are all left undocumented — including the 90-degree default and the 0<angle<180 bound, which are only implicit in the schema.

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

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

States a specific verb and resource ('Create a coaxial countersink (conical) hole') and defines the resulting geometry precisely (through cylinder plus conical countersink from the top face). It also explicitly names the two siblings it is not (nx_hole, nx_counterbore_hole), so the agent can distinguish it without inspecting 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?

The 'Independent of nx_hole / nx_counterbore_hole' clause tells the agent this is the standalone option rather than a modifier of another hole feature, which is useful routing context. It never states an explicit selection condition (e.g. 'use when the fastener head is conical rather than cylindrical') or any prerequisites, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description must carry the behavioral load; it does disclose the key prerequisite that edge_index is a 0-based index obtained from nx_list_edges on the given body, which is real operational context. It says nothing about whether the dimension persists in the model, permission/part-state requirements, or side effects of creating an annotation.

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

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

Three short sentences, front-loaded with the action, then the differentiation, then the parameter prerequisite. Nothing is redundant and every sentence adds 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?

An output schema exists, so return values needn't be explained, but for an 8-parameter mutation tool with no annotations and 0% schema coverage the definition leaves too much open: what the tolerances do, where pos_x/pos_y place the dimension, and what part/view context is required.

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

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

Schema description coverage is 0% across 8 parameters, so the description must compensate and it only explains edge_index (and implies body_id). Placement coordinates (pos_x, pos_y), view_id, dim_name, and the tolerance pair are entirely undocumented in either place, leaving most of the surface for the agent to guess.

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 DIAMETER dimension') plus the exact target scope ('on one edge'), and explicitly contrasts it with the linear-dimension alternative. An agent can distinguish this from nx_create_dimension or nx_create_radius_dimension on purpose alone.

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 condition for use: cylindrical/circular features where a linear dimension between two edges cannot express a diameter, with a parenthetical use case (shafts). It does not address the closest sibling, nx_create_radius_dimension, nor when-not to use it, 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the dimension is associative, uses BilateralTwoLines style, and defaults to ±0.1 mm tolerance. However, it does not disclose mutation effects on the drafting view, failure conditions for invalid body/view/edge selections, or other operational constraints.

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

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

The description is front-loaded and compact: the core action is stated first, followed by measurement scope and default tolerance behavior. 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?

Although an output schema exists and return values need not be described, this is a complex 10-parameter creation tool with no annotations and 0% schema description coverage. The description covers the main concept but omits enough parameter meaning and operational detail that an agent may not know how to populate or safely invoke several inputs.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate. It explains the edge-index parameters, body/view context, and tolerance defaults, but leaves pos_x, pos_y, dim_name, and the measurement enum unexplained, which is a significant gap for a 10-parameter tool.

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

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

The description states a specific verb and resource: create an associative linear dimension. It also scopes the operation to measuring distance between two model edges inside a drafting view, which differentiates it from radius/diameter dimension tools and from a plain distance measurement.

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

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

It clearly establishes the usage context: create a linear dimension between two body edges in a drafting view, with edges selected by index from nx_list_edges. It does not explicitly state when not to use this tool or name alternatives such as nx_measure_distance or the radius/diameter dimension tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses the geometry prerequisite, but not whether this mutates the active part, how duplicate sheet names are handled, what permissions or open-part state are required, or what side effects occur.

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 the primary action front-loaded and the prerequisite following. 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 five-parameter mutation tool with no annotations, the description is too sparse. The output schema covers return values, but the description does not compensate for the missing parameter and behavioral 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 0% across five parameters. The description only vaguely references 'the given model view' and does not explain name, size, scale, projection, defaults, or allowed values, leaving parameter meaning almost entirely undocumented.

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

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

The description uses a specific verb and resource: 'Create a drawing sheet' and 'place a base view.' The phrase 'base view' distinguishes it from sibling tools such as nx_create_projected_view, and an agent can tell what the 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 a prerequisite ('The part must already contain geometry') but does not explicitly state when to choose this tool versus alternatives like nx_create_projected_view or when not to use it. Usage is therefore implied rather than fully 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?

With no annotations, the description carries the full burden, and it does add genuine behavioral detail beyond the schema: the '|' newline convention and the sheet-coordinate unit (mm). It does not disclose what happens if no drawing sheet is active, whether the note persists until nx_save_part, or whether the call is idempotent, which are material gaps for a document-mutating tool.

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

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

Three short lines, front-loaded with the action and resource, followed by the two pieces of information an agent needs before calling. The worked example earns its space by demonstrating the delimiter convention that would otherwise be ambiguous.

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

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

An output schema exists, so return values need not be explained, and the format/coordinate details cover the core call. However, for a mutating drafting tool with zero annotation coverage, the description never states the prerequisite of an open drawing sheet or any failure behavior, leaving an agent unable to predict what happens on a bad 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 0%, so the description must compensate, and it does: the '|' delimiter rule for 'text' and the 'sheet coordinates (mm)' framing for pos_x/pos_y give real meaning that the bare schema titles do not. The default values (20, 20) and their origin are not explained, keeping it below a 5.

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

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

The description states a specific verb ('Add') and resource ('technical-requirement / process text') with its target ('the current drawing sheet'), which is far more concrete than the sibling list alone would suggest. It implicitly separates itself from nx_create_dimension, nx_create_roughness and nx_create_title_block by naming the content type as free-form note text, though it never references those siblings directly.

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

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

Usage is implied by the phrase 'current drawing sheet', which signals this is a drafting-stage operation, but there is no explicit when-to-use/when-not-to-use guidance and no mention of alternatives such as nx_create_title_block or nx_create_roughness for other annotation types. Prerequisites (an active sheet created via nx_create_drawing_sheet) are left 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?

No annotations are provided, so the description carries the full behavioral burden. It mentions the configured workspace but does not disclose whether an existing part is overwritten, what permissions are required, or what side effects occur.

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

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

The description is a single front-loaded sentence with no wasted words. It is concise, though its brevity contributes to the missing behavioral and parameter context.

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

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

For a create/mutation tool with no annotations, two undocumented parameters, and a configured-workspace dependency, the description is too thin. The output schema can carry return values, but overwrite behavior, path meaning, and units are left 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 description coverage is 0% and the description does not mention either parameter. It does not clarify whether 'path' is a file path, part name, or workspace-relative path, nor does it explain the 'units' enum and default.

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 has a clear verb+resource (create a part) and a scoping detail (inside the configured workspace). It distinguishes from open/save/close part operations, though it does not explicitly contrast with sibling tools such as nx_open_part.

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 what the tool does but gives no explicit guidance on when to use it versus alternatives like nx_open_part, nor any preconditions beyond the configured workspace. Usage is only implied by the tool 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the parent-view fallback behavior, but it does not mention side effects, required permissions, failure modes, or what happens if no drafting view exists.

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

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

The description is two short sentences, front-loads the core action, and uses the second sentence for a concrete parameter rule. There is no redundant or wasted 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 creation tool with no annotations and 0% schema coverage, the description leaves important gaps: prerequisites such as an existing sheet/drafting view, the purpose of the name parameter, failure behavior, and side effects are unstated. The output schema helps with return values, but the input and behavioral context remain incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It partially explains x/y as sheet position and clarifies the parent_view_id fallback, but it says nothing about the name parameter, units, coordinate format, or parent-view ID format.

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

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

The description states a specific action and resource: projecting a view from an existing drafting view at a sheet position. It is clear enough to distinguish from most sibling tools, though it does not explicitly contrast with related drafting-view tools.

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

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

It gives one useful usage rule: leave parent_view_id empty to use the first drafting view on the sheet. However, it does not explain when to use this tool versus alternatives such as listing drafting views or creating drawing sheets, nor does it mention prerequisites.

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

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

No annotations exist, so the description carries the full burden of behavioral disclosure. It reveals nothing about the fact that this mutates the open part document, whether the dimension is undoable via nx_undo, what happens if edge_index is invalid, or what pos_x/pos_y/view_id control — significant gaps for a write 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?

Two short sentences, front-loaded with the action and followed by the one non-obvious parameter hint. No filler, though the brevity comes at the cost of coverage rather than from disciplined editing.

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

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

An output schema exists, so return values needn't be described, but this is still a mutation tool with no annotations and six largely undocumented parameters. The description omits the preconditions an agent needs (open part, active view) and gives no guidance on the positional and naming parameters, so it is not complete enough to call the tool reliably.

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

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

Schema description coverage is 0% across 6 parameters, and the description only clarifies one of them (edge_index, including its source and 0-based indexing) plus an oblique reference to 'the given body' for body_id. pos_x, pos_y, view_id, and dim_name are undocumented in both the schema and the description, leaving most of the call signature opaque.

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 RADIUS dimension') with the target geometry clarified as an edge and the geometric cases enumerated (fillets, arcs, rounds). It implies the distinction from nx_create_diameter_dimension and nx_create_dimension, but never names those siblings, so sibling differentiation is left to inference.

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 actionable prerequisite: edge_index must come from nx_list_edges on the given body, which tells the agent how to prepare the call. It says nothing about when to prefer this over nx_create_dimension or nx_create_diameter_dimension, nor whether a part must be open or a view active.

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

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

With no annotations, the description carries full burden: it discloses the target scope (current sheet), the meaning and units of position, and how value is placed. It omits whether the operation fails without an active sheet, whether it is undoable, or whether value accepts non-Ra grades — relevant for a mutation tool with zero annotation coverage.

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 lines, front-loaded with the action, then the two pieces of non-obvious information (slot semantics, coordinate frame). No filler 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?

An output schema exists, so return values needn't be explained, but for a 3-parameter creation tool with 0% schema coverage the description should also state the preconditions (active drawing sheet) and whether the symbol can be updated or only created. Adequate but with clear gaps.

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

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

Schema coverage is 0%, so the description must compensate, and it does for two of three params: value is mapped to the symbol's a1 slot with concrete examples ("1.6", "3.2"), and pos_x/pos_y are placed in sheet coordinates in mm. It doesn't mention the defaults (20, 20) or that zero params are required, leaving a small 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 ("Create a surface finish (roughness) symbol") plus the scope ("current drawing sheet"), which is clearly distinct from annotation siblings like nx_create_note or nx_create_dimension. It stops short of explicitly naming how it differs from other drawing-sheet creators such as nx_create_title_block.

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

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

The description implies usage (drawing sheet context, sheet coordinates) but never says when to choose this versus nx_create_note or the dimension tools, and gives no prerequisites such as needing an existing/active drawing sheet. Usage is inferable 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?

With no annotations, the description carries the full burden. It does disclose one non-obvious side effect — the new sketch is 'activated' — but omits prerequisites (open part required?), what happens to any previously active sketch, whether a duplicate name is rejected, and whether the operation is undoable.

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

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

A single front-loaded sentence with no filler. It is efficient, though so terse that it omits needed context rather than wasting space.

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

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

An output schema exists, so return values needn't be explained. Still, for a state-changing creation tool with zero annotations and zero schema descriptions, the description leaves out prerequisites, naming behavior, and how it fits the sketch workflow.

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

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

Schema description coverage is 0%, so the description must compensate. 'Principal datum plane' vaguely gestures at the plane parameter but doesn't explain the XY/XZ/YZ choices or the default; the 'name' parameter is never mentioned at all.

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

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

Specific verb and resource ('create and activate a sketch') with the placement target ('principal datum plane'). It is reasonably distinguishable from the nx_sketch_* drawing siblings, though it doesn't explicitly state its role as the setup step preceding 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 and no mention of alternatives or sequencing (e.g., that sketch entities are added afterwards via nx_sketch_line/nx_sketch_rectangle and closed with nx_finish_sketch). Nothing says whether an open part is required.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses coordinate semantics but not that this is a mutating operation on the sheet, whether it replaces or duplicates an existing title block, or whether it requires an active sheet — all material gaps for a no-annotation write tool.

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

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

Two short sentences, front-loaded with the action and then the coordinate guidance. No filler, and the example is the most useful payload for a caller picking numbers.

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

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

An output schema exists, so return values need no explanation, and the tool is a simple two-parameter placement. However, the absence of annotations means the description should have covered the prerequisite (an existing drawing sheet) and the mutation behavior on repeat calls; those omissions leave it only minimally complete.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it gives units (mm), the coordinate frame (sheet coordinates), and a concrete worked example (pos_x=340, pos_y=5 for A3 landscape). That is real added meaning over bare `number` defaults, though it doesn't state the origin or valid range.

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: 'Place a title block on the current drawing sheet.' That clearly separates it from siblings such as nx_create_note, nx_create_dimension and nx_create_roughness, which all add different drafting entities. It stops short of naming those siblings explicitly, so it lands at 4 rather than 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?

'on the current drawing sheet' implies the prerequisite that a sheet must already exist and be active, but the description never states that condition or what to do otherwise. There is no when-not guidance and no reference to alternatives such as nx_create_drawing_sheet. Usage is inferable, not spelled out.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait — deletions are not recoverable via nx_undo — which is valuable, but it says nothing about whether a part must be open, whether a missing id raises an error or no-ops, or whether the operation can be batched.

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 blocks: what it deletes, how to identify the target, why you'd use it. The verb and resource are front-loaded and the examples are the minimum needed to make the selector format unambiguous — 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?

An output schema exists so return values need no explanation, and the identifier semantics — the real ambiguity for a 1-param destructive tool — are fully covered. The remaining gap is operational context (open-part requirement, failure behavior on an unknown id), which an agent would want before calling a delete.

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

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

Schema coverage is 0% and the single parameter is a bare 'Annotation Id' string, so the description does all the work: it documents three accepted forms (journal id, name like "HANDLE R-5132", and "kind:index") with worked examples and the 0-based ordering tied to nx_list_dimensions / nx_list_annotations.

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

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

The first line names a specific verb (Delete) and enumerates exactly which resources qualify (note / dimension / GDT / roughness annotation). That set of resources distinguishes it cleanly from the many nx_create_* annotation siblings 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?

It states the accepted identifier forms and gives a concrete use case — cleaning up test annotations that nx_undo cannot reach — which implicitly routes routine undo work to nx_undo instead. It stops short of an explicit 'do not use this for X' exclusion or stating prerequisites such as an open part.

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

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

No annotations are provided, so the description carries the full behavioral burden for a mutating geometry operation. It discloses only the default-edge scoping; it says nothing about whether the feature is undoable, what happens when the radius is geometrically impossible for the local edge geometry, or whether it requires an active part.

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 compact sentence with the action and the scoping default front-loaded via a semicolon. Nothing is wasted, though the terseness leaves no room for the behavioral context this operation 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?

Output schema exists, so return values need not be explained, but for a no-annotation mutation tool at 0% schema coverage the description omits body sourcing, radius units, edge index origin, and failure behavior. An agent can guess the call shape but not the preconditions.

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

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

Schema description coverage is 0%, so the description must compensate. It does add real meaning for one parameter by resolving the null default of edge_indices into 'all edges', but body_id's provenance (e.g. from nx_list_bodies) and the units/validity constraints on radius remain undocumented.

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

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

States a specific verb and resource ('Create an edge blend (fillet)'), and the parenthetical maps the CAD term to the common one, which is genuinely useful. It does not explicitly distinguish itself from the nearest sibling operation, nx_chamfer, 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 'default all edges' clause implies usage: omit edge_indices to blend the whole body rather than selected edges. There is no explicit when-to-use guidance versus nx_chamfer, and no stated precondition such as needing a part open or a body listed first.

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

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

With no annotations, the description does disclose a genuinely important behavioral trait: the export follows the *current* display, and passing sheet_name mutates that display state before exporting. However, it says nothing about whether an existing file at path is overwritten, what permissions or file-extension expectations apply, or what happens on failure — significant gaps for a file-writing operation with zero annotation coverage.

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, front-loaded with the core action and followed by the one caveat that matters. No filler, no restating of the name or schema.

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

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

An output schema exists, so return values need no explanation here. Combined with the useful sheet_name semantics and the sibling pointer, the definition covers most of what an agent needs; only the 'path' destination behavior is left entirely to inference.

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

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

Schema description coverage is 0% for both parameters. The description adds real meaning for sheet_name (it activates that sheet before export, not a passive filter), but 'path' is never explained — no hint about destination semantics, extension, or overwrite behavior despite being the only required parameter.

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

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

States a specific verb and resource ('Export the current drawing display to a PDF file') and implicitly distinguishes itself from the format-specific sibling nx_export_step. An agent can tell immediately what the tool produces and from what source scope (the current display, not the whole model).

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 tells the agent to pass sheet_name to display a particular sheet first, and points to nx_list_drawing_sheets to discover valid names — a real routing instruction. It stops short of stating when NOT to use this tool (e.g., STEP export via nx_export_step) or prerequisites for export.

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

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

With no annotations provided, the description carries the full burden. It discloses the main behavioral outcome—a STEP export of the active part into a workspace—but does not mention potential side effects like file overwriting, naming behavior, or failure if no part is active. 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?

The description is a single, front-loaded sentence with no filler. Every word adds meaning: the action, the subject, the format, and the destination are all stated directly.

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?

Although the tool is simple and has an output schema, the description still leaves the required 'path' parameter semantically ambiguous. An agent cannot reliably construct a correct call without understanding whether path is a file name, a folder, or a workspace-relative location. The missing parameter guidance is a significant gap.

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

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

Schema description coverage is 0%, and the description does not explain the required 'path' parameter beyond the schema's bare title. The phrase 'inside the configured workspace' hints at where the path resolves, but it does not clarify whether path is a filename, directory, relative path, or absolute path.

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 (export), a precise resource (active work part), a format (STEP), and a destination (configured workspace). This clearly differentiates it from siblings like nx_save_part or nx_release because it identifies the exact action and output type.

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

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

No guidance is given about when to use this tool versus alternatives such as nx_save_part or nx_release. The description implies an export workflow but does not state prerequisites, exclusions, or conditions where a different tool should be chosen.

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

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

No annotations are provided, so the description carries the full behavioral burden. It reveals that the tool mutates the model by creating or subtracting material, but it does not explain requirements for subtract mode, what happens when target_body_id is missing, whether operations are undoable, or what constraints apply to distance and reverse.

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

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

The description is a single front-loaded sentence with no wasted words, and it efficiently states the core action and two outcomes. It is concise, though its brevity contributes to the missing guidance and parameter semantics.

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

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

This is a modeling mutation with six parameters, no schema descriptions, no annotations, and conditional behavior for subtract mode. Although an output schema exists, the description is not complete enough for an agent to safely infer prerequisites, parameter effects, or failure conditions.

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

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

Schema description coverage is 0% across six parameters, so the description must compensate and largely fails to do so. It only alludes to the sketch, distance-based extrusion, and target body; it says nothing about reverse, start_offset, or the conditional relationship between operation='subtract' and target_body_id.

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

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

The description uses a clear verb ('Extrude') and resource ('a sketch') and distinguishes the two outcomes: creating a new body or subtracting from an existing target body. It does not mention the sibling nx_revolve or other modeling operations, but the core 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?

It states that extrusion can create a body or subtract from a target, but it gives no explicit conditions for choosing between those modes, no prerequisites such as requiring a finished sketch, and no comparison to alternative tools like nx_revolve. The implied usage is present but not actionable guidance.

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

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

With no annotations, the description carries the full burden, yet only says the sketch is "deactivated and finished." It does not state whether the sketch geometry is preserved or discarded, whether the sketch can be reopened later, whether it must currently be active, or whether calling it twice is safe — all key traits for a state-changing 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 short sentence, front-loaded and free of padding, but its brevity tips into under-specification rather than efficiency. Nothing is wasted, but very little is delivered.

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 presence of an output schema means return values need not be explained, but for a mutation tool with no annotations and an undocumented parameter, the description omits the state-transition and precondition details an agent needs 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 0% for the single required sketch_id, and the description adds nothing about whether it is a name, index, or handle — nor how to obtain one (plausibly via nx_list_sketches). The description fails to compensate for the total lack of schema documentation.

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

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

"Deactivate and finish" gives a verb and "sketch" the resource, but the object is described as an "explicit sketch reference," which is ambiguous jargon for what is presumably a sketch_id. It is not differentiated from neighboring lifecycle tools like nx_create_sketch, nx_list_sketches, or nx_release, so the agent must infer where this fits.

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 statement of when to call this — e.g., after nx_sketch_line/nx_sketch_rectangle to close out the profile before nx_extrude — and no mention of the alternative lifecycle operations (nx_create_sketch, nx_release). Usage must be inferred entirely from the tool 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?

No annotations are provided, so the description carries full behavioral burden. It states that the tool operates on the active modeling view, implying a non-destructive camera/view change, but it does not explicitly confirm that the model geometry is unaffected or describe any side effects.

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

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

The description is a single, front-loaded sentence with no filler or redundant wording. Every word contributes to understanding the tool's 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 zero-parameter view command with an output schema present, the description is nearly complete. It lacks only explicit behavioral guarantees like 'does not modify the model' or usage notes, but these are minor for such a straightforward tool.

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

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

The tool has zero parameters, so there is no parameter information to convey. The schema coverage is 100% trivially, and the baseline for zero-parameter tools is 4; the description cannot add meaningful parameter semantics beyond the schema.

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

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

The description uses a specific verb ('Fit') and resource ('active modeling view'), making the tool's function immediately clear. It is also implicitly distinguishable from all sibling tools, none of which target view fitting, so no ambiguity exists.

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

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

The description implies when to use the tool: when the user wants to fit the active modeling view. However, it does not explicitly state any conditions, exclusions, or alternatives, relying entirely on the operation name and conventional CAD knowledge.

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

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

With no annotations, the description carries the full disclosure burden. Saying it performs a 'boolean subtract' hints that the target body is mutated in place and that a sketch feature is created as a side effect, but nothing states whether the cut is blind or through, whether the operation is reversible, or what conditions cause failure.

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

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

A single front-loaded sentence with no filler, and the parenthetical mechanism is genuinely informative. It is on the edge of under-specification rather than being verbose, so it is efficient but a little thin for a mutating geometry operation.

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

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

An output schema exists, so return values need not be explained, but with no annotations, 0% parameter coverage, and an unexplained optional start_offset, the description leaves too much unstated for a five-parameter body-mutating modeling tool that competes with two specialized hole siblings.

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

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

Schema description coverage is 0% across five parameters, and the description supplies no meaning for body_id, center, diameter, depth, or the optional start_offset. Only a weak inference is possible — center/diameter define the sketch circle, depth the cut — and start_offset is entirely unexplained.

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

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

States a specific verb and resource ('Create a hole on a target body') and adds the mechanism (circle sketch + boolean subtract), which confirms the result is a plain cylindrical cut. It does not explicitly distinguish itself from the sibling tools nx_counterbore_hole and nx_countersink_hole, so an agent must infer the contrast.

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

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

No guidance on when to use this versus nx_counterbore_hole or nx_countersink_hole, and no stated prerequisites such as requiring an existing body from nx_create_part or a prior nx_extrude. The agent gets the what but not the when.

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

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

With no annotations present, the description carries the full burden and does real work: it clarifies that count is inclusive of the original, that spacing is a per-instance delta in mm, and that the original body is retained while new instances are separate, non-united bodies. Missing is any statement about required part/body state, error conditions, or whether the operation is undoable.

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 verb-and-resource sentence followed by two tight clarifications, with the most surprising behavior (instances are not united) surfaced rather than buried. The backticked parameter names read slightly documentation-flavored but no sentence is wasted.

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

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

An output schema exists, so return values need not be explained, and the core semantic ambiguities around count/spacing/merging are resolved. However, for a five-parameter mutation tool with zero annotation coverage, the absence of any prerequisite or safety context (open part, how to obtain body_id via nx_list_bodies, undo availability) leaves real gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does well for two parameters, disambiguating count (total including original, count=4 → 4 bodies) and spacing (per-instance delta in mm). It says nothing about body_id, direction, or the reverse flag, leaving three of five parameters to bare type/enum hints.

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 (pattern), resource (a body), and the qualifying mode (linearly along X/Y/Z). The word 'linearly' paired with the sibling names nx_circular_pattern and nx_mirror lets an agent place this tool precisely in the feature family without reading 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 a clear conditional rule: instances are independent bodies, so use nx_unite if merging is required. That names a real sibling and the condition that selects it. It stops short of an explicit 'when not to use' (e.g. versus nx_circular_pattern or nx_mirror) or prerequisite state such as an open part and a valid body_id.

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

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

No annotations are supplied, so the description carries the full burden: 'Read' signals a safe non-mutating operation, and the pipe-delimited format block discloses the exact shape of each returned entry per annotation kind, which is real behavioral value. It stops short of stating prerequisites such as requiring an open part or drawing sheet, and says nothing about what happens when no annotations exist.

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 one-sentence purpose, then a compact format reference, then the pairing advice. The monospace format lines are dense and information-bearing rather than filler; nothing could be removed without losing specification detail.

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

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

An output schema exists, so the return-value explanation is optional reinforcement rather than a necessity, and the description is complete for a zero-parameter read tool. The one gap is operational context: it never states that a drawing must already exist or be open, which matters given the many part/drawing creation siblings.

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 to disambiguate and the baseline applies. The description correctly adds no parameter prose, though it also does not explain what is implicitly scoped (e.g. which drawing is read).

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 leads with a specific verb and resource ('Read the non-dimension annotations of a drawing') and enumerates exactly which annotation types are covered: notes, GD&T, roughness. It explicitly carves out the boundary against nx_list_dimensions, so an agent can distinguish it from that sibling 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?

It gives a clear usage condition: pair it with nx_list_dimensions to fully understand an existing NX 2D process drawing. The complement-sibling relationship is explicit, but there are no stated exclusions or prerequisites (e.g. whether a drawing sheet must be active), which keeps it 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?

With no annotations, the description carries the full burden; "read back" correctly signals a non-mutating read, which is the key safety signal. However, it says nothing about behavior when no part is open or when no attributes exist (empty list vs error), so edge-case transparency is missing.

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

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

A single front-loaded sentence with no filler, and the disambiguating parenthetical is placed where it earns its space. It is minimal 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?

For a zero-parameter read tool with an output schema describing the return values, the description is close to complete. The only shortfall is the unstated precondition that a part must be open/session active.

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 beyond the implicit 'which part' scoping, which the phrase "set on the part" already conveys adequately.

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

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

States a specific verb+resource combination ("Read back all user attributes set on the part") and the parenthetical "(title-block content)" disambiguates it from the similarly named nx_list_annotations and nx_list_dimensions siblings. It is clear what it returns, though it never explicitly names the sibling it is not.

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 statement of when to use this versus nx_list_annotations or nx_list_dimensions, and no precondition such as requiring an open part. Usage is only inferable from the tool's name and the word "Read back".

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

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

With no annotations, the description carries the full behavioral burden. 'List' implies a read-only operation, but nothing is said about what happens when no part is open, whether it errors or returns empty, or whether hidden/suppressed bodies are included.

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. It is appropriately short for a zero-argument listing call, though it is so brief that it omits useful qualifiers rather than being trim.

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

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

An output schema exists, so return values need not be explained. However, for a tool whose only real failure mode is 'no active part', the description should say so; that prerequisite is left unstated.

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. The only semantic content is the implicit scope of 'active work part', which is stated.

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

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

States a specific verb ('List') and resource ('bodies') scoped to 'the active work part'. That scope phrase distinguishes it from sibling listing tools like nx_list_sketches and nx_list_features, though the wording is terse.

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 indication of when to use this versus other list tools, and no stated preconditions. The critical condition — that a part must already be open/active — is implied only by 'active work part' and never spelled out.

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

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

With no annotations, the description still communicates the essential behavior: this is a read-back operation, values are recovered from the model, and results are returned one entry per dimension in a stated format. It does not explicitly state absence of side effects or permission requirements, but for a zero-parameter listing tool the disclosed behavior is strong.

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

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

The purpose is front-loaded in the first sentence, followed by the return format and concrete usage examples. The format string earns its place by telling the agent exactly how entries are shaped, and there is no unnecessary filler.

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

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

Given zero input parameters, an output schema, and low mutation risk, the description is complete enough to invoke the tool correctly. It covers purpose, usage context, data source, and return format without needing to duplicate the output schema.

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

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

The tool has zero input parameters, so the baseline is 4. There are no parameters for the description to clarify, and the schema is empty.

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

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

The description uses a specific verb and resource: 'Read back every dimension in the part,' and explicitly states the returned content is measured size and tolerance. This clearly distinguishes it from creation tools such as nx_create_dimension and from sibling list tools like nx_list_annotations.

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 contexts: verify dimensions just created, or read an existing NX 2D drawing to understand its specifications without opening the UI. It does not explicitly say when not to use it or name an alternative sibling, 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?

No annotations are provided, so the description carries the full burden. The verb 'List' implies a safe read operation, and the 'current drawing sheet' scope is useful context, but it does not explicitly state non-destructiveness, error behavior when no drawing sheet is active, or whether hidden views are included.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action and scope immediately, which is appropriate for a simple zero-parameter listing tool.

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

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

Given the tool's simplicity, zero parameters, and presence of an output schema, the description is nearly complete. It identifies the active drawing sheet as the scope, though it could explicitly state that a drawing sheet must be active before invocation.

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

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

The tool has zero parameters, so there is no parameter semantics to explain. Baseline is 4 because the empty schema is self-contained and the description does not need to compensate for missing parameter documentation.

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

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

The description gives a specific verb and resource: list drafting views. It also scopes the operation to the current drawing sheet, which helps distinguish it from sheet-listing and view-modification siblings, 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?

Usage is only implied by the phrase 'on the current drawing sheet.' The description does not state when to use this instead of nx_list_drawing_sheets, nx_update_views, or other listing tools, nor does it mention prerequisites such as an active drawing sheet.

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

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

No annotations are provided, so the description must carry the behavioral burden. Saying 'list' implies a read-only, non-destructive operation and 'active part' implies a prerequisite context, but the description does not explicitly state this or mention what happens if no active part exists. For a zero-parameter read tool with an output schema, this is adequate but not rich.

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

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

The description is a single, efficient sentence with no wasted words. The core information (action, resource, scope) is front-loaded and immediately readable.

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

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

An output schema exists, so the description need not explain return values. For a zero-parameter listing tool, stating the resource and active-part scope is nearly sufficient; the main missing piece is explicit prerequisite handling (e.g., what happens when no part is active).

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

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

The tool has zero parameters, so there are no parameters to document. The description correctly does not invent or misdescribe any parameter semantics, matching the baseline for a parameterless tool.

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

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

The description states a specific verb (list) and resource (drawing sheets) with scope (active part). It is clear what the tool does, though it does not explicitly distinguish itself from the sibling nx_list_drafting_views or other list tools.

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

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

The description implies usage by naming the active part as the context, but it provides no explicit when-to-use guidance or alternative tools. An agent can infer this is a read-only listing tool, but must decide independently when to prefer it over nx_list_drafting_views.

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

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

With no annotations provided, the description carries the safety burden and explicitly states 'Read-only' and 'Inspect every edge', making it clear this is non-mutating and comprehensive. It does not discuss errors or edge cases, but for a read-only inspection tool the disclosure is strong.

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

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

A single sentence front-loads the action and resource, then efficiently lists the returned fields. Every word earns its place and there is no filler.

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

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

Given the simple one-parameter input and existing output schema, the description covers purpose, scope, and safety sufficiently. It is only missing explicit guidance about sibling tools, but that deficit is already accounted for in the usage-guidelines dimension.

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 only parameter, body_id, is largely self-explanatory, and the description reinforces that it refers to the body being inspected. With 0% schema description coverage, however, the description does not add details about the expected ID format or how to obtain 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?

The description states a specific verb ('Inspect every edge') and a clear resource ('a body'), and enumerates the exact data returned. It naturally differentiates from siblings like nx_list_faces and nx_list_bodies by focusing specifically on edges.

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

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

The intended use is implied: call this when you need detailed edge geometry and topology of a body. However, it does not explicitly say when to prefer this over nx_list_faces or nx_list_bodies, nor does it mention prerequisites such as the body already being loaded.

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

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

With no annotations, the description carries safety disclosure and explicitly adds 'Read-only', which is meaningful for an inspection tool. It also discloses a non-obvious output nuance: normal is reported only for planar faces. It does not cover invalid body_id or empty-body behavior, but this is a minor gap for a read-only listing 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?

Single purpose-built sentence, front-loaded with the verb and resource, followed by a bullet-like list of returned fields and the read-only flag. 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?

The output schema covers return value structure, and the description enumerates the returned face attributes, so an agent can predict the call's behavior. It omits prerequisites such as needing an open part or a valid body_id from nx_list_bodies, but the omission is unlikely to cause incorrect invocation.

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

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

The only parameter is `body_id`, and although the schema gives no description, the phrase 'of a body' ties the parameter directly to the resource being inspected. For a single self-descriptive identifier this is sufficient compensation for the 0% schema coverage.

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

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

States a specific action ('Inspect'), a clear resource ('every face of a body'), and enumerates the exact data returned. This makes it immediately distinguishable from siblings such as nx_list_edges, nx_list_bodies, and nx_list_features.

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 makes the intended use obvious (face inspection) but does not explicitly state when to prefer it over alternatives or mention that edge/body/sketch listing has separate tools. The when-to-use is implied by scope, not stated as guidance.

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

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

No annotations are provided, so the description must carry the behavioral load. 'List' implies a non-destructive read and the phrase 'active work part' hints at a prerequisite state, but there is no disclosure of ordering, pagination, or what qualifies as a 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 front-loaded sentence with no filler. It is efficient, though the extreme brevity leaves little room for the context an agent might want.

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 parameterless read with an output schema, so return values need not be explained. The state prerequisite ('active work part') is at least implied, making the description sufficient for correct invocation, though a note on ordering or scope would round it out.

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; the schema is empty and fully covered. Baseline 4 applies for a parameterless tool.

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

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

The description names a specific verb (List) and resource (features) plus a scope (the active work part), which separates it from siblings like nx_list_sketches or nx_list_bodies. It stops short of explicitly stating how 'features' relates to those other entity lists, so the differentiation relies partly on the tool name.

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

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

The phrase 'in the active work part' implies a part must already be open, but there is no explicit when-to-use guidance, no exclusions, and no pointer to alternatives such as nx_list_sketches for sketch geometry. Usage is inferred 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?

No annotations are provided, so the description carries the full burden. 'List' implies a safe read and 'active work part' implies scoping to the open part, but it never says what happens with no active part, whether results are flat or nested, or whether the list can be empty — behavior that matters for a discovery tool on a session-scoped modeler.

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 sentence, front-loaded with the verb and resource, zero filler. For a zero-parameter list call there is no wasted 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?

The output schema covers return values and there are no parameters to document, so the description's burden is small. Still, it says nothing about the precondition of an open part or how this list relates to the sibling list_* tools, which is the remaining gap for an agent operating across a large CAD toolset.

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; the baseline of 4 applies. The mention of the 'active work part' implicitly explains the one piece of implicit context that governs the call.

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

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

States a specific verb+resource ('List sketches') and scopes it to the active work part, which distinguishes it from the mutation siblings like nx_create_sketch. It does not, however, contrast itself with the other list_* tools (list_bodies, list_features, list_edges), leaving the agent to infer the boundary from the noun alone.

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 when-to-use guidance, no prerequisite (e.g. a part must be open), and no mention of alternatives such as listing features or bodies instead. The single sentence gives no routing help at all.

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

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

With no annotations, the description carries the safety burden and does it well: it declares this is a read-only query that creates no annotation, and discloses the return contents (numeric mm distance plus two closest points). It stops short of stating error or precondition behavior for invalid edge indices.

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 with zero filler, and the core purpose is front-loaded ahead of the query/return details.

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

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

For a three-parameter read tool with an output schema, this covers purpose, read-only nature, return shape, and index provenance. Only preconditions on the target body are left implicit.

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

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

Schema coverage is 0%, so the description must compensate. It adds the critical fact that edge indices are 0-based and come from nx_list_edges, which the schema does not say, but body_id and argument ordering remain unexplained.

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

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

States a specific verb and resource: 'Measure the minimum 3D distance between two edges of a body.' No sibling tool measures distance, so an agent can identify this uniquely from the description alone.

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 frames the tool as a QUERY and explains the payoff: 'so an agent can verify geometry instead of guessing.' There is no competing measurement sibling to exclude, but it does not state prerequisites such as needing an open part or body loaded.

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

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

With no annotations, the description carries the behavioral burden and does well by disclosing that the mirrored body is independent and NOT united with the source. It still leaves some behavior implicit, such as whether the original body is preserved and what the output body identity is, though the output schema may cover return details.

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

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

The description is front-loaded with the core operation, then adds parameter meaning and the key non-union behavior. Every sentence contributes useful information 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 simple three-parameter CAD operation with an output schema, the definition covers the essential semantics and the most important side effect. A brief explicit note about body_id and source-body preservation would make it fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that plane selects XY/XZ/YZ and that offset shifts the plane along its normal in millimeters with a default of 0; body_id is only implied by 'Mirror a body' rather than explicitly defined.

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

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

The description opens with a specific verb and resource: 'Mirror a body about a datum plane.' It clearly distinguishes this operation from nx_unite by explaining that the result is independent and not merged.

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

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

It gives an explicit alternative for the common merge case: use nx_unite if the mirrored body should be joined to the source. It does not cover broader usage guidance such as prerequisites or when to choose mirroring versus other duplication-style operations.

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

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

With no annotations at all, the description carries the full behavioral burden and does not meet it: it says nothing about what happens if a part is already open, whether the previous part is closed, whether this is a session-mutating operation, or what errors occur for a missing/invalid path. Only the vague 'configured workspace' phrase hints at resolution 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?

One front-loaded sentence with zero filler — the core action and its scope lead immediately. It is terse rather than padded, though the brevity is also where its omissions come from.

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

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

An output schema exists, so return values need not be explained, but for a state-changing session operation with no annotations the description leaves out all preconditions (an active NX session), the already-open case, and path resolution rules. Given the surrounding family of CAD-operation tools that assume an open part, these gaps matter.

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 single parameter 'path' has 0% schema description coverage, so the description must compensate and largely does not. 'From the configured workspace' is a weak hint that the path may be workspace-relative, but it never states whether absolute paths are accepted, what format/extension is expected, or whether the part must already exist.

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?

Uses a specific verb ('Open') and resource ('a part') and scopes it to the configured workspace, which naturally separates it from nx_create_part, nx_save_part, and nx_close_part. It stops short of naming any sibling explicitly, so the differentiation comes from the verb alone.

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 statement of when to reach for this tool versus nx_create_part or nx_status, and no indication that opening a part is a prerequisite for the modeling siblings (extrude, hole, sketch, etc.). A reader can infer the intent, but the description supplies no explicit usage guidance or exclusions.

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

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

With no annotations, the description carries the behavioral burden. It discloses important non-obvious behavior: the C# Loader backend and named pipe remain alive, and the plugin is not unloaded or restarted with Alt+F8. It could say more about what 'task state' includes, but it adds substantial valuable context beyond the tool name.

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

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

The description is two sentences and front-loads the core action. The second sentence adds useful behavioral detail without excessive length, though it could be slightly tighter.

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

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

The tool has no parameters and has an output schema, so return-value details are not needed. The description explains the release behavior and the backend lifecycle well enough for an agent to call it correctly, though it could clarify what state is actually cleared.

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

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

The tool has zero parameters, so there is no parameter meaning to explain. The baseline for a parameterless tool is 4, and the description does not create confusion about inputs.

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

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

The description states a specific action: clearing task state and returning NX to normal interaction. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as nx_status or explain what 'task state' encompasses.

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 purpose: call it when ending a task and returning to normal interaction. However, the description does not explicitly say when to use it versus alternatives, nor does it provide exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose meaningful traits: the operation is purely additive (no unite/subtract), it requires a closed sketch section, and the axis is defined in sketch XY space. It does not state whether the source sketch is consumed/modified, what happens on failure, or whether the sketch must be currently active — significant gaps for a mutation tool with zero annotation coverage.

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 plus a parameter note, front-loaded with the core action and immediately followed by the most important constraint. No filler; the only minor redundancy is restating the axis semantics that are close to self-evident from the parameter names.

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

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

An output schema exists, so return values need not be explained, and the axis/angle semantics are covered. However, for a 5-parameter mutation tool with no annotations and 0% schema coverage, the undocumented `reverse` flag and the effect on the source sketch leave the definition short of fully self-sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It does add real meaning for axis_start/axis_end ('sketch XY coordinates defining the revolution axis') and for angle (degrees, 0 < angle <= 360), but leaves `reverse` and `sketch_id` entirely undocumented beyond their names, so roughly half the parameters remain opaque.

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

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

The description opens with a specific verb and resource ('Revolve a closed sketch section around an in-sketch 2D axis'), which is unambiguous and clearly distinct from additive operations like nx_extrude. It also scopes the result ('Creates a new solid only'), but never names a sibling tool or contrasts itself with nx_extrude where an agent might plausibly hesitate.

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 real constraint — 'Creates a new solid only (no unite/subtract)' — which tells the agent not to expect boolean behavior, implying a follow-up nx_unite would be needed. Beyond that it gives no when-to-use guidance versus nx_extrude or any prerequisite about the sketch being finished/closed.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without addressing side effects. It does not say whether the save overwrites an existing file, what happens if no part is active, or whether the operation can fail.

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

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

The description is one short, front-loaded sentence with no filler. It supplies exactly the needed information for a parameterless command and does not waste tokens.

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 tool, 'Save the active work part' is nearly complete: it names the object and the action. It falls slightly short because it does not specify behavior when no part is active or whether the save is a persistent overwrite, but the output schema can cover result details.

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

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

The input schema has zero properties, so there are no parameter semantics for the description to add. Since there are no parameters, the baseline of 4 applies and the description appropriately references the contextual 'active work part' state.

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

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

The description uses a specific verb ('Save') and identifies the exact resource ('active work part'), making the tool's core function clear. It doesn't explicitly name or contrast sibling tools like nx_close_part or nx_release, but the action of saving is distinct enough that an agent can tell it apart.

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

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

The description gives no guidance on when to invoke this tool versus alternatives such as nx_close_part or nx_release. There is no mention of prerequisites (e.g., an active part must exist) or of typical sequences like saving before closing.

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

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

With no annotations, the description carries the full burden. It does add real behavioral detail beyond the schema: typical attribute names and the note that values may contain spaces. However, it never states whether setting an existing name overwrites the previous value, whether new attributes can be created this way, or what happens if no part is open — material gaps for a mutation tool.

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

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

The core action is front-loaded in the first sentence, followed by a compact rationale and examples. Four short sentences with no filler, though the example list of Chinese names is slightly long relative to the rest.

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

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

An output schema exists, so return values need not be explained, and both parameters are named in the text. But for a two-required-parameter mutation with no annotations, the description omits overwrite semantics and preconditions, which an agent would need in order to call it safely.

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

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

Schema description coverage is 0%, so the description must compensate, and it partly does: it gives typical values for 'name' (名称 / 图号 / 材料 …) and clarifies that 'value' may contain spaces. It still doesn't say whether 'name' is free-form or must match an existing attribute, leaving the key semantic question unanswered.

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 ('Set a string attribute on the part') and then explains the downstream purpose (populating title-block cells via part attributes). That is well beyond a tautology. It does not explicitly contrast with the read counterpart nx_list_attributes, so it stops short of 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?

'This is how a title block gets its CONTENT' implies the use case (populating title-block fields) without stating when to prefer this over alternatives or what preconditions apply. There is no when-not guidance and no mention of prerequisites such as an open part or an existing title block.

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

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

With no annotations at all, the description carries the full burden. It does disclose two real behavioral traits: only a single face is removed in this version, and inward=True preserves outer dimensions. It does not disclose failure modes, required permissions, or what happens to the removed face's geometry beyond the opening.

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 operation before the qualifiers. 'First version removes a single face' is slightly awkward phrasing but carries genuinely useful scoping information, so little 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?

An output schema exists, so return values need not be described, and the core geometry semantics are covered. However, for a mutation tool with no annotations and zero schema descriptions, the definition should say more about preconditions and how to obtain the face index.

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

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

Schema description coverage is 0%, so the description must compensate. It explains inward (preserves outer dimensions) and implicitly clarifies thickness and remove_face_index through 'constant wall thickness' and 'remove one face as an opening', but leaves body_id and the source/format of the face index (presumably from nx_list_faces) unaddressed.

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 ('Shell (hollow) a body') and immediately explains the mechanism: removing one face as an opening while keeping a constant wall thickness. This is clearly distinguishable from sibling operations like nx_hole or nx_extrude.

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

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

The operation's purpose implies when it is appropriate (hollowing a solid body), but there is no explicit guidance on when to choose this over alternatives such as cutting with an extrude, nor any stated prerequisites (e.g. body must be solid, body must exist).

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

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

No annotations are provided, so the description carries the full burden. 'Add' implies a document mutation, but it says nothing about whether the sketch must be open/active, whether the operation is undoable via nx_undo, what happens with an invalid sketch_id or out-of-range angles, or any permission/state requirements.

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

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

A single front-loaded sentence with no filler; the geometry summary is placed immediately after the resource. It is efficient, though its brevity is partly the cause of the missing prerequisite details rather than a model of density.

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

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

An output schema exists, so return values need not be explained. But for a state-changing sketch operation with zero annotation coverage, 0% schema description coverage, and 5 parameters, the description omits preconditions, failure modes, and the meaning of sketch_id — significant gaps for an agent 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 0%, and the description names four of five parameters (center, radius, start/end angles) and importantly specifies that angles are in degrees, which the schema does not state. It does not explain sketch_id beyond 'explicit sketch reference', leaving one parameter undocumented in both places.

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

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

States a specific verb ('Add') and resource ('arc') scoped to a sketch, plus a parenthetical summarizing the geometry that defines it. It is distinguishable from nx_sketch_line and nx_sketch_circle by resource name, though it never explicitly contrasts itself with those siblings.

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

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

No guidance on when to use this versus nx_sketch_circle (a full circle is just an arc of 360°) or the other sketch primitives. The phrase 'explicit sketch reference' hints that a sketch must already exist, but there is no stated prerequisite about obtaining sketch_id, being in sketch-edit mode, or finishing with nx_finish_sketch.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only says geometry is added. It does not disclose that this is a mutating operation, that it requires an existing open sketch, or what coordinate frame/units the center uses. For an unannotated write tool, that is a significant 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?

A single front-loaded sentence with no filler, immediately conveying verb, resource, and required inputs. Efficient for its size, though the tightness comes at the cost of the missing behavioral detail noted elsewhere.

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

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

An output schema exists, so return values needn't be explained. However, for an unannotated mutation tool with 0% parameter description coverage, three undocumented parameters, and no output schema explanation needed, the description is too thin to fully equip an agent (no prerequisites, units, or mutation semantics).

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

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

Schema description coverage is 0%, so the schema gives only names and types. The description clarifies the roles of center and diameter and that sketch_id refers to an explicit sketch, but says nothing about units, coordinate system (sketch-local vs world), or the exclusiveMinimum constraint beyond the schema. It adds marginal 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?

States a specific verb ('Add') plus resource ('circle') and the defining parameters (center + diameter), and scoping it to an 'explicit sketch reference' makes its role clear against siblings like nx_sketch_line, nx_sketch_rectangle, and nx_sketch_arc. It doesn't explicitly name an alternative, but the geometry it creates 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?

No statement of when to use this versus the other sketch primitives, no mention of prerequisites (e.g. an open part or active sketch), and no exclusions. The phrase 'explicit sketch reference' hints that a sketch_id is required, but that is inference rather than guidance.

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

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

With no annotations, the description carries the full burden and only implies a mutation ('Add'). It does not disclose whether the sketch must be open/editable, coordinate units or frame, failure behavior, or whether the operation is reversible.

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 wasted words, but it is minimal to the point of under-specification for a 3-parameter mutation 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?

The output schema covers return values, but for a mutation tool with zero annotation coverage and zero schema parameter descriptions, the definition is missing essential calling context. An agent would have to guess at coordinate conventions and sketch-state 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 0%, so the description must compensate, but it only loosely ties 'explicit sketch reference' to sketch_id. The start/end Point2D parameters get no explanation of units, coordinate system, or whether coordinates are absolute/relative.

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 ('Add') and resource ('line') scoped to a sketch reference, which is enough to tell it apart from siblings like nx_sketch_circle or nx_sketch_rectangle. However, 'explicit sketch reference' is slightly vague and it never names the alternatives or clarifies what 'explicit' means.

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

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

There is no guidance on when to use this versus nx_sketch_rectangle, nx_sketch_circle, nx_sketch_arc, or when a sketch must already exist/finished. No prerequisites (open part, active sketch, sketch_id source) are 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?

With no annotations, the description carries the full burden. 'Add' implies mutation of sketch geometry, but nothing is said about required permissions, whether the part/sketch must be open or in edit mode, whether the operation is undoable, or what happens on invalid or degenerate corners.

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 no filler and the object of the operation is front-loaded, but it is terse to the point of omitting information an agent needs, so brevity is not fully earned.

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

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

An output schema exists so return values need not be described, but for a 3-parameter mutation tool with zero annotation coverage and no parameter documentation, the description omits the sketch/part preconditions and corner geometry semantics that determine a correct 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 description coverage is 0% and the description adds nothing: it never explains that corner1/corner2 are two diagonally opposite corners of the rectangle, nor the coordinate system or units, nor where sketch_id comes from. The parameter names alone do most of the work here.

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

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

The description states a specific verb ('Add') and resource ('rectangle') plus the target ('explicit sketch reference'), which distinguishes it from sibling geometry creators like nx_sketch_line, nx_sketch_circle and nx_sketch_arc. It stops short of naming or contrasting with those siblings explicitly, so it is clear but not maximally differentiated.

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 indication of when to choose this over nx_sketch_line/nx_sketch_arc, nor any stated prerequisite such as an active sketch from nx_create_sketch or a sketch_id from nx_list_sketches. 'Explicit sketch reference' hints that a sketch must exist but leaves the workflow 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?

No annotations are provided, so the description must carry the behavioral load. It implies a non-mutating read, but never states that it is safe/read-only, whether it requires an active bridge session, or what happens if no part is open — the single biggest behavioral question for a status call ('active-part status') goes unexplained.

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, front-loaded with the verb and enumerating exactly the three pieces of information returned. No filler, no restatement of the tool 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?

An output schema exists, so return-value detail is not the description's burden, and with zero parameters there is nothing else to document. The only gap is behavioral: no mention of session/prerequisite state or whether the call is safe to invoke at any time.

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 disambiguate; the schema is trivially complete. Baseline 4 applies since no parameter 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?

Specific verb + resource: 'Report' with three named outputs (bridge, NX version, active-part status). It is unambiguous what the tool returns and is clearly distinct from the modeling/list siblings, though it doesn't explicitly contrast itself with any of them (it doesn't need to, since none overlap).

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 'use when' statement, but the diagnostic/health-check nature is implied by 'Report ... status' and by the absence of any alternative status tool in the sibling list. An agent can infer it is the pre-flight/verification call before acting on a part, but that inference is not 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?

With no annotations, the description must carry the behavioral burden. It communicates only that an operation is reversed, but does not explain whether the undo is destructive, whether it applies only to MCP-created operations, what happens when there is nothing to undo, or what 'visible' means.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to the core meaning, making it easy to scan.

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

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

For a low-complexity, parameterless tool with an output schema, the one-liner is largely adequate. However, the undefined 'visible' qualifier and lack of any note about undo-stack behavior or edge cases leave a small but meaningful gap for correct invocation.

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

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

The input schema has zero properties and is fully covered, so there are no parameters that need documentation. The description adds nothing about parameters, but none are required; per the 0-parameter baseline, this 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 verb 'Undo' and the resource 'last visible NX MCP operation' clearly identify the action and target. It is distinguishable from the sibling tools (none of which are undo-like), though the qualifier 'visible' is not defined and weakens precision.

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 call this tool versus alternatives, nor on what conditions make an operation eligible for undo. The intent is implied by the name, but a caller receives no explicit situational context.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It earns credit for disclosing the destructive side effect — tool bodies are consumed and vanish from nx_list_bodies, so their ids become invalid — which is exactly the kind of consequence an agent needs. It does not cover failure modes (non-intersecting or non-solid bodies), permission/part-state requirements, or how nx_undo relates to the 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?

Two short sentences, verb-first, with the key scoping fact front-loaded and the consequence immediately after. Nothing is padded or restated.

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

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

An output schema exists, so return values need not be explained, and the id-lifecycle consequence is captured. For a mutating geometry operation with zero annotation coverage, however, the absence of any statement about part context, body type constraints, or failure behavior leaves the agent guessing before a destructive 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 description coverage is 0% and both parameters are bare strings/string arrays with no format hints. The prose does implicitly map 'target body' to target_body_id and 'tool bodies' to tool_body_ids, but adds no id syntax, no ordering or cardinality guidance, and does not say whether the target may also appear in the tool list.

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

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

The first sentence gives a specific verb (boolean-unite) and resource (tool bodies into a target body), which is unambiguous and clearly distinct from every sibling in the list (extrude, shell, edge_blend, etc.). It doesn't explicitly contrast itself with adjacent modelling operations, but the operation is self-defining.

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