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

No annotations are provided, so the description must carry behavioral load. It discloses matching against title, full path, or file name, case-insensitive comparison, the underlying ActivateDoc3 call, and a read-back verification step, but omits failure modes such as no match or multiple matches.

Agents need to know what a tool does to the 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 well-structured sentences with the purpose front-loaded. The implementation detail in the second sentence directly supports correct invocation and no words are 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. The description covers matching and confirmation but does not describe error behavior when no document matches or multiple documents match. Adequate but not exhaustive.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds case-insensitive matching and the accepted identifier forms, going slightly beyond the schema's 'Window title, full path, or bare file name'.

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

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

States a specific verb 'Switch' plus resource 'open document' and target state 'active one', which distinguishes it from siblings like open_model, load_part, or list_open_documents. 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?

No when-to-use guidance, no alternatives named (e.g., list_open_documents or open_model), and no prerequisites. The description explains the mechanism but not the selection context versus sibling tools.

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

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

With no annotations, the description carries full burden. It does not mention side effects, such as modifying the drawing, or requirements like having an open drawing. The phrase 'places annotation text in a drawing' implies a drawing context but is not explicit.

Agents need to know what a tool does to the 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 efficiently front-load the purpose with examples. No redundant information.

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

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

Given the nested input object with 12 parameters and an output schema, the description is adequate but thin. It does not explain the nested structure or relationship between positional parameters, though the schema fills in 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?

Schema description coverage is 100%, so the schema already documents each parameter. The description adds a high-level grouping (font size, leader, title-block fields) but no additional meaning beyond the schema.

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

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

The description clearly states it adds annotations like notes, balloons, or surface symbols, and mentions optional fields. However, it does not differentiate from sibling tools like add_note, which may cause ambiguity for an agent.

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

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

No guidance is provided on when to use this tool versus alternatives such as add_note or add_dimension. The description lacks any context about prerequisites or exclusion criteria.

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

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

No annotations are provided, so the description bears full responsibility. It fails to disclose preconditions (e.g., must have an active sketch), side effects, or error conditions. The description only states basic functionality without behavioral nuance.

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

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

The description is brief with two sentences. The first sentence states the action, the second adds context. It is appropriately sized but includes some generic text ('essential for...') that is not strictly necessary.

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

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

The description mentions adding to the current sketch but omits important context such as the need for an active sketch, or what happens if no sketch exists. With an output schema present (as indicated), return values are not needed, but preconditions are missing.

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

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

Schema description coverage is 100%, with all parameters fully described. The description adds no new semantic meaning beyond restating that the arc is defined by center, start, and end points, which aligns with the schema.

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

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

The description clearly states the verb 'add' and the resource 'arc to the current sketch', and defines the arc by center, start, and end points. It differentiates from siblings like add_line, add_circle, add_rectangle, and add_spline by specifying it creates circular arcs for curved profiles.

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

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

The description implies usage for rounded corners and curved transitions but does not explicitly state when to use versus alternatives like add_fillet or add_spline. No exclusion or when-not guidance is provided.

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

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

With no annotations, the description carries the full burden. It discloses that centerlines are non-geometric entities used for reference only, which is helpful. However, it does not describe behavioral traits like whether it modifies the existing sketch, if it requires an open sketch, or what happens on failure. The output schema exists but its content is not summarized.

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

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

The description is concise with two sentences, front-loading the action. It avoids unnecessary words, but could include a brief note about prerequisites or returned values without becoming verbose. Still, it earns a 4 for being efficient and clear.

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

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

Given the complexity of the input schema (multiple coordinate parameters) and the presence of an output schema, the description provides the core purpose and nature of the tool. However, it lacks context about the surrounding sketch environment, such as needing an active sketch or how the centerline interacts with other sketch geometry. This gap prevents a higher score.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it does not explain how parameters like coordinates or the construction flag affect the centerline. The schema already describes each field adequately.

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

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

The description clearly states 'Add a centerline to the current sketch' with a specific verb and resource. It also explains that centerlines are construction/reference lines for symmetrical features or revolution axes, distinguishing it from regular lines (add_line) and other sketch entities.

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

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

