MCP_CAD

by danielproxd2

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.0.1
Disambiguation2/5
Many tools have overlapping purposes, e.g., multiple ways to create holes (add_bolt_circle, add_drill_pattern, hole_wizard, build_flange_boss, build_threaded_boss) and to build profiles. Descriptions help but an agent would still struggle to reliably pick the right tool.
Naming Consistency3/5
Tool names follow a mix of patterns (verb_noun, build_*, add_*, etc.). Some are descriptive but inconsistent (e.g., add_mate_by_face_position vs stack_components). No dominant pattern, leading to moderate confusion.
Tool Count2/5
With 100 tools, the server is over-scoped for a typical CAD automation use case. The recommended range is 3-15; 100 is far beyond that, making it hard for agents to navigate efficiently.
Completeness4/5
The tool set covers most common CAD operations: sketching, extruding, revolving, sweeping, mating, configurations, and materials. Minor gaps exist (e.g., no loft or advanced surfacing), but core autoparts workflows are well-supported.
Average 4.6/5 across 100 of 100 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that segment coordinates and depth_mm accept string expressions over variables, which is a key behavioral detail. However, with no annotations, it does not disclose side effects (e.g., whether it requires an active sketch), destructive potential, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a concrete example, no redundant text. It is concise but could be slightly more structured (e.g., listing key parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description leaves major gaps. It does not explain the purpose of most parameters (exact, merge, plane, end_condition) or the return value. A user would need extensive trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is the sole documentation for 8 parameters. It only explains segments and depth_mm's expression capability, leaving plane, exact, merge, variables, end_condition, and reverse_direction completely undocumented. This is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an exact closed profile and extrudes it as one composite. This differentiates from build_closed_profile (profile only) and build_revolved_profile (revolved), though not explicitly. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 build_closed_profile or extrude_sketch. The only usage hint is about size variants using a new variables dict, which is helpful but insufficient for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions creating a report and distinguishes check types, but omits side effects, output format, or consequences of missing parameters. This is insufficient for an 8-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose, but it is under-specified given the tool's complexity (8 parameters, no annotations). It could include parameter explanations without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description partially explains the tool's role relative to a sibling, but it lacks details about return values, behavior when parameters are omitted, and does not compensate for the missing output schema and parameter descriptions. Overall, it leaves significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning no parameter descriptions are provided. The tool description does not explain any of the 8 parameters (e.g., notes, drawing_spec_id, expected mass). This leaves agents with no semantic guidance for parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a structured verification report for the active part. It distinguishes from the sibling verify_against_spec by explaining that bbox is the hard envelope check while other metrics are advisory, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool versus verify_against_spec by differentiating hard vs. advisory checks, but it does not explicitly state use cases or when not to use it. There is no mention of alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the operation as mating planar entities, implying assembly modification. However, it does not disclose side effects, required permissions, error conditions, or behavior for non-planar entities. Minimal transparency beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Bilingual (Spanish/English) makes the description longer than necessary for an English-speaking AI. While the content is useful, it could be more concise by dropping the Spanish version. Sentences are clear and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no schema descriptions, the description is incomplete. It lacks details on how to obtain entity IDs, what the 'align' parameter does, and expected return value. References to similar tools partially compensate but own content is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does not explain individual parameters. It only notes same argument shape as add_concentric_mate, which is indirect. No details on component names, entity IDs, or the 'align' parameter. Fails to compensate for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a coincident mate between two planar entities (faces or planes). It specifies typical uses like flange-to-plate and sub-assembly base plane. It distinguishes from siblings by referencing add_concentric_mate's argument shape and listing related tools, but does not explicitly differentiate from all mate types (e.g., angle, distance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides typical use cases (flange-to-plate, sub-assembly base plane). Mentions same argument shape as add_concentric_mate, guiding agents familiar with that tool. Lists related alternatives: add_mate_by_face_position (convenience without entity names) and stack_components (batch 3 mates). Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description outlines the steps (creates axis, builds closed profile, revolves) and mentions the 'safe chain' concept, but does not clarify potential side effects (e.g., whether existing geometry is modified) or any required permissions. Since no annotations are provided, the description carries the burden, and while it gives some behavioral insight, gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, front-loaded with the primary action, and each sentence adds meaningful information (steps, usage context, capability). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description is insufficient. It lacks details on parameter formats, return values, error conditions, and how it integrates with the overall part model. The agent would struggle to invoke this tool reliably without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 9 parameters with 0% description coverage, yet the tool description only mentions 'segments' and 'variables' indirectly. It does not explain the format of the required 'segments' array, the meaning of 'plane', 'angle_deg', 'axis_reference_1/2', or other parameters. This is a critical gap for an AI agent to use the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an axisymmetric profile via a safe chain, specifying it for turned parts with ordered line/arc segments. It differentiates from siblings like build_closed_profile or revolve_sketch by calling itself the 'preferred path' for this specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool ('preferred path for turned parts...') and mentions variable expressions for variants, but does not explicitly state when not to use it or provide alternatives. The guidance is implied rather than explicit, which could leave ambiguity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'drawing-grounded through holes' but does not explain if the operation is destructive, whether it requires an active document, or other side effects. The description is minimal on behavior beyond the obvious creation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences. The first sentence states the overall action, and the second sentence provides key usage details. No extraneous words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 14 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return value, prerequisites, or how parameters like thickness or plane affect the result. For a complex tool, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It clarifies hole_positions_mm, bolt_circle_diameter_mm, bolt_count, origin coordinates, width, and height. However, many parameters (plane, thickness_mm, angle_offset_deg, reverse_direction, bolt_circle_center_*) are not mentioned, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a rectangular plate and drills through holes, specifying two hole placement methods (explicit positions or bolt circle). It distinguishes itself from sibling tools like add_bolt_circle or build_rectangular_pocket by combining plate creation with hole patterning in one operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions two usage modes (explicit positions vs bolt circle) but does not explicitly guide when to use this tool over alternatives like building a plate and holes separately. The context is clear but lacks exclusions or targeted usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 not disclose behavioral traits such as whether the mate is destructive, if it can be removed, permission requirements, or behavior when over-constrained. It mentions 'Returns the created mate's metadata' but lacks detail on what that includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but contains redundant Spanish and English text. The key information is front-loaded in the English portion. It is structured with an Args section and a Related line, making it scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and moderate complexity, the description is incomplete. It does not explain the entity IDs, component names, or align parameter. The reference to add_concentric_mate assumes knowledge of that tool. No return value details beyond 'metadata'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description explicitly only defines distance_mm (with unit) and refers to other arguments as 'same as add_concentric_mate,' providing minimal additional meaning. The align parameter with default is not explained, and entity/component parameters are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a distance mate (fixed offset) between two entities, and provides specific use cases (parallel plate separation, bearing-to-bearing distance). It distinguishes from sibling mates like add_concentric_mate and add_angle_mate by focusing on fixed offsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives typical use cases and explicitly lists related tools (add_mate_by_face_position, stack_components) that offer alternatives or convenience. However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 clearly states the tool does not mutate SolidWorks and returns tool names and parameters. However, it lacks details on error handling (e.g., missing drawing_spec_id), rate limits, or return format specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the core purpose, then add behavioral context and supported archetypes. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, lack of annotations, and no output schema, the description could be more complete. It states supported archetypes but does not mention prerequisites (e.g., a recorded DrawingSpec), behavior for unsupported archetypes, or the format of the returned plan. Some gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no parameter descriptions). The tool description does not compensate: it only mentions 'stored DrawingSpec' indirectly, with no explanation of what drawing_spec_id is, how to obtain it, or its format. This is a critical gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compile a stored DrawingSpec into an ordered FeaturePlan.' It uses a specific verb and resource, and distinguishes itself from siblings like run_feature_plan by noting it is 'Advisory only' and does not mutate SolidWorks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Advisory only' for planning without execution) and lists supported archetypes. However, it does not explicitly state prerequisites (e.g., requiring a previously recorded DrawingSpec) or when to avoid using it in favor of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses read-only behavior, search mechanism (token-based, accent-insensitive, etc.), and combinable filters. It also describes the return structure. This is adequate for a query tool, though no rate limits or side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but contains bilingual text (Spanish summary and English Args). The structure is logical, front-loading the purpose and then detailing parameters. Some sentences could be trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no output schema), the description covers the necessary context: search functionality, filter combinations, prerequisite, and return fields. It is sufficiently complete for an agent to understand the tool's capabilities and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for each parameter in the Args section, including examples ('p.ej. 'buje balero'') and constraints ('la pieza debe tener un barreno de este Ø'). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for similar parts in the local catalog, using a specific verb and resource. It distinguishes the tool's purpose from siblings like 'search_part_catalog' by focusing on local indexed parts, but does not explicitly differentiate. The Spanish summary adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('run build_part_index first') and that it is read-only. However, it lacks explicit guidance on when to use this tool versus alternatives like 'search_part_catalog' or when not to use it. The usage context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 indicates the tool modifies a dimension and returns updated state, but does not disclose error handling, side effects, or requirements (e.g., feature must exist). Some unit context is given but behavioral details are lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose, and uses a clear argument list. It is slightly verbose with examples but overall efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 required params, no output schema, no annotations), the description covers basics but lacks depth. It does not explain what happens if the dimension is invalid, locked, or suppressed. Adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains all three parameters with examples and unit guidance (mm for linear, degrees for angles). It adds significant value beyond the schema's bare titles, though ranges or exact format are absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Change a single dimension on a feature.' It specifies the resource (dimension) and the action (change), and distinguishes from sibling tools as the only one modifying existing dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in active part or assembly with examples, but does not explicitly state when to use this tool versus alternatives, nor provides exclusions or prerequisites. Guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles transparency. It discloses that the switch triggers a rebuild, applies suppressions and dimensions, and returns the previous configuration name. However, it lacks details on side effects like reversibility or error conditions, so it's good 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual (Spanish and English), making it longer than necessary. It is front-loaded with the main action but the repetition reduces conciseness. The Args section is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers purpose, side effects, use case, and return value. It is mostly complete, though it does not explain error handling or behavior for non-existent configurations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'name' is described as 'Name of the configuration to activate', which adds some meaning but is minimal. Given 0% schema coverage, this is adequate but not detailed; it essentially restates the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool activates a different configuration of the active document, distinguishes from sibling tools like create_configuration and delete_configuration, and mentions the rebuild effect and relation to build_variant_family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case: verifying a variant built with build_variant_family before saving. It implies context but does not explicitly state when not to use the tool or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the mate is fixed, the angle is in degrees with right-hand-rule orientation, and that the solver may reject if entities are coplanar. It describes the return value (metadata including angle_deg). It does not mention authentication, rate limits, or side effects, but for a mate creation tool, the behavioral traits are adequately covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bilingual text, a clear purpose statement, usage context, parameter notes, gotcha, and related tool. It front-loads the key information. While slightly verbose due to bilingual repetition, the structure aids readability and each section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (5 required), no output schema, and no annotations, the description covers the main behavioral aspects and constraints but lacks full parameter details (e.g., align, entity IDs). It does mention the return value. The gotcha and related tool add context. However, without schema coverage, the description could be more comprehensive for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the angle_deg parameter (positive per right-hand-rule) and states 'Other args: same as add_concentric_mate,' which is helpful but vague. It does not describe align, component_name, or entity_id parameters. Thus, it adds partial value but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Mate de ángulo — fuerza un ángulo fijo entre dos entidades' and 'Add an angle mate (fixed angular offset) between two entities.' It specifies the resource (angle mate) and the action (add). It distinguishes from sibling mates (e.g., concentric, distance) by focusing on angular relationships and providing typical use cases like chain-link articulation and hinge angles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes typical use cases (e.g., hinge angles, lever positions) and constraints (entities must be planar or axes). It warns against applying between two concentric cylindrical faces and mentions a gotcha about coplanar entities. It references a related tool (add_mate_by_face_position) but does not explicitly contrast with all sibling tools. The guidance is clear and practical, though not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, description fully discloses creation of temp .swb, RunMacro2 execution, network egress block, audit logging, and return fields. Also explains four levels of gating with override conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long and mixes bilingual text, purpose, process, and restrictions in a dense block. While front-loaded with purpose, it could be more concise and better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the full workflow, restrictions, audit log, and return format. Missing explicit parameter details and potential error handling, but sufficient for understanding execution and outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description indirectly explains override_warnings and override_low_confidence via gate rules. macro_job_id is not explicitly described, though its purpose is clear from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Ejecuta un MacroJob registrado' and describes the process of materializing, running, and cleaning up. Distinguishes from sibling run tools by focusing on macro jobs with VBA execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions that this call represents human approval and details gate conditions, but does not explicitly compare to alternatives like run_assembly_plan or run_batch_job. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: the tool is advisory-only, does not execute, intentionally crosses constraint #2, and blocks execution if '<required>' is in the source. It also describes the return object shape. Minor deduction for not stating idempotency or side effects, but overall strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose and includes bilingual repetition (Spanish and English). It is structured with an 'Args' section and front-loaded key points, but overall length could be reduced without losing essential information. The structure is clear but not highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description provides purpose, parameter details, behavioral notes, and return object shape. However, it omits documentation for the 'assumptions' parameter, does not describe error handling, and lacks explicit guidance on handling the '<required>' blocking. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates. It documents 5 of 6 parameters with specific semantics: intent (sentence describing macro), generated_source (full VBA body, .swb format), proc_name (default 'main'), provenance (structure for audit), confidence (0-10 affects recommendation). The missing 'assumptions' parameter is a gap, but the described parameters are rich and helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: registering a VBA macro job for advisory purposes only. It distinguishes itself from sibling 'run_macro_job' by emphasizing it does not execute and that human review of 'generated_source' is required. It also explains the design rationale of crossing constraint #2, providing unique context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for recording/advisory only ('Solo asesoría: NO ejecuta nada') and directs the agent to use 'run_macro_job' for execution. It implies use cases outside the verb catalog but does not explicitly state when not to use it or provide alternatives beyond the execution sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes effect (fully defined, stops drifting), no rebuild until next exit, and which relations take 1 or 2 points. Missing error conditions or behavior if relation already exists. With no annotations, carries burden 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bilingual intro, Args, Returns, and context. Slightly redundant due to dual languages, but front-loaded with essential info and no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage, no annotations, and no output schema, description covers purpose, parameters, return value, and usage context. Missing error handling or validation details, but adequate for most uses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully explains both parameters: relation values and entity_points_mm format (list of points). Adds meaning beyond schema by specifying number of points per relation type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it adds geometric constraints to sketch segments, lists specific relations, and explains its role in making sketches fully defined. It distinguishes from sibling tools like add_sketch_dimension and add_sketch_fillet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context: typical CSWA workflow, when to use (after drawing, before extrude), and requires sketch in edit mode. Implicitly differentiates from dimensioning and filleting but lacks explicit 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the slot geometry, the parametric constraint (non-driving dimensions), and the active sketch requirement. It does not mention return value or side effects like sketch closure, but the major behavioral trait (non-parametric) is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, including bilingual text (Spanish and English) which adds redundancy. While the content is valuable, it could be more concise. The key information is front-loaded, but the Spanish repetition detracts from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 required parameters, no output schema, and no annotations, the description covers geometry, parameter semantics, usage context, and a critical behavioral caveat (non-parametric dimensions). It lacks error conditions or return value, but these are partially expected without output schema. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It does so with a docstring-like list: x1_mm, y1_mm, x2_mm, y2_mm as center-line endpoints and width_mm as slot width. This adds meaning beyond the bare schema titles and compensates for lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Draw a straight slot on the active sketch' and explains the geometry (rounded-rectangle with semicircular end-caps). It distinguishes this tool from sibling sketch tools like create_rectangle or create_circle by specifying the slot shape and common autoparts use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage example (adjustable bolt slots) and explicit caveats: requires active sketch and the parametric limitation that modify_dimension cannot resize width/endpoints. It doesn't explicitly contrast with alternatives but implies specialized slot creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 notes the operation is subtractive (destructive) and returns a feature. The caveat mentions constraints similar to sweep_sketch but does not elaborate on permissions, reversibility, or specific limitations. This is adequate but not highly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, followed by use cases, arguments, return, caveat, and an example. While slightly verbose due to bilingual text and example, each section adds value and the structure is logical. Minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, no output schema, and no annotations, the description covers the essentials: purpose, parameters, return type, and a worked example. It lacks explicit prerequisites (e.g., active document) but these may be implicit. The caveat provides additional context. Overall sufficient 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters: profile_sketch_name is a closed profile sketch name (e.g., 'Croquis1'), and path_sketch_name must be a different sketch. This adds significant meaning beyond the schema titles alone, especially since schema description coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool subtracts a swept-profile-along-path volume from existing material. It uses specific verbs (subtract/cut) and resource (existing material), and distinguishes it from sibling tools like sweep_sketch which creates a sweep sketch rather than performing a cut.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides typical use cases (curved grooves, oil channels, milling tool paths, ergonomic cutouts) and an example. It mentions constraints via the caveat linking to sweep_sketch. However, it does not explicitly state when not to use the tool or recommend alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals that the tool mutates the part, requires a reference axis, returns a new Feature with a name, and explains how count includes the original. It covers key behaviors like angle defaults and spacing options, though it could mention side effects (e.g., whether it modifies existing features).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, use cases, prerequisites, detailed parameter list, and examples. It is slightly verbose (e.g., repeated explanation of total_angle_deg in both text and example), but the organization makes it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description is exceptionally complete. It includes prerequisites, parameter details, return value, and multiple examples covering common scenarios (bolt circle, partial arc). No major gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining all 6 parameters: feature_names (exact names from get_active_part_info), axis_name (from create_reference_axis), count (>=2, includes original), total_angle_deg (default 360, partial arcs), equal_spacing (True/False meaning), and reverse (direction). Examples clarify usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'repeat features around an axis' and lists standard autoparts uses (bolt circles, fan blades, etc.). It does not explicitly contrast with sibling tools like linear_pattern or mirror_feature, but the name and examples make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite ('Always preceded by a create_reference_axis call') and explains when to use equal_spacing=False for 'every 30 degrees' cases. It lacks explicit exclusion of alternatives (e.g., when to use add_bolt_circle instead), but the examples illustrate typical usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the composition of multiple steps, partial failure caveat, and no auto-rollback. Also explains return values. Slightly lacking details on save behavior but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, workflow, args, returns, caveat, and example. Slightly verbose but every sentence adds value. Not overly concise but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (composite tool, 5 parameters, safety concerns), the description covers purpose, parameters, returns, and a caveat. Could mention prerequisites like feature existence, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It does so thoroughly: feature_name, dimension_name, variants mapping, parent_config (empty for root), activate_at_end (must be a key of variants). Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a family of configurations by changing a single dimension. It includes a concrete example and distinguishes from sibling tools like create_configuration and modify_dimension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear workflow example and explains when to use (changing one dimension). However, it does not explicitly state when not to use or mention alternatives, though the context implies batch creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return value (geometry endpoints+length), non-parametric nature of sketch, and that modify_dimension only affects extrusion depth. No annotations provided so description carries full burden; could mention if line can be edited by other means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, args, return, usage, caveats. However, includes redundant bilingual text (Spanish and English) for the same caveat, making it longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites (active sketch), return value (geometry), param semantics, and key limitation (non-parametric). No output schema but return described. Sufficient for a simple line tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
0% schema coverage, so description compensates by explaining x1_mm/y1_mm as start point, x2_mm/y2_mm as end point, units in mm, and sketch-local frame. Adds meaningful context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Draw' and resource 'line on active sketch'. Distinguishes from sibling tools like create_rectangle, create_arc by specifying it's for lines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite (active sketch via create_sketch), use case (building block for non-rectangular profiles before extrusion), and limitation (not parametric, must rebuild for resizing). Provides alternative action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It reveals that the tool returns a JSON with tool_count and tools array, and emphasizes it is authoritative and live. While it does not detail edge cases or failure modes, it gives sufficient behavioral context for a simple inventory tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using a bilingual format (Spanish and English). Every sentence adds purpose or usage guidance. Slight redundancy due to bilingual repetition, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero params, no output schema), the description completely explains its purpose, return structure, and usage context. No gaps remain for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage (empty). The description adds value by specifying the return format, compensating for the lack of output schema. It explains what the caller gets, which is beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an authoritative live tool inventory listing only names. It distinguishes itself from siblings by noting that full descriptions already ship with tools/list, so this call confirms the surface without duplicating context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: call this to confirm the live surface or an exact tool name without re-paying for docstrings. Implicitly suggests not using it when full descriptions are needed, but no explicit 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the effects of each state (suppressed: hidden, excluded from BOM; resolved: fully loaded; lightweight: graphics only) and config_scope options. With no annotations provided, this adds essential behavioral context. It does not mention prerequisites (e.g., active assembly) or side effects (e.g., performance implications), but overall it is transparent enough for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose due to bilingual content (Spanish followed by English), but the English portion is well-structured with a clear purpose, usage, and parameter list. It is front-loaded with the core action. The bilingual redundancy could be trimmed for conciseness, but it remains functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description covers the states, scopes, and return value adequately. It lacks error handling or edge-case details, but the provided information is sufficient for typical use cases. The description is complete enough for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does so excellently by detailing each parameter: component_name source, state options with definitions, config_scope options, and config_names requirement with examples. This provides far more value than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 specific verb and resource: 'Cambiar el estado de carga de un componente' / 'Set a component's load state'. It provides concrete use cases (configuration variants, lightweight for large assemblies), making the tool's intent unambiguous and distinguishing it from siblings like set_components_suppression and set_mate_suppression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes typical usage scenarios: suppress/resolve for variants and lightweight for performance. This gives clear guidance on when to use the tool. However, it does not explicitly exclude cases where it should not be used or mention alternatives (e.g., set_components_suppression for batch operations), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool returns a checklist with three checks, explains that a red check on 'Active document' is normal if no part is open, and that a red check on 'SolidWorks connection' in live mode requires opening SW. Also mentions mock mode. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual (Spanish then English) and includes a junior workflow, which adds context but makes it longer than necessary. It is front-loaded with purpose, but some redundancy exists (e.g., both Spanish and English versions of purpose). Adequate but not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description includes a sample return object covering the checklist structure and behavioral notes. It explains edge cases and mock mode. Could mention idempotency, but overall sufficiently complete for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage, so baseline is 4. No parameter information needed in description beyond what schema provides, and description does not add any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a diagnostic to verify MCP_CAD installation. It explicitly mentions checking server response, SolidWorks connection, and active document, distinguishing it from sibling tools that perform modeling or manipulation tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool: after installation or when something seems off. It provides a junior workflow example. No explicit when-not-to-use but given the tool's unique diagnostic purpose, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It explains lines must be adjacent, sketch must be in edit mode, chamfer is 45° equal-distance, internal API may fail, and returns metadata. Very transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is bilingual (Spanish/English), doubling length unnecessarily. Essential info is front-loaded but redundancy reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description says returns metadata. Covers prerequisites, gotchas, and parameter usage. Adequate for a simple tool, though output details could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It clearly explains each parameter: line1_x_mm, line1_y_mm as a point on first line, line2 similarly, distance_mm as chamfer distance, and z_mm default. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it cuts a sketch corner with a 45° equal-distance chamfer, replacing a vertex with an inclined line. It distinguishes from sibling tools like add_sketch_fillet (rounds corners) and chamfer (3D edge chamfer).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides typical usage for CSWA Tool Block, prerequisites (sketch in edit mode, lines adjacent), and a gotcha with workaround. Distinguishes from 3D chamfer. Lacks explicit when-not-to-use but otherwise strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states read-only behavior, caveat about default material, and details the return fields with units. It could mention performance or side effects, but for a read-only tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, detailed return fields, caveat, common use cases, and an example. Every sentence adds value and it is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description thoroughly explains the return dictionary with units, field names, and interpretation. It also provides common use cases and prerequisites, making it complete for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so description does not need to add param info. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads mass properties for the active part or assembly. The verb 'get' and resource 'mass properties' are specific, and it distinguishes from sibling tools by being a read-only query tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions it is read-only, works on both part and assembly, requires a material to be set, and provides a common usage example with set_material. It does not explicitly list alternatives, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the data is in-memory and clears on server restart (transient nature). Does not claim side effects, and the return format is fully specified. No annotations exist to carry burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Bilingual but still concise with only three sentences plus return format. One redundant translation can be excused for inclusivity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully specifies return structure and behavioral traits (in-memory, clears on restart). Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so no additional info needed. The description is complete for zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns plans recorded in the current session for debugging. It specifies the four types of plans (assembly plans, feature plans, batch jobs, macro jobs) and distinguishes itself from sibling record/run tools as a retrieval tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'useful when LLM forgets a plan ID' providing clear usage context. While it doesn't explicitly list when not to use, the debug-aid framing and sibling tool set provide sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it creates and activates a new empty assembly using a default template, returns a dictionary with specific fields, and notes that it does not launch SolidWorks. It does not mention potential side effects like unsaved changes, but for a 'new' operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences in Spanish and English, front-loaded with the main purpose, includes return value specification and a caveat. No wasteful words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is complete: it explains what the tool does, what it returns, and a prerequisite. It covers all needed information for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameters. Baseline for 0 parameters is 4. The description adds no parameter information since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Crear' (Create) and resource 'ensamble nuevo y vacío (documento .SLDASM)' and explicitly distinguishes it from siblings like new_part by specifying it's an assembly. It clearly states the purpose as the starting point for inserting components and mates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is the starting point for assembly creation. It includes a caveat that SolidWorks must already be running, which is a usage prerequisite. However, it does not explicitly state when not to use it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description discloses that it removes material (subtractive), gives parameter constraints (axis_name same as revolve_sketch, angle_deg range, reverse_direction), return type, and an example. Does not cover error conditions or prerequisites in depth, but adequate for a straightforward cutting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (~120 words), well-structured with title, explanation, use cases, parameter list, return type, and example. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input constraints, use cases, example, and return type. References sibling revolve_sketch for axis constraints. Does not explicitly require an active closed sketch, but example implies it. Adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description adds significant meaning: axis_name must come from create_reference_axis, angle_deg range (0,360] with default 360 and typical full-circle use, and reverse_direction flips sense. Example further clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool removes material by sweeping a closed sketch profile around an axis, using specific verbs and resource. It distinguishes from revolve_sketch by noting it is subtractive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific autoparts use cases (O-ring grooves, retaining-ring grooves, etc.) and notes it is a mirror of revolve_sketch but subtractive. Could be improved by stating when not to use or comparing to alternatives like extrude_cut, but sufficient for domain context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the tool restores all suspended operations and returns a specific value. This is transparent for a simple tool, though it does not discuss error cases or what happens if no rollback is active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus a return value example. It is front-loaded with the Spanish and English explanations, no filler. Every sentence is necessary and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description explains the purpose, the effect, and the return format. It is fully 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description naturally cannot add parameter info beyond the schema. As per guidelines, zero parameters baseline is 4, and the description adds no extraneous information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rolls the feature tree forward to the end, undoing a prior rollback_to_feature. It uses a specific verb ('restaurar'/'roll forward') and explicitly references the sibling tool rollback_to_feature, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after a rollback_to_feature has been executed, but it does not explicitly exclude cases where no such rollback was done or compare with alternatives like undo. The context is clear but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses locale sensitivity, effects on mass but not geometry, and the return value. The caveat about changing material affecting mass/inertia is well-stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-structured with sections and bullet points. It is front-loaded with the main purpose and includes an example. Every sentence adds value, though some redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (material assignment affecting downstream calculations) and absence of output schema, the description covers prerequisites, effects, return format, caveats, and usage examples. It is fully complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides extensive parameter semantics: examples for name (including locale sensitivity), usage explanation for database_path, and the format/requirements. This far exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'set the material on the active part' and distinguishes it from sibling tools. It also notes the prerequisite for get_mass_properties, providing specific verb+resource clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Required before get_mass_properties returns a meaningful mass,' and provides an example usage. It could be improved by mentioning when not to use or alternatives, but it gives clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool creates three mates to fully constrain components, and includes return format (Dict with mates list). It does not mention destructive behavior or auth, but the behavior is well-disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with summary, context, args, example, and returns. It is front-loaded and clear, though slightly lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes return type and structure. It covers behavior, parameters, constraints, and example. The context is 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter is explained: component names must be from get_active_assembly_info, and face positions must be opposite ends of same axis. An example is provided. Schema coverage is 0%, but the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it stacks two components with full constraint (3 mates in one call) and explains the difference from a single face mate. It distinguishes from sibling tools like add_mate_by_face_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides typical use cases (stacking parts for assembly fixtures, mounting speaker on plate) and implies when to use this over single mates. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains destructive behavior (replaces vertex with arc), that SW picks closest segment, and constraints (adjacent lines). Returns metadata. Good coverage for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded. The English portion is efficient, two sentences followed by a usage note and parameter explanations. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and no output schema, the description covers purpose, parameter semantics, prerequisites (edit mode), constraints (adjacent lines), and related tools. Sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description adds meaning for all 5 required params: explains that line1_x_mm/line1_y_mm are points on first line near corner, similarly for line2, radius_mm is fillet radius, z_mm is Z-coordinate default 0. Fully compensates for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it rounds a sketch corner with a tangent arc between two adjacent lines, replacing the vertex. It includes a typical use case (CSWA Tool Block R3) and distinguishes from siblings add_sketch_chamfer and fillet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: sketch must be in edit mode, lines must be adjacent, and gives a typical use case (R3). Mentions related tools. Lacks explicit when-not-to-use but is informative about requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes that rectangle is added to most recent sketch, returns geometric properties, and includes caveats about non-parametric dimensions (modify_dimension cannot resize). Could be slightly more explicit about error behavior if no active sketch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (Args, Returns, Example, Caveats, Related). Concise but includes necessary details. Slightly verbose due to bilingual caveat, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description mentions return of geometric properties (width and height). Covers prerequisites, usage, and limitations. Lacks exact return format but sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains parameters: two corner coordinates (x1_mm, y1_mm and x2_mm, y2_mm). Provides an example tying parameters to real-world usage, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it draws a corner-defined rectangle on the active sketch, specifying the resource (rectangle) and action (create). It distinguishes from sibling tool 'build_rectangular_pocket' which combines sketch and cut.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions requirement for an active sketch via 'create_sketch first'. Provides related tool 'build_rectangular_pocket' as an alternative for rectangular pockets. Gives clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses critical behavioral traits: non-parametric nature (re-radiusing requires deleting the feature), tangent propagation collapsing edges, and the return format. It also explains edge filtering behavior for circular edges. These details exceed what annotations typically provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a brief summary, usage context, detailed parameter explanations with defaults and recommendations, return format, caveats, and examples. Every sentence adds necessary value without redundancy, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is highly complete. It covers all parameters, return value explicitly with field names and types, caveats about non-parametric behavior and feature collapse, and three practical examples. It also incorporates domain-specific context (ISO 8062, autoparts).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining every parameter: radius_mm default and recommended ranges for different contexts, tangent_propagation behavior, min_edge_length_mm skip logic, body_name scoping, and include_arcs rationale. This provides actionable meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'fillet every edge (linear and circular by default)' and frames it as a composite for 'redondea todo' in one call. This specific verb+resource differentiates it from the sibling 'fillet' tool, which likely handles selective edges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance with domain-specific examples like cast/forged parts, structural brackets, and plastic injection-molded parts, including suggested radius ranges. However, it does not directly contrast with the sibling 'fillet' tool or specify when not to use this tool, slightly limiting guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: read-only nature, handling of unknowns ('through=None over COM'), occluded cuts needing verification via other tools, and the bores inventory derived from face geometry. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and well-structured but slightly verbose. It front-loads the purpose and then elaborates on specifics. Every sentence adds value, though minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool and absence of output schema, the description thoroughly explains the return structure: per-feature fields, bores fields, and edge cases (unverified, occluded). It covers all necessary context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined, so schema coverage is 100%. The description adds no parameter info since none exist, meeting the baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'Inventario completo de operaciones — one read of EVERY feature in the tree' with detailed per-feature info and a separate bores inventory. It distinguishes from siblings like describe_feature or list_faces by its comprehensive scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises to 'USE BEFORE modifying any multi-feature part' and provides a workflow: enumerate, modify, re-call, confirm. This gives clear context for when to use, though it doesn't explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: return structure, durability of indices, midpoint behavior (None for closed loops), and the caveat about coordinate matching. This exceeds what annotations would typically cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with clear sections for return fields, args, use case, caveat, and example. It is front-loaded with the purpose, and each sentence adds value, though some fat could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, output schema exists), the description fully covers the return structure, durability, usage context, and example. It is complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter 'body_name' is well explained: if given, return edges of only that body; otherwise, return edges of all solid bodies. This adds meaning beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates edges of solid bodies, with a specific verb ('Listar' and 'enumerate') and resource ('edges of one or all solid bodies'). It distinguishes itself from sibling tools like list_faces or list_dimensions by focusing exclusively on edges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly describes the use case as a pre-fillet/pre-chamfer LLM workflow, providing clear context. It does not explicitly state when not to use it or compare to alternatives, but the context is sufficient for the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. Discloses creation and activation, default template usage, return values, and caveats about legacy creation and need for running SolidWorks. Lacks details on error handling but covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Bilingual but well-structured: summary, usage guidance, return type, caveat. Each sentence adds value. Slightly longer due to translation but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, description covers purpose, usage, prerequisites, and return format completely. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. Description adds context about template usage but no parameter info needed. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Crear una pieza nueva y vacía') and the resource (SolidWorks .SLDPRT document). It distinguishes from siblings like 'new_assembly' and geometry tools that require an active part.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when no part is open or starting fresh, and that geometry tools need an active part. Also notes that SolidWorks must already be running, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behaviors: bistable nature of angle/distance mates, rebuild flipping risk, and the purpose of the pose_held check. This provides deep insight into the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, then detailed explanation, then an Args list. It is slightly verbose but every sentence contributes value. Could be tightened slightly without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (combined position + mate) and lack of output schema, the description covers the purpose, parameters, and behavioral output (pose_held check). It could detail the return structure more but is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds detailed meaning for each parameter, including the structured format for mates with fields like type, entity1_id, align, etc. This compensates fully for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the dual action: 'pose a component exactly, THEN create its mates.' This distinguishes it from sibling tools like add_*_mate and move_component, which only handle one aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'branch-safe mating recipe' explains when to use this tool (for precise positioning before mating) and what to look for after (pose_held flag). It lacks explicit when-not-to-use but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states reversibility, that nothing is destroyed (nada se destruye), and that it suspends the feature and everything after. Provides clear behavioral context beyond basic read/write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with separate sections for what it does, reversibility, args, returns, and related. However, it is bilingual (Spanish and English) adding some redundancy; could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter and no output schema, description covers the return shape, mentions exact naming, and lists related tools. All necessary context for correct usage is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description adds example value 'Cortar-Extruir1' and specifies 'exact feature name'. This adds meaning beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'roll back' and resource 'feature tree to just BEFORE the named feature'. Distinguishes from deletion-based undo by calling it the 'no-deletion way', and names alternative rollback_to_end for restoration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'no-deletion way to undo a wrong feature'. Tells when not to use by mentioning alternatives: rollback_to_end for restore, set_component_suppression for assembly-level, undo as coarse not reversible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description thoroughly discloses file-by-file execution, reporting of skipped files, return object keys (ok, changed, skipped, inspected, failed, manifest, failures, log_path), read-only verbs counted as 'inspected', and no deletion (deferred deletion). All behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat lengthy due to bilingual content and detailed gate explanation, but it is well-structured with numbered gates and front-loads the main action. Could be tighter without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers overall behavior, return value keys, and gates adequately. Given no output schema, description provides necessary details but could elaborate on error cases (e.g., missing batch_job_id) or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description explains all three parameters: batch_job_id (implied the recorded batch job), override_warnings (gate 2 override for risky warnings), and override_low_confidence (gate 1 override). Adds essential meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Ejecuta un BatchJob registrado' (execute a recorded batch job) with specific verb and resource. It distinguishes from siblings like run_assembly_plan, run_feature_plan, and run_macro_job by emphasizing file-by-file application, complete manifest, and human approval step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly positions this as the human approval step and outlines three gate levels with conditions for override. It lacks explicit 'when not to use' but provides sufficient context via gates and references similar tool run_assembly_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses locale sensitivity for entity names, align parameter, and return of mate metadata. However, lacks details on error handling or side effects (e.g., does it modify assembly state?). Still adds significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and bilingual content. Could be slightly more concise by omitting Spanish repetition, but front-loads core purpose and uses clear formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 5 parameters, required fields, typical usage, return value, and related tools. No output schema, but description adequately describes return as mate metadata. Complete for a mate tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates fully. Explains each parameter: component names from get_active_assembly_info, entity ID strings (locale-sensitive), and align values. Provides context beyond schema (e.g., copy verbatim note).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it aligns axes of cylindrical/conical entities via a concentric mate. Provides specific verb ('alinea ejes' / 'align axes') and resource. Distinguishes from siblings like add_mate_by_face_position and stack_components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes typical autoparts use cases (bolt+sleeve, sleeve+shaft, two bearings). Mentions related tools for alternative approaches, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: resolution of face positions based on normal vectors, coordinate frame details, defaults for Pieza-style parts, and explanation of mate_type, align, distance_mm. No contradictions or hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual (Spanish then English) and well-structured with a clear Args list, example, and explanatory notes. It is slightly verbose but every sentence adds value. Could be trimmed but organization is excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and 0% schema description coverage, this description is highly complete. It explains all parameters, provides default behavior, gives a concrete example, and explains the coordinate system. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% schema description coverage, so the description must compensate. It does so thoroughly: each of the 7 parameters is explained in the Args section with defaults, allowed values, and context (e.g., coordinate frame for positions, default align). Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: creating a mate between two components using face positions. It specifies the verb (add_mate), resource (components), and distinguishes from sibling tools by using position keywords instead of face indices. The example solidifies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: as a convenience wrapper to avoid locale-sensitive face-index handling. It provides context about interpreting position keywords in local coordinate frame. However, it does not explicitly mention when not to use or alternatives like add_coincident_mate, though the convenience argument implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully discloses behavior: driving dimension, auto-naming, dimension type inference based on point selection, value override forcing geometry update, text offset defaults, and return of dim name. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections for purpose, arguments, returns, requirements, and gotchas. However, it includes both Spanish and English, making it slightly longer than necessary for an English-only agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 0% schema coverage, no annotations, and presence of output schema (not shown), the description covers all necessary aspects: function, parameters, usage flow, return value, prerequisites, and a gotcha. It is fully adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description explains each parameter's purpose and usage: entity_x/y/z_mm as a point on the sketch entity, value_mm as desired dimension value that overrides geometry, text_offset_x/y_mm for cosmetic placement with defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool adds a driving dimension to a sketch entity at a given point with auto-naming. It implicitly distinguishes from siblings like add_sketch_relation and modify_dimension by focusing on dimension creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the sketch must be in edit mode and should be called after sketch creation and before closing. Provides a typical CSWA use case and a gotcha about dimension type inference. Does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It discloses multiple behavioral traits: loop validation before SW calls, leaving the sketch open, exact mode to prevent drift, fallback behavior, and call atomicity. This is thorough and honest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bilingual sections, bullet points, and clear examples. It could be slightly more concise, but the complexity of the tool justifies the length. Front-loads key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, nested segment objects, and no output schema, the description covers all necessary aspects: input format, behavior, return shape, notes on atomicity, and related tools. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only type and title for parameters (0% schema description coverage). The description compensates fully by explaining each parameter: plane (aliases), segments (detailed format with coordinate examples), close (auto-closing behavior), exact (exact mode vs inference, drift trade-off), name_hint (unused), and variables (parametric evaluation). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a closed profile from an ordered list of segments in one call, contrasting with creating multiple primitives. It specifies validation, leaving sketch open, and targets specific use cases like the CSWA Tool Block. This distinguishes it from siblings like create_line/create_arc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a typical use case and references related tools (add_sketch_relation, extrude_sketch). However, it does not explicitly state when to avoid using this tool (e.g., when you need individual primitives or open profiles). The guidance is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the orientation contract (L-profile in Front plane, extrusion direction, bolt hole drilling direction), that it creates multiple features, returns a dict with feature info, and a caveat about sharp inside corner. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but highly structured with sections for Args, Returns, Geometry, Caveat, Example. It is front-loaded with a clear one-liner. Every section adds value, so it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description covers everything: return dict details, geometry orientation, parameter constraints, a caveat, and an example. It is complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema). The description adds detailed explanations for each parameter: constraints (e.g., leg lengths must be > 2×thickness), defaults, and meanings (e.g., 0 = no bolts). This compensates fully for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an L-shaped bracket with bolt holes, using specific verbs and resource. It distinguishes from siblings by noting it wraps multiple operations into one call, providing a unique value proposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage context: typical use case (autoparts bracket), a junior workflow example, physical dimensions, constraints, and an example. It doesn't explicitly state when not to use it, but the context is rich and clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 explains the effect of reverse_direction, end_condition, and target_bodies in detail, including edge cases like cutting into air. It also mentions the return type (Cut-Extruir Feature info).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, workflow example, parameter list, and usage example. It is slightly long but each sentence adds value. The front-loading with the Spanish purpose and junior workflow is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 5 required, no output schema, no annotations), the description is highly complete. It covers purpose, parameter semantics, behavioral details, and provides a concrete example. It leaves little ambiguity for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), so the description must compensate. It provides thorough explanations for all 9 parameters, including constraints (e.g., width_mm > 0), defaults, and coordinate system context for center_x_mm and center_y_mm. The example also illustrates usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Hacer un vaciado rectangular en una sola operación' (Make a rectangular pocket in a single operation). It distinguishes itself from sibling tools like extrude_cut, create_rectangle, and create_sketch by combining these operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a junior workflow example showing how to use the tool, and implies it is a shortcut for create_sketch + create_rectangle + extrude_cut. However, it does not explicitly state when not to use it or mention alternatives, though 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes internal composed workflow, return metadata, and parameter effects (merge, angle). Caveats about orientation and transitions add transparency. Could be more explicit about safety (additive vs destructive), but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, workflow, args, returns, caveats, and example. Front-loaded with purpose. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description covers all necessary aspects: argument constraints, return values, caveats for orientation, transitions, and tapering. Includes an example for clarity. Complete for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides no parameter descriptions (0% coverage). Description compensates by explaining each parameter: diameters and lengths constraints (1-20, >0, same length), angle_deg default and use for sectors, merge behavior. Adds meaning beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates a stepped multi-diameter shaft in one call, with examples and distinction from primitive sketch tools. The title and description align with the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance via junior workflow example and caveats that tell when alternative tools (revolve_sketch) should be used. Also lists limitations (square shoulders, no taper, fixed orientation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses failure modes (via fillet reference), batch-all-identical-edges rule, default values, parameter constraints, and return value. Very transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and example, but slightly verbose. Could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, parameters, return value, and industry context. Lacks details on error handling and edge cases, but overall comprehensive given complexity (7 params, no output schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds substantial meaning to most parameters (e.g., edge_midpoints_mm from list_edges, distance_mm typical values, angle_deg default). However, 'edge_circles' parameter is not explained, and schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'bevel one or more edges (distance + angle)' with specific verb and resource. Distinguishes from sibling 'fillet' via explicit reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides extensive guidelines: references fillet for identical rules, offers example, lists standard autoparts use cases, and mentions deferred types. Explicitly tells when to use and alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: requires an active sketch, the circle geometry is non-parametric (modify_dimension cannot resize), and rebuilding from a fresh part is needed for resizing. It also mentions return values, providing complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main sentence, parameter details, example, and caveats. The bilingual caveat adds length but serves multilingual users. Overall efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, no output schema, and low schema coverage, the description covers purpose, parameters, usage, behavioral traits, and alternatives comprehensively. The return value indication and example complete the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description thoroughly explains each parameter: cx_mm/cy_mm as center point, radius_mm as radius with positivity constraint, and long-form aliases. It clarifies that only one name per axis should be passed, adding essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws a circle on the active sketch with a specific verb and resource. It distinguishes from the sibling tool add_bolt_circle by suggesting the latter for multiple holes, enhancing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage, including an example, parameter constraints, and a recommendation to use add_bolt_circle for bolt patterns. However, it does not explicitly state when not to use the tool, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses behavior: two modes, world-axis mapping, and limitations of single-reference. Lacks error handling details but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headings, table, and example. Somewhat long but every sentence adds value. Slight room for trimming.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a tool with 2 params, no output schema, and no annotations. Covers all aspects: modes, usage, output format, example, and internal use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Compensates for 0% schema coverage with detailed parameter explanations, including naming conventions and examples. Clearly explains reference_name and reference_2 semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a reference axis from two planes or a single feature. It distinguishes the two modes and provides a use case, differentiating it from sibling tools like create_reference_plane.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use each mode: two-plane recommended for v1, single-reference limited. Provides a use case for circular_pattern and warns about limitations of single-reference mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the COM driver degrades to feature-tree dims and through/depth may be None. It also warns about locale sensitivity for the feature_name parameter, providing essential behavioral context beyond a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro, return fields, usage context, and parameter details. It is fairly long but each sentence adds value. Slightly more concise formatting could improve readability, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter, no output schema, and no annotations, the description is highly complete. It explains return values, differences in execution contexts (add-in vs COM), and parameter specifics, fully covering what the agent needs to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage (no description for the parameter). The description compensates fully by explaining that 'feature_name' must be the exact name from get_active_part_info, verbatim, locale-sensitive, and never translated. This adds critical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'read a built feature's definition' and lists specific return fields (name, type, found, through, depth_mm, internal, source). It is specific and distinguishes from siblings like get_feature_inventory or get_active_part_info by focusing on describing a single feature's definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by stating it is 'used by verify_build_report to tell a through-hole from a blind one and read its depth'. It also explains the rich path vs COM driver degradation. However, it does not explicitly state when not to use this tool or mention alternatives, though 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it suppresses redraw, feature tree, and rebuild during processing, performs one rebuild at the end, and enforces all-or-nothing semantics with rollback on failure. It also details the verify parameter options and advises against per-feature rendering. The return structure for both success and failure is described, providing complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a main explanation, an English summary, an Args section, and additional notes on semantics and return values. It is comprehensive but not overly verbose, though it could be slightly more concise. The key concept is front-loaded, and the organization aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly covers return values, error handling, and behavioral aspects. It provides all necessary information for correct usage, including restrictions on operations and the all-or-nothing rollback mechanism. The sibling tools list includes many individual low-level operations and composite builders, and this tool's description clearly positions it as the batch primitive complementing those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries full burden. It adds crucial semantics: ops must be an array of objects with 'tool' (protocol operation name) and 'args' (matching exact parameter names), and clarifies which operations are allowed. verify is explained with its 'summary' vs 'none' options, and rebuild is described regarding rebuild suppression. This far exceeds the schema's minimal information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool executes an ordered list of low-level operations in a single pass, following a 'compile once, build once' approach like build123d. It distinguishes from separate calls by emphasizing efficiency gains, and explicitly states that it cannot invoke arbitrary API or composite build_* operations, making its purpose very specific and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use this tool instead of N separate calls for efficiency, ensure each operation is a protocol operation (not composite or perception/IO), and avoid nesting batch calls. It explains the parameters rebuild and verify with appropriate defaults and recommendations. However, it does not explicitly state when not to use it beyond the restrictions, which is sufficient for an advanced tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states prerequisites (active sketch, intersecting material), failure behavior (sketch reopened), and caveats (bug with reference planes in up_to_surface). Returns a Feature with name, type, dimensions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Args, Returns, Caveat, Failure recovery, Example, Related composites) and front-loaded with the core action. It is somewhat verbose given the complexity but remains organized and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no output schema, and complex interactions, the description covers all necessary context: failure modes, edge cases, parameter dependencies, return value, and even a known bug workaround. It is thoroughly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides detailed explanations for all 9 parameters, including meaning, defaults, interactions (e.g., depth_mm ignored for certain end_conditions), and workarounds. This far exceeds the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cuts material from a part, exiting the active sketch. It provides specific verb+resource ('cut material from the part') and distinguishes from siblings like extrude_sketch (adds material) by contrast in examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when to use each end_condition with examples (bolt holes, slots, etc.) and mentions related composites (build_rectangular_pocket, add_bolt_circle). It does not explicitly state when not to use this tool vs alternatives but covers usage context well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that components are top-level only (no recursion) and lists all included metadata. Being a read-only query, no side effects are expected, but the description could note it's safe. Still, transparent given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: first states purpose and contents, second provides usage guidance. No fluff; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description lists key return fields (name, flag, configurations, components, mates). Lacks format details but sufficient for an agent to understand what entities exist. Could be more precise about return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% with zero params. The description adds meaning by explaining what the tool returns, but parameter semantics are trivially satisfied due to absence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns metadata about the active SolidWorks assembly, listing specific items like assembly name, modified flag, and configurations. It distinguishes from siblings like get_active_part_info by focusing on assemblies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling before mate/suppression/configuration operations so the LLM knows existing entities. No alternative tools mentioned, but the guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains it returns metadata without side effects. While it doesn't explicitly state 'read-only', the context of returning information implies no modifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states purpose, second details content, third gives usage guidance. Front-loaded, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description fully covers what the tool returns and its intended use case, including a specific reference to extrude_cut. Complete for a read-only query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline for 0 parameters is 4, and description adds no additional parameter details as none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns metadata about the active SolidWorks part, listing specific data (part name, modified status, features with dimensions, solid bodies). It distinguishes itself from siblings like get_active_assembly_info and other inspection tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: 'Use this to inspect what's in the current part before suggesting modifications' and to discover body names for extrude_cut. It implies not to use for assemblies, referencing a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It states read-only behavior, lists all return fields with types and units, explains multi-body union behavior, and includes an example with assertions. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet complete, front-loading the purpose and read-only nature, followed by a structured list of return values, behavioral notes, use cases, and an example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the return format, units, multi-body handling, and coordinate frame. The example demonstrates practical usage, making the tool easy to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty. Per guidelines, this earns a baseline of 4. The description does not need to add parameter information since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the overall axis-aligned bounding box of the active part or assembly in mm, and explicitly declares it as read-only. This distinguishes it from sibling tools like get_mass_properties or get_feature_inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides three common use cases (stock selection, sanity check, nesting) that indicate when to use the tool, but does not explicitly mention when not to use it or compare it to alternative tools. However, no direct alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the first component is auto-fixed, subsequent components require mates, and floating components are invalid. It also states the return type (instance metadata). It lacks details on error handling or permissions but provides essential 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose and important caveat. The parameter list is clear but slightly verbose. Overall, every sentence adds value, but the parameter descriptions could be more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in a complex CAD workflow, the description covers the insertion action, critical mating requirement, parameter details, return value, related tools, and a reference to full workflow documentation. It provides sufficient context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully explains each parameter: file_path, x_mm/y_mm/z_mm (insertion point), and config_name. It adds meaning beyond the schema by specifying file type (.sldprt or .sldasm), coordinate frame (assembly frame), and default behavior for config_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inserts a part or sub-assembly into the active assembly at given XYZ coordinates. It distinguishes from sibling tools like place_and_mate and the various mate tools by emphasizing that this tool only inserts and does not mate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool and what additional steps are needed. It warns that insert_component alone does not finish the job, explains the auto-fix for the first component and the need for mates thereafter, and suggests calling get_active_assembly_info or asking the user if mating entities are unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: auto-activation, type inference from extension, returns a structured object, raises specific errors (ValueError, SolidWorksError for various conditions), and caveats about using OpenDoc (not OpenDoc6) and duplicate name behavior. It also provides a warning about OneDrive path discrepancy. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (main description, args, returns, raises, caveat, example) and uses both Spanish and English. It is somewhat verbose (e.g., repeating type info in args and returns) but every sentence serves a purpose. It is front-loaded with the primary function. A slightly tighter rewrite could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (SolidWorks document handling), no output schema, and no annotations, the description is complete. It covers return values, error conditions, behavioral caveats, and integration with active document tools. The example demonstrates typical usage. The agent has enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' has 0% schema description coverage, so the description must add meaning. It does so extensively: path must be absolute including extension; extension determines document type; lists valid extensions and their types; warns about invalid extensions; provides example path; and explains OneDrive path handling. This goes far beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: opening an existing SolidWorks document by absolute path. It specifies supported file types (.SLDPRT, .SLDASM, .SLDDRW) and mentions that the document becomes active, directly relating to sibling tools like get_active_part_info. The verb 'Abrir' (Open) and resource 'documento de SolidWorks existente' are specific and not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: it is for modifying saved parts without rebuilding from scratch. It also includes a caveat about OneDrive paths for Spanish Windows. However, it does not explicitly contrast with sibling tools like new_part or close_active_document, though the active document effect implies its role in a workflow. A clear when-to-use vs alternatives is missing, but the guidance is still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clarifies that the tool is non-mutating (dry-run), returns preview and warnings, and notes constraints like geometry not being transmitted and network path warnings. It could add more about permissions or side effects, but overall is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured with bullet points and clear sections for arguments and return value. It is informative without being excessively verbose, though some minor redundancy exists (e.g., repeating the preview cap in args and return). Still, it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema), the description covers inputs, behavior, and output structure thoroughly. It lists return fields (batch_job_id, matched_files, preview, etc.) and explains the advisory nature. An agent can fully understand how to invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining all 8 parameters in detail, including examples for 'intent', 'fileset', 'operation', and describing defaults and behaviors for 'save_after', 'continue_on_error', 'out_dir', 'confidence', and 'preview_cap'. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to register a batch job and return a dry-run preview without mutating data. It uses specific terms like 'Registra un BatchJob' and 'VISTA PREVIA EN SECO' and distinguishes from the sibling tool 'run_batch_job' which executes the batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to get a preview for human approval before executing with run_batch_job. It says 'Revísala; luego ejecútalo con run_batch_job', providing clear guidance on workflow and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It explicitly states 'Advisory only: does NOT mutate SolidWorks', clearly disclosing the non-mutating behavior. It also describes return values and the role in the pipeline, offering full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is fairly long but well-structured, starting with purpose and key note, then listing args, then returns. It is front-loaded with the most important information. A bit verbose but justified by the number of parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description covers purpose, behavior, usage, all parameters, and return values. It references a document for more info. For a complex tool with 11 parameters, this is complete and provides all necessary context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates fully by providing detailed parameter descriptions, including structure, allowed values, and notes. Each parameter is explained with examples and constraints (e.g., archetype options, internal_features types). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool records a structured drawing spec and distinguishes it from sibling tools by noting it is advisory-only, non-mutating, and part of a pipeline (compile_feature_plan_from_drawing_spec -> run_feature_plan). It also mentions the legacy path, providing specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use the tool (to record a parsed spec for deterministic build) and what it does not do (does not mutate SolidWorks). It references a pipeline flow but does not explicitly list alternatives or when not to use it. Still, the context and explicit mention of legacy path provide good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: axis constraints, error conditions, merge behavior, return type (boss_revolve), D1 meaning, and a caveat about sketch parametric limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and includes a useful example. It is slightly verbose with bilingual repetition and parameter explanations that could be more terse, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return type (boss_revolve), key dimension D1, and a critical caveat about non-parametric sketch dimensions. The example and parameter details make it fully complete for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains all four parameters in detail: axis_name with acquisition and constraints, angle_deg with range and examples, reverse_direction with impact, and merge with multi-body implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool revolves a closed sketch around an axis, and provides a list of typical turned parts (shafts, bushings, flanges, etc.), distinguishing it from sibling tools like extrude_sketch or revolve_cut.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (turned parts, full vs partial revolutions) and includes a caveat about axis placement and profile crossing. It does not explicitly exclude alternatives, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description reveals key behaviors: it is the human-in-the-loop approval, executes all mutating steps in one batch with deferred rebuild, runs verification once at end, and enforces gates for low confidence and unmodeled internal features with separate overrides. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is dense but well-structured: purpose, workflow (both in Spanish and English), then two gate paragraphs. Every sentence adds value, no fluff. Could be slightly more streamlined, but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no schema description, no output schema, the description covers usage, gates, and return (verify_build_report). Missing a bit of detail on the exact return structure, but mentions it briefly. Complex tool with good coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains all three parameters in context: feature_plan_id (implied), override_low_confidence (force partial/handback plans), override_unmodeled_internal (build without unmodeled internal features). It also clarifies they are independent flags. However, no dedicated parameter descriptions, so slightly below perfect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Build a compiled FeaturePlan in ONE pass' and specifies it is the approval step for the whole build. It distinguishes from siblings like compile_feature_plan_from_drawing_spec and verify_build_report by providing a workflow (step 3).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends a 4-step workflow with context for when to call this tool (after plan approval). Also explains when not to use: unresolved dimensions, partial_or_handback without override, unmodeled internal features without override. Provides clear alternatives for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: validation up-front (raises if any missing), config switching optimization per scope, and return dict structure. No annotations provided, so description carries full burden; covers mutation but could mention reversibility or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, usage, params, returns. Bilingual (Spanish/English) adds redundancy; could be more concise by using one language. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 params, no output schema, and no annotations, description covers all necessary aspects: purpose, typical use, efficiency, parameter details, return value. Sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains each parameter: component_names (source, validation), state (enum values with default), config_scope (enum values), config_names (conditional requirement). Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes suppression state of multiple components in one call, with a typical use case (trim-variant BOM prep). It distinguishes from sibling set_component_suppression by noting efficiency (switches config once per config_scope target instead of per pair).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance (suppress multiple components, more efficient than looping set_component_suppression), prerequisites (component_names from get_active_assembly_info, not empty), and conditional requirements (config_names needed with config_scope='specific').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: destructive of face-anchored sketches, thickness constraints, centroid matching tolerance, and outward parameter effect. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with overview, details, caveats, and example. Every sentence adds value, though slightly verbose; still appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description covers all necessary aspects: purpose, parameters, constraints, behavior, caveats, and a concrete example. It is fully sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are explained in detail: thickness constraint, face_centroids source from list_faces, outward meaning, and selector vs face_centroids mutual exclusivity. The description adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool hollows out a body (shell) with optional openings. It uses specific verbs and resources, and distinguishes from sibling operations like extrude or revolve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use shell (common for cast housings, plastic enclosures) and warns to run late in feature tree. It could explicitly name alternatives but gives sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses all key behaviors: uses get_bounding_box, applies max tolerance, volume check is order-of-magnitude only, never flips verdict, and lists caveats (cannot see wrong-location, wrong-topology, envelope-preserving errors). No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a Spanish/English bilingual format and a separate Args section. While fairly long, every sentence adds necessary detail, though some redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description covers input semantics, behavioral details, output structure (dict fields), and caveats. It is fully self-contained for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly documents all five parameters with default values, meanings, and usage notes (e.g., match_by='sorted' vs 'positional', tolerance interplay). This adds significant value beyond the schema which only has titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verifying built-part size against the drawing spec via bounding box measurement. It distinguishes itself as the 'first independent ground-truth check' among sibling verification tools like verify_build_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use (after building, as a ground-truth check) and caveats about what it cannot detect (wrong location, topology). However, it does not explicitly mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the composite nature, bore being 'through_all', reverse_extrude behavior, return structure, and caveats, providing comprehensive behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, workflow, args, returns, caveat, example), front-loaded purpose, and no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and no annotations, the description comprehensively covers all aspects: parameter details, behavior, caveats, return info, and an example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds detailed explanations for all 8 parameters, including constraints (e.g., bore_diameter_mm must be >0 and < outer_diameter_mm), which is absent in the schema (0% coverage). This significantly aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a cylindrical boss with optional through bore, provides a junior workflow example, and distinguishes from sibling tools by specifying the composite operation for a flange boss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a junior workflow example and advises when to use bore_target_bodies to restrict bore scope, and mentions using extrude_cut separately for blind bores. However, it could be more explicit about when to use this tool versus other build siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description thoroughly discloses behavior: it compiles to an op-list and executes as a batch with deferred redraw, all-or-nothing rollback, and single approval. It also describes the return value (execute_batch result plus compiled_ops and summary) and error handling (clear error for invalid DSL).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and examples. However, it is somewhat lengthy due to the list of methods and bilingual content. It could be slightly more concise, but the structure is clear and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (DSL with many methods and options), the description is comprehensive: it explains the grammar, supported methods, edges function, scope options, and fallback behavior. It provides enough context for an agent to use the tool correctly without additional clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides meaningful information for each parameter: script is 'la expresión fluida' with examples, dry_run compiles without affecting SolidWorks, and rebuild triggers a rebuild on batch close. This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it builds a part from a fluent build123d-style script in one call. It specifies the closed grammar and compilation to op-list, distinguishing it from individual geometry tools like create_rectangle or extrude_sketch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool versus alternatives: explicitly advises against using it for sketch-on-face (use create_sketch_on_face instead), and mentions fallback to execute_batch or loose tools for invalid DSL. It provides examples and lists supported methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: opens parts in series read-only, extracts metadata, no network, incremental, and rebuild option. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured paragraphs with front-loaded purpose. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists return fields. For a tool with 3 parameters and simple behavior, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully explains each parameter: folder (recursive, ignores temp files), rebuild (re-reads all), max_parts (limit). Adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool indexes a folder of .SLDPRT parts into a local catalog, distinguishing it from sibling tools that focus on modeling operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on incremental vs rebuild mode and advises running when SolidWorks is idle, but does not explicitly list when to avoid using the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses scope (Mexican-Spanish only), caveats (regional differences, ambiguous terms), version constraints (v1 fixed vocabulary, v1.1 extensible), and the exact return structure including a fallback for missing terms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-structured with sections for purpose, caveats, and example. The first sentence establishes purpose immediately. Every sentence adds value; however, minor trimming could enhance conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema, no annotations), the description adequately covers all necessary aspects: purpose, input, output structure (with fields and example values), and usage context. It is self-contained and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'term' lacks schema description (0% coverage), but the description explains it is case- and accent-insensitive and expects a Spanish/Spanglish autoparts term. An example is provided. Slightly more detail on expected format would push to 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves informal Mexican-Spanish autoparts terms into curated geometric archetypes, alternatives, and disambiguation questions. This distinctively sets it apart from sibling tools that perform CAD modeling operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to call this tool 'when a user uses an informal autoparts term and before proposing a plan', referencing Phase 2/Layer 2. It gives an example ('rin') and details the disambiguation flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adds crucial behavioral context: creating a configuration activates it (changes active config), and it is idempotent. The 'Gotcha' section highlights a live-verified side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (description, args, gotcha, related tool), front-loaded with purpose. Slightly long but not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the tool's purpose, side effects, parameter semantics, and alternatives. Fully adequate for agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates by explaining each parameter: name is unique and idempotent, parent is for derived configs, description is optional. Adds meaningful context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Crear una configuración nueva en la pieza o ensamble activo' with specific verb and resource. It distinguishes from sibling tool build_variant_family by explaining when to use that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use build_variant_family instead of create_configuration, and mentions idempotency for name. Gives clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses the safe nature of configuration deletion (pure metadata, no cascade), preconditions, and return value, ensuring the agent understands the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, constraints, and use case. Slightly lengthy due to bilingual text, but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value ('deleted configuration name') and covers all relevant aspects: purpose, preconditions, safety, and example use cases. Completeness is high for a simple deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'name' with schema coverage 0%, but the description clarifies 'The configuration to delete', which adds meaning beyond the schema title. Slightly lacking format details but sufficient for a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a configuration from the active document' and explicitly distinguishes itself as the ONLY deletion tool in v1 MCP, unlike sibling tools that include other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case (cleanup of obsolete trim variants) and prerequisites (configuration exists, not active, not only one), along with an alternative action (activate a different configuration first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses failure modes (midpoint mismatch, radius too large), non-parametric nature, batching advice to avoid body name shifts, and propagation behavior (tangent_propagation). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and key usage, followed by structured sections: selector explanation, args, returns, failure modes, caveats. Every sentence adds value, and the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers inputs, failure modes, and caveats adequately. It lacks details on the return object beyond name and type, and omits the 'edge_circles' parameter. Slight incompleteness for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds extensive semantics for most parameters: typical radius values, selector schema, edge_midpoints usage, edge_indices format, tangent_propagation effect. However, the parameter 'edge_circles' (present in schema) is not mentioned in the description, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'fillet (round) one or more edges, constant radius' with specific verb and resource. It distinguishes from sibling 'fillet_all_edges' by focusing on specific edges and explains alternative edge addressing methods (selector, edge_midpoints, edge_indices).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use selector vs edge_midpoints vs edge_indices, including recommendations (e.g., 'selector recommended') and exclusions (e.g., variable-radius deferred). It also explains mutual exclusivity of selector and edge_* args.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 thoroughly discloses behavioral traits: constraints on spacing (positive), count (≥2, includes original), reverse parameter, direction reference sources (e.g., Eje1, linear edge, sketch line), and locale sensitivity. It also describes the return value (new pattern Feature with name, type, dimensions). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: one-line summary, use-case context, detailed parameter descriptions with bullet points, and a concrete example. Every sentence adds value without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description is highly complete. It covers all parameter constraints, return value details, and even locale sensitivity. The example demonstrates usage with a related tool. No additional information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does so in detail: feature_names (exact names from get_active_part_info with example), direction_reference (preferred source create_reference_axis, alternatives), spacing_mm (must be positive), count (including original, ≥2), reverse (default false). The example ties it all together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a linear pattern of features in a single straight line. It specifies typical use cases (hole rows, fin arrays, bolt grids) and distinguishes from potential siblings like circular_pattern by noting 'single-direction only in v1'. The verb 'pattern' and resource 'features' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (single-direction linear patterns, defaults for certain part types) and notes that the second-direction variant is deferred. It does not explicitly list alternatives or when not to use, but provides enough context with the example and mention of deferred feature. Sibling tools like circular_pattern are listed elsewhere, but not referenced in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: lists all dimensions from operations and sketches, includes assembly mate dimensions in active assembly, notes internal component dimensions require opening the part, and highlights caveats about renamed dimensions and angular sketch dimension reporting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear paragraphs, front-loaded purpose, and no redundant sentences. Could be slightly more concise, but overall efficient for the amount of information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes return format with structured details, explains behavior in different contexts (assembly vs part), and covers edge cases. No output schema, but description compensates completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% vacuously. Baseline is 4 per guidelines. The description does not need to add parameter info but provides context about the tool's function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists all dimensions from the active document, specifying it includes operations and sketches with exact path, value, and units. It differentiates from siblings like modify_dimension and add_sketch_dimension by framing it as a discovery step for conversational editing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (discovery step before modification), provides precise instructions for mapping spoken values to dimensions, and mentions to pass results verbatim to modify_dimension. Also notes it is read-only, giving clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully discloses behavior: it explains the geometry_pattern parameter (exact copy vs recompute), lists acceptable plane aliases including bilingual support, and describes the return value with an example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and structured with clear Args and Returns sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations and no output schema, the description fully covers all aspects: parameter types, allowed values, behavioral nuances, return value, and a practical example. It is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter description coverage, but the description provides detailed semantics for all three parameters: feature_names requires exact names from get_active_part_info with examples, mirror_plane lists all acceptable forms (default plane aliases, user planes, planar face names), and geometry_pattern explains its behavioral impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool mirrors features about a plane or planar face, with specific use cases for symmetric geometry. It distinguishes from sibling tools like linear_pattern or circular_pattern which create pattern copies, not mirrors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (symmetric brackets, mirrored mounting bosses) and states it's for parts where half is modeled. It does not explicitly mention when not to use or list alternatives, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly declares it is read-only ('asesoría: no muta nada') and provides detailed behavioral constraints: skeleton must be the fixed component, each component must have at least one mate, confidence scale, etc. Since no annotations are provided, the description fully bears the burden and does so excellently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with bullet points for parameters and clear separation of Spanish and English sections. It efficiently uses sentences to convey necessary detail, though slight trimming could improve brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, nested objects, no output schema), the description is highly complete. It covers parameter details, behavioral constraints (e.g., no mates block run), and even describes the return value structure, exceeding what is minimally required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides thorough explanations for most parameters: intent, skeleton (with structure), components (with nested fields), save_path, confidence scale, and use_active_assembly. However, the 'assumptions' parameter is not described, leaving a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a structured assembly plan (SKELETON → list of parts → plan of mates) and is advisory only, distinguishing it from sibling tools like run_assembly_plan. It uses specific verbs and resources, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('before touching SolidWorks'), that it's only advisory, and directs to show plan to designer then execute with run_assembly_plan. Also notes that components with no mates or required params block run_assembly_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses extensive behavioral traits: sequential per-component execution, live per-step receipts, stop-and-report on failure with no deletion, final mate-count gate, and specific override behaviors. This fully compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured: main action, approval context, batch comparison, gate explanations, failure behavior, verification. Each section adds value without waste. Slightly longer than necessary but concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and moderate parameter count, the description is remarkably complete. It covers purpose, behavior, failure handling, verification, return value, and even provides an English translation. All essential aspects are addressed for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains the two override parameters (override_unmated, override_low_confidence) in detail, including their interdependence and effects. assembly_plan_id is self-explanatory. The description adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs/executes an AssemblyPlan with specific behavioral details: inserting and mating components one by one, per-step receipts, and distinguishing from batch execution. The verb 'Ejecuta' and resource 'AssemblyPlan registrado' are explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (human approval of assembly) and contrasts with sibling execute_batch, explaining why batch is unsuitable. Also explains gates for overriding recommendations and unmated components, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that all bound dimensions rebuild automatically, and explains units behavior. No annotations provided, so description covers key traits, though could mention additional side effects like write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose, typical usage, args, returns, raises. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a tool with 3 parameters, no output schema, and no annotations. Covers all necessary aspects for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description thoroughly explains each parameter: name must exist, new_value is numeric with units, and units is optional with preservation. Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies an existing global variable, distinguishing it from add_global_variable. The verb 'modificar/updates' and resource 'global variable' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a typical CSWA usage example and specifies prerequisites: variable must already exist. Implicitly tells when not to use (call add_global_variable first) and raises ValueError if not found.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses coarse granularity, limitation regarding MCP steps, inability to recover lost documents, and truthful return values. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Bilingual repetition adds length, but each sentence adds value. Core purpose is front-loaded. Warnings and return info are clearly separated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description fully explains return format and meaning. Sibling tools are all different, so no missing context. Complete for a parameterless undo tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100% (vacuous). Baseline is 4. Description adds no parameter info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Deshacer el ÚLTIMO paso de SolidWorks (Ctrl+Z / EditUndo2)', clearly specifying the verb (undo), resource (SolidWorks last step), and scope. It distinguishes from siblings as it is a generic undo, not a specific feature tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns that undo is coarse, may not correspond to last MCP call, and advises to verify after using. It also states what it cannot do (recover closed/lost documents). Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: creates a single sketch and extrude_cut for all holes, non-parametric, returns feature info, explains reverse_direction as escape hatch, and scoping with target_bodies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (summary, Args, Returns, Caveat, Example). Slightly redundant phrasing but overall effective and front-loaded. Could trim minor repetition for perfect conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 params, no output schema, no annotations), the description covers all parameters, return value, caveat, and provides an example. It is fully complete for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the Args section thoroughly explains each of the 11 parameters with constraints (e.g., circle_diameter_mm must be >0 and > hole_diameter, hole_count >=3, etc.) and defaults. Example demonstrates core parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a bolt circle with N holes using a single sketch and extrude cut. It distinguishes itself from feature-pattern alternatives like circular_pattern by noting it's sketch-based and works for any center position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (any center position) and when not (non-parametric, suggests create_reference_axis + circular_pattern for parametric counts). Also gives example for common use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that holes show as 'Cortar-Extruir' features, not Hole Wizard features, and notes no cosmetic threads and limitations like M12 not accepted for counterbore in v1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for args, returns, caveats, and examples, but somewhat lengthy; however, every sentence adds value given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no schema descriptions, no annotations, and no output schema, the description provides comprehensive coverage including return format, caveats, and two examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains all 8 parameters, including enum values, size constraints, mutual exclusivity of plane vs face_centroid_mm, and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drills N holes at specified positions using ISO Metric standards, and distinguishes it from hole_wizard (single-hole vs multi-hole).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (multi-position patterns where hole_wizard is impractical) and when not to (single hole with proper styling), and names hole_wizard as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the tool's composition and critical non-obvious behavior: reverse_direction=True for the extrude cut. Also explains orientation assumptions, return values, and warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections for workflow, args, returns, and caveats. Every sentence adds value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, orientation constraints, non-obvious extrude direction), the description is thorough. It explains all return values, including derived metrics and warnings, which is essential since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters are described in detail with units, defaults, constraints, and context (e.g., standard DIN widths, derivation of keyway_start/end_x_mm). The schema coverage is 0%, so the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool adds a DIN 6885-style axial keyway cut into a shaft end. Provides specific verb and resource, distinguishes from sibling tools like build_stepped_shaft and the primitive chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool operates on an active part with a shaft along world X, typically built with build_stepped_shaft. Provides a junior workflow example and explicitly tells when not to use (arbitrary orientation) with alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: discloses that units control equation suffix and internal conversion, describes return dict fields, explains raw SW string format, and warns about reuse. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, args, returns, binding example, related). Contains dual-language text (Spanish/English) which adds some redundancy but remains efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and no output schema, the description covers all needed context: how to use, what it returns, how to bind dimensions, unit behavior, and concrete example. Complements sibling tools effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds comprehensive meaning: name restrictions (no quotes, =, comma, @) and convention, value numeric, units with allowed values and conversion details. Far exceeds schema minimal info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a global variable (equation) that sketch and feature dimensions can reference. It distinguishes from related tools by explicitly naming set_global_variable and modify_dimension as alternatives, and warns against reusing the same name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context (parametric parts like CSWA Tool Block) and when-not-to-use (do not call again for same variable). Explains how to bind dimensions by adding another equation and lists related tools for modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: not parametric, creates sub-edges, modifies the part, returns a feature object with chamfered edges count, and explains default handling of circular edges. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with context paragraph, bulleted args, return info, caveat, and examples. Front-loaded with purpose. Slightly verbose but every section adds value; minor trim could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, description covers all necessary aspects: when to use, parameter details, return structure, side effects, interaction with other tools, and practical examples. Complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description provides rich detail for all 5 parameters: defaults, typical values, edge cases (e.g., circular edges skip min_edge_length_mm), and the purpose of include_arcs for round parts. Fully compensates for schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it chamfers every edge (linear and circular) in one call, designed for autoparts edge breaks per ISO 13715. Distinguishes from sibling tools like chamfer (requires selection) and fillet_all_edges by combining list_edges + filter + chamfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (universal deburring for autoparts), gives examples (standard deburr, single body, linear-only), warns about non-parametric nature and interaction with fillet_all_edges, and recommends using only one edge-break tool per part.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 thoroughly explains that the tool composes extrude_sketch and extrude_cut, that the tap is a 'Cortar-Extruir' feature (not a hole-wizard), and that no cosmetic threads are added. It also describes default behaviors, constraints, and return values. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear sentence, workflow paragraph, bulleted args, return info, caveat, and examples. However, it is somewhat verbose; some details could be streamlined. Given the lack of schema descriptions, the verbosity is justified, but it could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and no annotations, the description covers all essential aspects: parameter constraints, default behaviors, return structure, caveats, and example invocations. It also mentions the standard autoparts context. The agent has sufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully. Each parameter is explained with units, allowed values (including enumerated thread sizes), defaults, and constraints (e.g., outer_diameter_mm must be > 0 and > tap-drill diameter). It even lists ISO tap-drill diameters. This adds significant meaning beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool builds a threaded boss (cylindrical boss with centered tap hole). It distinguishes from sibling tools like build_flange_boss and hole_wizard by mentioning that for cosmetic threads, one should use hole_wizard directly. The verb 'build' and the resource 'threaded boss' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it references a 'Junior workflow' and gives example calls. It also includes a caveat explaining when not to use this tool (for cosmetic threads, use hole_wizard instead). This clearly differentiates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: read-only, images sent to Claude API, no redaction, temp file persistence, requirement for open document, error on unknown view, and no-op parameter. Comprehensive for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (purpose, warning, cadence, args, returns, caveats, example). Slightly verbose with bilingual content but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage including purpose, usage patterns, parameter details, return format, privacy/security, file handling, and example. Fully compensates for missing annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains all three parameters beyond schema: valid view names, default, error behavior; with_dims as no-op for future compatibility; section parameter with detailed effect and offset sign. Compensates for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool renders active part or assembly to PNG screenshots for visual verification. Specifies read-only nature and distinguishes from mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (checkpoints/end of build) vs. not (after every feature), with alternatives like cheap signals and verify_build_report. Includes privacy warning and debugging use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully bears the burden. It discloses default behavior (refuses dirty docs), force behavior (silent discard), underlying API verbs (CloseDoc vs QuitDoc), return dict fields, raised errors, and an example. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, Raises, and Examples sections. It is slightly verbose due to bilingual (Spanish/English) content, but every sentence adds value. The English part alone is clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return fields, errors, parameter semantics, and examples. It fully explains behavior, prerequisites, and edge cases, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is 0%, so the description must compensate. It explains the single 'force' parameter in detail: default false raises error if dirty, true discards changes. It also warns about using force only when doc is disposable and notes the underlying API distinction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 document, with a specific verb and resource. It distinguishes from siblings by contextualizing its role in iterative build/save/close flows, contrasting with save_as failure when windows pile up.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: in iterative build/save/close flows. Provides default behavior (refuses if dirty) and force=True usage with a warning. Includes an example flow showing canonical usage and a force-close example, offering clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: angle convention, direction flag's counter-intuitive effect, return value, and caveat. No behavior is left unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, though somewhat verbose. Every sentence adds value, but could be slightly trimmed. Still very effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and complex behavior, the description is fully complete—covers arguments, returns, use cases, examples, and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by detailing every parameter, including constraints (radius positive, angles different) and aliases. Examples illustrate usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws a center-defined arc on the active sketch, distinguishing it from siblings like create_circle and create_slot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance (slot end-caps, fillets, profiles) and when-not-to (use create_circle for full circles). Also mentions prerequisite (active sketch via create_sketch).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the behavioral disclosure burden. It explains that the plane is parallel to a source, offset is signed (zero rejected), positive/negative direction meanings, and return value (name, parent, offset). It also mentions testing for negative offsets, providing confidence in behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings and bullet points, front-loading the purpose. However, it is somewhat verbose (e.g., Spanish UI names and a cryptic testing note). For a complex tool, it's acceptable, but minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is exceptionally complete. It covers all modes, parameter details, return value, use cases, and even provides code examples with list_faces integration. An agent has everything needed to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does so thoroughly: offset_from lists allowed plane names (English and Spanish), offset_mm explains sign and zero rejection, face_centroid_mm is described as a 3-element array from list_faces. Examples illustrate usage, meeting the high burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a reference plane parallel to a default plane or face, distinguishing two modes (default-plane and face mode). It explicitly contrasts with sibling tools like create_reference_axis and mentions deferred methods, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance for each mode: default-plane for rib offsets and fixture-clearance planes; face mode for counterbore-on-flange-top and hole patterns. It also specifies when not to use (angled/through-3-points are deferred) and includes a caveat, leaving no ambiguity for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description covers all behavioral aspects: no rebuild, effect on other tools, return value (editing=True), and caution about sketch staying open. Also mentions specific future behavior (SW 2026 ES). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Bilingual text adds length, but each sentence adds value. Front-loaded with purpose, then usage, argument, return, warnings, and related tools. Minor redundancy due to translation but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations or output schema, the description covers all essential information: purpose, usage, parameter, return, behavior, warnings, and related tools. Nothing significant is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds the parameter's meaning: exact sketch name with an example ('Croquis1'). This fully compensates for the lack of schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (reopen/edit), resource (sketch), and scope (without rebuilding). It distinguishes from siblings like create_sketch and modify_dimension, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use (editing existing sketch) and when-not-to-use (alternatives like modify_dimension for dimensions). Includes a typical CSWA use case and warns that the sketch remains open until a consuming operation closes it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses the sketch is closed after extrusion, the feature is a new solid, the effect of reverse_direction on face-anchored sketches, merge behavior, and the return type (Feature with name, type, dimensions). It also warns about open/self-intersecting profiles and automatic re-opening on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings (Args, Returns, Caveat, Failure recovery, Example) and is front-loaded with the main action. While every sentence adds value, it is somewhat lengthy; minor trimming could improve conciseness without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description details the return value (Feature with name, type, dimensions). It covers prerequisites (closed profile), failure modes (reopening), and provides two examples showing typical usage and advanced multi-body case. Complete for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains each parameter: depth_mm (positive), end_condition (blind vs. through_all with note that depth_mm ignored), reverse_direction (default direction and gotcha for face-anchored sketches), and merge (default True, when to use False for multi-body). Examples illustrate usage, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exits the active sketch and extrudes it as a boss (solid) feature. It distinguishes itself from siblings like build_flange_boss (which combines sketch and extrude) and explicitly mentions other related tools (revolve_sketch, sweep_sketch, shell_part) and a missing feature (loft).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: after creating a sketch with at least one closed profile. It details failure recovery (sketch reopens on failure) and offers alternatives (e.g., use build_flange_boss for combined sketch+extrude, not for loft). It also explains parameter nuances like merge=False for multi-body workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers behavioral traits: requires Toolbox, errors on missing add-in, auto-undo on depth overconsumption, face-centroid validation, and return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with overview, args, returns, caveats, examples. Slightly verbose with bilingual content but earns its place with clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (6 params, no output schema), description covers all aspects: parameters, return format, prerequisites, limitations, alternatives, and examples, thus complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description compensates fully by explaining each parameter in detail (valid values, dependencies like depth_mm for blind, thread_class default/ignored), including examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it drills ONE standard ISO Metric hole (tapped or counterbore) on a face, distinguishing it from siblings like add_bolt_circle and extrude_cut for multi-hole or clearance scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use (single hole at face centroid) and when-not (multi-hole patterns, clearance holes), with explicit alternatives (add_bolt_circle, extrude_cut). Also mentions prerequisite (Toolbox add-in) and gives examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: it uses IComponent2.Transform2, rebuilds, and returns requested vs post-rebuild pose plus a 'moved' boolean. It warns that 'moved=False' indicates the component is fixed or mate-driven, revealing a critical edge case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a brief purpose, detailed args, and return info. However, includes Spanish phrase 'Mover componente' which is redundant given the English title. Otherwise concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a 3-parameter tool with no output schema and no annotations. It explains the return value, edge case of failed movement, and prerequisites (component name from get_active_assembly_info). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds complete meaning for each parameter: component_name is an instance name from get_active_assembly_info, origin_mm is [x,y,z] in mm, rotation_rows is optional 9-element row-major 3x3 entries with None defaulting to current rotation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a component's pose (position and optional rotation) via IComponent2.Transform2, followed by a rebuild. It distinguishes from siblings by mentioning the mirror-flip failure mode elimination when posing before mating, which is unique to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool to stage a component at its exact pose before creating mates, explaining that angle and distance mates have two solutions and posing first eliminates the mirror-flip failure. It also references the alternative tool 'place_and_mate' for the combined operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully discloses behavior: silent save (no UI dialogs), equivalent to Ctrl+S, required precondition (filename exists), return dict structure with specific fields, and exception types. No hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, using bullet points for the return dict and clear sections. Every sentence adds value. The bilingual content does not hinder clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple save operation, no output schema, and no annotations, the description covers all necessary context: purpose, behavior, return values, error conditions, and alternative tool. It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema provides no semantic information. The description adds no parameter descriptions because none exist. With 0 parameters, baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes exactly what the tool does: save the active SolidWorks document silently. Clearly distinguishes from the sibling tool 'save_as' by specifying that this tool only works if the document already has a filename, while 'save_as' is for new documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (document must have a filename) and when not to use (fresh document), and provides a direct alternative: 'save_as'. Also explains error conditions when no document is active or unsaved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses: behavior for fresh vs. already-saved documents, sets filename for future saves, does not create directories, failure cases (wrong extension), and region-specific desktop path handling. Also describes return dict differences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with bilingual sections, bullet points for args/returns/caveats/example. Some repetition between Spanish and English but acceptable for clarity. Not overly verbose given the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description specifies return dict and its keys. Parameter is fully explained. Given the tool's simplicity (1 param, no enums), the description covers all necessary behavioral and contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single 'path' parameter is described in detail: must include extension, SolidWorks infers document type from extension, lists valid extensions and their types, and warns that wrong extension causes failure. Schema coverage is 0%, but description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that save_as saves the active document to an explicit path, contrasting with save_active_document which only works on already-named documents. It explicitly handles fresh, unsaved documents and sets the filename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly compares with save_active_document, stating when to use save_as (for fresh documents) and when to use save_active_document (for subsequent saves). Also includes caveats about directory existence and OneDrive path for Spanish Windows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it does not download geometry, returns URLs and rankings, and provides fit verdicts and recommendations. It also explains follow-up actions (insert, edit, macro) and privacy constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections but includes both Spanish and English versions, making it longer than necessary. Each sentence adds value, but the duplication reduces conciseness slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and no output schema, the description covers purpose, parameters, return structure, usage guidelines, constraints, and alternative tools. It also explains post-search actions, making it comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description provides detailed parameter documentation: spec includes type, standard, size, material, nominal, query; resources lists allowed values; top_n and needs_edit have defaults and explanations. This adds value beyond the plain schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool searches for standard parts in open catalogs and judges fit, distinguishing it from the sibling query_part_library. It provides specific examples of parts (tornillo, tuerca, etc.) and the mode of operation (deep-link).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use guidance: only when local library lacks the part and it's a standard. It names the alternative query_part_library and states constraints like abstracted text only, no customer geometry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool suppresses/resumes a mate, returns metadata, and includes a live note about a version-specific lack of cascade, plus a cheap snapshot-diff workaround. This is excellent transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured: purpose, use cases, workflow, parameter explanations. Each part earns its place, though could be slightly more concise. Still highly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 2 required params, both fully explained. No output schema but description states return value. Workflow adds depth for complex use cases. No gaps for a CAD suppression tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and no param descriptions in schema. The description's 'Args' section explains mate_name (source and example) and suppressed (meaning of boolean). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Suppress or resume a mate by name', using a specific verb and resource. It distinguishes from sibling tools like add_coincident_mate (which add mates) and set_components_suppression (which suppresses components).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: disabling a wrong-branch mate before recreating via place_and_mate, and post-component-suppression cleanup. Includes a detailed workflow for cascade-aware resume, giving clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: merge parameter behavior, non-parametric nature (no D1/D2), orientation defaults (follow-path, no twist/guide curves), and v1 limitations. No contradiction with missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, args, returns, caveats, and example. Front-loaded purpose. Slightly verbose (example code is redundant with text) but still efficient. Minor deduction for unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and missing annotations, the description covers return value (Feature object), v1 limitations, and complete usage context. No gaps remain for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all three parameters: profile_sketch_name must be closed, path_sketch_name can be open/closed and perpendicular plane, merge merges or keeps separate. Adds critical context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sweeps a closed profile sketch along a path to create a boss feature. Distinguishes from sibling tools like extrude_sketch and revolve_sketch by specifying the sweep operation, and mentions sweep_cut for cutting vs. boss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites (sketches must exist, cannot be same sketch), limitations (no advanced options), and concrete examples of standard autoparts use cases. Also includes a code example and default behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that the sketch is left in 'EDIT mode', returns the sketch name and resolved plane name, and includes important caveats about document type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: purpose first, then argument details, then return value, then caveat. Every sentence adds value; no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description fully explains the return values, post-conditions (EDIT mode), and necessary context (part document). It also mentions subsequent steps, making the tool's role in a workflow clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for plane_name. The description adds extensive detail: lists the allowed values (front/top/right, plus Spanish equivalents), notes case sensitivity, and specifies lowercase English. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Start a new sketch on a named reference plane.' It uses a specific verb ('Start') and resource ('sketch on named reference plane'), distinguishing it from similar tools like create_sketch_on_face which creates on a face.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite: 'requires a part document (not assembly). Open a fresh part via SW UI before calling.' It also provides a sequence of use: create_sketch -> create_rectangle -> extrude_sketch, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavior like default extrude direction (into body), axis mapping non-intuitive behavior, failure modes, and requirement for face visibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured, front-loaded with a clear summary, then detailed sections for arguments, returns, gotchas, failure modes, and example. Every sentence adds value; appropriate length for complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a complex tool with no output schema: describes return values (name, face_centroid_mm, body_name, sketch_axis_mapping with schema), common uses, gotchas, failure modes. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description extensively elaborates on both parameters (selector and face_centroid_mm) with syntax, closed schema, and mutual exclusivity, fully compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts a new sketch on a body face, distinguishing from create_sketch (default planes only). It specifies the verb 'start' and resource 'sketch on a body face', and contrasts with sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (face on existing body) vs create_sketch (default planes). Includes guidance on selector vs face_centroid_mm, gotchas about extrude direction and axis mapping, and failure modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully handles transparency. It details non-durability of indices, field omissions based on face type, and explains when fields may be None. The example demonstrates expected output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into sections (summary, fields, args, use case, caveat, example). Every sentence adds value with no redundancy. It is detailed yet not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of face geometry enumeration and the presence of an output schema, the description covers all needed aspects: return fields, parameter usage, durability, examples, and integration with other tools. It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'body_name' is clearly explained: optional, filters to a specific body if given, otherwise returns faces from all bodies. This adds essential context beyond the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates faces of solid bodies. It explicitly differentiates itself as a mirror of list_edges, and the verb 'list' accurately describes the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use case is provided (chained-feature LLM workflow) with an example. It also includes a caveat about non-durable indexes and advises against caching centroids across edits, guiding proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP_CAD MCP server](https://glama.ai/mcp/servers/danielproxd2/MCP_CAD/badges/card.svg)](https://glama.ai/mcp/servers/danielproxd2/MCP_CAD)

Score Badge

Copy to your README.md:

[![MCP_CAD MCP server](https://glama.ai/mcp/servers/danielproxd2/MCP_CAD/badges/score.svg)](https://glama.ai/mcp/servers/danielproxd2/MCP_CAD)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielproxd2/MCP_CAD'

If you have feedback or need assistance with the MCP directory API, please join our Discord server