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
Disambiguation4/5
Most tools have clearly distinct purposes with detailed descriptions. There are a few overlapping pairs (e.g., verify_against_spec and verify_build_report, break_all_edges and fillet_all_edges), but the descriptions help differentiate them. Overall, an agent can distinguish tools with reasonable accuracy.
Naming Consistency3/5
Many tools follow a consistent verb_noun pattern (create_, add_, build_, list_, get_, set_, run_, record_, verify_), but there are deviations like 'break_all_edges', 'hole_wizard', 'place_and_mate', and 'stack_components'. The mix of underscores and no underscores creates some inconsistency, but the patterns are still readable.
Tool Count2/5
With 100 tools, the server is extremely large. While each tool serves a specific purpose, the sheer number is excessive for most workflows and may overwhelm users. Many tools are composites or niche functions that could be combined. The count far exceeds the typical well-scoped range of 3-15 tools.
Completeness4/5
The tool set covers a wide range of CAD operations including part creation, assembly, modification, measurement, verification, batch processing, macros, and catalog search. There are minor gaps (e.g., no direct tool for editing sketch geometry post-creation beyond dimensions), but overall the surface is comprehensive for the domain.
Average 4.5/5 across 100 of 100 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, persistence, or output behavior. The term 'Create' suggests a side effect but is not elaborated, leaving ambiguity.
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, consisting of two sentences with the primary purpose front-loaded and a quick differentiation. It could be slightly more detailed without losing conciseness.
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 absence of an output schema and the tool's complexity (8 optional parameters), the description fails to explain return values or usage context. More details are needed to compensate for the lack of schema coverage.
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?
With 0% schema description coverage and no parameter explanations in the description, the meaning of the eight parameters is entirely unclear. The vague references to bbox, mass, etc., do not adequately map to the parameters.
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 creates a structured verification report and distinguishes itself from verify_against_spec by mentioning bbox as a hard check and other fields as advisory. However, it does not fully define what a 'structured verification report' entails.
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 a usage scenario by comparing to verify_against_spec but lacks explicit when-to-use and when-not-to-use guidance. No alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the parametric expression capability, but lacks details on side effects (e.g., does it merge automatically? What if the profile is not closed?), error behavior, or prerequisites. Essential behavioral traits are omitted.
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 (two sentences) and front-loaded with purpose. However, it lacks structural formatting (e.g., bullet points) that could improve readability, especially for a parameter-heavy tool.
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's complexity (8 params, no output schema, no annotations), the description is incomplete. It explains only the variable expression aspect, leaving out parameter semantics, output details, and workflow integration. A more complete description would address the purpose of each parameter and the expected result.
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 description must compensate. It adds meaning for 'segments' and 'depth_mm' (accept expressions over variables), but ignores the other six parameters (exact, merge, plane, end_condition, reverse_direction, variables). The description is insufficient for an 8-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 the tool's action: 'Build an exact closed profile and extrude it as one composite.' It uses specific verbs and resources, and distinguishes from siblings like 'build_closed_profile' which only builds, and 'extrude_sketch' which extrudes an existing sketch.
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 for parametric designs by mentioning string expressions over variables, but does not explicitly state when to use this tool versus alternatives (e.g., building a closed profile then extruding separately). No when-not or exclusion criteria are provided.
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. It states 'fixed offset' and 'returns metadata' but does not disclose side effects, permissions, reversibility, or other behavioral traits beyond the basic function.
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 front-loaded with purpose but includes redundant Spanish and English versions. It could be more concise without losing essential information.
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?
For a tool with 6 parameters and no output schema, the description is incomplete. It explains distance_mm but omits meanings for align, entity IDs, and component names, and only vaguely mentions return value.
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?
Only distance_mm is described ('fixed distance in millimeters'). The description references 'other args: same as add_concentric_mate' without elaboration, leaving 5 out of 6 parameters undocumented. With 0% schema coverage, the description insufficiently 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?
Description clearly states it adds a distance mate (fixed offset) between two entities, and gives specific use cases (parallel plate separation, bearing distance, controlled gap). It distinguishes from siblings by mentioning related tools like add_concentric_mate, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides typical use case context and references sibling tools for comparison (e.g., 'same as add_concentric_mate', 'related: add_mate_by_face_position'). However, it does not explicitly state when not to use this tool or provide clear exclusions.
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 full burden. It only describes what it does without mentioning side effects, permission requirements, error conditions, or consequences (e.g., mate suppression). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. Every sentence adds value, avoiding unnecessary details. The bilingual format is efficient for the context.
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?
Without output schema, annotations, or parameter descriptions, the description leaves significant gaps. It covers purpose and typical use but lacks behavioral, parameter, and result information. For a tool with 5 parameters and no schema coverage, more 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 coverage is 0% and the description does not explain any parameter meaning. It only notes 'same argument shape as add_concentric_mate', which is vague. The 'align' parameter's default is unelaborated. Description adds minimal 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 adds a coincident mate between two planar entities, with concrete examples (flange-to-plate, sub-assembly base plane). It distinguishes itself from sibling tools like add_concentric_mate and add_mate_by_face_position by noting same argument shape and naming a convenience alternative.
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 (autopartes, specific scenarios) and references to related tools. However, it does not explicitly state when not to use (e.g., non-planar entities) or provide exclusion criteria.
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 full burden. It explains the plate geometry and hole modes but omits critical behavioral details: it does not state whether the tool creates a new part or modifies an existing sketch, whether the holes are destructive (through-cuts) or additive, or what the output is. The phrase 'drawing-grounded through holes' is ambiguous. Missing: required document context, effect on existing features, and return value.
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 sentences, each delivering essential information. The first sentence states the core function; the second explains the hole pattern alternatives and coordinate system. No redundant or extraneous text. Well-structured and front-loaded with the most important action.
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's complexity (14 parameters, no output schema, no annotations), the description is insufficient. It does not explain the broader build context (e.g., requires an active part document? affects existing geometry?), nor does it describe the result type. Sibling tools exist for similar operations, but no guidance is provided on when to use this tool over composing smaller steps. The description leaves many agent decisions unaddressed.
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?
With 0% schema description coverage, the description compensates partially. It adds meaning for `hole_positions_mm`, `bolt_circle_diameter_mm`, `bolt_count`, and the rectangle coordinate system (origin, width, height). However, many parameters remain undocumented: `plane`, `angle_offset_deg`, `reverse_direction`, `bolt_circle_center_x_mm`, `bolt_circle_center_y_mm`. The description covers about 6 of 14 parameters, which is adequate but not comprehensive.
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 'Build a rectangular plate and drill drawing-grounded through holes,' specifying the action (build, drill) and resource (plate with holes). It further distinguishes two hole pattern modes (explicit positions vs. bolt circle), which differentiates it from sibling tools like add_bolt_circle or add_drill_pattern that only handle hole patterns without creating the plate.
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 the two modes of hole creation ('Use either explicit `hole_positions_mm` or a bolt circle'), giving clear context for parameter usage. However, it does not explicitly state when to use this compound tool versus alternative tools (e.g., build_rectangular_pocket plus add_bolt_circle), nor does it mention any prerequisites or exclusions.
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?
With no annotations, the description carries full burden. It mentions a 'safe chain' and the steps involved, but lacks details on permissions, error handling, or side effects. It adds useful context about string expressions in coordinates but is not 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 at 4 sentences, each adding value. It front-loads the main purpose, then provides usage context and a noteworthy feature (string expressions). No extraneous information.
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 9 parameters, no output schema, and 0% schema coverage, the description is incomplete. It covers only purpose and two parameters, leaving many behavioral and parameter details unaddressed, which is inadequate for an AI agent to use correctly.
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 description coverage is 0%. The description adds meaning to 'segments' (ordered line/arc) and 'variables' (string expressions), but does not explain parameters like exact, merge, plane, angle_deg, or axis references. It compensates partially but not enough for 9 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 builds an axisymmetric profile by creating a reference axis, closed profile, and revolving. It explicitly distinguishes this as the preferred path for turned parts with known ordered segments, differentiating it from siblings like revolve_sketch and build_closed_profile.
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 context for when to use: 'for turned parts where the sketch profile is already known as ordered line/arc segments.' It implies this is the recommended approach but does not explicitly state when not to use or list alternative tools.
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 provided, the description carries full burden. It discloses that the tool modifies a dimension and returns updated state, but omits behavioral traits like whether the operation is destructive, requires specific permissions, or triggers model rebuilds. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, bulleted Args with examples, and a returns statement. Every sentence adds value, and the front-loaded main action aids quick understanding.
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 no annotations and no output schema, the description covers parameters well but lacks context on error conditions, required document state, or side effects. Returns statement is useful but incomplete for safe 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 compensates fully. It explains feature_name includes mate names in assemblies, dimension_name expects exact naming like 'D1', and new_value_mm specifies units and handling of angle dimensions. This adds critical meaning beyond the basic schema 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 'Change a single dimension on a feature in the active part or assembly,' providing a specific verb and resource. It distinguishes from sibling tools like list_dimensions or add_sketch_dimension by focusing on modification of 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 for modifying existing dimensions, but no explicit guidance on when to use versus alternatives, nor any exclusion criteria. It lacks context about prerequisites or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the tool is advisory-only and does not mutate SolidWorks, and that it returns MCP tool names and parameters. Supported archetypes are listed. Missing details on error handling or behavior for unsupported archetypes, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that convey all essential information without redundancy. The first sentence is a clear action statement; the second adds critical behavioral context. No wasted words.
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, non-mutating behavior, and supported archetypes. It hints at output (tool names+params). Minor gap: no mention of error states or behavior when archetype is not supported, but overall sufficient.
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?
The schema has 0% description coverage for its single parameter. The description implies 'drawing_spec_id' is an identifier for a stored DrawingSpec, but adds no additional meaning, format, or usage context beyond the 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 compiles a DrawingSpec into a FeaturePlan, uses a specific verb-resource pair, and distinguishes itself by being advisory-only and non-mutating. It also explicitly lists supported archetypes, making its scope clear.
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?
Usage is implied: use when you have a DrawingSpec and want a plan. However, there is no explicit guidance on when to use vs. alternatives (e.g., run_feature_plan), nor any when-not conditions. The advisory nature is mentioned but not contrasted with execution 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?
The description clearly states the tool does not mutate SolidWorks and details the return value, including stored spec, warnings, expected size, and build recommendation. Without annotations, it provides good behavioral disclosure, though it could elaborate on overwrite behavior or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy (over 500 words) and includes some tangential details (e.g., references to AUTOMATION_LANE.md, legacy path explanation). It is structured with an Args section, but the first paragraph is cluttered and could be trimmed for better 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?
For a complex tool with 11 parameters and no output schema, the description covers the workflow, parameter details, and return values comprehensively. However, it lacks information on error handling or validation behavior, which slightly detracts from completeness.
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 providing a detailed Args block for each of the 11 parameters, including allowed values for archetype and internal_features.type, and explaining the structure of nested fields like dimensions and features.
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 records a structured DrawingSpec and explicitly notes it does NOT mutate SolidWorks, distinguishing it from mutation-focused siblings. However, the purpose is somewhat buried in a verbose opening about legacy/dormant spine and file references, which could be more direct.
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 the tool is advisory-only and part of a legacy path, and it explicitly connects to compile_feature_plan_from_drawing_spec and run_feature_plan, giving some usage context. But it does not explicitly state when to use this tool over alternatives or provide clear exclusions, leaving some 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description reveals behavioral traits: it enforces a fixed angle, uses right-hand-rule for rotation direction, and warns about solver rejection for coplanar entities. It also hints at parity with add_concentric_mate. Some details like permissions or side effects are omitted, but the disclosure is substantial.
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 long with bilingual text (Spanish and English), which adds redundancy. It is structured with sections (typical use, args, returns, gotcha, related) but could be more concise by removing the Spanish section or merging it. Every sentence provides value, but the bilingual duplication reduces efficiency.
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 0% schema coverage and no output schema, the description covers the return metadata and mentions a key gotcha. However, it fails to document most parameters (5 out of 6 are vague). It does differentiate from sibling tools adequately. Coverage gaps leave the agent underinformed for correct invocation.
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 description must compensate. It explains angle_deg (degrees, rotation rule). However, it defers other parameters to 'same as add_concentric_mate' without referencing that tool's description. The remaining 5 parameters (component names, entity IDs, align) are not explained, leaving significant ambiguity.
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 an angle mate (fixed angular offset) between two entities. It uses specific verbs and resources, and distinguishes from sibling tools like add_coincident_mate and add_concentric_mate through typical use cases and entity type restrictions.
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 typical uses (chain-link, hinge angles, etc.), required entity types (planar or axes), forbidden cases (concentric cylindrical faces, coplanar entities), and mentions a related tool (add_mate_by_face_position) for alternative usage. This offers 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.
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 discloses that data lives in memory and clears on server restart, which is useful. However, it does not state whether the operation is read-only, synchronous, or any potential side effects. More detail (e.g., no destructive actions, idempotent) would improve transparency.
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 with Spanish first then English, which adds length. While the information is valuable, the duplication reduces conciseness. The front-loaded first sentence in Spanish is clear but could be streamlined into a single, multilingual-friendly paragraph.
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's simplicity (no parameters, no output schema), the description is fairly complete. It lists all returned fields with types (dictionaries) and notes the in-memory nature. It does not mention any size limits or performance caveats, but these are minor omissions.
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 schema description coverage is 100% by default. The description does not need to add parameter meaning, but it could explain any implicit context (e.g., session-scoped). A baseline score of 4 is appropriate as the description provides a clear purpose for the tool without requiring parameter details.
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, specifying the verb 'list' and resource 'recent plans'. It provides a detailed breakdown of the plan types (assembly, feature, batch, macro) and explicitly positions itself as a debug aid when the LLM forgets a plan ID, differentiating it from other 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 explicitly states the use case ('Útil cuando el LLM olvida un id de plan' / 'Debug aid'), indicating when to invoke it. While it doesn't explicitly list when not to use or alternative tools, the sibling tools (e.g., record_*, run_*) are clearly distinct operations, making the guidance 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?
With no annotations, the description carries full burden. It discloses no deletion, read-only verbs counted as 'inspected', and details three safety gates. It lacks explicit statement about mutability but implies writing actions.
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, bilingual (Spanish and English redundant), and uses bullet-like structure. It could be more concise without repeating information in both languages.
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 return fields, gates, and verb counting. However, it lacks detail on batch_job_id format and full return types, leaving some gaps.
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%. The description explains override_warnings and override_low_confidence in the gates, but batch_job_id is only implicitly identified as the job to run, with no format or source details.
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 executes a recorded batch job file by file with a complete manifest, and distinguishes from siblings by referencing run_assembly_plan and noting it is the 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?
It describes when to use (after recording a batch job, as human approval) and conditions that block execution (go_recommendation, warnings, empty fileset). However, it does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses parameter behavior, typical values, and the return type. It mentions the batch-all-identical-edges rule and failure modes are identical to fillet, but doesn't detail side effects or nesting 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 well-structured with a clear opening, followed by detailed parameter explanations and an example. It is slightly verbose but every sentence adds value, and it is front-loaded with the main action.
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 7 parameters, no output schema, and no annotations, the description covers most critical aspects: typical use cases, parameter constraints, and references to fillet for common patterns. It lacks details on edge_circles and the full selector schema, but overall provides sufficient context for an AI agent.
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 description adds meaning beyond the schema for 6 of 7 parameters, explaining distance_mm, angle_deg, flip, edge_midpoints_mm, edge_indices, and selector with typical values and use cases. However, it misses edge_circles entirely, and the selector is only briefly described via reference to fillet.
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: 'Chaflán — bevel one or more edges (distance + angle).' It also distinguishes from fillet by referencing it for common details and provides an example 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 explicit usage context with standard autoparts applications, default angles, and deferred features. It directs users to fillet for the selector schema and failure modes, but doesn't explicitly state when not to use or alternatives beyond fillet.
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?
Without annotations, the description discloses key behavioral traits: the sketch geometry is not parametric, modify_dimension cannot resize slot width or move endpoints, and rebuilding from a fresh part is required for changes. This provides good transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, bullet-style parameter explanations, and separate caveats. The bilingual section adds useful context but could be trimmed slightly; overall, 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?
For a tool with 5 required parameters, no annotations, and no output schema, the description covers shape definition, parameter roles, usage caveats, and a common use case. It lacks explicit output specification but is otherwise thorough.
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?
All five parameters are explained in the description: endpoints (x1_mm,y1_mm and x2_mm,y2_mm) and width (width_mm) as slot width. The shape semantics are clarified (semicircular end-caps). Given 0% schema description coverage, this compensates effectively.
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 straight slot on the active sketch, describes its geometry, and distinguishes it from sibling tools like create_line or create_rectangle by specifying the slot's rounded-rectangle shape and intended use.
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 common use case (adjustable bolt slots) and a prerequisite (requires active sketch), but does not explicitly guide when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool is read-only ('Read-only sobre el índice'), which is critical for safety. It details the filter behavior (AND logic, tolerance, envelope). With no annotations provided, the description effectively communicates the non-destructive nature and search 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 a clear purpose, filter explanation, argument list, and return format. It is front-loaded with the main goal. However, it is slightly verbose; the inline parameter explanations could be shortened if schema descriptions were provided.
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 complexity (8 parameters, no output schema, no annotations), the description provides comprehensive details: filter combinations, tolerance semantics, envelope orientation-agnostic behavior, indexing prerequisite, and a full return structure. Nothing essential is missing for an agent to correctly use this 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?
With 0% schema description coverage, the description compensates by listing and explaining each parameter in the Args section, including examples (e.g., 'buje balero' for text). It adds meaning beyond the raw schema, though some parameters could use more detail on format (e.g., fits_envelope_mm).
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's purpose: searching for similar parts in a local catalog ('¿ya hicimos algo así?'). It provides a specific verb and resource, but does not explicitly differentiate from the sibling tool 'search_part_catalog', which may have overlapping functionality.
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 prerequisite: 'corre build_part_index primero en esa carpeta' (run build_part_index first). It also states it is read-only. However, it does not provide guidance on when not to use this tool or suggest alternative tools for similar queries.
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 burden. It mentions the return value {rolled_back_to: None, ok} and that it reactivates operations. However, it doesn't disclose whether the operation is reversible, if it triggers any side effects, or if there are any authorization requirements. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences plus a return value line, front-loaded with the purpose. Bilingual content adds slight redundancy but does not harm clarity. No unnecessary words, though could drop Spanish for 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 the tool has no parameters and no output schema, the description explains its function and return value adequately. It does not cover error cases or limitations, but for a simple tool this is sufficient.
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?
Input schema has zero parameters, and schema coverage is 100%. Description adds no parameter info because none are needed. Per guidelines, baseline 4 for zero parameters 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?
Description clearly states the tool rolls the feature tree forward to the end, restoring everything suspended by rollback_to_feature. It uses specific verbs and resources, and distinguishes itself from its sibling rollback_to_feature by indicating it is the inverse operation.
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 implies it should be used after a rollback_to_feature call to restore suspended operations. While it doesn't explicitly state when not to use it, the context makes the usage clear. Could be more explicit about prerequisites, but adequate.
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 clearly states the tool is reversible, suspends features, and does not delete. It also describes the return value structure. The behavioral traits are well disclosed beyond the minimal.
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 a bit verbose with both Spanish and English translations, but it is structured with sections for description, args, returns, and related tools. Could be more 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 only one parameter and no output schema, the description is quite complete: it explains the action, reversibility, return values, and related tools. It adequately addresses 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?
Schema coverage is 0%, but the description adds meaning by specifying the parameter is an 'exact feature name' with an example. This 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 tool rolls back the feature tree to just before a named feature, suspending it and everything after. It distinguishes itself from siblings like undo, rollback_to_end, and set_component_suppression by specifying it's the reversible, no-deletion alternative.
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 mentions when to use (instead of deleting a feature) and provides related tools (rollback_to_end for restore, set_component_suppression as assembly-level equivalent, undo as coarse and not reversible). 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the subtractive nature, an example return object (Feature with name, type, dimensions), and a caveat about v1 constraints. However, it does not explicitly state permance, prerequisites, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: definition, use cases, arguments, returns, caveat, and an example. It is slightly long but every section adds value. Could be more concise, but clear hierarchy compensates.
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 and 0% schema coverage, the description covers purpose, parameters, output structure, and provides an example. It references but does not detail sweep_sketch constraints. Missing failure modes and prerequisites, but adequate for a CAD 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?
The description adds significant meaning beyond the schema: explains profile_sketch_name as 'Closed profile sketch name (e.g., 'Croquis1' for cross-section)' and path_sketch_name as 'Path sketch name. Must be a different sketch than the profile'. With 0% schema coverage, this 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 the tool's action: 'subtract a swept-profile-along-path volume from existing material'. It uses specific verb (sweep cut) and resource, and distinguishes from sibling tools like extrude_cut or revolve_cut by emphasizing the swept path.
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 lists standard autoparts uses (curved grooves, oil channels, etc.) but does not explicitly contrast with alternatives like extrude_cut or sweep_sketch. A caveat about 'same constraints as sweep_sketch' is present, but no when-not-to-use guidance is given.
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 full burden. It includes a 'Caveat' section detailing partial failure behavior and the lack of auto-rollback, which is useful. It also explains the composition order and single save at the end. However, it could be more explicit about side effects like saving the document.
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 line, args section, returns, caveat, and example. Each section adds value, though the arg descriptions could be slightly more concise. The caveat is particularly important and earns its place.
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 the tool's complexity (composing multiple operations), the description is highly complete. It covers purpose, all parameters with constraints, return format, failure behavior, and provides an example. The caveat addresses real-world usage concerns.
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, so the description must compensate. It provides detailed semantics for each parameter: constraints for variants (non-empty, >0), meaning of parent_config, and requirement that activate_at_end must be a key of variants. This far exceeds the schema's basic type 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 the verb ('Crear una familia de configuraciones') and resource (cambiando una sola dimensión). It distinguishes itself from siblings by explaining it composes create_config, activate, and modify_dimension into a single macro, which is a higher-level operation than individual tools like create_configuration.
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 provides a junior workflow example but lacks explicit when-to-use vs when-not-to-use guidance. It implies usage for multi-variant creation along one dimension, but does not explicitly contrast with using individual tools for a single variant. More directive guidance would improve agent decision-making.
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 the description carries full burden. It discloses return value (geometry with endpoints and length) and includes a critical caveat about the line not being parametric (modify_dimension cannot adjust endpoints or length). This reveals important behavioral limits beyond the simple 'draw' action.
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 first sentence front-loads the purpose. The structure includes args, return, usage, and caveats. The bilingual caveat adds length but is reasonable for international users. Could be slightly more concise, but overall well-organized.
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?
Despite no output schema or annotations, the description covers purpose, parameters, return value, prerequisite, and an important behavioral caveat. It does not mention whether the line is immediately visible or if there are constraints, but this is sufficient for a simple tool given sibling context.
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 must add meaning. It explains x1_mm, y1_mm as 'Start point in mm (sketch-local frame)' and x2_mm, y2_mm as 'End point.' This provides units and frame context that the schema lacks, though coordinate system orientation or bounds are omitted.
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 line on the active sketch.' It distinguishes the tool from siblings like create_rectangle, create_circle, and create_arc by noting it is used for non-rectangular profiles before extrusion. The verb 'Draw' and resource 'line' 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 explicitly requires an active sketch via 'requires an active sketch (call create_sketch first).' It also implies usage as a building block for non-rectangular profiles, but does not explicitly exclude alternatives (e.g., use create_rectangle for rectangles). Clear context 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool creates a non-parametric feature (re-radius requires delete+re-run), but notes that parametric edits via modify_dimension work for simple cases. It also surfaces failure modes and side effects like body name shifts, but lacks explicit mention of whether the operation is reversible or what 'Redondeo' implies.
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 highly detailed and well-structured with paragraphs, bullet points, and examples, but it is verbose (over 30 lines). While thorough, it could be more concise by trimming redundant explanations (e.g., repeating failure modes). Not minimal, but organized 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?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is remarkably complete. It covers all aspects: parameter purpose, failure modes with hints, typical usage values, and return value (Redondeo feature). It also warns about caveats like non-parametric behavior and body name shifts.
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?
With 0% schema description coverage, the description must compensate. It extensively documents most parameters (selector, edge_midpoints, edge_indices, radius_mm, tangent_propagation), including nested schemas and usage examples. However, it fails to explain the 'edge_circles' parameter in the schema, leaving a gap. Overall, adds significant meaning but incomplete.
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 rounds one or more edges with a constant radius. It specifies the resource (edges) and the action (fillet/round). It distinguishes from variable-radius fillets by noting they are deferred, and from sibling tools like 'fillet_all_edges' by implication (this tool targets specific edges).
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 each edge-addressing method (selector recommended vs. edge_midpoints vs. edge_indices), including failure modes and recovery strategies. It also gives typical radius values for different autoparts contexts and warns against batching fillets that cause body name shifts, effectively guiding correct invocation.
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?
With no annotations, the description carries a heavy burden. It discloses that the tool returns a new pattern feature with name, type, and dimensions, and describes the behavior of parameters (spacing must be positive, count includes original, reverse default false). However, it does not warn about failure modes (e.g., invalid feature names or direction references) or clarify whether the original features are modified.
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 clear Args, Returns, and an Example section. It is concise yet thorough, every sentence adds value, and it is front-loaded with the tool's purpose.
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 parameters, no schema descriptions, and no output schema, the description provides solid coverage. It explains the return format (name, type, dimensions) and includes an example. However, it lacks details on error handling or edge cases, such as what happens if the direction reference is invalid or if pattern instances exceed limits.
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, so the description must fully define each parameter. It does so comprehensively: 'feature_names' lists exact names from get_active_part_info, 'direction_reference' provides sources (Eje1, edges, sketch lines) with locale-sensitivity, 'spacing_mm' must be positive, 'count' includes original and must be ≥2, 'reverse' defaults false. 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 that the tool patterns features in a straight line, using specific verbs like 'Repeats' and providing concrete examples (hole rows, fin arrays, bolt grids). It distinguishes itself from siblings like 'circular_pattern' by specifying 'single straight line' and mentioning that the second-direction variant is deferred.
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 patterns) and notes that the second-direction variant is not available in v1. It provides an example usage but does not explicitly mention when not to use it or suggest alternative tools for other pattern types.
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 must disclose behavioral traits. It states that the tool requires SolidWorks already running (does not launch it), activates a new part, and uses legacy creation if no default template exists. It also specifies the return value. However, it does not describe error behavior if SolidWorks is not open or if creation fails, which would improve 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 bilingual (Spanish/English) and well-structured: purpose, usage, return type, caveat. Each sentence provides essential information with no fluff. However, the repetition of content in both languages slightly reduces conciseness; a single-language description could be shorter.
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's simplicity (no parameters, no annotations, no output schema), the description covers the necessary context: creation action, activation, prerequisite (SW open), fallback for missing template, and return format. Missing details include potential error states or what happens if the tool is called when SW is closed. Still, it is reasonably complete for a straightforward tool.
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 tool has no parameters and schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the tool's purpose and context, but it does not provide additional parameter-specific information since none is needed. The description is adequate for a parameterless 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 the tool creates a new empty part in SolidWorks (.SLDPRT), uses a specific verb ('Crear', 'Create'), and distinguishes itself from sibling tools like 'new_assembly' by specifying 'part'. It also notes that geometry tools require an active part, implying this is a prerequisite.
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 'Úsalo cuando no haya pieza abierta o quieras empezar desde cero' (Use when no part is open or you want a fresh start), providing clear context for usage. It also mentions that geometry tools require an active part, guiding the agent to use this tool first. The caveat about SolidWorks needing to be open and legacy fallback adds practical usage 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 bears full responsibility. It explains the bistable nature of angle/distance mates, the risk of rebuilds flipping, and the pose_held check that indicates problems. It does not detail permissions or side effects, but the core behavioral traits are 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 front-loaded with the core purpose and rationale. It is structured with a brief intro, detailed reasoning, argument list, and return value description. Every sentence adds value, though a slight tightening could be achieved.
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 parameters and no output schema, the description covers the purpose, usage rationale, argument details, and return keys. It explains the pose_held concept which is critical for interpreting results. It lacks error handling details but is otherwise 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?
With 0% schema description coverage, the description compensates by explaining each parameter: component_name from get_active_assembly_info, origin_mm/rotation_rows as exact target pose, mates structure with example fields, and pose_tolerance_mm default. It adds meaningful context beyond the schema's type-only definitions.
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 pose a component exactly and then create its mates. It distinguishes itself from sibling tools like add_angle_mate or move_component by combining both actions in a specific order, with a rationale about branch-safe mating.
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 the branch-safe mating recipe and why the order matters, providing clear context for when to use this tool. It does not explicitly list alternatives or when not to use, but the context implies it is for precise placement where mate branch stability is critical.
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 explains the subtractive nature and return type (CortarRevolución, type='cut_revolve'), but lacks disclosure of prerequisites (closed sketch, axis existence), errors, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and use cases, then parameter details, then a concrete example. Could be slightly more concise but the structure is logical.
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 usage, parameters, return type, and provides a detailed example. It gives domain context for autoparts, making it complete for a moderate-complexity 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%, so description must compensate. It explains axis_name as from create_reference_axis with same constraints, angle_deg as sweep range (0,360] with default 360 and typical full-circle use, and reverse_direction as sense flip. 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 it is a subtractive revolve operation, explicitly distinguishing it from revolve_sketch as its mirror. It provides specific autoparts use cases (O-ring grooves, retaining-ring grooves) and contrasts with sibling tools like extrude_cut and sweep_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 gives concrete examples of when to use (autoparts grooves) and notes it's the subtractive counterpart of revolve_sketch. However, it does not explicitly state when not to use it or compare to alternatives like extrude_cut or sweep_cut.
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, description covers up-front validation and early failure, config_scope batching behavior, and return structure. Lacks mention of authorization requirements or side effects like rebuilds, but sufficiently transparent for typical use.
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 and somewhat verbose, but front-loaded with purpose and efficiency. Could be trimmed to single language without loss, 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?
Covers purpose, usage, parameters, behavior, and return type. No output schema, but return dict is described. Complete for a batch mutation tool with clear sibling differentiation.
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%, but description explains all four parameters: component_names source and validation rule, state enum, config_scope behavior, and config_names dependency. Adds value beyond 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 it changes suppression state of multiple components in one call, with specific verb 'set' and resource 'components suppression'. Distinguishes from sibling set_component_suppression by noting efficiency gain.
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 recommends over set_component_suppression for multiple components and gives typical trim-variant BOM prep example. Does not explicitly state contraindications (e.g., single component) but implied by sibling existence.
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?
Without annotations, the description carries full burden. It details parameter effects (e.g., reverse_direction flips cut, target_bodies restricts bodies, end_condition ignored if through_all) and notes that the pocket may cut into air if the parent body is on the wrong side. Return value is described as '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 moderately long but well-structured, with a clear intro, workflow breakdown, and parameter list. It is front-loaded with the core purpose and example, though some sentences could be tightened.
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 9 parameters and no output schema, the description covers parameter usage thoroughly, includes an example invocation, and describes the return value type. It could be improved by detailing the structure of the returned feature info, but is largely 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 adds comprehensive meaning for all 9 parameters. It includes examples for plane (English/Spanish), units for dimensions, constraints (e.g., width_mm > 0), defaults, and special behavior (e.g., depth_mm ignored when end_condition='through_all').
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 also provides a concrete example workflow, distinguishing it from generic cut tools like extrude_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 a junior workflow example and explains it composes create_sketch, create_rectangle, extrude_cut, implying it is a shortcut. However, it does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains angle convention (CCW), direction flag with counter-intuitive example, returns dict with fields, and troubleshooting tip (flip direction if revolve fails). Missing some error cases 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: purpose first, then parameters, returns, use cases, examples, caveat. Front-loaded and efficient, though slightly long. 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?
Given 8 parameters, no output schema, and no annotations, the description covers parameter conventions, examples, use cases, and a key caveat (active sketch needed). Does not cover all edge cases but is sufficient for typical 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?
Schema has 0% description coverage; the description explains all 8 parameters in detail: meanings, defaults, constraints (radius positive, start/end different), long-form aliases, and direction behavior. 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?
The description clearly states 'draw a center-defined arc on the active sketch' with specific parameters (center, radius, angles). It distinguishes from siblings like create_circle (full circles) and create_slot (slot end-caps).
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: requires active sketch, common use cases (slot end-cap, 2D fillet, curved profiles), and explicitly says to use create_circle for full circles. Lacks explicit when-not-to-use but gives good 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 provided, so description carries full burden. Discloses up-front validations (existence, not active, not only), notes reversibility (configs are pure metadata, no broken geometry), and specifies return value. Lacks mention of permissions or error handling, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose first, then scope, validations, and use case. Slightly verbose due to bilingual content, but each sentence adds value. Front-loaded 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?
Comprehensive coverage for a deletion tool: explains preconditions, edge cases (active/only config), return value, and typical use cases. No output schema, but return value is described. Sibling reference enhances context.
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?
Input schema has one required string 'name' with 0% field description coverage. Description adds 'The configuration to delete' which clarifies purpose but is minimal. For a simple single-parameter tool, this is adequate but not exceptional.
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 specifies that the tool deletes a configuration from the active document. Distinguishes itself as the only deletion tool in v1 MCP, explicitly contrasting with component/feature deletion which is not exposed.
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 (cleanup of obsolete trim variants, removing test/scratch configurations) and when not to use (not for components/features). Provides prerequisites (not active, not only configuration) and references sibling tool activate_configuration for switching active config.
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 covers behavioral traits: clearly states 'no muta nada' (does not mutate), 'solo asesoría' (advisory only), and describes return values including warnings and blocking conditions for incomplete components. No contradiction.
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 and bilingual (Spanish and English), adding length without additional information for an English-speaking agent. While structured and front-loaded, it could be more 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 the complexity (7 params, nested objects, no output schema or annotations), the description is quite detailed, covering the plan structure, mate tools, substitution mechanism, and return values. However, it misses the 'assumptions' parameter, and the confidence scale is briefly touched but not fully elaborated.
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 description coverage is 0%, so description must add meaning. It explains details for 6 of 7 parameters (intent, skeleton, components, save_path, use_active_assembly, confidence) but completely omits the 'assumptions' parameter from the description, which is present in the schema. This is a significant 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 records a structured assembly plan before touching SolidWorks, is advisory only, and does not mutate anything. It distinguishes from run_assembly_plan by noting that the plan should be reviewed with the designer and then executed via that 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 tells when to use ('ANTES de tocar SolidWorks', advisory only) and when to use the sibling tool run_assembly_plan for execution. Also mentions that incomplete components block execution, guiding proper usage.
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 must carry the behavioral disclosure burden. It states the tool returns created mate's metadata, but omits details on permissions, side effects (e.g., modification of assembly), or state dependencies. However, for a straightforward mate creation, the basic behavior is implied, earning a mid-range score.
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, typical use, argument details, return info, and related tools. It is slightly long but efficiently front-loaded with the purpose. Every sentence contributes value, though minor redundancy exists (bilingual repetition could be streamlined).
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 (5 parameters, no output schema, 0% schema coverage), the description thoroughly covers all aspects: purpose, parameter meanings, usage context, related tools, and return value. It is fully adequate for correct invocation without requiring external resources.
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 is essential. It explains each parameter: component1_name and component2_name with examples ('bracket_L-1'), entity1_id and entity2_id with locale-sensitive string examples, and the align parameter with allowed values. This adds significant meaning 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?
The description clearly states the tool's purpose: 'Mate concéntrico — alinea ejes de dos entidades cilíndricas/cónicas.' It uses a specific verb ('add concentric mate') and resource ('cylindrical/conical entities'), effectively distinguishing it 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?
The description provides typical use cases ('Uso típico autopartes: alineación de ejes de barrenos') and explicitly references related tools, explaining when to use alternatives ('add_mate_by_face_position for box-style components, stack_components for fully-constrained stacked pair'). This gives clear guidance on when to use this tool versus others.
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 it replaces vertex with arc, requires sketch edit mode, and that lines must be adjacent. Mentions it returns metadata. No annotations provided, so description carries the burden and does it well.
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 bilingual (Spanish and English) which adds length, but is well-structured and front-loaded with key information. 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 mentions it returns metadata. It covers preconditions (edit mode, adjacent lines), differentiates from siblings, and provides typical usage 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?
Schema has 0% coverage, so description fully explains each parameter: line1_x_mm and line1_y_mm are points on the first line near the corner, similarly for line2, radius_mm is the fillet radius, and z_mm is Z-coordinate with default 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 rounds a sketch corner with a tangent arc, replacing the vertex. It distinguishes itself from create_arc and add_sketch_chamfer, and mentions typical use (CSWA Tool Block).
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?
Describes when to use (rounded corners, CSWA Tool Block) and compares to alternatives (chamfer, manual arc). Does not explicitly list exclusions or when not to use, but provides sufficient 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?
No annotations provided, so description carries full burden. It explains parameter behaviors (equal_spacing, reverse, total_angle_deg) and mentions the return value (a new Feature with name). It does not discuss side effects or destructive actions, but the tool is a pattern creation which is typically non-destructive.
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, bullet points for arguments, and examples. While verbose, every sentence adds value for a parameter-heavy tool. Could be slightly more concise, but overall 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 6 parameters and no output schema, the description covers all parameters, explains the return value, and provides two complete examples. It also notes the prerequisite, making it fully actionable 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?
Schema coverage is 0%, but the description provides detailed semantics for all 6 parameters, including types, defaults, and usage (e.g., count includes original, total_angle_deg default 360, equal_spacing behavior). 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?
The description clearly states 'repeat features around an axis' and provides specific use cases like bolt circles and fan blades. It distinguishes from siblings like linear_pattern by describing the circular axis-based repetition and the prerequisite create_reference_axis call.
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 mentions the prerequisite create_reference_axis call and provides examples for common use cases. It does not explicitly state when not to use, but the context and examples imply appropriate scenarios, and it guides the user on parameter settings for partial arcs.
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; description covers merge behavior, reverse direction, D1 meaning (angle not distance), and non-parametric sketch dimensions caveat. Lacks disclosure of additional error conditions or performance implications.
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 list, returns description, caveat, and example. Slightly verbose (e.g., example could be shorter), but every sentence adds value. 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?
Complex tool with 4 params and no output schema; description provides parameter details, return info (feature type, D1 mapping), caveats, and a full example. Relates to sibling tools via comparison with extrude_sketch.
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?
Input schema has 0% description coverage, but description explains all four parameters: axis_name origin, angle_deg interval and default, reverse_direction effect, merge behavior. Also connects angle_deg to D1 dimension and notes it can be modified via modify_dimension.
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 'revolve a closed sketch around an axis' and lists concrete use cases (shafts, bushings, flanges) that distinguish it from siblings like extrude_sketch or sweep_sketch.
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?
Describes axis placement constraints ('must lie in same plane as or beside sketch profile') and warns against crossing axis. Provides typical use case (turned parts) but does not explicitly list when not to use or suggest 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?
Since no annotations are provided, the description carries the full burden. It discloses arbitrary code execution, network egress block, audit logging, temporary file cleanup, and four levels of gates with clear conditions. Returns are listed.
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, mixing English and Spanish, and contains redundant translations. While organized with bullet points, it could be more concise to improve 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 the complexity and no output schema, the description fully explains the tool's behavior, safety considerations, return values, and prerequisites. 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?
Schema description coverage is 0%, but the description explains override_warnings and override_low_confidence in the gates context. macro_job_id is not elaborated, but its purpose is implied. Adds value beyond parameter names.
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 'Execute a recorded MacroJob by materializing VBA to a temporary .swb,' specifying the verb and resource. It distinguishes from siblings like run_batch_job and run_assembly_plan by focusing on macros.
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 it is disabled by default and requires opt-in (MCP_CAD_ENABLE_UNSAFE_MACROS=1). Details the four gates and when overrides are allowed, providing clear context for usage. Does not explicitly compare to alternatives but implies caution.
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 discloses that the tool creates three mates, requires opposite face positions on the same axis, and raises ValueError for invalid pairs. It also notes that a single face mate only locks one axis. Missing details like whether previous mates are affected or if the operation can be undone as a group.
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 purpose, explanation, parameter descriptions, example, and return value. It is front-loaded with the key purpose. However, the bilingual text (Spanish and English) makes it slightly verbose than necessary.
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 the description details the return (Dict with mates list in order). It covers all parameters, includes an example, and explains the behavioral constraints. For a 4-parameter tool with no annotations, this is very 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 the description compensates fully. It specifies that component names come from get_active_assembly_info, and face positions must be from a set of six directions and required to be on opposite ends of the same axis, with an example.
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 goal: 'Fully constrain two components in a stacked arrangement (3 mates in one call).' It specifies the resource (components) and action (stack/full constraint), and distinguishes from single face mate 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 explains when to use the tool (for full constraint in stacking) and contrasts with a single face mate that only locks one axis. It provides typical use cases and an example. However, it does not explicitly state when NOT to use it, such as when a distance mate is needed.
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 full burden. It thoroughly explains how face positions are resolved to actual faces based on local coordinate frames, including axis mapping for each keyword. It also describes default behavior and mate types. It does not mention side effects or undo capacity, but this is acceptable for a creation 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?
The description is concise yet comprehensive, using clear sections (intro, args explanation, example). Every sentence adds value, no wasted words. The structure aids quick scanning for 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 7 parameters and no output schema, the description covers all aspects: parameter semantics, relationships, coordinate frame interpretation, and a practical example. It is complete enough for an agent to invoke correctly without additional 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?
With 0% schema description coverage, the description fully compensates by detailing each parameter: component names from get_active_assembly_info, face positions with axis mappings, mate_type with options, distance_mm condition, and align with defaults. The example ties everything 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 mate between two components using relative face positions (top/bottom etc.), differentiating it from other mate tools that require entity names or indices. The verb 'creates a mate' and specific resource handling 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is a convenience wrapper to avoid locale-sensitive face naming, and provides an example for stacking. It implies when not to use (if you have exact entity names or need precise face selection), but does not explicitly list alternatives or when to use other mate tools. However, 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, the description fully discloses behavioral traits: sketch edit mode required, no rebuild until exit, relation makes sketch fully defined and prevents drifting. Also explains return format. Comprehensive for a tool without annotations.
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?
Contains redundant bilingual text (Spanish and English versions). While the English part is well-structured, the duplication adds unnecessary length. Could be more concise by removing one language section.
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 and no output schema, the description covers purpose, usage constraints, parameter details, return info, and related tools. Fully adequate 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?
Schema coverage is 0%, so description adds crucial meaning: relation values are listed (horizontal, vertical, etc.), entity_points_mm explained as points on segments with closest-segment picking. Also specifies which relations take 1 or 2 points. Greatly enhances 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 adds geometric constraints (horizontal, vertical, coincident, tangent, equal, fix) to sketch segments. It uses specific verbs and resources, and 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 explicit context: sketch must be in edit mode, used after drawing geometry and before extrusion. Mentions typical CSWA workflow and combination with add_sketch_dimension. Lacks explicit exclusion of alternatives but sufficiently guides 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?
No annotations are provided, so the description carries full burden. It discloses that the sketch stays open, must be exited to save changes, and that a rebuild while open will exit it on SW 2026 ES. It also notes that other sketch tools work as on a fresh sketch. Missing error handling (e.g., sketch not found) slightly reduces score.
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 fairly concise and front-loaded with the purpose. It includes both Spanish and English, which may be redundant but adds clarity for bilingual users. Key sections: purpose, usage, args, returns, caveat.
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 (1 param, no output schema, no annotations), the description is thorough: explains purpose, usage, behavioral nuances, return value, and related tools. Nothing critical is missing.
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 compensates by specifying the parameter 'sketch_name' as an exact name with an example ('Croquis1'). This adds 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: reopening an existing sketch for editing (dimensions, relations, geometry) without rebuilding the part. It distinguishes itself from sibling tools by specifying it's for editing, not creating.
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 a typical CSWA usage example and explicitly mentions when to use alternatives like create_sketch or modify_dimension. It also instructs that after editing, the user must exit with a sketch-consuming operation to lock changes.
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 return contents (part name, modified status, features, bodies) and implies read-only behavior, but doesn't mention potential limitations like performance impact.
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 well-structured sentences: purpose, contents, usage guidance. No extraneous words, front-loaded with key 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 no output schema and a simple tool, description adequately covers what the tool returns and its purpose. Could mention prerequisite (part must be open) but implied by 'active part'.
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%. Description adds full meaning beyond the empty schema by detailing the information returned.
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 uses a specific verb ('Return') and resource ('active SolidWorks part') and clearly distinguishes from siblings by mentioning its use for discovering body names needed for extrude_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 states when to use (before modifications) and references a specific sibling tool (extrude_cut) to provide context for body name discovery.
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 states the tool is read-only and does not modify the document. It explains that for multi-body parts, the bounding box unions all solid bodies. Since no annotations are provided, the description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a summary, field list, behavioral note, use cases, and an example. It is concise without superfluous information, though slightly longer than necessary for a zero-parameter tool.
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 is complete. It explains what the tool does, its return values, behavior for multi-body parts, and practical applications. No additional information is needed.
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 no parameters, so schema coverage is 100% trivially. The description adds value by detailing the return dict structure (min_mm, max_mm, size_mm, center_mm) and their meanings, compensating for the lack of output 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 returns the axis-aligned bounding box of the active part or assembly in mm. It specifies the output fields and distinguishes from other tools by focusing solely on bounding box retrieval. No sibling tool serves this 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 provides common autoparts uses like stock selection, sanity checks, and nesting. While it doesn't explicitly list when not to use this tool, the use cases are clear and there are no direct alternatives among 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?
With no annotations, the description fully discloses read-only behavior, lists dimension types (operations, sketches, mates), and mentions limitations like renamed dimensions not appearing and angular sketches reported as length.
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 informative but somewhat verbose. It front-loads the purpose but could be slightly more concise 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 fully explains the return value structure (count, dimensions with path, owner, etc.) and covers behavior in assemblies and caveats. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100%, so baseline is 3. Description does not need to add parameter 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 the tool lists all dimensions in the active document ('lista TODAS las cotas del documento activo'). It specifies the use case as a discovery step for conversational editing and distinguishes itself from sibling tools like 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (as discovery step for editing), provides guidance on mapping spoken values to dimensions, and tells the user to pass owner/name to modify_dimension. Also includes caveats about renamed dimensions and angular reporting.
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 the description carries full burden. It explains the geometry_pattern behavior, parameter sources, and return value, but doesn't mention potential side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with paragraphs, bullet points, and a clear 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param tool with no output schema, the description covers purpose, all parameters with examples, usage tips, and return value, making it 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?
With 0% schema coverage, the description fully compensates: explains feature_names sourcing, mirror_plane aliases and syntax, and geometry_pattern effect, far exceeding the schema's type/default 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 mirrors features about a plane or planar face, provides concrete examples like symmetric brackets, and distinguishes it from other pattern tools among siblings.
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 it (symmetric parts, half-modeling) and provides an example, but does not explicitly contrast with alternatives like linear_pattern or circular_pattern.
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 the behavioral effects of each state: 'suppressed' means hidden and excluded from BOM, 'resolved' fully loaded, 'lightweight' graphics only. It also describes the config_scope options and notes the return value. No contradictions exist.
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 purpose and includes a structured 'Args' section. However, it repeats information in both Spanish and English, which adds redundancy. Otherwise, it is well-organized and each 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?
Given the 4 parameters and no output schema, the description covers the input semantics and typical usage. It also specifies the return value (updated state). It lacks mention of prerequisites (e.g., active assembly) or error handling, but the CAD context is implied.
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?
Since schema description coverage is 0%, the description adds crucial meaning beyond the schema types. It explains 'component_name' comes from 'get_active_assembly_info', defines each state with its effect, and provides example usage for 'config_names'. Parameters are well-documented.
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 the component load state and provides typical use cases like suppressing/resolving for configuration variants and using lightweight for large assemblies. It distinguishes itself from siblings such as 'set_mate_suppression' and 'set_components_suppression' by targeting a single component's load state.
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 concrete examples of when to use each state (e.g., 'suppress/resolve to build configuration variants' and 'lightweight on big assemblies with hundreds of fasteners'). However, it does not explicitly state when not to use this tool or mention alternative tools (e.g., the plural version 'set_components_suppression'), so the guidance is clear but not fully exclusive.
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 that activation triggers a rebuild, applies suppressions and dimension values, and returns the previous configuration name. No annotations exist, so the description fully carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise bilingual description with front-loaded main action, then details, use case, and parameter doc. 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?
Fully covers the tool's behavior, return value, and use case. No output schema, but description explains return. Complete for a simple 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?
Describes the single parameter 'name' as 'Name of the configuration to activate', adding meaning beyond the schema's type string. Schema coverage is 0% but the description 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 states the verb "activate" and resource "configuration" clearly, and distinguishes from siblings like create_configuration or delete_configuration by specifying the action of switching and the rebuild trigger.
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 mentions the use case: verify a variant built with build_variant_family before saving. Provides context but does not list conditions when not to use or alternatives other than build_variant_family.
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 compensates. It explains that SW selects the closest entity, infers dimension type, overrides the value, and returns the dim name. It also includes a gotcha about forcing dimension type.
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 front-loaded action and bullet points, but includes Spanish content that is redundant for an English-language AI agent. Still, every English 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 the tool's complexity (6 parameters, required edit mode, return value), the description covers all aspects: prerequisites, behavior, gotchas, and follow-up usage with modify_dimension and global variables. It is fully 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%, but the description explains each parameter in detail: entity point must lie on the entity, value_mm overrides, text_offset defaults to (20,10). It adds meaning far 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?
The description clearly states the tool adds a driving dimension to a sketch entity at a given point, with auto-naming. It distinguishes well from sibling tools like add_sketch_relation and add_sketch_fillet by focusing on dimensioning.
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 context: typical use after creating sketch entities in CSWA, and a strict prerequisite requiring sketch edit mode. It also warns about dimension type inference. It doesn't explicitly name 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: validates loop closure before SolidWorks call, leaves sketch open, explains exact mode to avoid drift, and notes it's call-count atomic but not SW-transactional. All important traits are 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 lengthy but well-structured with clear sections, bilingual text, and bold headings. It is front-loaded with the core purpose and typical use. Minor redundancy from bilingual text.
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 (dict with sketch_name, plane, etc.) and mentions related tools. All aspects of a complex tool are adequately covered.
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 carries the full burden. It provides detailed explanations for all 6 parameters, including format, defaults, valid values, and usage notes. The segments parameter is thoroughly described with sub-fields.
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 a sketch from a single ordered list of segments, distinguishing it from the many separate create_line/create_arc calls. It also emphasizes the validation of loop closure, making the purpose very 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 provides a typical use case (CSWA Tool Block) and contrasts with primitives. However, it does not explicitly state when not to use this tool or list alternatives beyond create_line/create_arc.
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, but the description is extensive: it details the internal composition steps, the return dictionary, geometry orientation contract, and a caveat about a sharp inside corner. This fully compensates for the lack of 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 well-structured with sections, but the junior workflow example and detailed step composition could be considered slightly verbose. However, it remains clear and 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?
Given the complexity (8 parameters, no output schema, no annotations), the description is comprehensive. It covers purpose, parameters, geometry, return values, and provides an example, making it complete for agent selection.
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, but the description provides detailed explanations for all 8 parameters, including defaults, constraints, and units. It adds significant meaning beyond the schema 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 builds an L-shaped autoparts bracket with bolt holes, and distinguishes it from siblings by specifying it wraps multiple steps into one call. The verb 'build' and resource 'L-bracket' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is for the most common stamped autopart and wraps a multi-step flow, but does not explicitly state when to use this tool versus alternatives like build_plate_with_hole_pattern or build_flange_boss. However, the specificity makes usage 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?
No annotations provided, so description carries full burden. Explains default behavior (refuses dirty doc) and force behavior (discards unsaved changes), underlying verb distinction (CloseDoc vs QuitDoc), return dict fields (closed, name, was_modified), and error conditions. 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?
Well-structured with sections (Args, Returns, Raises, Examples) and front-loaded purpose. However, includes both English and Spanish translations which may be slightly redundant. Generally clear but could be 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 no output schema, description covers return dict and errors. Provides examples, explains error conditions, and gives canonical use cases. Complete for a simple tool with one parameter.
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 (no param descriptions), so description must add meaning. It does: explains default (False) raises error if dirty, True silently discards, with use case (throwaway doc). 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?
Description uses specific verb 'Close' and resource 'active document in SolidWorks', with additional context about its role in iterative workflows. Clearly distinguishes from siblings like save_as and open_document.
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 describes when to use (iterative build→save_as→close→new_part→rebuild flows) and why (prevents window pile-up and save_as collisions). Mentions default vs force behavior but doesn't explicitly state 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?
With no annotations, the description carries full behavioral disclosure weight. It reveals that COM driver may return None for through/depth, indicating a degradation in capability. It does not mention idempotency or auth, but for a read-only feature inspection tool, the provided details are sufficient.
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 mostly concise but includes a Spanish fragment at the start which may confuse some agents. The key information is front-loaded and each sentence adds value, but the bilingual aspect slightly reduces 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 a single parameter, no output schema, and no annotations, the description fully covers the tool's behavior: return fields, usage scenario, parameter specification, and limitations. It is complete for agent 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 compensate. It provides detailed semantics for feature_name: exact name, verbatim requirement, locale-sensitivity, and source (get_active_part_info). This is critical for proper invocation and far exceeds basic schema repetition.
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 reads a built feature's definition and lists the returned fields. It also mentions its use by verify_build_report, providing a specific use case that distinguishes it from sibling tools like 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the tool (e.g., for distinguishing through-hole vs blind features) and provides conditions for accurate results (rich path vs COM driver, locale-sensitive feature names). This gives clear guidance beyond the basic purpose.
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. Discloses requirement for active sketch and intersecting material, failure behavior (sketch re-opened), return format (Feature with name/type/dimensions), and a known bug with up_to_surface and reference planes.
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?
Long but well-structured with sections (Args, Returns, Caveat, Failure recovery, Example). Every sentence adds value. Front-loaded with purpose. Slightly verbose due to complexity but justified.
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?
Completely covers all 9 parameters, return value, caveats, failure recovery, examples, and even a known bug. No output schema, but description provides sufficient behavioral and semantic 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?
Zero schema description coverage, but description provides rich parameter details: conditional meaning of depth_mm, locale-sensitive reference_name, target_bodies as scope, offset_reverse only for offset_from_surface, start_condition/start_offset_mm, etc. Adds value well 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 cuts/subtracts material from a part after exiting an active sketch. Provides a SolidWorks analogy and common use cases. Distinguishes from siblings like extrude_sketch (additive) and other cut tools by focusing on linear extrude cuts.
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?
Extensive guidance on when to use each end_condition, target_bodies, and other parameters. Includes failure recovery and related composites. Could be more explicit about when not to use this tool vs. revolve_cut, sweep_cut, etc., but the detail is thorough.
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 key behaviors: non-parametric nature, tangent propagation collapsing edges, filtering rules for min_edge_length_mm, and include_arcs 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 clear sections for args, returns, and examples, though slightly long; 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?
Covers all aspects: purpose, parameters, return format, behavior notes, and examples. Output schema is implicitly provided in description.
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, meaningful explanations for each parameter including typical values, behaviors, and edge cases.
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 every edge' and provides specific use cases for autoparts, distinguishing it from siblings like 'fillet' and 'break_all_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?
It gives explicit when-to-use contexts (cast/forged parts, brackets, plastic parts) and includes examples, but lacks direct when-not-to-use or alternative tool mentions.
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?
Describes return content in detail. No side effects noted; 'get' implies read-only. Could mention error handling for no open assembly, but sufficient for agent.
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 concise sentences with purpose first, then content, then usage guidance. No waste, well-structured.
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?
Provides full return details without output schema, plus usage context. Complete for a metadata retrieval 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, schema coverage 100%. Baseline 4 appropriate as description adds no parameter info, but none 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?
Clearly states it returns metadata about the active assembly, listing specific content (name, modified flag, configs, components, mates). Distinguishes from sibling manipulation 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?
Explicitly instructs 'Call this before any mate / suppression / configuration operation', providing 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?
With no annotations, the description fully discloses behavioral traits: index instability across rebuilds, midpoint being null for closed-loop edges, and the inability to select edges by name string. It explains durable vs non-durable references.
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-organized with sections for return values, args, use case, caveat, and example. While slightly lengthy, every sentence adds value. The structure aids comprehension.
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) and the presence of an output schema, the description thoroughly covers return fields, use case, caveats, and parameter behavior. It is complete for agent 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?
The sole parameter 'body_name' has 0% schema description coverage, but the description fully explains its effect: when given, returns edges of that body; otherwise returns edges of all bodies. This adds complete 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 it enumerates edges of one or all solid bodies, with specific return fields. It distinguishes from sibling tools like list_faces and fillet/chamfer by providing the use 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 explicitly guides use for pre-fillet/pre-chamfer workflows and advises using midpoint values verbatim. It does not list exclusions but provides a caveat about edge selection limitations, offering practical 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 exist, so description carries full burden. It exhaustively documents return fields, durability caveats, and omitted fields for non-planar/non-cylindrical faces, ensuring 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?
Well-structured with sections (Args, Use case, Caveat, Example). Slightly long but every sentence adds value, and the bullet format keeps it 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 output schema exists, description still provides rich detail on all return fields, edge cases, and an example, making it fully self-contained for the 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?
The only parameter, body_name, is fully explained: if given, filter to that body; else all bodies. Schema has no description (0% coverage), but this description completely 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 states 'enumerate faces of one or all solid bodies' and explicitly frames it as a mirror of list_edges for faces, clearly distinguishing its 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?
Provides clear when to use via the body_name parameter and describes a chained-feature use case. Missing explicit 'when not to use' or alternative tool mention, but still strong.
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: creates and activates empty assembly, requires SW already running, does not launch SW. Returns a dictionary with name and created status.
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?
Bilingual but concise, covering purpose, usage context, caveat, and return value in a few sentences. Information is well-structured 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?
No parameters or output schema needed. Description completely covers essential information: what it does, return format, and prerequisite (SW running).
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?
Tool has zero parameters; baseline score of 4 applies. Description does not need to add parameter 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?
Explicitly states it creates a new empty assembly (.SLDASM), activates it from default template, and is starting point for inserting components. Clearly distinguishes from sibling tools like new_part and open_document.
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?
Describes as starting point for components and mates, and includes caveat that SolidWorks must already be running. Provides 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It details auto-activation behavior, the behavior when a document with the same name is already open (SW activates existing), the limitation of using OpenDoc vs OpenDoc6 (errors/warnings always 0), and caveats about redirected paths. It also explains error types (ValueError, SolidWorksError) and conditions under which they occur.
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 clear sections: main description, usage guidance, args, returns, raises, caveat, and example. Every sentence adds value. However, it is bilingual (Spanish and English), which duplicates content and slightly reduces conciseness. Despite this, the structure is logical 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?
Given the tool's low complexity (1 parameter, no output schema), the description is highly complete. It explains the return value structure, error handling, caveats about OpenDoc vs OpenDoc6 and existing documents, and provides a concrete example. All necessary context for correct invocation is present.
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 only defines 'path' as a string with 0% coverage. The description adds critical meaning: the path must be absolute and include the extension, which determines the document type. It lists valid extensions, explains that invalid extensions cause SolidWorksError, and specifies that empty path raises ValueError. This goes far beyond the schema's minimal 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 it opens an existing SolidWorks document by absolute path, specifies the supported file extensions (.SLDPRT, .SLDASM, .SLDDRW), and explains that the opened document becomes the active document for other tools. This distinguishes it from sibling tools like new_part, new_assembly, save_active_document, and close_active_document.
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 usage context: 'Úsalo para modifica esta pieza guardada' and explains that it reopens and modifies in place, never rebuilding from scratch. It also gives an example of refreshing after external edits using close_active_document and open_document. However, it lacks explicit 'when not to use' statements or comparisons to alternatives beyond the example, so it does not fully exclude 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, the description carries full burden. It explains no mutation, dry-run only, advisory recommendations, metadata-only reading, network path warnings, and confidence affecting go_recommendation. Fully 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 bullet-point Arg list, but slightly verbose with explanatory prose. Still front-loaded and 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 complexity (8 params, nested objects, no output schema), the description covers purpose, parameters, return fields, usage flow, and limitations. Extremely 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?
Despite 0% schema coverage, the description provides detailed explanations for all 8 parameters, including examples for 'operation' and semantics for 'fileset'. Adds immense 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 the tool records a batch job and returns a dry-run preview without mutation. It uses specific verbs ('Registra...devuelve...SIN mutar') and distinguishes from the sibling 'run_batch_job'.
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 guides use: first use this tool for advisorial preview, then use 'run_batch_job' to execute. It 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It states the tool records only, does not execute, requires human review of generated_source, and that '<required>' in code blocks run_macro_job. 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 somewhat lengthy but well-structured with a purpose paragraph and an args list. It is front-loaded with critical information. 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.
Completeness4/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 covers the tool's purpose, parameters (except assumptions), return object, and workflow. It is sufficiently complete for a recording/advisory tool, though error handling is omitted.
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 description adds detailed meaning for most parameters (intent, generated_source, proc_name, provenance, confidence) beyond the schema (which has 0% description coverage). However, the 'assumptions' parameter is not explained, 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 an AI-authored VBA macro job for execution via RunMacro2. It distinguishes itself from sibling tools like run_macro_job by emphasizing it is advisory only and crosses constraint #2 for tasks outside the verb catalog.
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 this tool (for tasks outside the standard verb catalog) and when not to use it (it does not execute; instead, use run_macro_job after human review). It also explains the approval workflow, making it clear how to proceed.
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 effects: changes mass properties but not geometry. Provides return value details and caveats (locale, database path). Transparent about 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: summary, explanation, parameter details, caveat, example. Front-loaded with purpose. Slightly verbose but justified by 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?
No output schema, but description provides return format. Covers prerequisites, locale, custom databases, and relationship to other tools. Complete for a setter 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?
Input schema has minimal parameter info (0% coverage). Description adds extensive meaning: lists common material examples, explains locale sensitivity, details database_path usage. Fully compensates for schema 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?
Clearly states 'set the material on the active part'. Provides a specific verb and resource, distinguishing it from siblings. Also explains prerequisite for get_mass_properties, reinforcing its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says required before get_mass_properties for meaningful mass. Gives examples and locale warning. Does not explicitly state when not to use, but the dependency makes it 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?
With no annotations, the description carries full burden. It discloses behavioral traits such as the live note about component suppression not flipping mates' suppressed flags in this version, and advises a snapshot-diff workflow. It also notes the return value includes metadata. This adds valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long due to bilingual content, but the English portion is clear and front-loaded with purpose and use cases. The workflow is detailed but justified. A minor redundancy between languages prevents a perfect score.
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 simple parameters, the description addresses complexity with version-dependent behavior and provides a concrete workflow. It mentions returning metadata (no output schema needed). The description is complete for safe and correct tool 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%, but the description fully explains both parameters: mate_name is an SW-assigned name from get_active_assembly_info (with example), and suppressed is True to suppress, False to resume. This adds complete 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 suppresses or resumes a mate by name, with specific verb+resource. It further distinguishes from siblings by providing use cases like parking a wrong-branch mate before recreating and post-component-suppression cleanup, which contrasts with component suppression 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 provides when to use the tool, including concrete scenarios: 'desactivar un mate de rama incorrecta antes de recrearlo con place_and_mate' and 'limpiar tras supresión de componentes'. Additionally, it includes a detailed workflow for cascade-aware resume, guiding the agent on proper usage sequence.
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 important behavioral traits: destructiveness to subsequent face-anchored sketches, SolidWorks silent rejection of thickness too large, outward parameter effect, return value format. Since no annotations exist, the description carries full burden and meets it thoroughly.
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, detailed args, caveat, and example. Some redundancy (bilingual title) and verbosity, but information is effectively organized 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?
Covers all aspects: purpose, parameters with constraints, behavioral caveats, usage timing, and a concrete example. No output schema exists, but return value is explained. Complete for a complex shell operation.
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, the description adds complete meaning: thickness_mm (positive, < half smallest dimension), face_centroids_mm (from list_faces, exact match), selector (face-selector schema, mutually exclusive), outward (default inside). Compensates fully for missing 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 the tool's function: 'Vaciado de pared (shell) — hollow out the body, optionally removing the listed faces to leave openings.' It specifies the verb (hollow out) and resource (body), and distinguishes it from siblings by focusing on shell operations with face removal options.
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 usage contexts: common for cast housings, plastic enclosures, and hollow cases. Advises to run shell_part late in the feature tree to avoid destructiveness. Does not explicitly state when not to use, but the guidance is clear and 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?
With no annotations, the description fully discloses behavioral traits: it creates a boss feature, requires a closed profile, the path can be open/closed, merge behavior, return type (Feature), and v1 limitations (no twist, guide curves, etc.). 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 clear sections (purpose, uses, args, returns, caveat, example). It is slightly verbose but each part adds value. Minor redundancy could be trimmed, but overall 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 no output schema, the description explains the return value (Feature with specific properties). It covers prerequisites, limitations, and provides a full example. All aspects needed for correct usage are addressed.
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 thorough explanation for each parameter: profile_sketch_name (closed contour), path_sketch_name (open or closed, perpendicular plane), and merge (merge vs. multi-body). An example with concrete values is included.
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 sweeps a closed profile sketch along a path to create a boss feature. It lists specific use cases (tubes, gaskets, etc.) and distinguishes from the sibling sweep_cut by focusing on boss 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?
The description explains when to use the tool (e.g., for tubes, gaskets) and what prerequisites are needed (sketches must exist separately). It does not explicitly state when not to use it or mention alternatives like sweep_cut, but enough context is provided for appropriate 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 are provided, so the description carries the full burden. It details the internals: uses get_bounding_box, numeric comparison with tolerance, optional volume check (order-of-magnitude only, never flips verdict), and the return structure. It also discloses limitations and caveats.
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 Spanish and English versions. It is front-loaded with the core purpose and then provides arg explanations. A minor concession for length, 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 the complexity (5 params, no output schema), the description covers necessary behavioral details, output structure, and caveats. It also references related tools (get_bounding_box). It is complete for an agent to understand when and how to use 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%, but the description thoroughly explains each parameter: expected_size_mm (three extensions in any order), tolerance_mm (minimum band), tolerance_pct (relative, uses max), expected_volume_mm3 (optional, order-of-magnitude), match_by (sorted vs positional). It 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 explicitly states the tool verifies built-part size against the drawing spec, contrasting with visual checks. It clearly identifies the resource (built part size) and the action (verify). It distinguishes itself from other verification tools by being an independent ground-truth check.
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 the first independent ground-truth check) and when not to rely solely (caveats: cannot see wrong location, topology, envelope-preserving errors). It provides context on the kind of errors it catches, but does not explicitly name alternative tools for other types of checks.
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 fully carries the burden. It discloses the internal storage (meters/radians), the equation manager's behavior (accepts dim-paths on LHS), and the warning against re-adding. It also describes the return value in detail, ensuring the agent understands the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage, parameters, return, additional notes). It is front-loaded with the primary purpose. While slightly lengthy, every sentence adds value, so it earns a 4 rather than a 5.
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?
The description covers parameters, return value, and usage context thoroughly. It includes an example of binding a dimension. However, it lacks error handling details or edge cases, which would make it complete given the lack of an 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?
Schema description coverage is 0%, but the description compensates fully. It explains each parameter: name (LHS with constraints), value (numeric), units (options and default). It gives SW conventions and examples, 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's purpose: to add a global variable (equation) as a named parameter. It specifies the verb 'add' and the resource 'global variable', and distinguishes from siblings like set_global_variable and modify_dimension. The context of parametric parts is also provided.
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 (parametric parts like CSWA Tool Block) and when-not (do not call again with same name; use set_global_variable for modification). It also explains how to bind dimensions to the variable and lists related 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, description carries full burden. Discloses behavior: replaces vertex with line, requires edit mode, adjacent lines, potential API failure, and workaround. 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 (Spanish/English) adds length, but structure is clear with sections. Could be more concise by deduplicating languages, but still well-organized.
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 6 params, no output schema, no annotations, description covers purpose, prerequisites, gotchas, workaround, and return type. Slight gap: no detail on return format, but sufficient for agent 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: line points, z default, distance along each line. Adds meaningful context beyond schema 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?
Clearly states it cuts a sketch corner with a 45° equal-distance chamfer, distinguishes from sibling 'chamfer' (3D edge chamfer) 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (e.g., CSWA Tool Block), prerequisites (sketch in edit mode, adjacent lines), and workaround if API fails. Also notes distinction from 3D chamfer.
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. It details the composite operation, default direction, through_all behavior for the bore, and caveats about unintended cuts. It also explains the colinear construction and return format.
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, example, parameter list, returns, caveat, and usage example. It is front-loaded and every sentence adds value. Though lengthy, it is justified 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 no output schema, the description includes return format. It thoroughly covers all 8 parameters with constraints and examples, plus caveats. This provides complete context for an AI 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?
Schema description coverage is 0%, but the description fully documents each parameter with conditions (e.g., bore_diameter_mm > 0 and < outer_diameter_mm, reverse_extrude effect, bore_target_bodies scoping). This adds significant meaning beyond the schema's bare 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 it creates a cylindrical boss with optional through bore, using specific verbs like 'crear' and 'composes'. It distinguishes from sibling tools by describing its composite nature (sketch+extrude for boss and optional bore). The example clarifies 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 provides a junior workflow example and explicit exclusion: 'For blind bores, call extrude_cut separately after this composite.' It also advises when to use bore_target_bodies. However, it does not contrast with similar sibling tools like build_stepped_shaft or build_threaded_boss.
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?
Even without annotations, the description fully discloses behavior: opens files read-only in series, saves locally, no network/telemetry, incremental based on mtime+size, rebuild and max_parts limits, and that it opens/closes documents requiring SolidWorks idle.
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: summary sentence, then process details, then args list, then return fields. Every sentence adds value, no fluff. Front-loaded with the main 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 no output schema, the description lists return fields. It fully covers how the tool works, what it produces, and edge cases (incremental, rebuild, max_parts). Complete for a file scanning/indexing 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?
The description explains all three parameters (folder, rebuild, max_parts) in detail, providing meaning beyond the bare schema. It clarifies folder recurses and ignores temporary files, rebuild forces re-read, and max_parts is a cap per run.
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 (index), resource (folder of .SLDPRT parts), and result (local catalog in mcp_cad_index.sqlite). It distinguishes from siblings by being a local indexing tool vs. modeling or query 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?
Provides clear context for when to use (indexing parts locally), includes conditions (SolidWorks idle), and explains incremental behavior and rebuild option. Lacks explicit comparison to siblings like search_part_catalog, but the use case is well-defined.
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: requires active sketch, geometry is non-parametric (cannot resize post-hoc), returns center/radius/diameter, and suggests rebuilding from fresh part for resize. This goes beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, parameter list, return, common uses, example, caveats, and related tools. It is front-loaded and every section 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 having no output schema, the description covers return values. It includes prerequisites, limitations, and alternative tools. For a simple drawing tool, it is comprehensively 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 the description compensates by explaining all 5 parameters: cx_mm, cy_mm, radius_mm, and aliases center_x_mm, center_y_mm. It clarifies the constraint to pass one name per axis and that radius must be positive, with an example.
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 circle on the active sketch' with a specific verb and resource. It distinguishes itself from siblings by mentioning add_bolt_circle as an alternative for bolt patterns, and provides common autoparts uses.
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 the prerequisite (requires active sketch) and explicitly names an alternative tool (add_bolt_circle). It implies when to use via common uses, but does not explicitly state when not to use (e.g., for parametric circles).
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 discloses that the sketch is left in EDIT mode after creation, and returns the sketch name and resolved plane name. With no annotations, it carries full burden; some minor aspects like error handling on invalid plane names are not covered, but overall it's good.
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 and well-structured: one sentence for purpose, a bullet list for parameter values, and clear flow instructions. 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?
For a single-parameter tool with no output schema or annotations, the description covers input, behavior (edit mode), return values, prerequisites, and post-creation steps. It is sufficiently 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 coverage is 0%, but the description fully explains the plane_name parameter: lists valid values ('front', 'top', 'right' and Spanish equivalents) and notes case-sensitivity. This adds complete meaning beyond the schema that only defines type 'string'.
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' with specific verb and resource. Among siblings like create_sketch_on_face, it correctly distinguishes by specifying the starting reference is a plane, not 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 when to use (requires a part document, not assembly) and provides a workflow sequence: create_sketch first, then add geometry with create_rectangle, then extrude_sketch. It also warns about the prerequisite of opening a fresh 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?
With no annotations, the description fully discloses behavior: it is a read-only operation that reads every feature and returns specific details. It mentions handling of unknowns ('through=None') and occluded cuts, and explicitly states 'Read-only.' There are 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 relatively long but well-structured with clear sections: overall purpose, feature details, bore info, and usage advice. Every sentence adds necessary information, though some redundancy could be trimmed. It is front-loaded with the main 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 no output schema, the description provides a thorough explanation of all returned data: per-feature fields, per-cut details, source of values, handling of unknowns and occluded cuts, and the bore inventory. This ensures the AI agent understands exactly what to expect.
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 description does not need to explain parameter meaning. According to the rubric, 0 parameters warrants a baseline of 4. The description adds value by explaining the output structure, which is helpful for understanding what the tool returns.
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 provides a complete inventory of every feature in the tree with detailed per-feature and per-cut information, plus a geometry-based bore inventory. It distinguishes itself from siblings like 'describe_feature' and 'list_faces' by offering a comprehensive overview suitable for before-modification verification.
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 guidance is given: 'USE BEFORE modifying any multi-feature part: enumerate every cut, change one, re-call, then confirm feature_count + the OTHER features are unchanged.' This clearly indicates when to use the tool and the intended workflow. The description also notes that occluded cuts require a different tool ('capture_views'), providing when-not-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?
With no annotations provided, the description fully discloses behavior: it is read-only, returns data in specific units, lists all return fields with types and units, and notes the dependency on a material being set. No surprises or 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 thorough but not overly verbose. It is well-structured with sections for purpose, return dict, caveats, uses, and example. The front-loading of the core purpose is good. Could be slightly more concise, but the structure 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 zero parameters and no output schema, the description provides a complete explanation of the tool's functionality and return values. It also provides context for typical use cases and prerequisites, making it fully self-contained for an 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?
There are no parameters, so the schema coverage is 100%. The description adds value by detailing the output format and units, which goes beyond the empty input schema. Baseline 4 is appropriate as the description compensates for the lack of 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?
Clearly states the tool reads mass properties (mass, volume, surface area, etc.) for the active part or assembly. The verb 'read' and specific resource 'mass properties' make the purpose unambiguous. It distinguishes itself from sibling tools by specifying its exact output fields.
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 common use cases (quoting, lightening pass, inertia analysis) and provides a concrete example. Includes caveats: requires material to be set, behavior with default material, and references set_material as a prerequisite. This provides clear when-to-use and actionable 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 were provided, so the description carries full burden. It thoroughly discloses behavior: sequential per-step execution, real-time receipts via get_active_assembly_info, stop-and-report on failure with no deletion, final mate count verification, save only on verified success, and return structure {ok, steps, verification, saved, warnings}. All critical traits are 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 moderately long but packed with essential information. It front-loads the main action and uses bullet-like structure (Compuertas, Verificación final) for clarity. The English translation at the end aids comprehension. Every sentence contributes value, though some consolidation 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 (sequential live assembly with failure handling and verification), no annotations, no output schema, and 3 parameters, the description covers all necessary aspects: purpose, behavior, failure modes, verification criteria, return format, and overrides. It leaves no critical gap for the agent to execute 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 description coverage is 0%, so the description must compensate. While it does not explicitly list parameter names, it explains the override flags' purpose and conditions (override_unmated for unmated components, override_low_confidence for confidence gates). The assembly_plan_id is implied by 'AssemblyPlan registrado'. This adds meaningful context 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?
The description clearly states the tool executes a recorded AssemblyPlan by inserting and mating components one by one, and explicitly distinguishes it from batch execution (execute_batch). It uses a specific verb ('Ejecuta') and resource ('AssemblyPlan registrado'), making 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?
The description provides explicit usage context: when to use (sequential live assembly), when not to (batch execution due to real rebuilds and rollback limitations), and conditions for overrides (go_recommendation, unmated components). It even mentions failure handling and alternative mitigation (set_component_suppression).
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 discloses key behaviors: silent save (no UI dialogs), only works if document has filename, and raises specific errors. It also details return dict fields including error/warning bitmasks.
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 clear sections and alternating languages, but the bilingual nature makes it slightly longer than necessary. 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 annotations and no output schema, the description covers all necessary context: purpose, usage, behavior, return format, and error handling. It is complete for a tool of this 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?
There are no parameters, and the baseline for 0 params is 4. The description adds value by explaining behavior and return values, but no parameter semantics 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 the tool saves the active SolidWorks document silently, equivalent to Ctrl+S, and explicitly mentions it works on parts, assemblies, or drawings. It distinguishes itself from save_as 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?
The description explicitly says the tool should be used when the document already has a filename, and for new documents it instructs to use save_as. It also notes prerequisites and error conditions.
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 coarse behavior, honest reporting of nothing to undo (undone=False), and states it cannot recover closed/lost documents. 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?
Front-loaded with core purpose and includes essential warnings. Slightly lengthy due to bilingual text, but every sentence adds value. 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?
For a no-parameter tool, description covers purpose, usage, behavioral constraints, return format, and verification steps. Very complete given simplicity and lack of 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?
No parameters in schema (0 params), so no additional meaning needed. Baseline 4 is appropriate for zero-parameter tools.
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 undoes the last SolidWorks step (Ctrl+Z/EditUndo2). It distinguishes from siblings like rollback_to_end/rollback_to_feature by emphasizing coarseness.
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 warnings: undo is coarse, does not necessarily correspond to last MCP call, cannot recover closed docs; advises to capture_views after and not chain blind undos.
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 explains behavior: it runs diagnostics, returns a checklist with ok/summary/checks, and interprets results (e.g., normal scenarios). 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 bulleted checks and JSON example but includes bilingual text and some redundancy. Could be slightly more concise, but all content is relevant.
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?
Description covers all necessary context: purpose, when to use, what checks are performed, return format, and interpretation of results. No annotations or output schema needed given completeness.
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 does not need to add parameter 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?
Clearly states it is a diagnostic tool for verifying MCP_CAD installation. Lists specific checks (server, SolidWorks, active document) and output format. Unambiguously distinct from sibling modeling 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?
Explicitly tells when to use: after install or when something seems off. Provides expected behavior for different check outcomes, e.g., red check on active document is normal, SolidWorks issue requires opening SW 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?
Since no annotations are provided, the description fully discloses behavior: it creates a single sketch with all holes and a single extrude cut, returns feature info, and highlights that it is not parametric. It explains reverse_direction and target_bodies, and the caveat that changing hole_count requires deletion and re-run.
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 summary, detailed args, caveats, and an example. It is front-loaded with the main purpose. However, it is somewhat verbose due to the level of detail required for 11 parameters, but 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 (11 parameters, no annotations, no output schema), the description is very complete. It explains the return value (single feature info), all parameter constraints, and provides usage context (e.g., alignment, scoping cuts with target_bodies).
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, the description provides detailed parameter explanations in an Args section, including constraints (e.g., hole_count >=3, circle_diameter > hole_diameter), defaults, and when parameters are required (depth_mm when end_condition='blind'). This fully compensates for the 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 adds a bolt circle by composing a sketch with N circles placed on a circle and then an extrude cut. It distinguishes itself from feature-pattern-based approaches, 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?
The description explicitly states when to use (sketch-based, any center position) and when not to use (not parametric; for parametric counts use circular_pattern). It provides a concrete example and explains parameters like angle_offset_deg for alignment.
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?
Although no annotations are provided, the description fully discloses behavioral traits: caveat about feature tree representation (Cortar-Extruir instead of Hole Wizard), no cosmetic threads, and details on return values including hole_count, diameters, and counterbore depth.
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 sections for parameter details, return dict, caveats, and examples. Every sentence provides necessary context; however, some repetition (e.g., ISO standards mentioned twice) could be trimmed slightly. Still, it's efficient 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?
For a tool with 8 parameters, 0% schema coverage, no output schema, and no annotations, the description is comprehensive: covers purpose, parameters, return format edge cases, and usage examples. No gaps remain for an AI agent to misuse.
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 carries full burden. It explains every parameter with constraints: hole_type options, size ISO range and limitations, positions_mm format and uniqueness, plane vs. face_centroid_mm mutual exclusivity, end_condition and depth requirements, counterbore_depth_mm default. 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?
The description clearly states the tool 'drills N holes at specified positions using ISO Metric standards.' It specifies action (drill pattern), resource (holes), and distinguishes from sibling hole_wizard by noting multi-position capability vs. single-hole per call.
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 explicitly says when to use (multi-position patterns) and when not (single hole needing proper Hole Wizard styling, direct user to hole_wizard). It also provides two concrete examples for different use cases (tap holes on plane, counterbore on face).
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 transparency burden. It discloses that the operation is not parametric, creates sub-edges affecting subsequent operations, and explains parameter defaults and behaviors (e.g., min_edge_length_mm filter skips circular edges). It also specifies the return 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?
The description is well-structured with a summary, context, args, returns, caveats, and examples. It is not overly verbose given the complexity, though the length could be slightly trimmed (e.g., the Spanish phrase could be more concise). Overall, 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?
Despite no output schema, the description explains the return type and fields. It covers parameter details, edge cases (circular edges skip filter), and caveats. Examples illustrate typical and advanced use. The tool is complex, but the description is fully 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 has 0% description coverage, but the description adds extensive semantics for all five parameters: distance_mm (with recommended values), angle_deg (default), min_edge_length_mm (filter logic for linear vs circular), body_name (scope), and include_arcs (linear-only option). Each parameter is given practical 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?
The description clearly states the tool chamfers every edge (linear and circular by default) for deburring autoparts. It specifies the verb 'chamfer' and resource 'all edges', and distinguishes from siblings like fillet_all_edges and single-edge chamfer tools by noting it replaces three steps.
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 context: universal edge-break for autoparts where deburring is required. It contrasts with manual three-step process, warns about non-parametric nature and interaction with fillet_all_edges, and gives examples for standard, single-body, and linear-only use cases.
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 reveals behavioral traits: closed grammar, no code execution, rollback all-or-nothing, deferred redraw/rebuild, single approval, clear error messages, and return structure (execute_batch result + compiled_ops + summary).
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 with examples, method list, and English summary. While a bit long, each sentence adds value given the complexity of the DSL grammar.
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 complex DSL tool with no output schema, the description covers the entire API: grammar, supported methods, edges, parameters, return value, and error handling. It's 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?
Input schema has 0% description coverage, but the description fully compensates by explaining 'script' as the fluent expression with examples, 'dry_run' as compile-only without touching SolidWorks, and 'rebuild' as a rebuild upon batch close.
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 a part from a fluent build123d-style script in one call. It distinguishes from siblings like execute_batch by explaining it compiles to an op-list and runs as a batch, and from other build tools by emphasizing the closed grammar and no-code-execution nature.
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 (fluent script, one call), what not to use (NO sketch-on-face, use create_sketch_on_face separately), and mentions fallback to execute_batch or standalone tools. It also provides a list of methods and constraints on grammar.
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 the description carries full burden. It fully discloses the composition (creates axis, sketch, lines, revolve), orientation (along +X, Front plane), square shoulders (no fillets), and output structure. Limitations (v1 no taper, fixed orientation) are clearly 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 well-structured with title, workflow, args, returns, caveats, and example. It is front-loaded with the purpose. While slightly long, 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?
No output schema or annotations present. The description covers purpose, parameters, internal behavior, output structure, caveats, and example. For a tool with 4 parameters and moderate complexity, this is fully 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 the description must explain all parameters. It does so thoroughly: diameters_mm as list of step diameters, lengths_mm same length, angle_deg sweep angle (0,360] default 360, merge boolean default true. Constraints (1..20 entries, >0) are provided, adding 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 explicitly states 'Flecha escalonada — build a stepped (multi-diameter) cylindrical shaft in one call.' It clearly identifies the resource (stepped shaft) and verb (build), and distinguishes from siblings like revolve_sketch by noting it is a composite operation.
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 a junior workflow example, caveats for orientation, transitions, and no taper, and explicitly mentions when to use revolve_sketch directly for tapered shafts or custom orientation. It includes a concrete example, giving strong guidance on when and how 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: it composes an extrude_sketch and an extrude_cut, notes that the tap hole is not a Hole-Wizard feature, and explains limitations (no cosmetic threads). It also describes the return dict and provides caveats about 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?
The description is well-structured into clear sections (overview, workflow, args, returns, caveats, examples), but it is somewhat verbose with extraneous details like the Spanish phrase. However, it is front-loaded with the core purpose and remains informative without 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 the tool's complexity (10 parameters, no output schema, no annotations), the description is exceptionally complete. It covers all parameters, constraints, return values, usage examples, and caveats. It leaves no significant gaps for an AI agent to misinterpret.
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, so the description compensates fully by explaining each parameter in detail: plane with examples, center coordinates, outer_diameter_mm with constraint, height_mm, thread_size with ISO metric mapping, thread_depth_mm with default, end_condition options, reverse_extrude, and tap_target_bodies. This 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 creates a cylindrical boss with a centered tap hole. It distinguishes from alternatives like hole_wizard by noting that this tool does not produce cosmetic threads, and it explicitly positions itself as a standard autoparts pattern. The purpose is 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 guidance on when to use this tool (for threaded bosses in autoparts patterns) and when not to (when cosmetic threads are needed, use hole_wizard). It includes a junior workflow example and constraints on parameters (e.g., outer_diameter_mm must be > tap-drill diameter).
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 the description carries full burden. It discloses privacy risks (images may contain confidential data, sent to client/host), cadence advice, behavior of parameters (with_dims is a no-op, section creates cut planes), return format (list of images + summary), and caveats (requires open part, temp files not deleted). 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 lengthy but well-structured with clear sections (privacy warning, cadence, args, returns, caveat, example). Each part adds value, though it could be slightly tightened. The front-loading of purpose and privacy warning 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 no output schema, the description covers return values (list of images + summary dict with resolved views, paths, with_dims, privacy note) and handles edge cases (unknown view raises ValueError, section behavior, with_dims no-op). Includes an example showing integration with other tools. All essential context for correct use is present.
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; the description fully explains all three parameters. views: acceptable subset of view names, default, error on unknown. section: optional dict with plane and offset_mm, how it works for internal cuts. with_dims: accepted but no-op, rationale. Provides concrete examples and constraints.
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 renders the active part or assembly to PNG for visual verification. It uses specific verbs and resources (render, PNG, visual verification) and distinguishes itself from sibling tools by emphasizing its role in visual checks, not modeling or 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?
The description provides explicit guidance: use at checkpoints and end of build, not after every feature; trust cheaper signals in between; per-feature renders only for debugging; mandatory final render. It also mentions an alternative (verify_build_report capture_view_names) for bundling renders.
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 shoulders behavioral disclosure. It details return structures for match and miss, caveats about Mexican-Spanish specificity, terms that are generic or ambiguous, and mentions version limitations (v1 vs v1.1). 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 longer but well-structured with sections for use case, return values, caveats, and example. Information is front-loaded with the core purpose in Spanish and English. Every sentence adds value, but the dual-language nature slightly increases 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 1 parameter, no output schema, and no annotations, the description covers purpose, parameters, return structures (both match and miss), caveats, and example usage. It is fully complete for the tool's complexity and context signals.
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 description in schema), so description adds all meaning. It thoroughly explains the 'term' parameter: case- and accent-insensitive, and specifies the context (Spanish/Spanglish autoparts term). This far exceeds baseline and compensates for 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 that the tool returns curated geometric interpretations for informal Spanish/Spanglish autoparts terms, specifying the verb 'look up' and resource 'autoparts terms'. It distinguishes itself from sibling CAD/modeling tools by being a disambiguation/interpretation step before proposing a plan.
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 instructs to use in Phase 2 / Layer 2 when a user uses an informal term and interpretation is needed before proposing a plan. Provides example terms and emphasizes the need to confirm geometric archetype via the disambiguation question. Though no explicit 'do not use', the context and caveats effectively guide appropriate 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, so description fully covers behavioral traits: it discloses that creating a configuration activates it, warns to read active_config before relying on scoped operations, and notes idempotency. 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 well-organized with clear sections (purpose, args, gotcha, related) and is bilingual which adds some length but is acceptable. It is informative without being overly verbose, though the 'verificado en vivo' note could be 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?
Despite no output schema, the description states it returns the configuration name. It covers behavior, parameters, side effects, and alternatives thoroughly. For a tool with 3 parameters, this is complete and leaves no obvious 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?
Schema has 0% parameter descriptions, but the description provides clear explanations for each parameter: name (unique, idempotent), parent (optional for derived configs), description (optional). This adds significant meaning 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?
The description clearly states the tool creates a new configuration on the active part or assembly, explains what a configuration is (metadata sharing geometry but allowing variations), and distinguishes from the sibling build_variant_family which creates multiple configs in one call.
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 (v1 path for variants without duplicating files) and names an alternative tool (build_variant_family) for creating multiple variants. Also includes a gotcha about activation side effect, guiding the agent on proper 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?
Despite no annotations, the description fully discloses behavior: creation operation, modes available, limitations of single-reference mode (face/edge names not supported), and world-axis mapping. 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 well-structured with bullet points, a table, and a code example. It is lengthy but every section adds value; no redundancy. Minor deduction for length but fully justified by 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 2 parameters, no output schema, and no annotations, the description is exceptionally complete: covers return value format, use cases, limitations, examples, and edge cases. 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?
With 0% schema description coverage, the description provides complete parameter semantics: explains reference_name and reference_2 inputs, naming rules (English/Spanish, custom planes), and default values. This fully compensates for the 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 the tool creates a reference axis from two planes or a single feature, with explicit verb 'Create' and resource 'reference axis'. It distinguishes this from related sibling tools like create_reference_plane by specifying the output and usage context.
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 the two-plane mode (recommended) vs single-reference mode (limited), gives detailed mapping of plane pairs to world axes, and includes an example with a specific use case for circular patterns. No ambiguity about 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 provided, so description carries full burden. Discloses two methods for specifying face (selector vs face_centroid_mm), return structure with sketch_axis_mapping, failure modes (centroid mismatch, hidden face), and behavioral nuance that extrude_sketch defaults to inward direction. No contradictions with any 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, comparison, args, returns, gotchas, failure modes, example), front-loaded with key info. Length is justified by tool complexity, though some repetition (e.g., gotchas restated) could be trimmed. Slightly verbose but 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 no output schema and low schema coverage, description covers all essential aspects: parameters, return values, failure modes, axis mapping, extrusion direction, and an example. Addresses real failure modes (LLM assumption about axes). Comprehensive for a complex geometry 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%, so description must compensate. It does so extensively: explains selector with closed schema and example, explains face_centroid_mm sourced from list_faces, notes mutual exclusivity, and describes return fields including sketch_axis_mapping schema. Adds meaning far beyond 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?
The description clearly states the tool creates a sketch anchored to a face on an existing body, and distinguishes it from create_sketch which only works on default planes. The verb 'start a new sketch on a face' is specific and the resource is clearly identified.
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-based sketch) vs alternative (create_sketch for default planes). Outlines workflow with other tools (create_circle, extrude_sketch) and includes common use cases (counterbore, hole pattern). Also gives gotchas about extrude direction and axis mapping, guiding correct 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?
Describes the all-or-nothing semantics with rollback on failure, suppressed redraw/rebuild, and verification options. Without annotations, this fully discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose due to bilingual text (Spanish and English), but it is well-structured with sections. Information is valuable and front-loaded with the core concept.
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, no annotations, and no output schema, the description covers all essential aspects: purpose, usage, parameters, return values for success and failure, and behavioral guarantees. It is fully informative for an 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, the description extensively documents all parameters: ops format (tool and args with examples), rebuild default, and verify options. This compensates fully for the schema's 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 that the tool executes an ordered list of low-level operations in one pass, using a 'compile once, build once' approach. It distinguishes from making separate calls and explicitly notes it is not for composite or perception/IO 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 (batch instead of individual calls) and what not to include (no nested batch calls, no composite tools). Also clarifies that human approval on this call is approval for the entire batch.
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 extrusion behavior, parameter effects (including reverse_direction gotcha for face sketches), merge behavior, return values, sketch closure, and failure recovery. 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?
The description is thorough and well-structured with sections (Args, Returns, Caveat, etc.) and front-loaded action. While somewhat lengthy, every sentence adds value with no redundancy. Could be slightly tighter.
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, 4 parameters, and no annotations, the description covers all critical aspects: parameters, return info, prerequisites, error handling, multiple examples, and sibling tool relationships. Nothing 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?
Schema has 0% description coverage; the description fully compensates. Each parameter (depth_mm, end_condition, reverse_direction, merge) is explained with constraints, defaults, and behavioral effects. 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 exits the active sketch and extrudes it as a boss feature. It uses a specific verb (extrude) and resource (active sketch). It distinguishes from siblings like build_flange_boss and revolve_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?
Explicitly provides when to use vs alternatives: mentions build_flange_boss for combined sketch-extrude, advises against using extrudes for revolve/sweep features, and notes loft is not available. Also covers failure recovery and 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?
In absence of annotations, description fully discloses requirements (Toolbox add-in), limitations (single hole, clearance not supported), and unexpected behaviors (end-face guard, auto-undo on depth consumption). 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 Args, Returns, Caveats, and Examples sections. Slightly verbose but each sentence adds value. Could be tightened, but clarity benefits from thoroughness.
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, describes return dict. Includes caveats with workarounds and examples. Covers all necessary context for a complex tool, making it 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?
Schema has 0% description coverage; description compensates by explaining each parameter: hole_type values, size ranges per type, face_centroid_mm usage from list_faces, end_condition options, depth_mm requirement, and thread_class default. Adds meaning well 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?
Clearly states the tool drills one standard ISO Metric hole on a face, specifying tapped or counterbore types. Distinguishes from siblings like add_bolt_circle and extrude_cut by explicitly mentioning alternatives for clearance holes.
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 (single hole, standard ISO fasteners) and when-not-to-use (clearance not supported, multi-hole patterns). References alternatives like add_bolt_circle and extrude_cut for unsupported cases.
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: the first component is auto-fixed, subsequent components need mates, and an assembly with floating components is considered wrong even if it looks correct. It also mentions that the tool returns instance metadata.
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 bold warning, bullet-like arg list, return info, and related tools. It is slightly lengthy but every sentence adds value. Minor redundancy could be trimmed, but it remains 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 complexity of CAD assembly insertion, the description is very complete. It covers the workflow, prerequisites (need for mates), common pitfalls, references a design guide, and specifies the return type. No output schema is present, but the description mentions returning 'instance metadata', which is 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% coverage (no parameter descriptions), but the tool description provides clear explanations for each parameter: file_path (absolute path), x/y/z_mm (insertion point in mm), and config_name (specific configuration or empty string for active config). 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 'Insert a part or sub-assembly into the active assembly at the given XYZ.' It specifies the verb 'insert' and the resource, and distinguishes itself from siblings like 'place_and_mate' and 'stack_components' by noting that it does not complete the assembly on its own.
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 'insert_component alone does NOT finish the job' and provides guidance on when to use it (only as part of a larger process) and when not (if mating entities cannot be identified, use get_active_assembly_info or ask the user). It also lists alternative tools like 'stack_components' and 'add_mate_by_face_position'.
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: returns a JSON object with tool_count and alphabetical tool names. It also clarifies that full descriptions are not included, preventing false expectations. This is complete transparency for a listing 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?
The description is very concise with bilingual text, front-loaded with the main purpose. Every sentence adds value: purpose, distinction from alternatives, and return format. 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?
Despite no output schema, the description specifies the exact return format and contents. For a zero-parameter tool with a simple inventory list, this is fully complete and sufficient for an AI agent to understand and use 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?
No parameters exist, so the description does not need to add parameter semantics. Baseline 4 is appropriate as there are no gaps to fill.
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 lists authoritative tool names. It specifies 'solo nombres' and 'names only', distinguishing it from tools/list which provides full descriptions. This directly addresses the purpose of inventory listing.
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 using this tool to confirm the live surface or exact tool name without the overhead of full docstrings from tools/list. It provides clear context for when to use this tool versus the 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, description fully discloses behavior: it runs mutating steps in one batch, verifies once at end, acts as human-in-the-loop approval. Guard conditions (low confidence, unmodeled internal, unresolved dimensions) are explained, as is the return of verify_build_report and final render.
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?
Dense with information and well-structured with workflow and conditions. However, the English translation duplicates the Spanish content; removing the translation would make it more concise without loss. Still, every sentence adds value and the structure is logical.
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 purpose, workflow, guard conditions, parameter semantics, and return value (verify_build_report + render). Despite no output schema, the description provides sufficient context 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?
Despite 0% schema description coverage, the description explains all three parameters: feature_plan_id (implicitly from compilation), override_low_confidence (for forcing partial plans), and override_unmodeled_internal (for missing internal features). States independence of the two boolean overrides.
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 builds a compiled FeaturePlan in one pass. It distinguishes from sibling compile_feature_plan_from_drawing_spec by being the execution/approval step. The workflow steps explicitly position this tool as the final build step.
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 recommended 4-step workflow with clear context for when to use this tool. Explicitly states when not to use: plans with partial_or_handback or unmodeled internal features require overrides. Unresolved dimensions are blocked entirely.
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 thoroughly discloses behavioral traits: it sets the filename, subsequent save_active_document will write to the same path, it describes the return dict, and it warns that passing wrong extension causes failure. It also mentions caveats about directory existence and special folders.
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 (Spanish/English, args, returns, common use, caveats, example) and is front-loaded with the key distinction. It could be slightly more concise, but it is efficiently organized and 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 the tool complexity and lack of output schema, the description is complete: it explains the return dict shape, error behavior, and caveats. It covers all necessary information 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 only parameter 'path' has no schema description (0% coverage), but the description adds significant meaning: absolute file path including extension, lists valid extensions with their document types, and warns about wrong extension causing failure. 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 it saves the active document to an explicit path (Save As), and explicitly differentiates it from the sibling save_active_document by noting that save_as works for fresh documents without a filename, while save_active_document only works for already-named docs. This is a specific verb and resource, distinguishing it from siblings.
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 this tool (for fresh, never-saved documents) versus when to use the sibling (already saved documents). It also gives a common use case (scripted runs) and caveats (parent directory must exist, special folder handling). This is comprehensive.
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: search+judge, no geometry download (v1 deep-link), returns ranked candidates with deep-links, recommendation logic based on needs_edit, and data handling constraints (only abstract text leaves host).
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?
Front-loaded with summary and well-structured with headers (Args, Returns, constraints), but somewhat redundant due to Spanish/English duplication. Still concise enough given 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?
Provides full output structure, workflow with other tools, constraints, fallback logic, and covers all aspects for a search+judge tool with no 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?
Schema has 0% description coverage, but description explains each parameter in detail: spec (type, standard, size, material, nominal, query, warning), resources (allowed values, default all), top_n (max candidates, default 3), needs_edit (boolean driving recommendation). 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 it searches for standard parts in open catalogs (3D ContentCentral, McMaster-Carr, TraceParts) and judges fit, with specific examples like tornillo, tuerca. It distinguishes from query_part_library by explicitly mentioning reuse-first logic.
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 designer needs a standard part not found locally, and to first check query_part_library. Provides alternative tool and context about abstracted text only.
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 discloses that all bound dimensions rebuild automatically when a variable is updated. It also mentions the error case for non-existent variables. With no annotations, this fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, but it includes both Spanish and English text for the same information, which adds slight redundancy. The key information is 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?
For a tool with 3 parameters, no output schema, and no annotations, the description fully captures purpose, usage, parameters, behavior, and error conditions. It leaves no critical 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?
Although the input schema has no descriptions (0% coverage), the description explains each parameter in detail: `name` must exist, `new_value` is numeric with units, and `units` is optional with specific allowed values and preservation behavior.
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 modifies an existing global variable, distinguishing it from `add_global_variable`. The verb 'modificar' and resource 'variable global existente' make the purpose 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?
It provides a typical usage example (CSWA workflow) and explicitly warns that the variable must exist, guiding the agent to call `add_global_variable` first. This tells when to use and when not to.
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?
Without annotations, description fully discloses internal steps, the critical reverse_direction flag, axis assumption, resolution of end position, and return fields including warnings. 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?
Well-structured with overview, workflow, critical note, parameter list, returns, and caveat. Every sentence adds value; front-loaded with purpose. 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?
Given no output schema and no annotations, description covers input, output, side effects, constraints, and verification fields. Complete for a tool with 6 parameters and internal steps.
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 adds complete semantic meaning for all 6 parameters: defaults, constraints, standard DIN width table, and specific usage notes for each.
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 specific verb (add) and resource (axial keyway cut into shaft end), includes junior workflow example, and distinguishes from siblings like extrude_cut and build_stepped_shaft. No ambiguity.
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: after building a shaft with build_stepped_shaft, and provides a caveat for arbitrary orientation suggesting alternative primitive chain. Includes critical parameter 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?
Describes that rectangle is added to most recent sketch, returns geometric properties, and crucially warns that rectangle is not parametric (modify_dimension cannot resize; only extrude depth is parametric). No annotations provided, so description fully bears 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 args, example, caveat, and related tool. Front-loaded purpose. No filler; 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?
Covers purpose, parameters, example, behavioral caveats (non-parametric), prerequisites, and sibling alternative. No output schema needed since return value is simple geometric properties. Complete for safe agent 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?
Explains param meaning: 'One corner of the rectangle in mm' and 'The opposite corner.' Provides example (0,0,50,30) to clarify usage. Input schema has 0% description coverage, so description compensates fully.
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 'Draw a corner-defined rectangle on the active sketch.' Distinguishes from sibling build_rectangular_pocket by noting it is sketch-only vs sketch+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 requires an active sketch ('create_sketch first'). Provides alternative build_rectangular_pocket for rectangular pockets, guiding when to use this primitive vs a 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?
No annotations provided, so description fully covers behavior: signed offset with positive/negative directions, zero rejected, return value (plane name, parent reference, signed offset), and even mentions tested offset limits from live verification (2026-06). This gives the agent a clear understanding of effects.
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 headings, bullet points, and code examples. Each sentence provides essential information without redundancy. Front-loaded with core purpose, then details. Efficient use of space.
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 3 params and no output schema, the description is comprehensive: covers both modes, parameter details, return value, examples, caveats, and use cases. No gaps remaining 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?
Schema coverage is 0%, but description adds rich semantics: explains `offset_from` default plane names in English and Spanish, `offset_mm` as signed distance with zero rejection and practical limits, and `face_centroid_mm` as array from list_faces(). Code examples further clarify usage. 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?
Clearly states it creates a reference plane parallel to a default plane or a face, with two distinct modes described. The verb 'Create' and resource 'reference plane' are specific. No sibling tool duplicates this purpose, so the description effectively distinguishes it.
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 instructs to pass exactly one of `offset_from` or `face_centroid_mm`, and describes when to use each mode: 'Default-plane mode' for rib offsets, 'Face mode' for counterbore-on-flange-top. Also includes a caveat about deferred angled/through-3-points planes, indicating 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it sets position/rotation, triggers a rebuild, and returns whether the movement held. It explains the significance of 'moved=False' (component fixed or mate-driven).
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 one-line summary, a detailed explanation of use case, and a clear 'Args' section. Every sentence is informative and there is 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 no output schema, the description fully explains return values (requested vs post-rebuild pose, plus 'moved' flag). It also covers the rebuild side effect and constraints (fixed/mate-driven components). 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?
Despite 0% schema description coverage, the description explains all parameters: 'component_name' from get_active_assembly_info, 'origin_mm' as [x,y,z] in mm, and 'rotation_rows' as optional 9-element row-major rotation matrix. This adds critical meaning beyond the schema's basic 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?
The description clearly states the tool's purpose: 'set a component's pose (drag-equivalent)' by positioning and optionally rotating a component. It distinguishes from sibling tools like 'place_and_mate' by explaining its 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The explicit guidance to use this tool for staging a component at exact pose before creating mates, and warning about the alternative 'place_and_mate' for combined posing and mating, provides clear usage context. Also informs about interpretation of the 'moved' return value.
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:

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

Score Badge

Copy to your README.md:

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

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/solidworks-mcp'

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