The description mentions usage as a centerline for symmetrical features and revolution axes, providing some context. However, it does not explicitly say when to use this tool versus alternatives like add_line or add_sketch_constraint, nor does it mention prerequisites (e.g., an active 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. It mentions adapter-support variability and the empty edge_names fallback, but omits that this mutates the model, requires an active document/selection, and how failures are handled; the detailed selection behavior lives only in the schema.

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

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

The purpose is front-loaded in the first sentence, and the whole description is two short paragraphs. The sentence 'Chamfers the specified named edges with the given distance' is largely redundant with the opening sentence, preventing a 5.

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

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

An output schema exists, so return values need not be explained, and the input schema exhaustively covers edge selection mechanics. The description gives enough to identify the operation, though it could mention the fillet alternative; given the schema richness, 4 is appropriate.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the SolidWorks edge-name convention and empty-edge_names behavior already documented in rich detail by the schema, adding no new parameter semantics.

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

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

States a specific verb and resource: 'Add an equal-distance chamfer to selected edges of the current model.' It does not name or distinguish the obvious sibling add_fillet, 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?

There is no guidance on when to choose chamfer over add_fillet, nor any when-not-to-use condition. Only parameter-level advice ('leave edge_names empty to chamfer all edges') is given, which does not address tool selection.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action, but does not reveal any consequences, required sketch state, or error conditions.

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

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

Single sentence, front-loaded with action and resource. Every word earns its place; no redundancy.

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

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

For a simple circle creation tool with an output schema, the description is largely sufficient. It could mention coordinate system or units, but the schema already provides mm units.

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

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

Schema description coverage is 100% with detailed parameter descriptions in the input schema. The tool description adds no additional parameter semantics, so baseline score of 3 is appropriate.

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

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

Description clearly states the tool adds a circle to the current sketch, with specific verb and resource. It distinguishes from sibling tools such as add_rectangle or add_line.

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

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

No guidance on when to use this tool versus alternatives (e.g., add_ellipse, add_arc). No mention of prerequisites like needing an active sketch or when not to use.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Add' implies a mutation on a drawing, but the description does not disclose permission requirements, duplicate-label behavior, reversibility, or error conditions.

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

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

A single front-loaded sentence with no filler, clearly identifying the action, symbol type, label example, and drawing 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?

The presence of a complete schema and output schema means parameters and return values need less explanation. However, for a mutation tool with no annotations, the description is still thin on operational context and when-to-use guidance.

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

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

Schema description coverage is 100%, so the nested input fields are already well documented. The description reinforces the datum letter and drawing-edge placement but adds no syntax or format detail beyond the schema.

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

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

The description gives a clear verb+resource: 'Add a datum feature symbol' on a drawing edge. It conveys the specific drawing-annotation purpose and label format, but it does not explicitly distinguish itself from nearby siblings such as add_gtol or add_note.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 placement context ('on a drawing edge'), but provides no guidance on when to use this tool versus related drawing annotation tools, no prerequisites, and no exclusions.

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

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

No annotations provided; description mentions 'current drawing' but fails to disclose prerequisites (e.g., active drawing view), side effects, or whether it can overwrite existing dimensions. Adequate but lacks depth.

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

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

Three efficient sentences with no fluff. Action verb first, examples immediately, purpose in last sentence. Front-loaded and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 value explanation is unnecessary. Description covers purpose and types, but lacks prerequisites (e.g., active drawing view needed) and coordinate system context. Minor 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?

Input schema has 100% coverage with descriptions for all parameters. The description adds no new semantic value beyond listing dimension types, which are already in the schema. Baseline score applies.

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

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

The description clearly states 'Add a dimension to the current drawing' with specific verb and resource, and lists types (linear, radial, angular, diameter), distinguishing it from sibling tools like auto_dimension_view or add_annotation.

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

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

The description implies usage for adding dimensions to drawings but does not explicitly state when to use versus alternatives (e.g., auto_dimension_view for automated placement, set_dimension for modifying existing). No exclusions or context provided.

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

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

No annotations provided, so description carries burden. It mentions supported configurations but lacks details on operation behavior (e.g., prerequisites for update/remove) or return values. Adds some context but not exhaustive.

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

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

Two sentences, front-loaded with main purpose, then supporting details. No wasted words.

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

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

Tool handles three operations with many parameters and has output schema, but description omits details on operation parameter, valid values, or how to identify views for update/remove. Somewhat incomplete given complexity.

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

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

Schema coverage is 100%, so baseline 3. Description lists key parameter groups but adds no meaning beyond schema. Does not explain relationships or constraints.

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

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

The description clearly states the tool adds, updates, or removes drawing views, specifying the verb and resource. It distinguishes from siblings like create_section_view by covering general view management.

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

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

No guidance on when to use this tool versus alternatives like create_drawing_view or create_section_view. The description only states what it does, not use cases 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?

No annotations exist, so description carries full burden. It discloses the action (add to current sketch) but omits details like error handling, return value, or behavior when sketch is not active. 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?

Three sentences: action, entity description, use cases. Front-loaded with purpose, no wasted words. Each sentence adds value.

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

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

With output schema present but not described, and no parameter details, the description is adequate for a simple tool but lacks return format and input structure. Could be more 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 provides vague description for input_data. Description adds meaning by mentioning center and axes, but does not explain how to structure the input object. Partially compensates for schema weakness.

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

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

The description clearly states the verb 'Add' and resource 'ellipse', specifying it creates an elliptical entity with center and axes. It distinguishes from sibling sketch tools like add_circle by naming ellipse-specific attributes.

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

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

The description implies usage for oval shapes but lacks explicit when-to-use guidance, prerequisites (e.g., active sketch), or exclusions compared to other sketch tools. No mention of alternatives or conditions.

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

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

No annotations are provided, so the description carries the full burden. It does add useful behavior context — the adapter-capability caveat and the fallback to filleting all edges — but it never states that this mutates the model irreversibly, whether it requires an open document, or how failure surfaces.

Agents need to know what a tool does to the 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 paragraphs, front-loaded with the operation and followed by the edge-naming note; nothing is padding. The sentence about leaving edge_names empty is somewhat redundant with the far more detailed schema 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?

With an output schema present and full schema-level parameter documentation, the description supplies enough to call the tool correctly. The main remaining gap is mutation/reversibility semantics, which matter for an unannotated modeling operation.

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

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

Schema description coverage is 100% and the nested edge_names field already documents naming conventions, coordinate hints, and face selection in detail. The description's mention of the 'Edge<1>' convention and the empty-list case repeats what the schema already provides, so baseline 3 applies.

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

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

States a specific verb and resource (add a fillet to selected edges of the current model) plus what a fillet is for clarity. It does not differentiate itself from the sibling add_chamfer, which is the natural competing operation, so an agent must infer the distinction.

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

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

It says edge_names may be left empty to fillet all edges 'if the adapter supports it', which is conditional usage context, but there is no guidance on when to choose this tool over add_chamfer or when filleting is inappropriate. The rich selection-strategy guidance (face: vs coordinate vs live selection) lives in the schema rather than the description.

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

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

No annotations are provided, so the description must bear the full burden of behavioral disclosure. It states that a line is added but does not mention side effects, prerequisites (e.g., an active sketch), or important flags like 'construction' from the input schema.

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

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

The description is concise with two front-loaded sentences. It efficiently conveys the core purpose without unnecessary elaboration.

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

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

The description is adequate for a simple tool, given that an output schema exists and the input schema is detailed. However, it could be improved by mentioning that the line is added to the active sketch and clarifying the effect on sketch state.

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

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

Schema description coverage is 100%, so the schema itself documents the parameters adequately. The description adds no additional meaning beyond what the schema provides, meeting baseline expectations.

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

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

The description clearly states the tool adds a line to the current sketch and describes it as a line segment between two points. It distinguishes from siblings like add_circle or add_rectangle by specifying 'line' but does not explicitly differentiate from other sketch 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 lacks any guidance on when to use this tool versus alternatives such as add_arc or add_spline. No prerequisites or contextual exclusions are provided.

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

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

With no annotations, the description carries the full burden, and it discloses a genuinely important limitation: entities are selected by feature name, so only reference planes/axes can be mated and specific faces/edges cannot be enumerated by this adapter. That pre-empts a likely failure mode. It omits what happens on failure or any permission/rebuild side effects, so not a 5.

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

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

Three short paragraphs, front-loaded with the core action, then mate-type semantics, then the entity-selection caveat. No sentence is wasted and the most important constraint sits in its own paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, and the description covers the key invocation constraint (entity naming). For a mutation tool with zero annotations it could say more about defaults or failure behavior, but it is complete enough to call the tool correctly.

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

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

Schema description coverage is 100% and every field carries its own description plus defaults, so the schema already does the heavy lifting. The description adds conceptual meaning for coincident/concentric/distance but no syntax or value guidance beyond the schema, so baseline 3 applies.

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

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

Opens with a specific verb+resource and scope ('Mate two components in the active assembly'), then enumerates the positioning behaviors (coincident, concentric, distance). An agent can distinguish this from sibling generators like generate_vba_assembly_mates without opening any schema.

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

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

Explains the conditions for the mate types (stack/align planes, line up axes, hold a gap) and gives a clear constraint on which entities are selectable. It stops short of naming a sibling alternative or stating explicit when-not-to-use guidance, but the context is clear.

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

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

With no annotations, the description must disclose behaviors but only says 'Add a note'. It does not mention prerequisites like an active drawing, idempotency, or side effects. The phrase 'current drawing' is present but not explained.

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

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

Description is two sentences with front-loaded action. It efficiently covers core purpose and types of notes, though 'note or annotation' is slightly redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 existence of an output schema and full parameter descriptions, the description is adequate but lacks details on leader attachment behavior or positioning context. It is complete enough for basic understanding but not comprehensive.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter-level detail beyond what the schema already provides, so it meets but does not exceed expectations.

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

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

The description clearly states it adds a note or annotation to the current drawing and lists use cases like text annotations and callouts. However, it does not differentiate from sibling tool 'add_annotation', which may overlap in functionality.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives like 'add_annotation' or 'add_dimension'. It only implies general use for technical documentation, leaving the agent without clear selection criteria.

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

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

No annotations are provided, so the description carries the full burden. It mentions the creation of a regular polygon with sides, center, and radius but does not disclose prerequisites (e.g., active sketch), error conditions, or side effects (e.g., overlapping geometry). The generic input schema 'input_data' leaves critical behavioral details unspecified.

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

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

The description is concise with three short sentences. The first sentence immediately states the core action, making it front-loaded. No unnecessary words or verbose explanations are present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 adds a sketch entity, essential context is missing: the need for an active sketch, coordinate system for center point, and any constraints or behavior when the polygon is placed. The output schema exists but is not described, and the return value is not mentioned. The description leaves significant gaps for proper tool 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 one generic parameter 'input_data' with a vague description. The tool description partially compensates by naming 'number of sides, center point, and circumscribed radius,' but it does not specify the exact structure, types, or key names expected. With schema description coverage effectively very low, the description inadequately defines the parameter semantics.

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

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

The description clearly states the verb and resource: 'Add a regular polygon to the current sketch.' It distinguishes from sibling tools like add_line or add_circle by specifying polygon creation. The added examples (hexagonal nuts, octagonal features) reinforce the tool's purpose.

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

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

The description implies use when a regular polygon is needed but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites like having an active sketch. No exclusions or conditional contexts are given.

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

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

Describes that four line segments are automatically generated, forming a closed rectangle suitable for extrusion. However, lacks details about sketch activation requirements or error conditions. No annotations provided, so description carries burden but offers some useful behavioral context.

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

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

Two concise paragraphs with key information front-loaded. 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?

Lacks explicit mention of sketch activation requirement. Output schema exists, so return value documentation is not needed, but parameter aliases could be better explained.

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

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

Schema coverage is 100%, so baseline is 3. Description adds little beyond schema; does not clarify the alias parameter groups (x1,y1 vs corner1_x,corner1_y) or when to use each.

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

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

The description clearly states the tool adds a rectangle to the current sketch, specifying it creates a closed profile from two opposite corner points. It distinguishes from sibling sketch tools like add_line or add_circle.

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

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

No guidance on when to use this tool over alternatives like add_polygon or add_centerline. No prerequisites or exclusions mentioned.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only states the function without noting potential failures, prerequisites (e.g., active sketch), or whether it modifies existing constraints. This is insufficient for a mutation tool.

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

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

Two concise sentences with no redundancy. The first sentence immediately states the core purpose, followed by examples and context. Every sentence adds value.

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

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

The description does not explain return values (though output schema exists), prerequisites (e.g., active sketch), or error conditions. For a geometric constraint tool in a CAD context, more context is expected for safe usage.

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

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

Schema coverage is 100%, already documenting all parameters. The description adds no new semantic details beyond listing relation types, which the schema already includes. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool adds geometric constraints/relations between sketch entities, with specific examples (parallel, perpendicular, etc.). It distinguishes from sibling tools like add_sketch_dimension and sketch creation tools by focusing on constraints.

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

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

The description mentions it is essential for fully defined parametric sketches, which implies when to use. However, it does not explicitly state when not to use or mention alternatives, such as add_sketch_dimension for dimensions.

Agents often have multiple tools that could apply. Explicit usage 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 details the non-interactive behavior, suppression of sketch-input preferences, and use of dedicated APIs for circles/arcs. This provides significant insight beyond just 'add dimension'.

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

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

The description is three paragraphs; the first is direct, the second adds motivational context, and the third explains technical behavior. Each paragraph adds value, though the second is somewhat generic. Overall efficient and front-loaded.

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

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

Given the presence of an output schema (context indicates true) and the tool's complexity, the description adequately covers the core behavior and non-interactive nature. It could mention prerequisites (e.g., active sketch) but is sufficient for an AI agent.

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

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

Schema coverage is 100% with descriptions for all parameters. The description does not add independent parameter meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool adds dimensions to sketch entities, creating dimensional constraints for precise parametric designs. It distinguishes from sibling tools like get_dimension, set_dimension, and add_dimension (drawing-dimension).

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

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

The description explains that the tool is non-interactive in automation by suppressing the Modify dialog, implying it should be used in automated workflows. However, it does not explicitly state when not to use it or list alternatives.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions the spline 'passes through or near' control points but does not state prerequisites (e.g., active sketch), side effects (e.g., sketch modification), or whether the operation is destructive. This is insufficient transparency.

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

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

The description is two sentences: a clear first sentence stating the action, and a second sentence providing use-case context. No redundant or irrelevant information.

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

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

Given the tool's complexity (nested objects, one parameter) and the presence of an output schema, the description covers purpose and usage adequately. It implicitly requires a current sketch but does not explicitly state prerequisites. Overall, reasonable completeness.

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

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

Schema coverage is 100% with a description for the 'points' parameter. The tool's description adds that the spline 'passes through or near' the points, which provides additional behavioral meaning beyond the schema's 'List of spline control points with x, y coordinates.' Baseline 3 is appropriate with minor improvement.

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

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

The description clearly states 'Add a spline curve to the current sketch' with a specific verb and resource. It distinguishes splines from other sketch tools (e.g., add_line, add_circle) by highlighting free-form curves for organic shapes, which is unique among siblings.

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

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

The description provides clear context by stating splines are 'ideal for creating organic shapes, complex profiles, and smooth transitions.' However, it lacks explicit when-not-to-use guidance or direct comparison with alternative tools like add_line or add_arc.

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

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

No annotations provided, and the description fails to disclose behavioral traits such as whether the tool reads or modifies data, or what impact it has on the drawing state.

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

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

Single sentence, no fluff, but could be slightly more structured. Adequately concise.

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

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

Missing critical context such as whether a drawing must be open, what the output contains, or how to interpret results. The presence of an output schema is noted but not described.

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

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

The description adds no extra meaning beyond the input schema, which covers all parameters. Baseline 3 is appropriate since schema coverage is 100%.

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

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

The description clearly states the tool's purpose with a specific verb 'analyze' and resource 'drawing annotations and notes quality'. It distinguishes from sibling tools like 'analyze_drawing_comprehensive' by focusing on annotations specifically.

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

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

No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or when not to use it.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as read/write nature, side effects, authentication needs, or performance impact. The analysis likely reads data, but this is not confirmed.

Agents need to know what a tool does to the 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 vague sentence that does not earn its place; it adds no information beyond the name. True conciseness should provide meaningful insight in minimal words.

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

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

Given the complex nested input schema and the large set of sibling analysis tools, the description is severely incomplete. It lacks details on output, use cases, and differentiation from similar tools.

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

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

Schema description coverage is 100% (all parameters have descriptions in the schema). The tool description adds no value beyond the schema, but per the rubric the baseline is 3 when coverage is high.

Input schemas describe structure but not intent. Descriptions should explain 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 'Handle analyze drawing comprehensive' is a vague restatement of the tool name. It does not specify a concrete verb or resource, and fails to differentiate from sibling tools like analyze_drawing_dimensions or generate_drawing_report.

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

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

No guidance on when to use this tool versus the many similar sibling tools (e.g., analyze_drawing_views, check_drawing_standards). The description does not mention prerequisites, context, or exclusion criteria.

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

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

With no annotations, the description must disclose behavioral traits. It indicates the tool performs analysis (likely read-only) but does not explicitly state whether it modifies anything, requires an open drawing, or has side effects.

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

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

The description is two sentences, front-loaded with the core action, and every word adds value. No redundancy or filler.

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

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

Given the presence of an output schema, the description does not need to explain return values. However, it omits prerequisites (e.g., drawing must be open) and does not indicate if the tool is safe/read-only, which is important for a file-based tool with no annotations.

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

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

The input schema has 100% description coverage, with each parameter already well-documented (e.g., check_precision: 'Check dimension precision consistency'). The description adds no further semantic value beyond restating the same concepts.

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

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

The description clearly specifies the action ('Analyze dimensions') and resource ('SolidWorks drawing'), and mentions the scope ('consistency and completeness'). However, it does not explicitly distinguish this from sibling tools like 'analyze_drawing_comprehensive' or 'analyze_drawing_annotations', which may 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 guidance is provided on when to use this tool versus alternatives (e.g., broader analysis tools). The description implies it is for dimensional analysis but does not give 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 provided, the description must disclose behavioral traits. It merely states 'analyze', which suggests a read operation, but does not confirm safety, side effects, or what the output entails. The existence of an output schema is not mentioned, and the description is insufficient for a tool with potential complexity.

Agents need to know what a tool does to the 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, focused sentence with no unnecessary words. It is efficient and front-loaded, but could benefit from slightly more detail without sacrificing conciseness.

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

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

Given the complexity implied by the sibling set and the analysis task, the description is too vague. It does not specify what 'arrangement and quality' entails or how to structure the input. An output schema exists, but the description should still provide enough context for correct usage.

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

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

The schema has 100% coverage for the single parameter 'input_data', describing it as 'The input data value.' The description adds no further meaning or constraints. Baseline 3 is appropriate since the schema already documents the parameter adequately.

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

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

The description clearly states the action (analyze) and the resource (drawing views) with specific aspects (arrangement and quality). However, it does not differentiate from similar sibling tools like analyze_drawing_comprehensive or analyze_drawing_dimensions, which may cause confusion.

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

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

No guidance is provided on when to use this tool versus the many sibling tools. There is no mention of context, prerequisites, or exclusion criteria, leaving the agent without direction.

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

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

The description does not disclose whether the tool modifies the model, what it returns, or any prerequisites. Since no annotations are provided, the description carries the full burden but fails to mention behavioral traits such as side effects or required model state.

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

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

The description is short but the first sentence is redundant with the tool name. It conveys the core purpose but lacks specific details that would make it more useful. It could be more informative without being longer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 performs analysis, the absence of output description (despite having an output schema) and lack of context about when analysis is valid or what prerequisites exist make it incomplete. The description does not compensate for these 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 100% with descriptions for each parameter. The tool description repeats the analysis types already in the schema, adding no new meaning. Without additional param details, baseline 3 is appropriate.

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

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

The description specifies the tool's function: performing geometry analysis like curvature, draft, and thickness. It clearly states the resource (geometry) and action (analyze), but does not explicitly differentiate it from sibling analysis tools like calculate_mass_properties, though the specific analysis types are listed.

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

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

No guidance is given on when to use this tool versus alternatives. Sibling tools include other analysis and modeling functions, but the description lacks any indication of when geometry analysis is appropriate or when to prefer this tool over others.

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

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

No annotations exist, so the description carries full burden. It mentions providing insights into structure and performance but does not disclose whether the tool is read-only, requires specific permissions, or has side effects. The behavioral traits are vague.

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

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

Two sentences, no wasted words, front-loaded with the core purpose. Efficient and well-structured.

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

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

Given the complexity (nested input schema, output schema, many siblings), the description is too generic. It does not explain output contents, analysis types, or depth options, leaving significant gaps for an agent to use the tool correctly.

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

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

Schema coverage is 100% with parameter descriptions in the schema itself. The description adds no additional meaning beyond 'analyze a macro', missing context on how to specify the macro (e.g., file path vs. content). Baseline score applies due to high schema coverage.

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

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

The description clearly states the tool analyzes macros for complexity, dependencies, and optimization, with a verb 'Analyze' and resource 'macro'. It distinguishes from siblings like 'optimize_macro' by focusing on analysis rather than modification, but does not explicitly name alternatives.

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

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

No guidance on when to use this tool versus siblings such as 'optimize_macro' or 'execute_macro'. The description implies analysis precedes optimization but provides no explicit context or exclusion criteria.

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

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

No annotations are provided, so the description carries full burden. It states the tool applies settings including properties, dimensions, and formatting, but does not disclose behavioral details like what happens with overwrite_existing=false, error handling on invalid paths, or whether the model is modified in-place. Adequate but lacks depth.

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

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

The description is concise with two sentences. The first sentence front-loads the core action. No unnecessary words or repetition.

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

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

Given the complexity (mutation tool, no annotations, output schema present but unknown), the description is incomplete. It does not explain the return value, prerequisites (e.g., model must be loaded), or the default behavior of the overwrite_existing parameter. Important context is missing.

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

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

Schema description coverage is 100%, each parameter is described. The tool description adds general context ('saved template settings') but does not add specific meaning beyond what the schema already provides. Baseline score of 3 is appropriate.

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

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

The description clearly states 'Apply a template to an existing SolidWorks model' and lists the types of settings applied (properties, dimensions, formatting). It distinguishes from siblings like create_template and batch_apply_template by focusing on applying to an existing single 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?

The description provides no guidance on when to use this tool versus alternatives (e.g., batch_apply_template for multiple models). It does not mention prerequisites like the model needing to be open or that a template must already 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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses spacing rules, side selection, the unplaced fallback, and the exact verification criteria after moving. It still does not say whether the move is undoable or what permissions/state are required, leaving a small gap 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 action is front-loaded in the first sentence, followed by compact layout rules and the validation criteria. The spacing details are dense but relevant to predicting behavior; a little pruning of parenthetical measurements could tighten it further.

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

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

For a geometry-rearranging tool with an output schema, the description covers the operation, placement rules, the unplaced edge case, and post-move validation. It lacks prerequisites such as requiring an active drawing or existing dimensions, but no critical invocation information is missing.

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

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

Schema coverage is 100%, so the single optional view_name parameter is already fully documented. The description reinforces its scope (one view versus every view) and confirms the overlap check remains sheet-wide, but adds no syntax or format detail beyond the schema.

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

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

The description states a specific verb and resource ('Move drawing dimensions') and adds a verification pass ('then check the real result'). It clearly distinguishes itself from insertion tools like auto_dimension_view by describing rearrangement of existing dimensions, though it never names a sibling explicitly.

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

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

The use case is implied by 'so nothing overlaps' and the post-move sheet checks, but there is no explicit guidance on when to call this versus check_drawing_standards, auto_dimension_view, or analyze_drawing_dimensions. No prerequisites or exclusions 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 provided, the description carries the full behavioral burden, and it does real work: it discloses that the API reports no count, that the response returns before/after centre-mark counts and the delta, and that a zero-delta run is still a success rather than an error. It stops short of noting that this mutates drawing data (relevant given the undo sibling) or any permission/document-state requirement.

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

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

Front-loaded with the action in the first sentence, then uses the remaining lines only for non-obvious behavior (count reporting, zero-delta success). No sentence is filler and the important caveat is stated rather than buried.

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

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

An output schema exists, so return-value documentation is technically redundant, but the explicit before/after/delta explanation is a useful disambiguation of a non-obvious result shape. Combined with clear mutation intent, the definition is nearly complete; only document-state or permission prerequisites are 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?

Schema description coverage is 100%, so the nested view_name, mark_holes, mark_slots and mark_fillets fields are already documented, including defaults. The description adds no syntax, format, or default information beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Auto-insert centre marks on circular features in a drawing view' and reinforces it with the implementation note about SolidWorks' automatic insertion for the named view. This is clearly distinguishable from siblings like auto_dimension_view, add_annotation, or auto_dimension_view without opening any schema.

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

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

Usage is implied by the operation itself (call it when a drawing view needs centre marks), but the description never states when to prefer this over manual annotation tools such as add_annotation, nor any prerequisite like an active drawing document being open. No explicit alternatives or exclusions are given.

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

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

No annotations are provided, so the description must carry the full burden. It states the tool adds dimensions automatically but lacks details on safety (non-destructive?), potential over-dimensioning, or side effects. The behavioral impact is only vaguely described.

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

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

The description is concise with two sentences. The first sentence front-loads the main purpose, and the second adds detail. No unnecessary words or repetition.

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

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

Given that there is an output schema (mentioned in context), the description need not explain return values. However, it does not mention prerequisites (e.g., active drawing view) or what exactly 'input_data' should be. The tool is complex, so more context about the input and output would improve completeness.

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

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

The only parameter 'input_data' is an untyped object with no specific properties defined. The description does not clarify what this input should contain (e.g., view reference, options). The schema description is vague ('The input data value.'), and the tool description adds no further meaning.

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

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

The description clearly states that the tool automatically dimensions a drawing view by analyzing geometry and adding common dimensions. It mentions specific dimension types (overall sizes, hole diameters, radii). However, it does not explicitly differentiate from similar sibling tools like 'add_dimension', which is for manual dimensioning.

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

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

No guidance is provided on when to use this tool vs alternatives, such as manual dimensioning or other automatic dimensioning tools. There is no mention of prerequisites, limitations, or best practices.

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

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

Since no annotations are provided, the description should disclose behavioral traits such as side effects (e.g., UI changes), permissions required, or that recording will capture subsequent user actions. The description only mentions capturing actions and generating scripts, which is minimal.

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

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

The description is concise with two sentences, front-loading the main purpose. However, it could be more structured by adding key behavioral details without adding length.

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

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

Given the output schema exists, return values are not needed, but the tool has a nested input object with many parameters. The description does not explain how to use these parameters or that recording must be stopped later (e.g., via 'automation_stop_macro_recording').

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it does not mention any parameters or their purposes.

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

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

The description explicitly states the tool starts macro recording in SolidWorks to capture user actions and generate scripts. However, it does not differentiate from the sibling tool 'start_macro_recording', which likely serves the same purpose.

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

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

No guidance is provided on when to use this tool versus alternatives like 'start_macro_recording' or when recording is appropriate. The description lacks context on prerequisites or usage scenarios.

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

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

The description discloses that the tool stops and saves but does not cover edge cases like no active recording or error handling. No annotations exist to compensate.

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

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

The description is two concise sentences, front-loading the core action, with no unnecessary 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?

Despite an output schema, the description omits what the tool returns and how to structure input_data, leaving gaps for an agent to understand full usage.

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

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

The only parameter input_data has a generic schema description, and the tool description adds no extra meaning beyond 'input data value', leaving its purpose unclear.

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

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

The description clearly states the tool stops recording the current macro and saves actions as VBA, distinguishing it from siblings like start_macro_recording or execute_macro.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 after starting a recording but does not explicitly state when to use it, prerequisites, or alternatives.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states that the tool applies the same template configuration to all matching files, but omits key details like whether it overwrites existing settings, requires permissions, or if the backup option (in schema) is automatic. More context on mutation behavior is needed.

Agents need to know what a tool does to the 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 long, front-loaded with the primary action, and contains no redundant information. Every sentence earns its place.

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

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

Given the existence of an output schema and high schema coverage, the description conveys the core purpose but lacks details about the batch process behavior, such as what happens to existing configurations or error handling. For a batch operation, more context would benefit the AI agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema; it only mentions 'template configuration' without elaborating on the parameters. The nested input_data structure is not explained further.

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

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

The description clearly states the tool applies a template to multiple models in batch, specifying it processes SolidWorks files. This distinguishes it from the sibling tool 'apply_template' which likely operates on single files, providing a clear verb+resource+scope.

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

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

The description implies batch usage but does not explicitly contrast with 'apply_template' or provide when-to-use/when-not-to-use guidance. The context of 'batch' suggests multiple files, but no direct comparison or alternatives are mentioned.

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

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

With no annotations provided, the description carries full burden. It only mentions execution order (sequence or parallel) but fails to disclose other behavioral traits such as error handling, file modifications, or prerequisites. The description is too minimal.

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

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

The description is two sentences long, front-loaded with the tool's core function. The first sentence is somewhat redundant but not harmful. Overall, it is concise and avoids unnecessary elaboration.

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

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

Given the complexity (nested input, output schema exists) and no annotations, the description is adequate but minimal. It explains the batch execution concept but does not detail the workflow context or error behavior. The output schema may cover return values, so completeness is sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add any meaning beyond the schema for the parameters like macro_list, stop_on_error, or execution_order. It merely states the overall capability.

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

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

The description clearly states the tool's purpose: 'running multiple macros in sequence or parallel for complex automated workflows.' It uses specific verbs ('run') and a resource ('multiple macros'), and it distinguishes itself from the sibling 'execute_macro' by specifying batch execution.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives like 'execute_macro' or other macro tools. It only implies use for 'complex automated workflows' without any exclusions or conditions.

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

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

No annotations are provided, so the description carries full burden. It states it processes directories and converts files, but does not disclose whether it modifies originals, handles errors, or requires permissions. Basic behavioral traits are implied but not fully detailed.

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

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

The description is three sentences, front-loaded with the core action. It is efficient but could be slightly tighter by removing 'Essential for...' which is not strictly necessary.

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

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

Given the complexity (batch operation with nested parameters) and presence of an output schema, the description adequately covers the main purpose. However, it lacks details on output behavior, error handling, and directory structure preservation, leaving some 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 100%, so baseline is 3. The description mentions directories and target format but adds no specific parameter details beyond what the schema already provides (e.g., recursive, format_type, file_patterns).

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

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

The description clearly states the tool does batch export of multiple SolidWorks files to a target format, mentioning processing entire directories. This distinguishes it from single-file export tools like export_step or export_pdf, as it emphasizes batch and directory-level operation.

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

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

The description provides usage context: project migrations, supplier deliverables, and large-scale conversions. It implies use when handling multiple files, but does not explicitly state when not to use or compare to alternatives like batch_process_files.

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

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

No annotations provided. Description states the tool performs file operations but fails to disclose behavioral traits like destructiveness, reversibility, permissions, or error handling. For a mutation tool handling delete/rename, this 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?

Two sentences, front-loaded with the core action and purpose. Every sentence adds value without redundancy or fluff.

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

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

Despite an output schema, the description lacks essential context for a batch operation tool: no mention of file selection, error behavior, prerequisites, or scope limitations. Leaves the agent guessing about execution 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?

Input schema has 100% description coverage for all properties. The main description adds no additional parameter meaning beyond listing example operations, meeting the baseline of 3.

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

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

Description clearly states the tool runs file operations across multiple files as a batch workflow, listing specific operations (copy, move, rename, delete) and target documents (SolidWorks). This distinguishes it from siblings like batch_export or batch_process_files.

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

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

Description mentions intended use for repetitive file management tasks and gives examples, but lacks explicit guidance on when not to use or alternatives. Usage is implied rather than clearly bounded.

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

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

No annotations provided, so description carries full burden. It mentions types of operations but does not disclose potential side effects, authorization needs, error behavior, or result format. Minimal transparency.

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

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

Two sentences; first is generic but second adds specifics. Efficient use of words, but could be more front-loaded with key details like file types and supported operations.

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

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

Complex tool with one nested parameter containing multiple fields. No mention of output, error handling, or expected behavior per operation. Output schema exists but description doesn't leverage it. Incomplete for agent invocation.

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

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

Schema coverage is 100% with parameter descriptions. Description lists operation types but adds no meaning beyond what schema already provides. Baseline 3 is appropriate.

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

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

Description clearly states it processes multiple files in a directory with operations like rebuild, save as, export, or property updates. This distinguishes it from sibling tools like batch_export, but could be more specific about SolidWorks file context.

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

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

No explicit guidance when to use this tool vs alternatives like batch_export or batch_file_operations. Implied by name and description, but no contrasts or preconditions provided.

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

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

No annotations are provided, so the description bears full responsibility. It claims to 'calculate and return' mass properties but does not disclose whether the tool modifies the model, requires an active document, or any error conditions. The read-only nature is implied but not explicit.

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

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

The description is concise with two sentences, front-loaded with the main purpose. It efficiently states what the tool does and why it's useful, though it could be more precise about inputs and the specific output 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?

Given that the tool has a nested input parameter and an output schema, the description provides a reasonable overview of outputs. However, it lacks details on the 'current model' requirement, the input structure, and differentiation from the sibling 'get_mass_properties'.

Complex tools with many parameters or behaviors need more documentation. 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 100% documentation coverage on all properties, so the baseline is 3. The description adds no additional meaning to the parameters; it merely lists output properties. No parameter names or semantics are elaborated beyond the schema.

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

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

The description clearly states 'Get mass properties of the current SolidWorks model' and lists the specific properties computed (volume, surface area, mass, center of mass, moments of inertia). However, it does not differentiate from the sibling tool 'get_mass_properties' which has a very similar purpose.

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

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

The description mentions it is 'essential for engineering analysis, weight calculations, and structural design,' providing some context. However, it lacks explicit guidance on when to use this tool versus alternatives, such as the similarly named sibling 'get_mass_properties', and does not state any prerequisites or conditions.

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

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

With no annotations, the description carries full burden for behavioral disclosure. The minimal text does not reveal if the tool modifies files, requires a model to be open, what the output contains, or any side effects. This is insufficient for trustful agent invocation.

Agents need to know what a tool does to the 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 excessively concise (one sentence) at the expense of informativeness. It fails to provide essential details that would justify its length. A few more sentences could significantly improve clarity without making it verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 nested input schema and presence of an output schema, the description is too sparse. It does not explain what compliance checks are performed, expected inputs format, or output structure. With no annotations, the description must compensate but does not.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it does not explain parameter roles or provide examples. However, the schema already documents parameters adequately, so no deduction.

Input schemas describe structure but not intent. Descriptions should explain 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 'Check drawing compliance with company standards' indicates a verb and resource but lacks specificity. It doesn't mention which standards or what aspects of compliance are checked, and fails to distinguish from sibling tools like 'check_drawing_standards' and 'analyze_drawing_comprehensive'.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not specify prerequisites, context, or exclusions, leaving the agent without decision-making support among similar drawing analysis tools.

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

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

With no annotations, the description carries the full burden but only says it validates and provides recommendations. It does not disclose whether the tool modifies the drawing, requires certain permissions, or has 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 two paragraphs but contains redundancy (the first sentence restates the name) and could be more concise while still covering key 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?

The description does not explain the output format (e.g., list of issues, pass/fail) despite an output schema existing, leaving the agent uncertain about what to expect after calling the tool.

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

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

The only parameter 'input_data' has a vague schema description ('The input data value'), and the tool description does not clarify what content or format is expected, only mentioning the 'current drawing' in context.

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

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

The description clearly states 'Check the current drawing against drafting standards' and lists specific standards (ANSI, ISO, DIN), providing a specific verb and resource that distinguishes it from general validation 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 it is used for compliance checking but does not explicitly differentiate from sibling tools like 'check_drawing_compliance' or 'validate_drawing_completeness', nor does it state when not to use it.

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

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

The description indicates it provides detailed interference detection results, but since no annotations exist, it should also mention read-only nature or any side effects. It does not cover performance or modification aspects, leaving some ambiguity.

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

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

The description is concise with two short sentences. The first sentence states the action, and the second provides context. No unnecessary words.

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

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

Given the nested object parameters and presence of an output schema, the description covers the purpose and importance. It is nearly complete, though could mention the output schema briefly. Still, it provides sufficient context for an agent.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add any additional meaning beyond what the schema already provides for each 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?

Clearly states the tool checks for geometric interference between components in an assembly, a specific and distinct action among many siblings. The description makes it immediately evident what the tool does.

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

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

The description mentions it is critical for assembly validation and design conflict identification, providing context for when to use. However, it does not explicitly state when not to use or compare with alternatives like analyze_geometry.

Agents often have multiple tools that could apply. Explicit usage 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 for behavioral disclosure. It only states the check action but does not mention whether it is read-only (though implied), what happens if the sketch does not exist, or any potential 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 sentence with no superfluous words. It is concise and front-loaded with the essential purpose.

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

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

Given the tool's simplicity (one optional parameter, likely boolean output), the description is mostly adequate. However, it omits explicit mention of return value or error scenarios, though the presence of an output schema mitigates this. Some context like requiring an active sketch is only in the schema, not the description.

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

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

Schema coverage is 100% with the parameter description already detailed in the input schema (e.g., 'Optional sketch name. If omitted, checks the active or last sketch.'). The tool description adds no additional parameter information, but the schema suffices, yielding a baseline score of 3.

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

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

The description 'Check whether a sketch is fully defined' uses a specific verb and resource, clearly stating the tool's function. However, it does not differentiate from sibling tools like 'check_drawing_compliance' or 'check_interference', but the context of sketches is unique enough.

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

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

No usage guidance is provided. The description lacks information on when to use this tool versus alternatives, prerequisites (e.g., sketch must exist), or conditions under which it should not be used.

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

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

Despite no annotations, the description indicates the tool is a 'read-before-write helper', strongly implying no side effects. It describes the inputs (model-info and tree data) and output (classification). Missing details on error handling, but overall clear behavioral intent.

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

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

Two concise sentences. The first states the core action, the second elaborates on the output categories and context. Every sentence adds value with no redundancy.

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

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

With a known output schema and 100% parameter coverage, the description adequately covers purpose, inputs, and output categories. The 'read-before-write' context is valuable. Missing a brief note on the output format, but the output schema likely covers that.

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

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

Schema coverage is 100%, so the description need not elaborate on parameters. It mentions using 'model-info and tree data', which aligns with the parameters, but adds no additional semantic nuance 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 the specific verb 'classify' and clearly identifies the resource as the 'active model' and output as a 'feature family'. It lists the possible classification categories, distinguishing this tool from all sibling tools, none of which perform classification.

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

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

The description explicitly states 'This is a read-before-write helper for delegation', giving clear guidance on when to use it (before writing, for delegation). As the only classification tool, no alternative is needed, and the context is well-defined.

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

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

No annotations are provided, so the description must fully disclose behavior. It doesn't specify what happens when save=false with unsaved changes (e.g., discard or prompt), nor if it closes just the document or the application.

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

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

The description is concise with two sentences, front-loaded with the action. Every sentence adds value.

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

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

The description is mostly complete for a simple tool, but missing behavioral details about unsaved changes when save=false. However, an output schema exists (not shown) so return value explanation is not 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?

The schema covers 100% of parameters, so baseline 3. The description adds no new meaning beyond stating the save option, which is already 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?

The description clearly states the tool closes the active SolidWorks model, with a specific verb and resource. It distinguishes from sibling tools like open_model and save_file.

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

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

The description implies usage for model lifecycle management and data loss prevention, but does not explicitly state when to use versus alternatives like saving and then closing separately.

Agents often have multiple tools that could apply. Explicit usage 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 disclose behavioral traits. It does not specify whether the tool is read-only or modifies files, what side effects exist, or what the comparison output format is. This lack of transparency 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?

The description is a single concise sentence without wasted words. However, it is too brief to provide adequate guidance, so it balances conciseness with under-specification.

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

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

Despite having an output schema and nested objects, the description does not explain the return value or the expected input structure. Given the tool's complexity (comparing versions), the description leaves too many gaps for an agent to use it effectively.

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

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

The input schema has 100% description coverage, but the parameter 'input_data' is described generically as 'The input data value.' The tool description does not add meaning about what data should be provided (e.g., version identifiers, file paths). Thus, it fails to compensate for the generic 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 'Compare different versions of drawing files' clearly states the action (compare) and the resource (drawing file versions). It distinguishes itself from sibling tools, none of which focus on version comparison.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or context for use. It is a standalone statement without any usage recommendations.

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

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

No annotations are provided, so the description must fully disclose behavior. It only states it compares and generates a report, but does not mention destructive potential, permissions, side effects, or output format. The report generation is vague.

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

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

Two sentences with the core action clear. The second sentence is somewhat redundant ('analyzes differences' rephrases 'compare'), but overall concise.

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

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

Despite having an output schema (not shown), the description lacks details about the output report, file format, or how templates are referenced. It does not explain the difference between comparison types or when to use this tool versus its 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 100% with brief descriptions for each sub-parameter. The tool description adds no additional meaning or context beyond what the schema already provides. No explanation of parameter interactions.

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

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

The description clearly states the tool compares two templates and generates a difference report. It specifies the resource (templates) and action (compare, generate report). Among siblings, there is no other template comparison tool, so it distinguishes well.

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

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

No guidance is provided on when to use this tool versus alternatives, such as compare_drawing_versions. It does not mention prerequisites, context, or when not to use it.

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

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

No annotations provided, so description must disclose behavior. It only mentions 'exporting source files' but omits details like side effects (e.g., file overwriting), permission requirements, or whether the operation is a read or write. This is insufficient for safe agent decision-making.

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

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

Two sentences, front-loaded with purpose ('Convert a SolidWorks file from one format to another'), no filler. Efficient and easy to parse.

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

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

Despite output schema existing, the description lacks context about required sub-parameters (source_file, target_format) and optional ones like units and quality. For a tool with nested parameters and no annotations, this is insufficiently complete.

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

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

Schema coverage is 100% with descriptions for all parameters, so description adds no extra meaning beyond schema. Baseline of 3 is appropriate as the schema already documents each parameter 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?

Description clearly states 'Convert a SolidWorks file from one format to another' and lists supported formats (STEP, IGES, STL, PDF). This distinguishes it from sibling export tools that target a single format, making the purpose specific and clear.

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

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

No guidance on when to use this tool versus sibling export tools like export_step or export_iges. The description does not specify prerequisites or scenarios where this generalized conversion is preferable.

Agents often have multiple tools that could apply. Explicit usage 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 usefully discloses two side effects: the document becomes the active document, and an unspecified default template is used when none is passed. It says nothing about whether anything is written to disk, whether name is a filename/path, what happens on an invalid template path, or whether the call fails when the template 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?

Three tight sentences with the core action front-loaded. The final clause about component insertion and mating is the weakest part but still conveys the post-creation state, so it broadly earns its place.

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

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

An output schema exists so return values need not be described, and the schema is fully documented. However, the tool takes a nested input object with a `components` field that the description entirely ignores, leaving the agent unsure whether to supply components at creation time or call insert_component afterward.

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

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

Schema description coverage is 100% and already explains that name is the assembly name and template is an .asmdot path defaulting to the SolidWorks default, so the description adds no new parameter detail. Notably it never addresses the `components` array, and its "ready for component insertion" phrasing creates ambiguity about whether components are inserted at creation or afterwards.

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

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

Opens with a specific verb + resource ("Create a new SolidWorks assembly document"), which cleanly separates it from create_part, create_drawing, and load_assembly among the siblings. It does not name those siblings explicitly, so the differentiation is inferable rather than stated.

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

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

The description implies the usage flow ("ready for component insertion, mating, and assembly-level operations") and explains the template-or-default choice, but never states when an agent should call this versus load_assembly (open existing) or create_part. No exclusions or prerequisites are given.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does add real value by disclosing the construction method ('intersection of two built-in planes'), but it omits the mutation profile of a creation tool, side effects, and any document/permission prerequisites, leaving notable gaps.

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

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

The core action is front-loaded in the first sentence, with a compact second sentence supporting it. The plane-intersection detail earns its place, though the parenthetical mapping could be 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?

An output schema exists, so return values need no explanation, and the single parameter is fully covered by the schema. What remains missing is usage context and prerequisites for a document-mutating creation tool, so it is adequate but not complete.

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

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

Schema description coverage is 100%, and the schema already documents 'reference' as 'x', 'y' or 'z' with case-insensitivity and +/- stripping. The description adds the geometric derivation for each direction, which is context but not parameter clarification beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Create a reference axis') plus the scope ('along a principal direction'), which is enough to distinguish it from create_reference_plane and create_reference_point in the sibling list. However, it never names those siblings explicitly, so differentiation is inferred rather than stated.

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

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

There is no when-to-use or when-not-to-use guidance, no statement of prerequisites (e.g. an open document is required), and no routing to alternatives like create_reference_plane. The description only explains what the tool does, not when an agent should pick it.

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

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

With no annotations, the description carries the burden and mostly succeeds: it discloses the automatic direction-flip behavior and the direction_flipped reply flag, the sketch fallback rule and its error-reporting behavior, and the both-directions cut semantics. It omits preconditions such as requiring an active part document with an existing solid body, or what state a failed cut leaves behind.

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

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

Purpose is front-loaded in the first sentence, followed by usage, sketch-selection, and direction sections that each earn their place. The direction and sketch paragraphs are long and partly restate the schema's sketch_name text, so it is efficient rather than tight.

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

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

For a mutation tool with no annotations and a nested schema, the description covers the tricky parts an agent would otherwise get wrong: direction ambiguity, sketch resolution, and through-all variants. An output schema exists so return values needn't be detailed, and the mentions of direction_flipped are appropriate. Missing preconditions (active document, existing solid body) keep it from 5.

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

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

Schema coverage is 100%, so baseline is 3, but the description genuinely adds meaning: it explains why sketch_name should be passed explicitly, what happens when it is omitted, and how reverse_direction/end_condition/both_directions interact (including that reverse_direction is usually unnecessary). That is real guidance beyond the field-level descriptions.

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

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

States a specific verb and resource ('Cut material from a sketch profile', 'Creates a Cut-Extrude feature') and anchors it to the SolidWorks UI path (Insert > Cut > Extrude). The contrast with adding material ('remove material') implicitly separates it from the sibling create_extrusion, so an agent can pick it without opening a schema.

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

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

Gives clear when-to-use context: after exit_sketch, to remove material, with concrete examples (windows, holes, slots, through/blind cuts). It also gives an explicit when-to-pass-sketch_name rule. It does not explicitly name create_extrusion as the alternative when the goal is to add rather than remove material, so it falls short of a full 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 full burden for behavioral disclosure. It describes the intended outcome (magnified view) but does not detail side effects, error behavior, or requirements (e.g., existing drawing or view). The description is adequate but not rich.

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

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

The description is extremely concise with two sentences. It proceeds in natural order: noun phrase of purpose, then elaboration. Every sentence adds value without extraneous content.

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

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

Given the output schema exists and schema coverage is 100%, the description is sufficient for a straightforward creation tool. However, it could be improved with usage guidelines or behavioral notes. Still, it's largely complete for the tool's complexity.

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

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

Schema description coverage is 100%, and the description does not add meaning beyond the parameter names and types. The parameter descriptions in the schema already explain each field (e.g., center_x, radius). Baseline 3 is appropriate since no additional semantic context is provided.

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

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

The description clearly states the tool's purpose: 'Create a detail view of a specific area' and explains it generates magnified detail views for manufacturing and inspection. This verb+resource combination distinguishes it from sibling tools like create_drawing_view or create_section_view.

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

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

The description implies usage for creating detail views of specific areas, but lacks explicit guidance on when to use this vs alternatives like create_section_view or add_drawing_view. No when-not-to-use or prerequisite conditions are mentioned.

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

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

No annotations, so the description carries the full burden. It does disclose two genuinely useful behaviors: the template fallback to the SolidWorks default, and the side effect that the new drawing becomes the active document. It does not say what happens to the previously active document, whether an existing name collides or errors, where the file is written, or whether it is saved to disk at all.

Agents need to know what a tool does to the 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 no filler. Minor redundancy between 'Create a new SolidWorks drawing document' and 'This tool creates a new drawing document from...' but it is not wasteful enough to penalize further.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 and parameter documentation is complete, so return values and inputs are covered. What remains thin is the surrounding context for a creation tool with zero annotations: session prerequisites, file-location/save semantics, and behavior on name collisions are all absent.

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

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

Schema description coverage is 100%, so each nested property is already documented; the description only restates the template semantics. It adds nothing about model_path or sheet_format, and nothing about what 'name' actually controls (document title vs. filename). Baseline 3 applies when the schema does the explaining.

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

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

States a specific verb and resource ('Create a new SolidWorks drawing document') and clarifies it is a whole document, not a view, which meaningfully separates it from siblings like create_drawing_view, add_drawing_view and create_technical_drawing. It never names those siblings explicitly, so the differentiation is inferential rather than stated.

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

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

The text explains how the template parameter resolves but never says when to reach for this tool versus create_part/create_assembly/create_technical_drawing, nor any prerequisites (SolidWorks session running, existing document state). An agent must infer the usage scenario from the verb alone.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states what the tool does ('creates') but does not mention prerequisites (e.g., an open drawing), side effects, permissions, or error conditions.

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

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

The description is concise with two sentences, front-loading the main action. It could be slightly more structured but avoids unnecessary verbosity.

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

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

While an output schema exists (not shown), the description lacks information about prerequisites (e.g., a drawing document must be active), orientation specifics beyond the parameter list, and potential issues like view placement overlaps. This leaves gaps for a tool with many parameters and nested objects.

Complex tools with many parameters or behaviors need more documentation. 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 covers all parameters with descriptions (100% coverage). The description adds value by enumerating view types, which aligns with the view_type parameter, but does not provide additional semantic context beyond what the schema already offers.

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

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

The description clearly states it creates drawing views and lists types like orthographic, isometric, section, and detail. This distinguishes it from general modeling tools, but it does not explicitly differentiate from specialized siblings like create_section_view or create_detail_view.

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

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

The description implies usage for generating production drawings, but it does not specify when not to use it or explicitly mention alternative tools. Given many sibling tools for specific view types, this omission reduces clarity.

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

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

The description only states it creates an extrusion with advanced options. It does not disclose behaviors such as whether it modifies existing geometry, error conditions if no sketch is active, or if the operation is reversible. With no annotations, more transparency is needed.

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

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

The description is brief with two sentences, front-loading the main purpose. It could be slightly more concise but is well-structured.

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

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

Given the complexity and many parameters, the description is adequate but lacks explanation of the overall workflow, prerequisites, and return value despite an output schema existing.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description only lists parameter categories without adding new meaning beyond what the schema provides.

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

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

The description clearly states the tool creates an extrusion feature from an active sketch, specifying both boss and cut options. However, it does not distinguish itself from the sibling tool create_cut_extrude, which could cause confusion.

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

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

No guidance is provided on when to use this tool vs alternatives (e.g., create_cut_extrude). It does not mention prerequisites like having an active sketch or when to choose boss vs cut.

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

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

No annotations are provided, so the description must carry the full burden. It discloses that each profile must be a closed contour and that guide curves are optional, but does not explain other behavioral aspects like error handling, effect of merge_result, or what happens with invalid inputs. Some important details are 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?

The description is three sentences, front-loaded with the main purpose. It is concise, but the inclusion of the menu path 'Insert > Boss/Base > Loft' is somewhat redundant for an AI agent. Overall efficient with no fluff.

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

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

Given the complexity of a loft operation and the nested schema with five parameters, the description covers the main purpose and the closed-contour constraint but omits details about other parameters like merge_result, start_tangent, and end_tangent. The output schema is present (not shown) but does not compensate for these 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 100%, so baseline is 3. The description adds value by stating 'Each profile must be a closed contour', which is a constraint not in the schema, and clarifies that guide curves shape the transition. However, it does not elaborate on other parameters like merge_result or tangent conditions.

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

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

The description clearly states 'Loft a solid between two or more profile sketches' and 'Creates a lofted boss/protrusion', using a specific verb and resource. It distinguishes from sibling tools like create_extrusion, create_revolve, etc., by emphasizing multiple profiles and optional guide curves.

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

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

The description implies usage for blending profiles but provides no explicit guidance on when to use this tool versus alternatives (e.g., when not to use it). It does not mention exclusions or provide comparisons to sibling tools like create_extrusion or create_sweep.

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