lambdacad-mcp
Server Quality Checklist
Latest release: v1.3.0
- Disambiguation4/5
Almost every tool has a clearly distinct purpose, and descriptions often explicitly contrast related tools (e.g., rotate_3d vs rotate_entity, hatch_circle vs hatch_islands). With 128 tools there are some potentially confusable pairs like get_entity_counts vs drawing_info, but the detailed explanations resolve most ambiguity.
Naming Consistency4/5The naming is largely consistent, with clear families such as draw_*, solid_*, bool_*, list_*, get_*, set_*, and assembly_*. Minor deviations like 'regen', 'leader', 'polygon', and the mixed bool/boolean (bool_union vs boolean_verified) prevent a perfect score.
Tool Count1/5With 128 tools, this is an extreme outlier for an MCP server. Even for a broad CAD domain, the surface is overwhelming and far exceeds the 3-15 tool guideline, making tool selection costly and impractical for agents.
Completeness5/5The toolset covers virtually every CAD operation: 2D drafting, 3D solids, editing, dimensions, layers, blocks, viewports, sheets, exports, rendering, analysis (interference, holes, overhang), assembly management, graph analysis, and a memory system. There are no obvious dead ends, and run_command/run_lisp fill any hypothetical gaps.
Average 3.7/5 across 128 of 128 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 44 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses that positions are computed server-side and that it's a single call, but it does not state what geometric entities are actually created (e.g., circles for holes, PCD circle, center marks) or any side effects. Given parameters like 'pcd_circle' and 'marks', these behaviors are likely but undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but for a tool with 9 parameters and no other documentation, it is under-specified rather than appropriately concise. The phrase 'positions computed server-side; one call' is useful but does not compensate for the lack of essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 5 required, no annotations) and that an output schema exists, the description is wholly inadequate. It does not explain the function's full behavior, parameter meaning, prerequisites, or return values. The agent cannot correctly select and invoke this tool based on the provided description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'pcd' as pitch-circle diameter and 'N' as the count, but it does not explain cx, cy, hole_dia, start_angle, layer, marks, or pcd_circle. The description adds minimal meaning beyond the parameter names, leaving most parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool creates holes arranged on a pitch-circle diameter (PCD), which distinguishes it from ordinary circle or point drawing tools. It doesn't use an explicit verb like 'creates' or 'draws', but 'N holes on a pitch-circle diameter' makes the purpose evident and distinct from siblings like draw_circle or array_polar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one call' hints at efficiency for creating multiple holes in a single operation, but there is no explicit guidance on when to use this tool versus alternatives (e.g., draw_circle repeatedly or array_polar). No exclusions or alternative tool names are mentioned.
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 the full burden of disclosing behavioral traits. It does not indicate whether the operation modifies the original solids, is destructive, or how it handles overlapping regions. This is a significant gap for a 3D boolean operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is extremely concise and front-loaded. It avoids unnecessary words and gets to the point. However, it may be too minimal, sacrificing valuable details for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3D boolean operation with no annotations and no parameter explanations, this description is wholly inadequate. It does not mention prerequisites (e.g., solids must be intersecting), what the handles refer to, or the nature of the result. The presence of an output schema does not compensate for the lack of operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention the 'handles' parameter at all, leaving the agent to guess that 'handles' refers to entity handles of the solids to be unioned. This is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (union) and the resource (3D solids). It is specific enough to understand the tool's purpose, but it does not distinguish it from sibling tools like bool_subtract or bool_intersect, which also operate on 3D solids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description simply states what it does without indicating prerequisites, selection requirements, or cases where bool_subtract or bool_intersect would be more appropriate.
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 the full burden of behavioral disclosure. It only mentions drawing at (x,y), omitting any details about layer behavior, units, coordinate system, or whether it creates a persistent entity. This is minimal and lacks transparency for a drawing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no wasted words. However, it is under-specified, lacking necessary context about parameters and behavior. It earns a middle score because it is concise but incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple drawing tool with a small schema, the description still fails to address key context like the layer parameter, output/return behavior, or coordinate system. The sibling tools provide some context, but the description itself is too sparse to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions x and y, ignoring the layer parameter entirely, and does not explain coordinate units, origin, or default behavior. The description adds almost no semantic value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Point at (x,y).' clearly indicates the tool creates a point at specified coordinates. It uses a specific verb and resource, distinguishing it from sibling drawing tools like draw_line or draw_circle, though it could be more explicit about drawing a point entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, with no context about coordinate systems, layers, or prerequisites, and no mention of when a point is preferred over other primitives.
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 the full burden, but it only discloses that the result is a 'single polyline,' which is a useful behavioral detail. It does not mention coordinate semantics, layer handling, or whether the shape is closed, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that gets to the point. The parenthetical 'raccordato' is redundant but not harmful, making the description slightly less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no schema descriptions, and no annotations, the description is severely incomplete. It provides no context about how to use the tool, what the coordinates represent, or how the radius behaves, making it nearly impossible 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.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the six parameters (x1, y1, x2, y2, radius, layer). With 0% schema coverage, the parameters are entirely undocumented in both schema and description, so the description fails to add any parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating a rectangle with rounded corners, which distinguishes it from plain rectangle or polyline siblings. However, it lacks an explicit verb like 'draw' or 'create,' instead relying on a noun phrase, so it is not fully explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as draw_rectangle, draw_polyline, or slot. The description merely states what it is, leaving usage entirely implicit.
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 the full burden of behavioral disclosure. It hints at a read-only query operation but does not explain error behavior for non-solid entities, invalid handles, or whether any modifications occur. The minimal phrase adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with zero filler, which is positive, but it is too sparse to be considered well-structured. A single noun phrase does not convey the action or context effectively, though it is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, some detail can be omitted. However, the complete lack of parameter explanation and behavioral context, combined with no annotations, makes the description insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'handle' parameter, and the description does not mention or explain it. The agent is left without any semantic clue about what 'handle' refers to, making the parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes volume and centroid of a 3D solid, which distinguishes it from sibling creation tools like solid_box or solid_sphere. However, it lacks a verb (e.g., 'Compute') and is phrased as a noun phrase, making it slightly less explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., requiring a solid entity, handle validity) or exclusions, leaving the agent to infer usage from the tool name alone.
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 must disclose behavioral details. It explains that the tool removes part of an entity, indicating a mutating operation, but omits specifics such as how the pick point determines which side to trim, what happens if there is no intersection, or whether the cutting entity is affected. This partial disclosure is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise and front-loaded with the main action. It avoids redundant wording, but its brevity contributes to the lack of parameter and usage details, so it does not achieve a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and the presence of many sibling editing tools, the description is incomplete. It lacks parameter explanations, usage scenarios, and edge-case behavior. The output schema exists but does not compensate for the missing parameter semantics and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain the parameters. It says 'cut by the cutting entity' but never maps that to 'cutting_handle', nor does it describe 'pick_x' and 'pick_y'. An agent cannot infer which parameter serves which role from the text alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: removing a portion of an entity at a pick point, with the cutting entity defining the cut. This distinguishes it from broader drawing tools, though it does not explicitly differentiate it from similar editing tools like break_entity or extend_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., the cutting entity must intersect the target) or scenarios where this tool is preferred. The description implies a general trimming operation but lacks explicit usage context.
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 the full burden. It does not disclose side effects (modifying or destroying original solids), behavior with multiple handles, or what happens when solids do not overlap. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no fluff. It is front-loaded and avoids unnecessary words, but could be slightly expanded for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description still leaves critical gaps: unknown parameter semantics, no output description (though an output schema exists), and no warnings about side effects. It is minimally viable but falls short for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The only parameter 'handles' is vague; the description does not clarify that handles are entity IDs or how they should be provided. There is no compensation for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Keep only the intersection of 3D solids.' This is a specific verb+resource directive and inherently distinguishes it from sibling boolean tools like bool_union and bool_subtract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (union, subtract, slice). It does not mention prerequisites, selection rules, or scenarios where intersection is appropriate.
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 the full burden of behavioral disclosure. It only states the action and coordinates, but does not mention side effects like adding an entity to the current drawing, layer behavior, or return values, which are important for a drawing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the core action and location, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and an output schema exists, the description leaves gaps in parameter semantics and behavioral expectations. The defaults for size and layer are visible in the schema, but their purpose is not explained, and no usage context is provided relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains x and y. The size and layer parameters are left entirely unexplained, and the description does not compensate for the lack of schema-level documentation for those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a center-mark cross at a given (x,y) coordinate, which is a specific resource and action. It distinguishes itself from sibling drawing tools by naming a unique annotation type, though it lacks an explicit verb like 'draw'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use center_mark versus similar tools such as draw_point or bolt_circle. The description only states what the tool does, leaving the agent to infer usage context without explicit alternatives or 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?
With no annotations, the description must disclose behavioral details, but it only states that it returns intersection points. It does not explain whether this is a read-only operation, behavior for non-intersecting entities, or the return format, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with three short phrases. The final phrase 'The anti-collision check' adds some context but is slightly redundant, though overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and a sparse schema, so the description needs to clarify handle semantics, return values, and edge cases. It fails to do so, making the tool under-specified despite an output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain handle1 and handle2. It refers to 'two entities' but fails to map them to the parameters or clarify what a handle is, providing no help to the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks for intersection/overlap between two entities and returns intersection points, using a specific verb and resource. This differentiates it from siblings like bool_intersect, which performs a boolean operation rather than a query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a vague hint that this is an anti-collision check, but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or related 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 the full burden. It discloses the special 'selection' value for handles, but does not mention whether the original entities are copied or moved, how rows/cols spacings are measured, or behavior on invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the tool's main purpose. There is no fluff; every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity and no annotations, the description is minimal. It does not explain key behavioral aspects like whether arraying preserves layers, how selection is captured, or error scenarios. The output schema exists but does not cover behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to handles by explaining the 'selection' special value, and the concept of rows x cols with spacings maps to related parameters. However, with 0% schema coverage, it does not fully explain units, ordering, or exact semantics for row_spacing and col_spacing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a rectangular array of entities with rows, columns, and spacings. It distinguishes itself from the sibling array_polar by specifying 'rectangular', though it lacks an explicit verb like 'creates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like array_polar. It only hints at using the GUI selection via handles=['selection'], but does not explain typical use cases, prerequisites, or 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?
With no annotations, the description must disclose behavioral traits. It only lists the geometric inputs needed, but says nothing about what happens when the tool is invoked (e.g., whether it creates a dimension entity, modifies the drawing, or requires an active drawing). This is a significant gap for a tool that likely has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core concept. Every word earns its place, but it is almost too terse given the complexity of the tool. Structure is clean and no unnecessary detail is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no annotations, and a description that covers only the input roles. It omits important context such as the resulting entity type, units, orientation, or any preconditions. With low schema coverage and no safety hints, the description is inadequate for fully understanding the tool's behavior and return value, though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description groups the eight schema parameters into meaningful roles: 'vertex', 'a point on each side', and 'dimension arc position.' This adds semantic context beyond bare parameter names like x1, y1. However, it does not precisely map each parameter (e.g., which point corresponds to x1,y1 vs x2,y2), and with 0% schema coverage, it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating an angular dimension, defined by vertex, points on each side, and arc position. It distinguishes from other dimension tools by specifying 'angular dimension' and the geometric components, though it could be more explicit about the action (creating a dimension). The verb is implied rather than stated directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like dim_linear or dim_aligned, nor does it mention required drawing state or prerequisites. Users are left to infer the tool's role from the name and terse definition.
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 the full burden. It discloses that angles are in degrees and counterclockwise, which is helpful. However, it omits critical behavioral details such as the angle reference (e.g., positive x-axis), the direction from start to end, and what happens if start equals end. The description is too sparse for a drawing primitive where orientation and semantics matter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded with 'Arc', wasting no words. It is a single phrase that quickly conveys the essential concept. However, the extreme brevity likely contributes to the lack of behavioral clarity, so it is concise but not overly so.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 0% schema description coverage, and no annotations, this description is insufficient. It does not explain the angle reference, coordinate system, layer defaults, or return value. A tool like this needs more context to be used correctly, especially for users unfamiliar with CAD conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to schema parameters by stating 'center, radius, start/end angles in degrees (CCW)', which clarifies that cx/cy are the center, radius is the radius, and angles are in degrees. However, it does not mention the 'layer' parameter at all, and it does not clarify the coordinate system or units for radius. Since schema coverage is 0%, the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating an arc and specifies its defining parameters (center, radius, start/end angles). It distinguishes from siblings like draw_circle or draw_ellipse by mentioning angles. However, it lacks an explicit verb, relying on the tool name 'draw_arc' to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as draw_circle or draw_ellipse. There is no mention of specific use cases, prerequisites, or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the geometric parameters. It does not reveal whether a new entity is created, how the layer parameter is applied, what happens with invalid inputs (e.g., negative radius), or what the operation returns. This is minimal behavioral context for a drawing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at seven words, front-loaded with 'Circle,' and contains no filler. It is efficient, though perhaps overly terse, sacrificing completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (though not provided) and 4 parameters, the description is incomplete. It does not explain the layer parameter, coordinate system, units, or return behavior, and it does not reference sibling tools for differentiation. For a simple tool this might suffice, but the missing parameter context and lack of behavioral detail create gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by interpreting 'cx, cy' as center coordinates and 'radius' as the circle's radius, which partially compensates for the 0% schema description coverage. However, it omits the 'layer' parameter entirely, which has a default but no explanation of its purpose or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Circle at (cx,cy) with radius,' which clearly indicates a circle-drawing operation with center coordinates and radius. Though it lacks an explicit verb, the tool name 'draw_circle' makes the action obvious, and it distinguishes from siblings like draw_ellipse and draw_arc by specifying center/radius.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as draw_donut, bolt_circle, or draw_ellipse. It does not mention any specific use cases, prerequisites, or exclusions, leaving the agent to infer applicability.
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 must disclose behavioral traits. It only clarifies rotation units but does not mention that the tool creates a new text entity, how it interacts with the current layer, or any side effects. This is insufficient for an agent to understand the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, efficiently conveying the core operation and the rotation unit. However, it is so sparse that it omits valuable context, but for conciseness it is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks sufficient context for an agent to correctly select and invoke the tool. It does not explain parameters like height and layer, nor does it provide usage guidance relative to draw_mtext, making it incomplete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only clarifies x,y and rotation units. It does not explain the meaning of 'text', 'layer', or 'height' parameters, leaving the agent to infer their semantics. This partially compensates for the lack of schema descriptions but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating single-line text at a specific (x,y) coordinate, and specifies that rotation is in degrees. The term 'single-line' distinguishes it from draw_mtext among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as draw_mtext for multi-line text. The description provides only the basic definition without any contextual usage advice or 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?
The description provides only surface-level behavior (extend to boundary) without disclosing edge cases, such as what happens if no intersection exists, supported entity types, selection rules, or side effects. With no annotations, the description carries the full transparency burden but omits these essential details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words, and it front-loads the verb 'Extend'. However, its brevity makes it slightly cryptic, and a more structured layout (e.g., separate action, target, and boundary) could improve clarity without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has three required parameters and no parameter descriptions or annotations. The one-sentence description is insufficient for a CAD editing operation, as it does not explain selection mechanics, boundary requirements, return values, or failure modes, leaving significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description hints at 'boundary entity' and 'picked near the end', which loosely map to boundary_handle and pick_x/pick_y, but it does not explicitly define the parameters, coordinate system, or the exact meaning of boundary_handle. Since schema description coverage is 0%, the description only partially compensates for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: extending an entity to a boundary. It identifies the action ('Extend'), the target ('entity picked near the end'), and the termination point ('boundary entity'), making it distinct from sibling operations like trim_entity or offset_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any exclusions or prerequisites. It does not mention that it is specifically for lengthening entities to a boundary or that the pick point must be near an end, leaving the user to infer usage from the action name.
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 responsibility for behavioral disclosure. It only states the output format (raw DXF) but does not mention whether the tool is read-only, error behavior for invalid handles, or any side effects. The description adds minimal value beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase with no redundant information. It is highly concise and easy to parse, achieving maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description is too sparse to be fully contextual. It lacks any usage context, prerequisites, or confirmation of behavior. For a simple get tool, one might expect at least a note about handle uniqueness or return format, but the description remains minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does mention 'by handle,' connecting the sole parameter to the entity lookup, but it does not elaborate on the handle's format or usage. This provides some semantic value over the bare schema, but not enough for a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'raw DXF data of an entity by handle,' which identifies the resource and scope. Although it lacks an explicit verb, the tool name 'get_entity' implies retrieval, and the phrasing distinguishes it from sibling tools like entity_points or entity_length.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With numerous sibling query tools, the description fails to clarify when raw DXF data is needed or why one would choose this over entity_points or get_extents.
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 the full burden of behavioral disclosure. It states the tool creates a 'real HATCH entity', which is a useful detail, but it does not disclose side effects, whether the polygon is modified, error conditions for non-closed polygons, or how layers/scale/angle are applied. This is a mutation tool with minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words, making it easy to parse. However, it is under-specified, which detracts from structure since it front-loads only the core action without supporting context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and 5 parameters, the description lacks completeness. It does not address safety, error handling, or interaction with existing geometry. For a CAD tool that creates entities, more context is needed to avoid misuse, especially with zero annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions pattern names (ANSI31, SOLID), adding minimal insight into the 'pattern' parameter. It does not explain 'points', 'angle', 'scale', or 'layer' beyond raw schema definitions, leaving semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fill a closed polygon with a real HATCH entity (pattern ANSI31, SOLID, ...).' It uses a specific verb ('Fill') and resource ('closed polygon'), and mentions example patterns, which distinguishes it from sibling tools like hatch_circle or hatch_islands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites beyond 'closed polygon', or direct siblings. Users must infer usage from the tool name and schema, which is insufficient.
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 the full burden of behavioral disclosure, but it only states the geometric definition. It does not reveal that this is a creation operation, that it will add the sphere to the current drawing, or any coordinate system or unit assumptions. The behavior is largely implied and under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-structured sentence that front-loads the core concept and lists parameters in a clear notation (cx, cy, z, radius). No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3D solid creation tool with no annotations and many siblings, the description is too sparse. It doesn't explain how the sphere is placed, what the output is, or how it relates to other operations. The output schema exists but isn't visible here; still, the description should at least state that it creates a solid object in the active drawing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly names all four schema parameters and adds meaning by grouping cx, cy, z as the center and radius as the sphere's radius. However, it doesn't clarify units, coordinate plane, or optionality beyond what the schema already provides (e.g., z defaults to 0 in schema). Given 0% schema description coverage, the description partially compensates but leaves some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a 3D solid sphere and lists its defining parameters (center coordinates and radius). While it lacks a verb like 'creates' or 'draws', the meaning is unambiguous. It doesn't explicitly distinguish from sibling solid primitives like solid_torus or solid_box, but the sphere concept is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling solid creation tools (solid_box, solid_cylinder, solid_cone, etc.). There is no mention of context, prerequisites, or alternatives, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only lists parameters and does not state that the tool creates/adds an entity, how it interacts with the drawing, or any side effects. This is a significant gap for a construction 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the essential geometric parameters in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and 0% schema parameter descriptions, the description is underspecified. It does not explain the expected behavior (creating a solid), how the center coordinates are interpreted, or any constraints. An output schema exists, but the description still fails to provide sufficient context for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description maps parameters to geometric concepts: 'center (cx,cy,z)', 'ring radius', and 'tube radius'. This clarifies that 'radius' refers to the ring radius and 'tube_radius' to the tube thickness, adding meaning beyond the raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as creating a '3D solid torus' and lists its defining parameters (center, ring radius, tube radius). This clearly distinguishes it from sibling solid primitives like solid_box and solid_cylinder, though it lacks an explicit verb such as 'create' or 'draw'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other solid primitives. The description merely states the shape and parameters, leaving the agent to infer usage from the tool name. There are no alternatives mentioned or 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 responsibility. It only states that the dimension is placed on a circle/arc by handle, but does not disclose the effect of the angle and offset parameters, what happens on invalid handles, or the nature of the created dimension entity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose without extraneous details. It is concise and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description is too sparse for a tool with three parameters and no annotations. An agent cannot infer the meaning of angle and offset, nor the tool's behavior in edge cases, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'handle' parameter as the means of selecting the circle/arc, but leaves 'angle' and 'offset' completely unexplained, which is a significant gap given their defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool creates a diameter dimension on a circle or arc selected by handle. The resource and method are specific, and it distinguishes from sibling tools like dim_radius and dim_linear, though it lacks an explicit verb like 'create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for diameter dimensions on circles/arcs, but does not explicitly state when to use this tool versus alternatives such as dim_radius or dim_aligned. No exclusions or prerequisites are mentioned.
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 the full burden of behavioral disclosure. It merely states the action 'Regenerate the view' without revealing whether the operation is destructive, requires permissions, affects the drawing database, or what side effects occur. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence with no fluff. It earns its place by stating the core action, though it may be too sparse to provide sufficient context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is very brief. It does not explain what 'regenerate' means in the CAD context, what the output represents, or when this tool is appropriate compared to other view-related tools. This leaves significant gaps for an agent to safely invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the empty schema already fully documents that no arguments are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Regenerate') and resource ('the view'), clearly stating what the tool does. However, it does not differentiate from sibling view-related tools such as render_view or zoom_extents, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention typical scenarios, prerequisites, or why regeneration might be needed, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only explains the closed parameter and does not mention layer handling, coordinate expectations, side effects, or return values. This lack of detail could leave an agent uncertain about the tool's behavior beyond the basic polygon creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, conveying the essential behavior in a single compact phrase. Every word adds value, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple drawing tool, the description covers the core points and closed behavior, but lacks context about layer usage, coordinate system, and relationship to other drawing commands. Since an output schema exists, return values are not needed, but overall completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the points format as [[x,y],...] and the meaning of closed=true, adding value beyond the bare schema. However, the layer parameter is not mentioned, leaving one of three parameters undocumented despite 0% schema coverage. This is a partial but incomplete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating a polyline through a list of [x,y] points, and mentions the closed option. It is distinguishable from sibling drawing tools like draw_line or draw_circle, though it lacks an explicit verb. The tool name 'draw_polyline' reinforces the intended action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as draw_line or draw_spline. There are no use cases, prerequisites, or exclusions mentioned. The 'closed=true' hint is a parameter detail, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It fails to state that exploding is likely destructive (replaces the original with components) or mention any side effects, limitations, or prerequisites for the input entity. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the action and target. It is concise, front-loaded, and contains no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description omits crucial information about the operation's effect on the original entity, error conditions, or compatibility with nested objects. For a destructive command, the missing contextual details make the description incomplete for an agent to invoke safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'handle' as a string with no additional description, and the tool description does not mention the parameter at all. With 0% schema description coverage, the description must compensate, but it provides zero semantic information about what 'handle' is or where to get it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Explode' and clearly identifies the resource types (block/polyline/dimension) plus the outcome ('into its components'). This distinguishes it from sibling tools like break_entity or trim_entity, making the tool's purpose very 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for the listed entity types, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare against alternative decomposition methods. The context is somewhat clear but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the key side effect of creating both the circle boundary and the hatch, but it omits other behavioral details such as reliance on the current layer, use of default pattern/scale/angle, or any destructive implications. This is insufficient for a mutation tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the core purpose and the important boundary-creation side effect in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no annotations, and despite having an output schema, the description does not explain the parameter semantics or differentiate from closely related sibling tools (draw_circle, hatch_polygon). The one-line description leaves significant gaps for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explicit parameter explanations. cx, cy, and radius can be inferred from 'circular area', but angle, layer, scale, and pattern are not described, and schema description coverage is 0%. The description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and object: 'Hatch a circular area', and the parenthetical 'creates the circle boundary + HATCH' clearly distinguishes it from merely drawing a circle (draw_circle) and from hatching an existing polygon (hatch_polygon).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools like draw_circle and hatch_polygon are not mentioned, and the description does not state prerequisites, exclusions, or scenarios where this tool is preferred.
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 the full burden of behavioral disclosure. It only clarifies that rotation is in degrees, but omits details such as units for x/y, scale behavior, what happens if the block name does not exist, or whether the operation modifies the current drawing as expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It contains no fluff or redundancy, every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the five-parameter schema, no annotations, and the presence of an output schema, the description is too brief. It lacks usage guidance, behavioral details, and full parameter descriptions, making it inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does clarify that x,y are coordinates and rotation is in degrees, but it does not mention the scale parameter at all. For five parameters, this leaves a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('insert') and resource ('a block (or .dwg file)') with specific placement at (x,y) and rotation in degrees. It distinguishes itself from sibling tools like create_block or list_blocks by focusing on placement rather than definition or querying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It fails to distinguish between inserting an existing block and creating a new block definition, 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.
- Behavior2/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 disclosing behavior. It specifies the cylinder's orientation (height along Z) and base center, but does not mention side effects such as adding an entity to the drawing, return values, or constraints like positive radius.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: '3D solid cylinder: base center (cx,cy,z), radius, height along Z.' Every word adds value, efficiently conveying the essential geometry without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core geometry parameters sufficiently for a simple primitive, and an output schema exists (though not shown). However, it omits drawing-level context such as whether the cylinder is inserted into the current drawing or how it interacts with current layers/settings, leaving some gaps for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by clarifying that (cx, cy, z) is the base center and height is along Z, but it does not explain defaults, units, or constraints for individual parameters, leaving the schema's bare number types only partially enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a 3D solid cylinder with parameters for base center, radius, and height. It identifies the specific resource (cylinder) and distinguishes from sibling solid primitives, though it lacks an explicit verb like 'create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like solid_box or solid_cone. There is no mention of prerequisites or exclusions, leaving the agent to infer usage purely from the name.
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 is the sole source of behavioral information. It only says 'Zoom to a rectangular window' without disclosing side effects, coordinate system, or that it is a view-only operation. The tool name implies view manipulation, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loaded, saying exactly what the tool does without wasted words. While it lacks detail, the brevity is appropriate for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema being present, the description is minimal. It does not explain the relationship to the drawing view, whether the zoom is persistent, or how the rectangular window is interpreted. For a 4-parameter tool, this feels incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists four coordinate parameters with no descriptions, and the description does not clarify how x1,y1,x2,y2 map to the rectangular window (e.g., opposite corners) or the coordinate system. The parameter names are only marginally self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Zoom) and the resource (rectangular window), and the four coordinate parameters directly support this. It also distinguishes from the sibling zoom_extents by specifying a rectangular window, though it doesn't explicitly mention the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as zoom_extents. The description gives no context for choosing a window zoom over other view operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that ALL corners are rounded and that CAD computes the result, but it does not state whether the original polyline is modified in place, whether the polyline must be closed, or what happens if the radius is invalid. The lack of side-effect information is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and free of filler. It front-loads the action and resource, and every word contributes to understanding the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutating nature and lack of annotations, the description is too sparse for complete guidance. An output schema exists, so return values need not be described, but the tool's preconditions (e.g., closed polyline, radius limits) and effects (in-place modification) are missing. An agent might invoke it incorrectly without these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description must compensate. It does map 'radius' to the fillet radius and 'polyline' to the handle, adding meaning beyond raw types. However, it does not explain units, constraints (e.g., positive radius), or the format of the handle. This is minimal but adequate for a two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fillet (round)') and the resource ('ALL corners of a polyline'), with the radius as the key parameter. It distinguishes from the sibling tool 'chamfer_polyline' by explicitly saying 'round', which implies rounding rather than beveling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is provided. The description does not mention that this differs from chamfer_polyline or when to choose one over the other. The phrase 'CAD does the math' is a mild hint about automation but does not offer exclusions or alternative scenarios.
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 the full burden of explaining behavior. It states only what redo does (restores the last undone operation) but does not disclose failure modes (e.g., if there is nothing to redo), whether it is a mutating operation, or any side effects. This is a significant gap for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential meaning without any wasted words. It is optimally concise for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and has no parameters, the description lacks critical context about edge cases (e.g., behavior when no undo history exists). With an output schema present, return values are presumably covered, but the description still feels incomplete for a tool that modifies state. It meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter meanings. The description does not need to compensate for any parameter details. The baseline of 4 applies because the schema and description together are sufficient for a no-argument tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Redo the last undone operation' clearly identifies the action (redo) and the target (the last undone operation). It is specific enough to distinguish it from the sibling 'undo' tool, though it does not explicitly reference that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It implies it follows an undo, but does not state prerequisites, exclusions, or situations where redo would be inappropriate. There is no mention of the sibling 'undo' tool or the need to have an undo history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the basic transformation, but does not clarify whether the entity is mutated in place, what the return value is, or how 'selection' works. This is minimal for a transformation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no redundancy. It packs the core operation into a compact form, though it achieves this at the cost of missing useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description still lacks essential context for a 4-parameter tool with zero schema descriptions. It does not explain the selection mechanism, base point semantics, or the effect of the factor, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%, and the description provides only partial meaning: it explains 'base point' and 'factor' implicitly, but 'handle' remains vague. It does not explicitly map parameters to their roles, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (scale), the resource (one entity or selection), and the method (from a base point by factor). This distinguishes it from siblings like scale_all, rotate_entity, and move_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for individual entities or a selection, but does not explicitly state when to choose this over alternatives like scale_all. There is no exclusion or mention of 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?
Without annotations, the description carries the full burden of behavioral disclosure. It does add the key behavioral trait that it affects only NEW dimensions, not existing ones, which is valuable. However, it omits other relevant behaviors such as whether the settings persist, if they apply globally or per-draw, or any side effects. The disclosure is minimal and lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys all essential information without redundancy. Every phrase earns its place: 'Appearance of NEW dimensions' sets scope, and the parameter list is concise. No filler words or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 optional parameters, no required inputs) and the presence of an output schema, the description covers the core function and all parameter semantics. However, it lacks usage context, such as when to invoke this in a drawing workflow or how it interacts with dimension creation tools. It is adequate but not complete, warranting a mid-range score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does well by explicitly listing the parameter roles: 'text height, arrow size, decimal places, overall scale' map directly to text_height, arrow_size, decimals, and scale. This adds meaningful semantic context to each parameter, making the tool usable despite the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: controlling the appearance of new dimensions by specifying text height, arrow size, decimal places, and scale. It distinguishes from siblings like dim_linear and dim_aligned, which create dimensions, by explicitly targeting 'NEW dimensions' (style settings) rather than dimension creation. However, it lacks an explicit verb like 'sets' or 'configures', making it a noun phrase rather than a full action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool relative to alternatives. There is no mention of prerequisites, whether it should be called before creating dimensions, or when not to use it. No alternative tools are named, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the filled nature and the special case of inner_dia=0, but it does not disclose whether the donut is created on the current layer, how the fill is rendered (e.g., hatch or solid?), or any interaction with existing entities or coordinate systems. The lack of safety or mutation info is a gap for a drawing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, highly efficient sentence that conveys the essence of a donut and clarifies an edge case. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and has a small parameter set, the absence of annotations and output schema (actually an output schema exists, but the description doesn't need to explain return values) means the description covers the core geometry but lacks placement context (e.g., current layer, coordinate system) and any drawing conventions. It is adequate for a basic drawing primitive but not complete for an agent unfamiliar with CAD conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning beyond parameter names. It explains the key relationship between inner_dia and outer_dia and the boundary case for inner_dia=0. However, it leaves cx, cy, and layer meanings implicit — though cx/cy are universal coordinate parameters and layer is standard, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as drawing a donut (filled ring) and clarifies the relationship between inner and outer diameter, distinguishing it from similar shape tools like draw_circle or draw_arc. However, it doesn't explicitly name the sibling alternatives, so it doesn't fully differentiate from the draw_circle or draw_ellipse family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by defining the geometry (inner_dia=0 gives a filled dot) but does not state when to prefer this over draw_circle, draw_arc, or hatch_circle. There is no explicit when-to-use or alternative guidance, only contextual hints about the parameter semantics.
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 the burden of behavioral disclosure. It discloses two key behavioral traits: the (x,y) anchor is the top-left corner, and width controls the wrap width. This is valuable context beyond what the schema provides. However, it does not mention that the tool creates a new entity, how height affects rendering, or whether it operates on the current layer, leaving several behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence (fragment) with no wasted words. Each clause provides meaningful information: the entity type, anchor semantics, and wrap width. It is front-loaded with the core purpose. While it may be under-specified for completeness, it remains appropriately sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and only a minimal description, the description is not complete enough. It covers only a few parameter semantics and lacks broader context such as how the text is placed, what height means, or the expected return/effects. An output schema exists, so return values are not needed, but the description still fails to fully explain the tool's behavior and parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaning to x and y (top-left corner) and width (wrap width), covering three of six parameters. The required 'text' parameter is obvious from the context, but 'layer' and 'height' are not explained. This partial compensation makes it adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as multiline text and specifies the coordinate semantics (top-left corner) and wrap width. The verb 'draw' is implicit from the tool name 'draw_mtext', and the distinction from the sibling 'draw_text' (single-line text) is clear. However, the description is a fragment rather than a full statement like 'Draws a multiline text entity'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Multiline text' implies this tool is for multiline text, as opposed to the sibling 'draw_text' which is presumably for single-line text. However, there is no explicit guidance on when to prefer this over alternatives, nor any exclusions or alternative recommendations. The usage context is implied but not spelled out.
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 provided, the description carries the full burden. It does disclose that the tool provides key points and lists the kinds of points, which adds context beyond the name. However, it does not disclose behavior for unsupported entity types, error handling, or coordinate format. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose and lists the point types. The second clause adds a useful use case without unnecessary detail. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple (one parameter) and has an output schema, the description does not specify which entity types are supported or what 'key points' means for complex entities. The vague 'connect geometry without math' is not sufficient to fully understand the behavior, but it is not severely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required 'handle' parameter with no description coverage. The tool description mentions 'entity' but does not explain what the handle should be, how to obtain it, or its expected format. With 0% schema coverage, the description fails to compensate for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns key points of an entity, listing specific types (ends/mid/center/radius/vertices). This distinguishes it from sibling query tools like entity_length or get_extents, though it does not use an explicit verb like 'returns' or 'gets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'connect geometry without math' implies a use case for constructing geometry directly from entity key points, but it does not explicitly mention when to use this tool versus alternatives, nor any exclusions. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the 'selection' special value, but does not mention irreversibility, error handling, or any side effects of deletion. This is a notable gap for a destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the action and includes a key special case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description provides the essential use case. However, as a destructive operation with no annotations, it lacks safety/error context that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'handle' parameter's role and gives special meaning for 'selection', which adds value beyond the schema's bare string type. However, it does not define what a handle is or how to obtain one, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete an entity') and the resource (entity via handle), and includes a special case for 'selection'. This distinguishes it from sibling tools like erase_last or move_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus other deletion tools (e.g., erase_last). The special 'selection' value hints at GUI usage but no alternatives or prerequisites are mentioned.
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 the full burden of behavioral disclosure. It adds the point-direction rule and 'CAD does the math' but fails to disclose whether the offset creates a new entity or modifies the existing one, nor does it mention error conditions or side effects. This is a significant gap for a geometry 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the purpose and the second adds a useful behavioral hint. Every word contributes to understanding, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description is too terse for a 4-parameter tool with no annotations. It omits the meaning of 'handle', whether the original curve is retained, and any sign/unit conventions for distance. The minimal context leaves critical operational details undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explicitly mentions distance and tow_x/toward_y, which clarifies their roles, but it does not explain the 'handle' parameter at all, nor any constraints on distance (e.g., sign, units). The parameter meaning is only partially conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (offset), the resource (curve), and the method (by distance toward a point). This distinguishes it from sibling tools like move, copy, rotate, and trim, which all have different core operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for offsetting a curve but does not explicitly state when to choose this tool over alternatives such as copy_entity or trim_entity. It offers no exclusions or alternative tool references, leaving the agent to infer the context from the tool name and operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic scaling action and scope but does not mention whether the operation modifies entities in place, whether it is reversible via undo, whether it affects layers or non-drawing objects, or any side effects. Given that this tool mutates the entire drawing, the absence of such context is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded, with no redundant information. It conveys the core purpose efficiently. However, it could be slightly expanded with essential parameter clarifications without much bloat, so it does not earn a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For the simple operation of scaling all entities, the description covers the main purpose and scope. However, it lacks critical context such as parameter semantics, usage guidance, and any warnings about the impact of scaling everything. Even though an output schema exists, the missing parameter and behavioral details mean the description is only minimally viable 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.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does map base_x/base_y to 'base point' and factor to 'factor' in a loose sense, but it fails to explain the coordinate system, units, factor constraints (e.g., must be positive), or how these values affect the scaling operation. The description adds minimal value over the raw parameter names and does not fully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Scale' and explicitly states it affects ALL entities from a base point by factor. This clearly distinguishes it from sibling tools like scale_entity (which would target a single entity) and rotate_all (which rotates instead of scales). The scope and operation are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'ALL' implies the tool is for scaling every entity in the drawing, which gives some usage context. However, it does not explicitly state when to prefer this over alternatives (e.g., scale_entity) or mention any exclusions, dependencies, or prerequisites. The guidance is essentially implied by the tool's name rather than explicitly stated.
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 must disclose behavioral traits. It only notes that color uses ACI and 256 means ByLayer, and that it can act on a selection, but it does not mention required permissions, what happens to unspecified properties, how selection is determined, whether changes are reversible, or error behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence, front-loads the action, and includes essential clarifying detail (ACI, ByLayer). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a simple tool, the missing parameter semantics, usage guidance, and behavioral details (due to no annotations) make the description incomplete for confident invocation. The output schema exists but doesn't excuse the absence of parameter explanations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description lists property names but does not explain the handle parameter, the meaning of default values (-1, empty strings), allowed values, or how partial updates work. Only color semantics (ACI, 256=ByLayer) are partially addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Change'), the resource ('properties of an entity (or selection)'), and enumerates the specific properties (layer, color with ACI, 256=ByLayer, linetype). This distinguishes it from sibling tools that set current defaults rather than modifying existing entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for existing entities or selections, but does not explicitly state when to use this tool versus alternatives like set_current_layer or set_current_color. There are no exclusions or alternative guidance, so usage context is only implicit.
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 must disclose behavioral effects. It explains the keep parameter but does not state whether the original solid is modified or destroyed, whether new solids are returned, or any permission requirements. This is a significant gap for a mutation-type 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. Every phrase adds meaningful information, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks essential context: the required 'handle' is undocumented, usage guidelines are missing, and side effects are not disclosed. For a tool with no annotations and six parameters, this is minimal at best.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'keep' and the two points, but leaves the required 'handle' parameter completely undefined and the 'point-side x,y' syntax terse. This is insufficient for the six-parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'slice' and names the resource '3D solid', further specifying a vertical plane through 2 points and the 'keep' option. This clearly distinguishes it from sibling solid operations like bool_subtract or solid_box.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for cutting solid objects but offers no explicit when-to-use guidance or alternatives. Since no sibling tool performs slicing, the intended context is inferred primarily from the tool's unique purpose.
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 the full burden. It reveals that handle='selection' copies the GUI selection, implying other handles are entity identifiers, but it does not clarify whether the original is preserved, what the return value is, or any side effects. Important behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose and includes the special-case behavior without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and schema parameter descriptions, the tool description is the primary source of context. It is too sparse to fully guide an agent on how to construct the handle parameter (beyond 'selection') or what to expect in return, despite the existence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains dx and dy as an offset and highlights the special handle='selection' case, but it does not specify the format of a regular handle value or the units for dx/dy. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies an entity with a dx/dy offset, which is a specific verb+resource. It also distinguishes the handle='selection' special behavior, setting it apart from siblings like offset_entity or move_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for copying entities and mentions the special 'selection' handle, but it does not explicitly state when to choose this over alternatives like move_entity or offset_entity. No exclusions or alternative tool references 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?
No annotations are provided, so the description bears the full responsibility for disclosing side effects. It only explains the mathematical parameterization (center, major-axis endpoint, ratio) but omits what the tool does (creates an ellipse entity), how it interacts with the current drawing state (e.g., layer, color), or whether any data is returned. The description gives no indication of the tool's behavior as a drawing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, every word is informative. It front-loads the core geometry and includes no filler or repetition. Structure is ideal for a parameter-heavy primitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description defines geometry but fails to state that this tool draws an ellipse entity. Given the tool name and sibling list, an agent might infer this, but for a drawing tool with an output schema, it would benefit from a short action statement. The parameter semantics are complete, but the lack of behavioral context makes it only minimally viable for an agent to choose this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explicitly defining cx, cy, major_dx, major_dy, and ratio. It clarifies that major_dx/dy are relative to the center and that ratio is minor/major, which are non-obvious and critical for correct invocation. Only the layer parameter is not mentioned, but its purpose is self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as 'Ellipse' and specifies its geometric parameters (center, major-axis endpoint, ratio), which distinguishes it from circle/arc siblings. However, it lacks an explicit action verb like 'draws' or 'creates,' relying on the tool name to convey the operation. This is clear but not fully explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus draw_circle, draw_arc, or other drawing tools. It doesn't mention any prerequisites (e.g., current layer) or alternatives. There is no usage context beyond parameter definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two meaningful behavioral traits: the spline passes exactly through the given points ('through') and is smooth rather than angular. However, with no annotations, it omits potentially important behavior like layer handling, whether the spline can be closed, or error conditions for invalid point counts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no extraneous words. It efficiently communicates the essential function and input format without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, zero schema coverage, and an output schema that exists, the description omits important context such as layer behavior, return values, and constraints on the points array (e.g., minimum number of points). It is barely adequate for an expert and lacks completeness for autonomous agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the structure of the 'points' parameter as an array of [x,y] pairs, which is not explained in the schema. However, the 'layer' parameter is not mentioned at all, and since schema description coverage is 0%, the description only partially compensates for parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Smooth spline through the given points' clearly identifies the tool's output as a spline entity that passes through points, distinguishing it from siblings like draw_polyline and draw_line. The mention of 'smooth' differentiates it from a polyline, and the point format is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as draw_polyline or draw_arc. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without direction for tool selection.
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 discloses the key behavioral trait of returning area for closed entities. It does not mention error handling, units, or behavior for unsupported entity types, which would be needed for 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without any waste. It lists supported types compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter query tool with an output schema, the description provides adequate context by listing supported entity types and the area behavior. Slight gaps remain around unit/error behavior, but they are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not explain the 'handle' parameter beyond implying it identifies a curve. An agent would need to infer that 'handle' is an entity identifier from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool computes length (and area if closed) of a curve, listing specific entity types. This is a specific function with clear scope, though it doesn't explicitly differentiate from sibling tools like entity_points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The applicable entity types (line, arc, circle, polyline, spline) imply when to use the tool. However, there is no explicit guidance on when not to use it or which alternative to prefer for non-curve entities.
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 of behavioral disclosure. It details the output contents (entity count, unsaved changes, read-only state) and that the active drawing is marked. However, it does not explicitly state that the operation is read-only or note any potential side effects or performance considerations, although those are likely implied by the listing nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs essential information: what is listed, the active drawing marking, and the included attributes. It is concise, though the grammar is slightly awkward ('Every drawing open in the CAD, marking...'), which slightly reduces clarity. Overall, no word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters) and the presence of an output schema, the description sufficiently explains what the tool does. It lists all open drawings and their status details, which is adequate for a simple listing tool. The only minor omission is whether the list includes the current drawing or only others, but this is a minor detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. The baseline for no parameters is 4. The description adds no parameter information, but none is needed. The one-sentence description does not confuse parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The name 'list_documents' and description 'Every drawing open in the CAD...' clearly indicate the tool lists all open drawings. It specifies the data shown (entity count, unsaved changes, read-only state) and marks the active document, distinguishing it from siblings like drawing_info or get_entity_counts. However, the phrasing lacks a direct verb like 'Lists', making the purpose slightly less explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as drawing_info or list_entities. It implies an overview function but does not state explicit use cases, prerequisites, or when another tool would be more appropriate.
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 the full burden. 'List layers with colors' implies a read-only operation and indicates that colors are included in the result, but it does not disclose behavior such as whether all layers are listed, whether hidden layers are included, or if a drawing must be open. This is minimal but not misleading for a simple query 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is front-loaded with the action and object, and every word contributes to the meaning, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple tool with no parameters and an existing output schema, but it lacks contextual guidance about its relationship to similar tools. It would benefit from stating that it lists all layers or specifying how it differs from 'layer_info'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to explain. The baseline of 4 applies since the description does not need to compensate for any parameter gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('layers'), and adds 'with colors' to specify the output includes color information. This differentiates it from create/modify tools, but not explicitly from the sibling 'layer_info' which could also provide layer details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'layer_info' or 'list_blocks'. It lacks context about scope, prerequisites, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only describes the geometric definition. It does not state whether this creates a new entity, affects existing geometry, or requires specific coordinate systems. The action ('creates') is only implied by the tool name and siblings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose and parameter roles without padding. Every word contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is a simple primitive, the description is too minimal for safe invocation. It does not explain the wedge's orientation, placement relative to the base corner, or the behavior of the tool (e.g., whether it adds to the current drawing). The presence of an output schema reduces the need to describe return values, but the lack of usage and behavioral details leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by mapping all parameters to meaningful roles: (x,y,z) as the base corner and (dx,dy,dz) as sizes. This adds value over the schema's bare number types, though it lacks orientation details about the wedge's slope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating a 3D solid wedge (ramp) with specific construction parameters (base corner and sizes). It distinguishes this from sibling solid primitives like box, cylinder, and sphere by naming the unique shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The only implied context is the 'ramp' hint, but it does not explicitly state when a wedge is appropriate.
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 the full burden of behavioral disclosure. It mentions the prerequisite that the profile must be closed and describes the output, but it does not disclose side effects (e.g., whether source entities are modified), permission requirements, failure conditions, or path restrictions. This is inadequate for a solid modeling operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the action and result. It includes no fluff or redundant details, and every word contributes value (closed, path curve, 3D solid, examples).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (3D solid creation), lack of annotations, and 0% schema coverage, the description is too sparse. It does not cover when to use this versus extrude_profile/revolve_profile, prerequisites beyond a closed profile, or potential side effects. The presence of an output schema reduces the need to describe return values, but other contextual gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions and coverage is 0%, so the description must compensate. It adds meaning by specifying that the profile must be 'closed' and that the path is a 'curve', which loosely maps to profile_handle and path_handle. However, it does not explicitly define each parameter or explain parameter relationships beyond the general wording, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Sweep a closed 2D profile along a path curve' with an explicit outcome '-> 3D solid' and example uses (pipes, rails, gaskets). This distinguishes it from sibling tools like extrude_profile and revolve_profile by emphasizing the path curve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining what the tool does, and the examples give some context (pipes, rails, gaskets). However, it does not explicitly state when to use this tool over alternatives like extrude_profile or revolve_profile, nor does it provide exclusions or alternative tool references.
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 transparently reveals key behavior: instances whose solid was consumed or erased are reported, not hidden, and explains the rationale (manifest cannot drift silently). This is valuable beyond a simple listing description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, somewhat convoluted sentence with a philosophical explanation ('a manifest that cannot drift silently is the point of having one') that is not strictly necessary. The key facts are present but could be expressed more directly and economically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with an output schema, the description sufficiently covers what the tool returns (instances, poses, solid existence) and its invariant. It does not explain return format, but the output schema presumably handles that. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is complete. Per guidelines, baseline is 4; the description adds no param details but none are needed. It focuses on output meaning, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool returns an assembly manifest with poses and solid existence status for every placed instance. Though it lacks a direct verb like 'list' or 'get', the meaning is specific and distinguishable from sibling assembly tools (assembly_place, assembly_clear).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. It does not name sibling tools or state exclusions, though the 'manifest' language implies a query/read context. The behavioral note about erased instances offers some implicit context but not usage direction.
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?
Since no annotations are provided, the description carries the full burden. It includes the response format 'OK n=<count>', which gives some transparency about the output, but it doesn't disclose potential side effects (likely none), specifics on what is counted (e.g., all model space entities), or error behavior. This is minimal but not absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase: 'Total entity count (OK n=<count>)'. Every word earns its place, providing the core purpose and expected response format without any redundancy. It is appropriately sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a simple output, the description is mostly complete. It conveys the purpose and the return format. However, it could clarify what 'entity' includes (e.g., all entities in the drawing) and whether any filtering applies, but the simplicity of the tool makes this a minor gap. An output schema exists, but its details are not shown, so the description partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to add parameter information since none exist. The schema is empty and fully covers parameter requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Total entity count' clearly states the tool returns the count of all entities in the drawing. It is specific about the resource (entities) and the metric (count), though it lacks an explicit verb like 'get' or 'return'. It distinguishes from siblings like get_entity_counts by focusing on the overall total, but doesn't explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_entity_counts or entity_length. The description simply states what it returns and doesn't mention other tools or the context in which this is the preferred choice.
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 the full burden of behavioral disclosure, but it only states the geometric operation. It does not reveal side effects (e.g., adds entity to current drawing), default layer behavior, or any additional traits beyond the coordinates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence that directly conveys the tool's function with no filler or redundancy. Every word is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple drawing primitive, the description gets the core idea across, and an output schema exists so return values need not be explained. However, it omits the layer parameter, does not acknowledge default behavior (layer '0'), and offers no differentiation from similar line-drawing siblings, leaving some gaps for a tool with 5 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the four coordinate parameters by naming them in the context of a line from start to end, which adds meaning over the bare schema. However, the 'layer' parameter is not mentioned, and schema coverage is 0%, so the description does not fully compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the tool draws a line segment defined by two endpoints (x1,y1) and (x2,y2). This is specific, uses a clear geometric resource, and naturally distinguishes from sibling tools like draw_circle or draw_polyline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this when you need to draw a single line segment. However, the description provides no explicit guidance on when to choose this over alternatives like draw_polyline or draw_batch, nor any exclusions or prerequisites.
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?
Annotations are entirely absent, so the description must disclose behavioral traits. It does not mention that the tool creates a new drawing entity, what layer it affects, whether it is additive or destructive, or any side effects. The phrase 'Regular polygon' is a geometric definition, not a description of tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that lists the essential defining parameters. No filler or repetition of the schema exists. It is appropriately 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the return values may be documented there. However, the description lacks any statement about the effect on the drawing or prerequisites (e.g., active layer). For a simple drawing tool, it is minimally adequate but omits behavioral context that would help an agent predict side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description carries the burden of explaining parameters. It adds valuable meaning by clarifying that the radius is circumscribed and that rotation is in degrees. It also implies that cx and cy define the center. However, it omits the 'layer' parameter entirely and does not specify constraints like positive sides or radius.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Regular polygon: center, number of sides, circumscribed radius, rotation degrees' clearly identifies the resource (a regular polygon) and the defining parameters. It distinguishes from sibling tools like draw_polyline (arbitrary polylines) and draw_rectangle by specifying the regular polygon construction method (center, circumscribed radius, rotation). Though no explicit verb like 'draw' is used, the context of a CAD tool makes the intent evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what the tool creates, not when it is appropriate (e.g., for regular polygons with circumscribed radius vs. inscribed or side-based). There is no mention of excluded cases or alternative tools such as draw_polyline or hatch_polygon.
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 the burden of behavioral disclosure. It provides placement and orientation (base center at (cx,cy,z), height along Z) but does not state side effects (e.g., adds a solid entity to the drawing) or any special requirements, so it partially covers the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main purpose without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple primitive creation tool, the description sufficiently defines the tool's purpose and geometry. However, it omits any mention of prerequisites, units, or interaction with the current coordinate system, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are indirectly defined through the geometric description: cx/cy are x/y center coordinates, z is the base Z coordinate, radius is base radius, height is along Z. Since schema coverage is 0%, this description is the only source of parameter semantics and it does add meaning beyond the bare names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating a 3D solid cone and specifies its defining parameters (base center, radius, height along Z). It distinguishes from sibling solid primitives by naming the geometry explicitly, though it lacks an explicit verb like 'creates' or 'draws'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives like solid_cylinder or sweep_profile. The description only states the geometry, not the use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal the effect (opens a gap) and the same-point edge case, but it does not mention whether the operation is destructive, what happens to the original entity, or any prerequisites. This is some transparency but 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main verb and includes a parenthetical for an important edge case. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no annotations, the description covers the core behavior but leaves gaps: it does not explain the handle parameter, point interpretation, or entity type constraints. The existence of an output schema mitigates the need to describe return values, but the description is still somewhat sparse for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies that x1,y1 and x2,y2 are the two points (via 'between two points' and the same-point note), but it does not explain the 'handle' parameter, coordinate system, or units. This is only partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Break' and resource 'entity', and clearly defines the action as between two points. It adds a useful parenthetical explaining the behavior (opens a gap; same point twice = split only), which distinguishes it from sibling tools like trim_entity or explode_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to break an entity at two points) but does not explicitly mention alternatives or exclusions. The parenthetical about same-point-split provides a specific usage nuance but no comparative guidance against similar 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?
No annotations are provided, so the description carries the full burden. While it mentions the selection-based behavior, it does not disclose whether original entities are kept (despite the keep_original parameter), what the axis coordinates represent in the drawing, or whether the operation is destructive. This leaves significant behavioral ambiguity for a transformation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, with the core operation front-loaded. Both sentences earn their place: the first defines the operation, the second gives a practical workflow tip. No redundant or filler words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 6 parameters, 0% schema description coverage, and no annotations. The description only partially covers the mirror axis and selected entities, but omits keep_original behavior and the effect on source entities. For a non-trivial transformation tool, this is under-specified and would leave an agent uncertain about default behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to x1,y1,x2,y2 by identifying them as a mirror axis and explains that handles=['selection'] uses the GUI selection, which is helpful given 0% schema coverage. However, it completely omits the keep_original parameter and does not specify any other acceptable values for handles, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Mirror entities across the axis (x1,y1)-(x2,y2)', which is a specific verb and resource with explicit geometric parameters. This unambiguously distinguishes it from sibling transformation tools like rotate_entity or copy_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Draw half, mirror the rest' provides a concrete workflow context, implying this tool is used to create symmetric entities. It also notes that handles=['selection'] uses the GUI selection, giving a clear usage hint. However, it does not explicitly exclude alternatives or mention prerequisites like requiring an active selection.
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?
Without annotations, the description carries the burden of behavioral disclosure. It reveals that handle='selection' affects the GUI selection, a useful nuance. But it does not disclose whether the operation is permanent, error handling, coordinate system, or units for dx/dy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the core operation and a special case. No wasted words; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three required parameters and no annotations, so the description must provide enough context for correct invocation. It fails to explain the format of handle for non-selection entities, the coordinate space, and when to use this tool relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains dx and dy as the move offset, which is helpful given 0% schema coverage. It also documents the special 'selection' value for handle. However, it does not explain what other handle values look like or how they identify entities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Move entity by (dx,dy)') and distinguishes it from siblings like move_all by implying this targets a specific entity. It also explains the special 'selection' handle value, adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for moving a specific entity by an offset, and the 'selection' special value provides some guidance. However, it does not explicitly say when to use this over move_all, copy_entity, or other transform tools, nor does it state any prerequisites.
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 the full burden, but it only discloses the *MCPRES* return mechanism. It fails to mention that this tool can execute arbitrary code with full drawing access, potentially destructive side effects, error handling, or that changes might not be undoable. This is a significant transparency gap for a code execution 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action ('Eval AutoLISP code') and adds only necessary clarifications. It is appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's power and risk (arbitrary code execution), the description is too brief. It omits warnings about side effects, destructive potential, when to prefer this over specific drawing tools, and does not explain the output schema despite it existing. A complete description would need to address these aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'code' parameter is described as containing AutoLISP code, and the note about multi-line and multiple expressions adds meaning beyond the bare schema. However, it does not provide examples, size limits, or clarify expected return format beyond the *MCPRES* hint, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Eval AutoLISP code' with a specific verb and resource, and notes support for multi-line and multiple expressions. This distinguishes it from sibling tools that perform specific CAD operations, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for evaluating arbitrary AutoLISP code when no dedicated sibling tool exists, and provides the *MCPRES* mechanism for returning data. It does not explicitly state when not to use it or mention alternatives, but the context is fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return value ('Returns the scale MEASURED back off the viewport') but does not describe side effects on the sheet, whether the operation is reversible, or any permission/error conditions. For a mutation operation, this is insufficient behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise, and front-loaded with the primary purpose. Every sentence adds value, and the format is clear and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters) and no annotations, the description covers the main geometric inputs but omits the sheet parameter semantics, optional parameters (locked, plot_border), and does not specify units for model coordinates. An output schema exists but was not provided in the context, so some return details are disclosed. It is adequate but leaves gaps for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining the key geometry parameters: rectangle corners (x1,y1,x2,y2), scale (1:scale), and center point (center_x,center_y). It does not describe sheet, locked, or plot_border, but the core parameters are well-defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Put a window onto the model on a sheet') and identifies the resource (sheet and model). It details the rectangle, scale, and center point, which distinguishes it from general view tools like view_3d or flatshot_view, and aligns with sibling fit_viewport which likely adjusts existing viewports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for placing a viewport on a sheet. It does not explicitly state when to use this tool over alternatives like fit_viewport or view_plan, nor does it provide exclusions or prerequisites. The context is clear enough but lacks explicit guidance on tool selection.
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 the full burden. It discloses that the dimension line position is controlled by (line_x,line_y) and that coordinates are exact unless snap=True, which is useful. But it does not explain what snap actually does, deferring to dim_linear, and does not mention any side effects or prerequisites. This is moderate transparency but has gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary purpose and includes a compact formula for the key parameter pair. Every phrase earns its place, and the reference to dim_linear is concise. There is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no schema descriptions, this brief description is incomplete. It does not explain all parameters, the meaning of snap, or how the output is structured (though an output schema exists). It relies on dim_linear to fill gaps, which reduces its self-contained completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate. It explains line_x and line_y as the dimension line position and implies x1,y1,x2,y2 are the two points, but it does not explicitly define any of the parameters. snap is only mentioned as a boolean trigger, with details deferred to another tool. This is insufficient for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it creates an 'Aligned (parallel) dimension between two points.' This distinguishes it from sibling dimension tools like dim_linear, dim_radius, and dim_angular, which are all different dimension types. The verb 'dimension' and the modifier 'parallel' provide a specific and unambiguous 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool (for aligned/parallel dimensions between two points) and references dim_linear for the snap behavior, hinting at a difference between the two. However, it does not explicitly state 'use this instead of dim_linear when...' or list exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the behavioral trait that the rectangle is a closed polyline, which is useful. However, it does not describe side effects such as whether the rectangle is added to the current layer, coordinate system assumptions, or any potential destructive actions. It is adequate but minimal for a simple draw 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the essential purpose. Every word earns its place, and it avoids redundancy with the schema or annotations. It is an excellent example of minimal but meaningful documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and no annotations. The description covers the core purpose and parameter meaning, but it lacks details about coordinate system, layer behavior, and how it differs from similar tools. While the output schema explains return values, the description could be more complete for an agent to invoke it correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The phrase 'between opposite corners' gives semantic meaning to the corner coordinates (x1,y1,x2,y2), but it does not explicitly map them to parameter names or explain the layer parameter. With 5 parameters and only partial coverage, the description adds some value but does not fully compensate 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rectangle (closed polyline) between opposite corners' clearly states the tool creates a rectangle as a closed polyline, which is a specific verb+resource and distinguishes it from sibling tools like draw_line, draw_circle, and draw_polyline. It also adds the key detail that the rectangle is a closed polyline, clarifying the entity type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for drawing a rectangle but provides no explicit guidance on when to use this tool versus alternatives like rounded_rect or polygon. It does not mention exclusions or prerequisites, so guidance is only implicit from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does mention the infinite nature and the geometric parameters, but it omits that this creates a new drawing entity and the default layer behavior. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds meaning: 'infinite' conveys the line type, 'through (x,y)' indicates the anchor point, and 'at angle degrees' specifies the orientation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, but the description fails to provide usage context or note the default layer (COSTRUZIONE). It covers the core geometry but leaves out practical details an agent would need, such as layer handling and comparison to draw_line.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains x,y as a point and angle in degrees, mapping well to three of the four parameters. The layer parameter is not explained, but it's optional with a default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool draws an 'Infinite construction line' through a point at an angle, which clearly distinguishes it from finite lines like draw_line. The verb is implied by the tool name, and the resource is precisely described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or comparison to alternatives is provided. The term 'construction line' hints at a purpose, but there is no mention of when to choose this over draw_line or other drawing 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Delete the last created entity') without mentioning side effects such as irreversibility, behavior when no entities exist, or interaction with undo/redo. This leaves significant ambiguity for a destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundancy. It is front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description provides the core action and is adequate, but it lacks behavioral caveats like undo compatibility or edge-case handling. The presence of an output schema reduces the need to describe return values, but the overall context could be richer given the destructive nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The baseline of 4 applies because there is nothing to explain; the description correctly avoids mentioning parameters. No additional information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete the last created entity' uses a specific verb and resource, clearly identifying the action. It distinguishes from siblings like erase_entity (which likely deletes a specified entity) and undo (which reverts multiple actions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for removing the most recently created entity, but it does not explicitly state when to use this tool versus alternatives like erase_entity or undo. No exclusions or alternative tool names are provided, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It only states the operation and destination, without disclosing side effects (e.g., file overwrite behavior), success/failure return values, or any prerequisites. This is a significant gap for an export 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is front-loaded with the action verb and includes all necessary information (action, object, format, destination) in a compact form. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the description covers the core purpose. However, with no annotations or output schema detail, the description lacks behavioral context (e.g., what happens on success, whether the file is overwritten) that would make it fully complete for an export operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for 'path' (0% coverage). The description adds meaning by indicating that 'path' is the destination file path for the DXF export, which is helpful. However, it doesn't specify path format or extension requirements, but the added context is valuable for a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export'), the resource ('the drawing'), the format ('ASCII DXF'), and the destination ('path'). This is a specific verb+resource+format combination that distinguishes it from siblings like export_pdf and save_as_dwg.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for DXF export but does not explicitly mention alternatives or when not to use this tool. The sibling list includes other export/save tools, but no comparative guidance is provided, so the agent must infer based on the tool name and format mention.
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 the basic action (moving all entities) and the transformation (by dx, dy), but does not mention potential nuances like whether locked layers or hidden entities are affected, or what the operation returns. For a simple geometric transform, this is a minimal but acceptable disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly action-oriented sentence with no filler. It is front-loaded with the verb and resource, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (two numeric parameters) and an output schema is present, so the description does not need to detail return values. It provides the core transformation but lacks any usage exclusions or behavioral nuances. Given the simple nature, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. The phrase 'by (dx, dy)' clarifies that dx and dy are displacement deltas, which adds meaning beyond the bare schema types. However, it does not elaborate on units or coordinate system, which is likely inferred given the CAD context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Move') and resource ('ALL entities') with a clear scope. This distinguishes it from sibling tools like move_entity, which implies a single-entity operation. The purpose is immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'ALL' implies this tool is for moving every entity at once, providing a clear context. However, it does not explicitly state when to use this versus the alternative move_entity for individual entities, so the guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds valuable context about explicitly reporting read-only states and explaining the .dwl lock file cause, which counters a cryptic failure. However, it does not mention whether the tool overwrites existing files, required permissions, or success response details, leaving some behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and then adding a specific edge case. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description covers the main action and an important failure mode (read-only lock), making it considerably more complete than a bare 'save as DWG'. It could mention overwrite semantics, but overall it is sufficient for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter `path` with no description coverage (0%). The description merely repeats 'to path' without elaborating on the expected format, relative vs. absolute paths, extension handling, or whether .dwg is auto-appended. With no parameter documentation in the schema, the description fails to compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save the drawing as DWG (2018) to path' with a specific verb, format, version, and destination. This distinguishes it from siblings like save_drawing, export_dxf, and export_pdf, which are implied by the format specification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context about the read-only lock file scenario and the resulting error, but it does not explicitly state when to use this tool instead of alternatives like save_drawing or export_dxf. The intended use is implied by the DWG format mention, but no direct comparison or exclusion is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states the action without confirming that the operation is view-only and does not modify the drawing, nor does it address edge cases like empty drawings. The description adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately sized for the tool's simplicity, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple with no parameters and has an output schema, but the description lacks context about the effect (e.g., fitting all entities into the viewport) and assumes understanding of 'extents'. Given the absence of annotations, a bit more detail would improve completeness, but the description is minimally adequate for such a trivial operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema confirms this with an empty properties object. With 0 parameters, the description has no need to explain parameter semantics, which aligns with the baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Zoom' and clearly identifies the target resource 'drawing extents'. It distinguishes the tool from siblings like zoom_window, which zooms to a user-defined window, and regen, which regenerates the drawing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The action 'Zoom to drawing extents' implies the use case of fitting the entire drawing into view, but the description does not explicitly state when to use this tool versus alternatives like zoom_window or view_plan. No alternatives or exclusions are mentioned, so the usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the requirement that the profile must be CLOSED and that the height is along Z. However, it does not mention error handling, whether the original profile is retained, or unit/direction details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose stated first. The tagline 'The 2D->3D bridge' is slightly decorative but adds memorable context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and an output schema, the description covers the main operation and a key prerequisite (closed profile). It omits edge cases, but the availability of an output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning to both parameters: 'height' is clarified as height along Z, and 'handle' is implicitly tied to the closed 2D profile. It does not explicitly name the parameters or explain handle's role as an entity identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Extrude') and resource ('CLOSED 2D profile') and clarifies the output ('3D solid'). It distinguishes from siblings like sweep_profile and revolve_profile by specifying straight extrusion along Z. The parenthetical '(polyline/circle)' further defines the input type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through 'The 2D->3D bridge' and the tool's name, but no explicit when-to-use or alternatives are given. Sibling tools like sweep_profile and revolve_profile are not referenced, so the guidance is weak beyond the core purpose.
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 provided, the description carries the full burden and it does well by explaining the step-by-step behavior: measures the drawing, picks the largest standard scale, and resizes the viewport to the drawing. It also discloses the return value (the scale and why). However, it does not mention side effects on existing viewport properties or the role of the 'locked' and 'margin' parameters, which slightly reduces completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences, front-loaded with the main purpose, and no filler. Every clause adds meaningful detail: measurement, scale selection, viewport resizing, and return value explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, so that part needs no description. However, the tool is moderately complex with 8 parameters, zero schema description coverage, and no annotations. The core algorithm is described, but parameter semantics and when to use vs. alternatives are missing, leaving the description only partially complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate by explaining any parameters. While the concept of a 'region' hints at x1/y1/x2/y2 and 'margin' might relate to the standard scale fit, the roles of 'sheet', 'layer', 'locked', and 'margin' are not clarified. For an 8-parameter tool, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fit') and clearly states the resource ('model into a region of a sheet'). It distinguishes itself from siblings like add_viewport or zoom_window by describing the unique behavior of sizing the viewport to the drawing rather than to the region, with a specific algorithm (measure, pick standard scale, resize).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to fit a model into a sheet region with a standard scale) but does not explicitly mention alternatives or exclusion conditions. It doesn't say 'use this instead of zoom_extents' or 'do not use with non-standard scales,' so guidance is only implicit.
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 the full burden. It discloses a key behavior (auto-creates the layer if missing) and specifies lineweight units. However, it does not clarify what happens if the layer already exists (e.g., whether color/lineweight are updated) or other side effects, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and the second sentence adds practical value. Every word is purposeful, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with an output schema, the description covers the core behavior and key parameter semantics (lineweight units). It lacks explicit statement about the tool's effect on subsequent drawing operations, but that is strongly implied by 'set current layer'. Overall, it is sufficiently complete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning to 'lineweight' (unit MM and typical values) and mentions 'color' as a parameter, but does not explain the integer color code or expand on 'name'. It partially compensates for schema gaps but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set current layer' with a specific behavior of auto-creating the layer if missing. It distinguishes from sibling tools like create_layer and set_current_color by combining setting and creation with color/lineweight parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance for lineweight values (walls 0.50, visible edges 0.35, etc.) and notes that lineweight is in MM. However, it does not explicitly state when to use this tool versus alternatives like create_layer or set_current_color, leaving the usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool reads the sheet size automatically and returns the measured border, which is useful behavioral context. However, it does not detail potential side effects or prerequisites, and there are no annotations to rely on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that immediately state the purpose, then add relevant details about behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the core function and return value, but with 10 parameters and no parameter documentation, the agent lacks sufficient guidance for correct invocation. The output schema likely covers return, but parameter semantics are an important gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 10 parameters and no schema descriptions (0% coverage), the description does not explain individual parameters like border, binding, or revision. It only provides high-level context about sheet mm coordinates and bottom-right placement, leaving parameter meanings to inference from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws a border and an ISO 7200 title block with specific dimensions and placement (180x40, bottom right). It also mentions reading sheet size and returning the measured border, distinguishing it from generic drawing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating title blocks on sheets but does not explicitly state when to use this over alternatives. It mentions it reads the sheet size itself, suggesting sheet-level drawing, but no alternatives are referenced.
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 present, so the description must disclose behaviors. It does mention 'Zooms extents,' a side effect, and lists valid values. However, it does not clarify whether the view change affects only the current viewport or if any drawing state is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with semicolon-separated lists. Every word adds value; no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple view tool with two optional params, the description covers the main options and the zoom extents side effect. An output schema exists, so return values need not be described. Minor omissions like the meaning of 'iso2' are acceptable for this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there are no enums, so the description compensates by listing allowed values for 'direction' and 'shade' (e.g., iso/top, wireframe/gouraud). This adds practical meaning beyond the bare schema, though defaults are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '3D view' and enumerates valid direction and shade options. This distinguishes it from siblings like view_plan (2D plan) and zoom_extents (zoom-only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply lists parameters without explaining use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full transparency. It discloses the operation as a copy (non-destructive), defines the center point (cx,cy), count, angle in degrees, and the special GUI selection for handles. However, it does not clarify whether count includes the original set or only new copies, nor does it mention edge-case behavior or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, using two sentences to convey purpose and a key usage detail. Every word contributes to understanding the tool, with no redundant or generic content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool but leaves ambiguity around count semantics (total instances vs additional copies) and does not explain how to provide entity handles other than the 'selection' keyword. The presence of an output schema reduces the need for return-value details, but the input behavior is not fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It successfully explains cx, cy as the center, count as the number of copies, angle in degrees, and handles=['selection'] as a special GUI-selection mechanism. This adds meaningful semantic value beyond the bare schema, though it doesn't detail the full range of handle values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'copy entities count times around (cx,cy) over angle degrees'. The name 'array_polar' and the description explicitly indicate a polar distribution of copies, distinguishing it from the sibling tool 'array_rect' which handles rectangular arrays.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that handles=['selection'] uses the GUI selection, implying when a selection is required. However, it does not explicitly compare with alternatives like array_rect or state a preferred use case, leaving the usage guidance mostly implicit.
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 responsibility for disclosing side effects. It states the operation but does not clarify whether the original solids are modified or destroyed, what happens if subtraction results in a fully removed part, or any return behavior. This is a meaningful gap for a potentially destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase adds value: the verb, the object, the example outcome, and the parameter semantics. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. However, it omits important behavioral context such as whether the operation is destructive and what happens with invalid handles or fully-removed keep solids. For a boolean modifier in a CAD environment, this is a notable gap, though the core usage is adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds clear meaning by explaining that 'keep_handles' are the part to retain and 'subtract_handles' are the tools to remove. This goes beyond the bare schema by defining not just types but the functional roles of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Subtract' with a clear resource 'solids' and explains the semantic outcome ('holes, pockets'). It also distinguishes itself from sibling boolean tools like bool_union and bool_intersect by defining the keep/subtract roles unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains the roles of the two parameters ('keep = the part, subtract = the tools'), which implicitly tells the agent how to invoke the tool correctly. It does not explicitly mention when not to use it or name alternatives, but the context is sufficient for a straightforward boolean subtraction operation.
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 the full burden. It states the core operation (bevel all corners with equal distances) but does not disclose side effects, whether the polyline is modified in place, or any prerequisites. This is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, with no wasted words. It conveys the essential operation efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, which may cover return values, but the description does not explain the effect on the original polyline, whether it is modified in place, or any failure conditions. For a simple mutation tool, the description is minimal but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The phrase 'equal distances' clarifies the 'distance' parameter as a uniform chamfer amount. The 'handle' parameter is implicitly the polyline handle from the tool name, but it is not explicitly defined. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('chamfer'), the resource ('polyline'), and explicitly states scope ('ALL corners' with 'equal distances'). This clearly distinguishes it from sibling tools like fillet_polyline, which rounds corners instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for beveling all corners of a polyline, but it does not explicitly name alternatives or state when not to use it. However, the sibling tool fillet_polyline exists for rounding, and the context makes the intended use 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 the behavioral burden and discloses specific effects: margins zeroed, plot rotation cleared, auto-viewport removed, and returns measured sheet size. However, it does not fully clarify the destructive implications of 'reset' on existing user-defined content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with a colon-delimited list of effects. It packs a lot of specific information efficiently without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and three parameters, and the description covers return value and key behavioral details. It lacks context on prerequisites or how the name and landscape parameters affect the result, but overall the core behavior is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only implies the size parameter accepts A4..A0. It does not explain the landscape or name parameters, leaving meaningful gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or resets a paper-space sheet (layout) with sizes A4..A0, specifying it is for 1:1 plotting. It distinguishes itself from sibling tools like add_viewport or title_block by focusing on the sheet-level setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for preparing a clean layout for plotting, but it does not explicitly state when to prefer this over alternatives such as add_viewport or title_block. No exclusions or conditions are provided.
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 available, the description carries the burden of disclosing effects. It explains parameter meanings but does not state that the tool modifies the drawing by adding a dimension object, nor does it mention any prerequisites beyond 'by handle'. It is not contradictory, but lacks explicit behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler. All content is relevant, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and a simple 3-parameter tool, the description covers the essential usage. It could be improved with an explicit mutation statement, but is 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description compensates by explaining angle ('where it points') and offset ('leader length factor'). The 'handle' parameter is only implied as the target entity, so not fully explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool as creating a radius dimension on a circle/arc using an entity handle. It distinguishes from sibling dimension tools (dim_diameter, dim_linear) by specifying 'radius' and 'circle/arc'. However, it lacks an explicit verb such as 'Creates' or 'Adds', relying on the noun 'dimension'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States the target entity type ('circle/arc') and the mechanism ('by handle'), giving clear context for when to use. It does not explicitly mention alternatives or when not to use, but the specific 'radius' scope provides implied guidance relative to other dimension tools.
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 must carry the full behavioral disclosure. It clearly conveys the core hatching action and the role of islands, but it does not mention whether a new hatch entity is created or an existing one is modified, nor how layer, scale, angle, and pattern affect the result. These gaps matter for a tool that likely mutates the drawing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, lean sentence that front-loads the primary action and seamlessly integrates parameter formats. Every word contributes to understanding the tool's purpose and core inputs, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the six-parameter schema, the description covers only the essential geometry and leaves out behavioral nuances such as return values or error conditions (though an output schema exists). It is adequate for a straightforward hatch operation but lacks depth for a tool dealing with polygon nesting and potential edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explains the two required parameters (outer and islands) with concrete coordinate structures, adding meaning beyond the schema's generic arrays. However, it does not describe angle, layer, scale, or pattern, although these have defaults and likely behave as standard hatch settings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'HATCH' with a clear resource: the outer closed polygon while skipping island polygons. It distinguishes itself from sibling tools like hatch_polygon and hatch_circle by explicitly stating the 'hatch around holes' behavior. The purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for hatching a region with holes by stating 'SKIPPING the island polygons' and provides the expected coordinate formats. It does not explicitly name alternatives or state when not to use this tool, but the context is sufficient for a CAD-savvy agent to discern appropriate scenarios.
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 must disclose behavior. It reveals the output is a clean PNG and explains the framing behavior. However, it does not mention side effects like file creation, overwrite behavior, or the meaning of the required 'path' parameter, leaving key behavioral details implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first states purpose and key output feature; the second gives precise parameter usage. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the optional window framing, but lacks details about the required 'path' parameter and coordinate system ordering (e.g., lower-left vs upper-left). Since an output schema exists, return values need not be explained, but the missing path semantics and potential side effects leave completeness gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the four coordinate parameters (x1,y1,x2,y2) as a window, but the required 'path' parameter is not explained. This is a significant gap since 'path' is the only required parameter, though the phrase 'render to a clean PNG' hints it is the output file path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Render' and the resource 'the drawing to a clean PNG', specifying the output format and purpose ('for visual inspection'). It distinguishes itself from sibling tools like export_pdf and export_dxf by emphasizing the PNG output with no UI chrome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'for visual inspection' and explains how to frame a region with the window parameters, including the alternative of omitting for the current view. It does not explicitly name alternatives or exclusions, but the intended use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the ACI code meaning and the ByLayer special value, but it does not disclose that the setting affects subsequently created entities or how it interacts with the current layer. Since no annotations are provided, the description carries the full burden and only partially covers behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that provides the key information without any wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, the description is mostly adequate, but it does not state the effect on future drawing operations (that the color will apply to entities created afterward), which is important contextual information. An output schema exists, so return values are not needed, but this omission leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the 'color' parameter. The description adds essential meaning by explaining that it is an ACI code and that 256 means ByLayer, fully compensating for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the current entity color, specifies the ACI code format and ByLayer value, and distinguishes it from sibling layer tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this should be used before drawing entities to set the active color, but it does not explicitly state when to use this tool versus setting layer colors or other alternatives, nor any 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?
No annotations are provided, so the description must carry the full transparency burden. The verb 'Read' implies a non-destructive query, but the description does not explicitly state that the tool has no side effects, nor does it describe behavior on invalid variable names. It is minimally transparent but lacks explicit safety or error behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loads the action and resource, and every word earns its place. It is concise without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with an output schema, the description is adequately complete. It conveys the core purpose and provides examples, but it omits information about edge cases (e.g., invalid variable names) and return structure, though the output schema likely covers the latter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides examples of system variables, implying that the 'name' parameter is a system variable name, but it does not explicitly map the parameter or describe its format. The examples add some meaning but not comprehensive parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and identifies a clear resource ('system variable') with concrete examples (CLAYER, DIMSCALE). This clearly distinguishes it from sibling tools like get_entity or get_extents, which operate on drawing objects rather than system variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's context clear by stating it reads system variables and giving examples, but it does not explicitly mention when to use this tool versus alternatives or provide exclusions. Since no sibling tool reads system variables, the usage context is well-implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the source-handle behavior ('first handle = source'), which is useful. However, it omits side effects like whether the original entities are deleted or a new polyline is created, and does not clarify if the source is modified in place. With no annotations, this context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the operation, input, and result efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple join operation, the description covers the essential information. It explains what entity types are supported and the source-handle rule. The missing side-effect details lower it slightly, but an output schema exists, reducing the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'handles' parameter by indicating that order matters (first handle = source) and specifying acceptable entity types (lines, arcs, polylines). With 0% schema coverage, this is valuable but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Join') and resource ('touching lines/arcs/polylines'), clearly identifying the operation and result ('into one polyline'). This distinguishes it from sibling tools like trim_entity or break_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (joining touching entities) but does not explicitly state when to use this tool versus alternatives. It offers no exclusions or comparisons, so the guidance is only implicit.
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 provided, the description carries the burden of behavioral disclosure. It implies a read-only operation but does not state side effects, scope (e.g., all layers), or behavior for empty layers. However, for a simple reporting tool, the described behavior is fairly transparent and not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that contains no filler. Every word adds value: 'Per-layer report' defines the action, and the colon-delimited list of attributes is concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, output schema exists), the description covers the essential purpose and content. It doesn't explicitly mention scope (e.g., all layers) or edge cases, but for a reporting tool this is minor. The output schema handles return values, so the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is empty, so the description adds value by explaining what the report contains rather than needing to describe parameter syntax. The baseline for 0 params is 4, and the description fully compensates by defining the output fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a per-layer report and lists the specific attributes it returns (object count, color, linetype, frozen/locked). This distinguishes it from siblings like list_layers (which likely lists layer names) and drawing_info (overall drawing info). The verb 'report' is implied and the resource 'layer' is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool vs alternatives. However, the wording 'Per-layer report' makes it clear this is for detailed per-layer inspection, which is a reasonable implication. No exclusions or alternative tools are mentioned.
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 the fields returned and the filtering behavior but does not explain the 'library' parameter or what happens when it is empty. The read-only nature is implied by 'list' but not stated explicitly, and side effects are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, then usage guidance. Every sentence adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema, return values are covered. The description provides the filtering options and usage context, but the unexplained 'library' parameter and lack of any mention of document scope or prerequisites leave a notable gap for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'category' parameter by listing all possible values and noting the empty default. However, the 'library' parameter is completely unexplained, and with 0% schema description coverage, the description must compensate for both parameters. It fails to do so for one of them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool offers symbol library information including block name, descriptions, category, and real size. It distinguishes itself from sibling tools by explicitly directing users to 'Use this before insert_symbol when you do not know what exists.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instructions: filter by category with a specific set of values, or leave empty for all. Also states when to use this tool vs. insert_symbol, which is a clear alternative.
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 bears the full burden of disclosing behavioral traits. It mentions what is purged but does not state that the operation is destructive, whether it can be undone, or what qualifies as 'unused.' This is similar to the update_drive example where lack of such details warranted a low score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and target. Every word is necessary, and there is no extraneous information or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description adequately covers its behavior. The only minor gap is the lack of explicit warning about irreversibility, but for a simple, parameterless command, the provided context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema is empty. The baseline for zero parameters is 4, and since there is nothing to describe, the description does not need to add parameter-specific semantics. It appropriately relies on the schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('purge') targeting specific resources ('unused layers, blocks, linetypes, styles') within the drawing. It distinguishes itself from sibling tools like erase_last or erase_entity, which remove entities rather than clean up drawing definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is used for cleaning up unused drawing definitions, a typical CAD maintenance operation. While it doesn't explicitly mention when not to use it or name alternatives, the purpose is self-evident and adequate for a parameterless tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the rotation direction (CCW) and that it applies to all entities, which are useful behavioral details. However, it does not mention side effects, reversibility, or any prerequisites, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. It is front-loaded with the verb and scope, making it immediately understandable and appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple transformation tool with three parameters and an output schema, the description covers the essential behavior (what, scope, direction). It does not explain return values, but the output schema handles that. Minor omissions like error conditions or layer handling are not critical for this type of tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly implies that base_x and base_y define the base point and angle is the rotation angle in degrees (CCW), effectively linking the parameters to their roles. It adds meaningful semantics, though it does not specify coordinate system or units for coordinates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('rotate'), the scope ('ALL entities'), and the direction ('CCW'), effectively distinguishing it from rotate_entity and other sibling tools. It 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'ALL' implies this is for rotating the entire drawing, but there is no explicit guidance on when to use it versus rotate_entity or other alternatives. The usage context is implied, not stated directly.
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 provided, the description carries the full burden. It discloses the side effect of making the style current and gives a font example, but it does not mention overwrite semantics, error behavior, or return value. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Create/set', and contains no unnecessary words. Every element contributes to understanding the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 parameters) and the existence of an output schema, the description adequately covers the primary purpose and the key side effect. It does not mention prerequisites (e.g., font file availability) but remains sufficient for a basic setup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds meaning by providing an example for the font parameter ('isocpeur.ttf for ISO drawings'). However, it does not elaborate on the required 'name' parameter beyond the obvious implication of a style name, so the compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create/set' with a resource 'text style' and clearly states the font and the side effect of making it current. This distinguishes it from siblings like draw_text, create_layer, and set_current_color.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (creating/setting a text style and making it current) but does not explicitly mention alternatives or exclusions. It provides clear context but falls short of explicitly naming when not to use it, unlike the get_calls example.
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 discloses that the selected entities become the block definition and that the block is not placed until insert_block is used. However, it omits important behavioral details such as whether the original entities are deleted, how naming conflicts are handled, and any preconditions for selecting entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the main action and resource. The parenthetical efficiently adds a key alternative without wasting words, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the relationship to insert_block, but it does not explain the base point, the fate of source entities, or any prerequisites. With 4 required parameters and no annotations, the context is incomplete, though the output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to 'handles' by referring to 'existing entities', but it provides no explanation for the required base_x and base_y parameters. While the parameter names are somewhat self-explanatory, the description does not fully cover all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Define' with a clear resource 'a reusable block' and specifies the source as 'existing entities'. It also explicitly distinguishes from the sibling insert_block by noting 're-place with insert_block', fully clarifying the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance by naming insert_block as the tool for re-placement, giving a clear when-not and alternative. This directly helps an agent select between the two tools and implies the appropriate use case for creating a block definition.
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 the behavioral burden. It discloses ACI color mapping, legal lineweight values, and snapping behavior. However, it does not mention behavior for duplicate layer names or error conditions, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the action and resource, then lists allowed values. Every clause adds useful information; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool, the description covers core behavior, parameter semantics, and edge-case snapping. Output schema exists, so return values don't need explanation. Minor gaps remain around duplicate layer behavior and default lineweight semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description compensates by explaining the meaning of color (1-7 with names) and lineweight (legal MM values + snapping). The name parameter is self-evident. This exceeds what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a layer' with specific attributes (ACI color, lineweight), using a specific verb and resource. It distinguishes from sibling tools like list_layers or set_current_layer by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as set_current_layer or layer_info. It does not state prerequisites, exclusions, or when this tool is preferred.
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?
Since no annotations were provided, the description carries the full burden of behavioral disclosure. It explains that the tool reads STL meshes (no CAD), measures overhang area, bridges, worst angle, height, and all six orientations, and importantly cautions that it measures faces, not spans. This is rich 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than two sentences, but every clause adds value: the opening question, the measurement details, the orientation scoring, the unit clarification, and the faces-vs-spans caveat. It is front-loaded and coherent, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and the existence of an output schema, the description covers the tool's purpose, parameter meanings, output units, and a key behavioral limitation. It does not detail return structure (output schema covers that) nor error handling, but those are not essential for this analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description effectively defines limit_deg ('overhangs past limit_deg'), build_dir (with examples 'z+' and 'z-'), and implicitly stl_path via 'Reads the STL mesh'. This compensates well 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the direct question 'Will this part print without supports, and which way up is best?' clearly establishing the tool's purpose. It specifies a unique verb+resource ('reads the STL mesh' and measures overhang properties) and distinguishes it from sibling tools like the solid modeling or drawing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for assessing printability without supports, but does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or when not to use it. There is no comparison to other report tools (e.g., contact_report, hole_report).
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 the full burden. It discloses a key constraint (the profile must be CLOSED) and defines the axis and angle semantics. However, it does not state whether the operation produces a solid or surface, nor does it mention any prerequisites or side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the operation and parameters without any fluff. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since an output schema exists, return values are not needed. The description covers the core parameters and constraints, but it lacks details on the required entity type for the profile (e.g., closed polyline) and any prerequisite state. It is adequate for basic use but leaves room for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining handle as '2D profile', x1/y1/x2/y2 as axis points, and angle as degrees. This adds substantial meaning beyond the bare type definitions, though it omits specifics like units or rotation direction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Revolve a CLOSED 2D profile' and specifies the axis via two points and an angle. This is a specific verb+resource construction that distinguishes it from sibling tools like extrude_profile or sweep_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(turned parts)' provides clear context for when this tool is appropriate, implying rotational symmetry. However, it does not explicitly mention alternatives or exclusion criteria, so it lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses the geometric meaning of parameters but does not mention effects on the drawing (e.g., entity creation, current layer), edge cases (negative sizes), or return value. Still, for a simple primitive, the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the key term '3D solid box' and immediately follows with parameter semantics. There is zero fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple solid primitive, the description covers the essential geometry and coordinates. It does not explain whether the tool creates a new entity or returns a handle, but the output schema exists to handle that. Overall, well-suited to the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, but the description fully compensates by explaining that x,y,z are the base corner and dx,dy,dz are sizes, with dz along Z. This adds meaning beyond the raw schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose as creating a 3D solid box, specifying the base corner and dimensions. It distinguishes from 2D draw tools (e.g., draw_rectangle) and other solid primitives (solid_cylinder, solid_sphere) without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description: it is for creating a rectangular solid box. However, no explicit guidance is given about when to prefer this over alternatives like extrude_profile or draw_rectangle, nor any conditions or 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 are provided, so the description carries the burden. It discloses important behavior: 'Refuses dead handles' (error handling for invalid entities) and 'Tags live beside the drawing and survive sessions' (persistence). This gives valuable insight 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loads the core purpose in the first sentence. The second and third sentences add examples and behavioral detail. The 'ghosts' metaphor is somewhat poetic but not overly verbose; every sentence contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no annotations, the description covers purpose, key behavior (dead-handle refusal, persistence), and integration with world_report. It lacks detail on return values, the note parameter, and any prerequisites, but is reasonably complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains 'role' with examples and implies 'handle' is an entity reference ('refuses dead handles'), but it does not clarify the 'note' parameter or provide explicit meanings for handle and role beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: 'Give an entity a semantic ROLE in the drawing's memory.' It provides concrete examples ('muro-nord', 'asta-principale') and distinguishes itself from sibling geometry/entity tools by focusing on semantic roles rather than geometric properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys its niche: assigning persistent, meaningful labels to entities. It mentions that 'world_report revalidates them against the live drawing,' implying this tool is for creating tags that world_report later checks. However, it does not explicitly name alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses the non-obvious behavior that a draw_batch counts as one operation, which is useful. However, it does not mention whether the operation is destructive or reversible, error conditions, or any limits, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and includes only the essential batch-counting nuance. There is no wasted text, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one parameter, and the presence of an output schema, the description covers the action and the crucial batch-counting behavior. This is complete for an agent to select and invoke the tool correctly, with no additional critical context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the count parameter. The phrase 'Undo the last N operations' directly maps to the count parameter, and 'a whole draw_batch counts as ONE' clarifies the counting unit, adding semantic meaning beyond the raw integer schema. It doesn't mention the default, but the schema already provides that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Undo' with the resource 'operations', clearly stating the action. The parenthetical about draw_batch counting as ONE clarifies an important semantic distinction, helping distinguish it from sibling tools like redo or erase_last.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (use when you want to revert recent operations) but provides no explicit when/when-not or alternative guidance. It does not mention that redo is the counterpart or distinguish from erase_last, so an agent might not know which undo-related tool to choose without additional context.
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 discloses the key behavior of fitting to the page and implies file creation, but omits details like overwrite behavior, file format specifics, or required permissions. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences. The first states the action, the second gives an alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter export tool, the description covers the core behavior and distinguishes it from the sibling. Output schema exists, so return values are handled separately. Minor omissions like error cases or path validation are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'path' has no schema description, and the tool description does not explicitly explain its meaning beyond the implicit output destination. The name is self-explanatory, but the description adds little value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports the current view to PDF, with a specific verb and resource. It also distinguishes itself from the sibling export_sheet_pdf by noting the alternative for real-scale sheets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a usage boundary: use this tool for a view fitted to the page, and use export_sheet_pdf instead for a sheet at real scale. This directly guides tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it discloses a meaningful behavioral trait: it verifies the PDF by measuring the page. It does not mention permissions or side effects, but the verification step adds useful 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key scale distinction, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are covered. However, parameter semantics are missing, and the description does not fully compensate for the complete lack of schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of the 'path' or 'sheet' parameters. The parameter names are self-explanatory to some degree, but no additional meaning or usage details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a sheet to PDF at its scale, with a specific verb and resource. It explicitly contrasts with export_pdf, distinguishing the two tools effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names the alternative export_pdf and explains the difference in behavior (scale vs. fit to page), making it clear when to use this tool instead.
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 transparency burden. It discloses what is returned (count, handles, types, layers) and implies a read-only operation, but it does not explicitly state that it has no side effects or describe behavior when nothing is selected. These gaps prevent a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose and result contents, with no unnecessary words. Highly structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description sufficiently covers purpose, usage, and returned content. A minor gap is the lack of explicit handling for an empty selection, but this is not critical for such a straightforward getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is nothing to document there. The description adds value by explaining that the implicit input is the current GUI selection, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific query operation: retrieving the user's current GUI selection, listing the data types (count, handles, types, layers). It distinguishes itself from sibling tools like select_by and select_window, which modify selection rather than read it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: enables 'do X on what I selected', indicating when to invoke it (when the agent needs to act on the current selection). It does not explicitly mention alternatives or exclusions, but the niche is well implied by the contrast with selection-modifying siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that layer and scale come from the library index, that symbols are sized/colored correctly automatically, that the block is loaded from the library DWG if missing, and the reference scale nuance. It does not mention error handling or return format, but the output schema covers return value structure, so this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence gives the main purpose, then explains synonym resolution, then covers layer/scale behavior, and ends with a pointer to list_symbols. Every sentence adds value with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and output schema, the description provides substantial context: usage examples, synonym behavior, scale conventions, and automatic block loading. It doesn't explain coordinate parameters or library selection, but these are moderately inferable from typical CAD semantics. Overall, it is quite complete for an insertion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning for scale_denominator (1:100 example) and symbol (supports colloquial names via synonym dictionary). However, it leaves x, y, rotation, library, and layer unexplained beyond what the schema types imply. The description also implies layer and scale are auto-derived, which is useful, but it doesn't fully document all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core function with a specific verb and resource: 'Place a library symbol'. It also differentiates from siblings by mentioning synonym resolution and library index conventions, and it explicitly references list_symbols as a separate tool for viewing available symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: place a symbol by name or colloquial name, with synonyms resolved automatically. It also gives usage tips like passing scale_denominator=100 for a 1:100 plan and mentions list_symbols to see what exists. However, it does not explicitly contrast with insert_block or other block-related siblings, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a verification method (DBMOD returning to 0) that is not present in any annotation, providing a concrete behavioral trait. With no annotations provided, this detail helps the agent confirm the write occurred, though it does not cover failure modes 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the core action first and additional verification detail second. Every sentence adds value, and there is no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter save command, the description covers the primary behavior and a way to verify success. However, it does not explicitly state return values or error handling, but with an output schema present, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the description correctly omits parameter details. The mention of 'active drawing' provides context about the implicit target, which is sufficient for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves the active drawing to its existing location using the verb 'Save' and resource 'active drawing'. It distinguishes from siblings like save_as_dwg by specifying 'where it already lives', indicating a standard save rather than save-as.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for persisting the current drawing to its existing file, but does not explicitly mention alternatives or when-not-to-use. It distinguishes from save_as_dwg implicitly 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully explains the crossing behavior and mentions optional filters, but it does not disclose whether the selection replaces the current selection, whether it triggers a UI highlight, or any side effects beyond the selection state. This is a moderate level of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence efficiently conveys the core functionality, the critical crossing distinction, and the filter options. It is front-loaded and every clause earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and an output schema, which reduces the need to describe return values. The description covers the decision logic and filters, and the coordinate system is reasonably inferable. It might have added a note about coordinate units or interaction with the current selection, but overall it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, leaving the description to compensate. It explains the meaning of 'crossing' and mentions 'type/layer filter' which maps to entity_type and layer parameters. However, it does not elaborate on the coordinate parameters (x1,y1,x2,y2), though these are relatively self-explanatory from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Select+highlight') and resource ('by rectangular area'), with a specific mechanism. It distinguishes itself from siblings like 'select_by' and 'zoom_window' by clearly indicating a rectangular selection 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for rectangular-area selection and explains the crossing parameter, but it does not explicitly state when to prefer this over alternatives like 'select_by' or 'get_selection'. No exclusion criteria are given, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two non-obvious behaviors: auto-loading missing linetypes and the conditional global linetype scale setting. However, it does not address what happens if the layer does not exist or whether existing entities on the layer are affected, leaving some side effects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core action, valid options, and key behavioral caveat without any filler. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose, allowed values, and the special ltscale condition. Given the output schema exists, return values need no explanation. It would benefit from specifying layer existence handling, but the current text is sufficient for a basic setter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by enumerating accepted linetype values and giving semantic meaning to CENTER. It also clarifies the ltscale parameter's conditional behavior, adding context beyond the schema's bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Assign' with resource 'a layer' and specifies valid linetype values. It also explains the meaning of CENTER, distinguishing it from sibling tools like create_layer and set_current_layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit alternatives are named, the tool's specific function is unmistakable from the first sentence, and the list of linetypes plus the layer target makes its use case immediate. However, it lacks explicit when-not guidance relative to sibling tools.
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 behavioral burden. It explains the geometric shape (rounded-end slot between arc centers with width) and warns against mistaking it for a rectangle, but it does not disclose whether the result is a polyline, block, or other entity type, nor does it mention layer behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the shape and its geometric construction, and the second provides usage guidance. There is no redundancy, and the essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple drawing primitive with an output schema available, the description is largely sufficient: it gives the geometric definition and clarifies when to use it. Minor omissions like the default layer and output entity type are not critical given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), but the description adds meaning by tying geometric parameters to concepts: x1/y1 and x2/y2 are arc centers, and width is the slot width. The optional layer parameter remains undocumented, but the core parameters are semantically explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating a slot/obround, defining it as a rounded-end slot between two arc centers with a given width. It also explicitly states 'Use this for slots - NOT a rectangle,' which differentiates it from sibling tools like draw_rectangle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage guidance: 'Use this for slots' and a clear exclusion: 'NOT a rectangle.' It does not mention other potential alternatives like rounded_rect or polyline, but the primary 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that it performs read-only operations (revalidates via entget), reads tags and journal, and reports results. It explains the liveness test and mentions manual GUI edits. It does not state side effects (likely none) but is largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact, information-dense, and front-loaded with a question that summarizes the purpose. Each sentence adds meaningful detail without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input, processing, and output categories. It's sufficient for an expert to understand behavior. No need to explain return values due to output schema. Minor gaps: prerequisites like memory enablement, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema is trivially covered. Description explains what data the tool reads (tags, journal) without needing to describe parameters. No extra parameter meaning needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it reads semantic tags and the autonomous journal, revalidates handles, and reports roles alive/dead, events, and newcomers. It distinguishes itself from sibling report tools by focusing on memory validity and change tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking drawing state and memory truth, but does not explicitly state when to use it over alternatives like drawing_info or contact_report, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses that the tool measures volume changes, checks against expected_change, detects the two specific failure modes, and warns about the handle retention trap where the result keeps the target's handle. This is rich, behavior-revealing context beyond any structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries meaningful information about behavior and failure modes. It is front-loaded with the core measurement concept, though the single-paragraph structure makes it a bit heavy. Still, there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (boolean verification with multiple failure modes and a handle trap) and the presence of an output schema, the description is thorough and covers most key behaviors. The main omission is tol_pct semantics, which is important for calibration, and tool_handles could be clearer. Overall, it provides sufficient context for an agent to select and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains expected_change in detail (mm3, derived from the shape), mentions target_handle as the receiving solid, and touches on op via SUBTRACT/UNION/INTERSECT semantics. However, tol_pct and tool_handles are not explicitly described, leaving gaps in parameter understanding for a tool with no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a boolean operation that verifies its own effect by measuring volume before/after and comparing to expected_change. It explicitly distinguishes itself from plain boolean operations by catching short cuts and missed cuts, which is a specific and unique purpose among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool: when you need to verify a boolean cut actually succeeded and trust the result. It contrasts with 'a plain boolean' that reports false successes, implying the alternative of standard bool_subtract/union/intersect, though it does not explicitly name them or state when not to use the 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 are provided, so the description conveys the key behavioral traits: it processes all 3D solids, projects from a specified direction, places the lower-left corner at (x,y), and returns a block handle and size. It does not mention side effects like creating a block definition or layer impacts, but covers the core outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the first being information-dense and front-loaded. The second sentence is a rhetorical hook ('Model in 3D, get the 2D view for free') that reinforces value but is somewhat redundant; still, it does not waste much space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity and no annotations or output schema details beyond 'returns block handle+size'. The description covers all parameters, behavior, and return value, making it effective for an agent. It could mention whether it creates a new block definition or affects the undo stack, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds essential meaning: x and y define the lower-left corner placement, and direction is the projection direction. This compensates for the schema's lack of parameter descriptions, though it does not list each parameter explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Auto-generate a 2D drawing view'), the target ('ALL 3D solids'), the projection directions, and the placement. This uniquely distinguishes it from all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after modeling 3D solids ('Model in 3D, get the 2D view for free'), and makes clear it operates on all solids. It does not explicitly state when not to use or name alternatives, but no direct alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 performance traits ('cheap', 'Instant') and implies a read-only operation via 'census', but it does not explicitly state that the tool makes no changes to the drawing or describe any error conditions or limitations. Some behavioral context is present but 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that combines purpose and usage guidance efficiently. Every word contributes meaning ('Instant', 'cheap', 'census', 'per type', 'call this FIRST'). There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a parameterless tool with an output schema, the description sufficiently covers both what the tool does and when to use it. It explains its role in the workflow ('call this FIRST') without needing to detail output fields, which are available in the output schema. The content is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds meaning by clarifying that the output is organized 'per type', though the exact return structure is presumably covered by the output schema. No parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific metaphor ('Instant census') and explicitly states the resource ('entity count per type'). This clearly identifies the tool's function and distinguishes it from sibling query tools like get_extents or entity_length by positioning it as a first-step overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to 'call this FIRST to understand a drawing', providing clear timing and priority guidance. The word 'cheap' adds a practical reason for this ordering. It does not mention exclusions or alternatives, but for a zero-parameter tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. The verb 'List' clearly indicates a read-only, non-destructive operation, which is the key behavioral trait. However, it does not explicitly state side-effect-free behavior or output format, but the safety profile is evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. There is no wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with an output schema, the description is complete. It unambiguously identifies the resource type and scope, and the presence of an output schema covers return-value details. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema is fully described. The description adds no parameter-specific semantics, but none are required given the parameterless interface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('List') and the specific resource ('block definitions') within the drawing context. This distinguishes it from sibling tools like list_layers and list_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's use case (listing block definitions) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It states counterclockwise direction and Z-axis limitation, which are useful. However, it does not disclose whether the original entity is modified in place or if a copy is returned, nor does it mention prerequisites like a valid handle. Basic behavior is clear, but some transparency gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the verb and key information. No redundant details, every clause adds value regarding scope, direction, and alternative tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple rotation tool with an output schema, but lacks additional context such as whether the entity is mutated or a new entity is created, and does not mention the rotate_all sibling for bulk rotations. It covers the essentials but leaves some operational details undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the base point and angle in the context of the rotation operation, mapping to base_x, base_y, and angle. The handle parameter is implicitly covered by 'one entity (or 'selection')'. It adds meaningful semantics, though it does not explicitly name each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Rotate', the resource 'one entity (or 'selection')', and specific details: around a base point by angle degrees CCW. It also distinguishes from rotate_3d by noting the Z-axis limitation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context: rotate a single entity/selection in 2D. It gives an explicit when-not constraint ('Turns around Z only') and names an alternative tool ('use rotate_3d' for other axes). This meets the 'explicit when/when-not/alternatives' criterion.
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 provided, the description takes on the full burden of behavioral disclosure. It states that copied solids are erased, entries leave the manifest, and 'Masters are never touched'—important side effects and safety behavior. It doesn't mention reversibility or undo, but the core effects are adequately disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, leads with the primary action, and every sentence adds distinct value (purpose, effect, safety caveat). No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers the essential behavior: removal, scope via names, and preservation of masters. Minor omissions like undo behavior or error cases are acceptable given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'names' as an optional array or null, but the description adds crucial meaning: 'names=None clears the whole assembly'. This clarifies the default behavior and the role of the parameter beyond the schema's structural definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Remove instances from the assembly', a clear verb+resource statement that sets this tool apart from siblings like assembly_place and assembly_list. It further clarifies the scope by specifying that copied solids are erased and manifest entries are removed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: removing instances from an assembly, with names=None clearing the whole assembly. It does not explicitly list alternative tools or exclusions, but the purpose is clear enough to guide selection.
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 provided, the description carries the full burden of behavioral disclosure. It explains that by default it measures exact coordinates, and that snap=True changes behavior to snap onto nearby geometry, including the critical caveat of silently measuring the wrong distance. This is valuable beyond what the schema shows, but it does not discuss other potential behaviors like return values 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every clause adds value: the core functionality, the key parameter (line_x/line_y), the exact-coordinate behavior, and the snap warning. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, no schema descriptions, no annotations) and the presence of an output schema, the description provides enough context for correct invocation: what it does, how to position the dimension line, and the snap trade-off. It doesn't cover prerequisites like an open drawing, but that is likely shared with all sibling tools and not necessary for this tool's selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning to parameters. It explicitly explains line_x and line_y as 'dimension line position' and snap as a boolean controlling object snap, while 'between two points' and the coordinate names (x1, y1, x2, y2) implicitly define the remaining parameters. This compensates well for the lack of schema descriptions, though it doesn't exhaustively detail each coordinate parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Linear (horiz/vert) dimension between two points' which identifies the tool as a horizontal/vertical dimension tool, distinguishing it from siblings like dim_aligned, dim_radius, etc. The verb 'dimension' and resource 'two points' 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use snap mode ('handy to dimension existing entities') and warns about the risk ('can silently measure the wrong distance'). However, it does not explicitly compare with alternatives such as dim_aligned, leaving the differentiation to the 'horiz/vert' description rather than an explicit 'use this instead of X' statement.
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 the burden. It discloses a key behavioral quirk: 'The edge nearest the camera wins' and the requirement for points to lie ON each edge. It does not mention mutation/undo behavior, but the selected details are genuinely useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose and input format, real-world motivation, camera-picking caveat, and verification tip. Front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential operational details: how to specify edges, the camera dependency, and how to verify the result. An output schema is present, so return values need not be described. Minor gaps remain around radius units and edge cases, but overall it is a well-rounded description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the 'edges' parameter by specifying its structure ([[x,y,z], ...]) and the crucial requirement that each point lies ON an edge. Radius is left implicit, but its meaning is obvious from the tool name and schema; nevertheless, the description does not spell out units or per-edge behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Round edges of a 3D solid', a clear verb+resource that distinguishes it from sibling tools like fillet_polyline. It also specifies the exact input format for edges, leaving no ambiguity about what the tool operates on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains why a printed part needs this ('a sharp inside corner is where the part cracks'), providing context for when to use it. It also gives practical tips about setting the view and checking with solid_volume, but does not explicitly name alternatives or when-not conditions.
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 provided, the description carries the full burden of behavioral disclosure. It adds useful traits such as being 'cheap' and producing 'no screenshot', but it does not explicitly state that the operation is read-only or describe behavior on invalid layer names. This leaves some gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the core function and adds a usage note. Every word is informative, with no redundancy or filler, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers all essential aspects: what it returns, the scope (whole drawing or layer), and a key non-functional trait (no screenshot). The output schema likely handles return structure, so no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description directly explains the sole 'layer' parameter: an empty value (default) means the whole drawing, while a provided value targets one layer. This meaningfully complements the bare schema, which has no description and 0% coverage, by giving essential semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the bounding box of either the whole drawing or a single layer. It uses a specific noun phrase and distinguishes itself from rendering tools by explicitly stating 'no screenshot', which differentiates it from visual inspection tools like zoom_extents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a 'cheap spatial check', indicating it is suitable for quick geometric queries without rendering. It does not explicitly name alternative tools or provide when-not-to-use guidance, but the 'no screenshot' note helps clarify it is not for visual inspection.
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 the full burden of explaining behavior. It precisely describes the geometric relationship between the leader arrow and text placement, which is the key behavioral trait for a drawing annotation tool. It does not discuss side effects, but for a simple creation command this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core concept ('Leader arrow') and then explains coordinate semantics without wasted words. It is appropriately concise and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple annotation tool, the description covers purpose, parameter roles, and a usage example, making it reasonably complete. It omits potential details like coordinate system or units, but these are likely implicit in a drawing context, and the presence of an output schema (though not shown) reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly maps x,y to the feature, end_x,end_y to the text location, and text to the callout content, adding meaningful semantics to all five parameters beyond their bare names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating a leader arrow annotation, specifying that it points at (x,y) and places text at (end_x,end_y). It also provides a concrete example, '4x D10', which distinguishes it from generic draw or dimension 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'For callouts like 4x D10' gives a specific use case, implying when the tool is appropriate. However, it does not explicitly mention alternatives or when not to use it, which would be helpful given sibling tools like dimension and text commands.
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 the full burden for behavioral disclosure. It adds useful context about handle='selection' and the 3D scope, but it omits side effects, standard handle value semantics, and return behavior. This leaves some operational uncertainty, though core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the operation, parameter semantics, and a sibling comparison with no redundancy. The core specification is front-loaded, and every clause contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameter meanings, and an alternative tool, which is solid for a 4-param move operation. It doesn't explain full handle syntax or error handling, but the presence of an output schema may cover return details. Overall, the essentials for correct usage are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description must explain parameters on its own. It interprets dx, dy, dz as the displacement vector and provides one concrete handle meaning ('selection'), but the general handle format is not explicitly defined. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'move' with resource 'entity' and explicitly defines 3D displacement via (dx,dy,dz). It also distinguishes from sibling move_entity, which only shifts in the XY plane, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'move_entity only shifts in the XY plane' provides explicit comparative guidance, indicating that move_3d is the appropriate choice for translations involving the Z-axis. This clearly steers an agent toward this tool when a 3D move is needed.
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 the full burden. It discloses a pre-check (command existence validation) and token parsing rule ('' = Enter), which is useful. However, it does not warn that running arbitrary commands can modify or destroy the drawing, which is a significant safety omission for a generic command runner.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by key behavioral and selection notes. Every word earns its place—no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one array parameter) and the presence of an output schema, the description covers invocation, validation, and alternative tool preference. It could add safety caveats or error behavior, but the essentials are present. The output schema likely documents return values, so this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'tokens list' and the special meaning of an empty string as Enter, giving essential syntax semantics beyond the bare array schema. It lacks detailed examples but is adequate for understanding the primary usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Run any BricsCAD command.' It also distinguishes this generic tool from the many dedicated siblings by noting 'Prefer dedicated tools when they exist,' making the purpose and scope immediately apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-not-to-use guidance is provided: 'Prefer dedicated tools when they exist.' Additionally, the detail that the command name is checked to exist before sending conveys a safe usage pattern for trying arbitrary commands.
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 provided, the description carries the full burden. It discloses that the tool returns handles and that the user visually sees the selection, indicating a non-destructive UI-visible operation. It also mentions wildcard behavior, which is a useful quirk. It does not explicitly state whether the current selection is replaced or accumulated, but 'select' implies replacement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and scope, followed by return value and UI behavior. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple selection tool with two optional params and an output schema, the description covers the essential behavior: what it selects, how (wildcards), and what the caller gets (handles). It does not mention selection accumulation/replacement semantics, but that is a minor gap given the output schema and the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the two parameters. It does: 'by type and/or layer' clarifies both entity_type and layer, and the parenthetical example ('layer='MUR*'') demonstrates wildcard syntax. This compensates for the bare schema, though it does not separately document each parameter's exact matching rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: selects and highlights entities by type and/or layer, with wildcard support. It clearly distinguishes from siblings like select_window (spatial selection) and get_selection (retrieving current selection) by specifying property-based selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: selecting entities based on type or layer. It does not explicitly name alternatives or exclusions, but the mention of 'by type and/or layer' implies the niche relative to select_window. A brief note on when not to use it would improve this dimension.
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 to rely on, this description carries the full behavioral burden and does so excellently. It discloses that ONE point per edge is required, that the edge nearest the camera wins (view-dependent selection), and that the actual removed volume is slightly less than the idealized formula due to intersection with other edges. This is exactly the kind of non-obvious behavior an agent must know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, each earning its place: purpose, parameter format, selection caveat, and verification tip. It is appropriately dense without being bloated. A minor deduction because the volume formula might be overly technical for upfront placement, but the structure is still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3D solid chamfer with view-dependent edge selection), the description covers the critical operational context: edge specification, camera behavior, and practical validation. It doesn't spell out the exact meaning of 'distance' in words, but the output schema is present so return values are already handled. This is a well-rounded description for a non-trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides types (array of arrays of number for edges, number for distance) with no descriptions. The description adds meaning by explaining edges as [[x,y,z], ...] with one point on each edge, and infers the distance parameter via the volume formula (distance^2/2 * length). It doesn't explicitly define distance as the setback length, but the context makes it reasonably inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action ('Chamfer edges of a 3D solid') and clearly identifies the resource (edges of a 3D solid). It distinguishes itself from related tools like fillet_solid (rounded edges) and chamfer_polyline (2D), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage guidance: it compares 45-degree chamfers to fillets for print support, advises setting the view (view_3d) when the target edge is hidden, and recommends verifying with solid_volume. While it doesn't explicitly state when to use chamfer_solid vs. alternatives, these contextual tips clearly help an agent decide and operate correctly.
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 behavioral traits such as pagination, wildcard filtering, and optional type/layer filters. Since no annotations are provided, the description carries the full burden and does a good job, though it doesn't describe error conditions or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no fluff; all information is relevant and front-loaded. It includes the main action, filters, pagination, and a performance tip without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's purpose, filtering behavior, pagination, and a performance tip. Given an output schema exists, return values need not be explained. Overall, a complete and efficient description for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that entity_type and layer are optional filters capable of wildcards, and that pagination is controlled by limit/offset. This adds semantic meaning beyond the schema, which has no descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists entities with type, handle, and layer, and supports pagination and optional filtering. It distinguishes itself from sibling tools like get_entity and get_entity_counts by focusing on bulk listing with filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to run get_entity_counts first on large drawings, indicating a specific alternative and context. However, it doesn't mention other alternatives or when not to use this tool, so it's slightly incomplete.
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 the key behavioral trait: it sets the active drawing for all subsequent calls. With no annotations, this is valuable context. It could mention error behavior on no match, but the core state-change is explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and immediate behavioral consequence. No wasted words; every phrase contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple selector tool, the description covers what it does, how the parameter works, and the effect on future calls. The existence of an output schema (though not shown) means return values need no explanation. It is complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description compensates by explaining that the 'name' parameter matches on file name or any part of the path. This adds meaningful semantic detail beyond the raw string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's function: 'Choose which open drawing the tools act on.' The verb 'choose' and resource 'open drawing' are specific, and the description distinguishes it from sibling drawing tools by making its selector role 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context: 'Everything after this call lands there' indicates it should be called before other operations that target a specific drawing. While it doesn't explicitly name alternatives, the guidance is clear enough for an agent to know when to invoke 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?
With no annotations provided, the description carries the burden. It discloses the exact behavior: returning to top, wireframe, and zoom extents view. This is a complete behavioral description for a view-change operation, though it does not discuss potential side effects (e.g., whether it resets other viewport settings).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the action and the second gives usage context. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple view command with no parameters and an output schema, the description fully covers its purpose, behavior, and usage context. It integrates well with the sibling set by clarifying its role versus 3D and zoom tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter-level documentation is needed. The baseline for zero-parameter tools is 4, and the description adds no unnecessary detail about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Back to flat 2D view (top, wireframe, zoom extents).' This uses specific verbs and resources, and distinguishes it from siblings like view_3d (which switches to 3D) and zoom_extents (which only changes zoom).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use after 3D work' provides clear contextual timing for this tool. It does not explicitly name alternatives or exclusion conditions, but the context is sufficient for an agent to know when to invoke it relative to 3D operations.
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 present, so the description carries the full burden. It discloses the return format ('Returns OK n=<total> h=<created handles>') and reveals that operations can have side effects (e.g., the 'layer' op sets current layer). However, it does not state whether the batch is atomic, how errors are handled, or any permissions needed, which are notable gaps for a mutation-heavy tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and information-packed, opening with a clear directive and then systematically listing operation signatures. Every sentence serves a purpose, but the wall-of-text format with many operation types could be slightly better organized with line breaks or a table. It earns a high score for efficiency, but not perfect due to readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many op types) and the absence of annotations or schema descriptions, the description provides essential operational detail and return values. It does cover the core functionality well, but omits edge-case behaviors like error handling, batch limits, ordering semantics, or coordinate/unit conventions. These are likely domain-known but still represent minor completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'operations' as an array of objects with additionalProperties true, providing zero semantic detail (schema description coverage 0%). The description compensates thoroughly by enumerating every operation type with its parameters, including optional ones like '[snap]' and clarifying notes for 'symbol', thus giving the agent complete parameter-level knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Execute many drawing ops in ONE call' and explicitly distinguishes it from single drawing tools by advising 'ALWAYS prefer this over single tools for 3+ entities.' It also lists all supported operation types, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'ALWAYS prefer this over single tools for 3+ entities.' This directly tells the agent when to choose this tool over the many sibling drawing tools, satisfying the criteria for strong usage guidelines.
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 the full burden and excels: it discloses the probe geometry, the throwaway copy, what counts as blocked, volume as blockage measure, one-round-trip execution, and that the part is never modified. This is exemplary 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by mechanics, a motivating anecdote, and a safety note. It is longer than strictly necessary—the 'born from' story could be trimmed—but it remains focused and each part contributes context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, this description is remarkably complete. It covers the algorithm, side effects, performance, use case, and parameter semantics in a way that an agent can confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description deeply explains the 'holes' parameter with its field meanings (name, x,y,z, axis, r, len) and the constraint that r is smaller than the hole's radius. However, it ignores 'handle' entirely, and schema coverage is 0%, so the missing handle is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource: 'Probe every hole of a part and say which are actually OPEN.' This immediately distinguishes it from sibling analysis tools like contact_report or overhang_report by focusing on hole verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete scenario ('a drawing lies about its holes unless something physically probes them') that implies when to use this tool, but it does not explicitly name alternatives or exclusion criteria. That fits 'clear context, no 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?
With no annotations, the description carries the full burden. It adds the important right-hand rule convention and the ANY axis capability, which are critical behavioral details not in the schema. However, it does not mention potential side effects (e.g., transformation behavior, undo semantics), so there is some gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main function, and no redundant wording. The description is efficient and every phrase adds value, including the right-hand rule and the comparison to rotate_entity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no annotations, the description is nearly complete: it defines the axis, angle convention, and usage context. It does not describe the output/return value, but an output schema exists. The only minor gap is that 'handles' is not explicitly described, though this may be inferred from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains x1,y1,z1,x2,y2,z2 as defining the rotation axis, and angle as degrees. It does not explicitly explain 'handles', but that term is common across sibling tools. The description covers 7 of 8 parameters meaningfully, which is strong given the schema lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Rotate entities around ANY axis: the line (x1,y1,z1)->(x2,y2,z2), by angle degrees (right-hand rule).' It specifies the verb (rotate), the resource (entities), and the axis definition, while explicitly distinguishing it from sibling rotate_entity, which can only rotate around Z.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with rotate_entity: 'rotate_entity can only turn around Z.' This tells the agent when to use this tool (for rotations about arbitrary axes) and when to use the alternative. It also provides a concrete use case ('swing a part about a hinge'), giving clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains side effects: the master stays in place, the copy is moved and rotated, and an instance is recorded in a manifest. It also clarifies the anchor semantics, giving the agent important information about how placement coordinates are interpreted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the action and packs a lot of useful information into two sentences. It is slightly verbose with the metaphorical 'sentence these copies belong together' but overall each clause adds value, making it well-structured and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no schema descriptions, and no annotations, the description is remarkably complete. It covers what the tool does, how parameters interact, the side effect on a manifest, and the conceptual purpose of assembly. Since an output schema exists, not detailing return values is acceptable. This is a complex tool handled very well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for any parameters (0% coverage), so the description must compensate. It explicitly explains all parameters: x/y/z as landing coordinates, name as the manifest record key, rot_z as rotation about the anchor point, anchor with its 'min' and 'center' values and a practical use case, and master_handle as the master part. This is exemplary compensation for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places a copy of a master part into the assembly, using the specific verb 'Place' and identifying the resource ('assembly'). It distinguishes itself from sibling tools by emphasizing the COPY behavior and the registration/pose aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool: when you need assembly semantics (copies belonging together) that a bare drawing cannot express, and it explicitly mentions that contact_report and assembly_list read the manifest created here. However, it does not explicitly list alternative tools or when NOT to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and succeeds: it discloses the algorithm (bounding boxes first, then real intersection on throwaway copies), non-destructiveness via throwaway copies, verdict semantics, and limitations (box gap is a lower bound, leading to possible false CONTACT on diagonal near-misses).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and fully front-loaded with the core purpose. Every sentence contributes either algorithmic detail, verdict definitions, or an accuracy caveat; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full workflow, verdict meanings, orphan implications, and a numerical limitation. Since an output schema exists, return-value details are not required here; the description is complete for an agent to select and confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that 'clearance' is the bounding-box proximity threshold initiating the expensive intersection step, adding meaning beyond the bare schema. It doesn't specify units or valid range, but the default in the schema and the contextual explanation suffice for this single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: determining which instances in an assembly touch, interfere, or contact nothing. It distinguishes itself from sibling assembly/intersection tools by defining specific verdicts (INTERFERENCE, CONTACT, CLEAR, ORPHANS) and the assembly-wide scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening 'Who touches whom in the assembly' provides clear context for when to use this tool. It gives guidance on interpreting CONTACT vs INTERFERENCE and what ORPHANS mean, but it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: handles=None exports every solid, to_origin parks the part and 'puts it back afterwards', and quality affects tessellation. The STL world-coordinate pitfall is explained, providing excellent transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then adds behavior details without fluff. Every sentence earns its place, and it remains compact despite covering multiple parameters and gotchas.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary context for an export tool: what it does, parameter effects, output considerations, and a critical coordinate-system gotcha. With an output schema present, no additional return-value explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains handles, quality, and to_origin, adding significant meaning. Path is self-explanatory, and binary is not explained, but the description covers the most nuanced parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export 3D solids to STL' with the specific purpose of generating a file for a slicer to 3D print. This is a specific verb+resource and distinguishes itself from sibling export tools like export_pdf and export_dxf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the tool is for 3D printing and explains parameter usage (handles=None exports all, quality settings, to_origin). However, it does not explicitly mention alternatives or when NOT to use this tool, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It clearly states the caching side effect ('cache it'), the report contents ('networks, junctions, total length, and the open ends'), the T-junction vs. break classification logic, tolerance behavior via the 'max-jump rule,' and that 'lengths are exact' in drawing units. This is comprehensive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but highly information-dense. It is front-loaded with the core purpose, then details behavior and parameters. Every sentence adds meaningful value (e.g., tolerance rule, report details, units). It could be slightly more concise (e.g., splitting into separate sentences for parameters), but it earns its length given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (graph analysis with tolerance, break detection, caching), and the description covers all major aspects: what it reports, how tol works, window/layer scoping, exactness of lengths, and the defect-detection purpose. The output schema exists, so detailed return structures need not be repeated. This is complete 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It does: tol's default behavior and override semantics ('tol=None (the default) makes the joining tolerance EMERGE... pass a number only to override'), window's format and scope ('window=[x1,y1,x2,y2] limits it to one drawing area'), and layer's scope ('layer to one layer'). This goes well beyond the schema's bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read the 2D geometry as a CONNECTIVITY GRAPH and cache it.' It clearly defines the tool's purpose as converting geometry into a graph structure and analyzing it, distinguishing it from sibling drawing/analysis tools like graph_trace or entity_length by emphasizing the connectivity graph and break detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong context for when to use the tool: 'so the drawing can be asked questions instead of read' and 'which on a schematic is the defect you were looking for.' It implies a schematic-checking use case. However, it does not explicitly name alternatives or state when not to use it, so it misses the 'exclusions' aspect of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool reads the cached index, does not read the drawing, and explicitly says it reports if no cache is found. This makes the cache-dependence and failure behavior transparent, which is critical for correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: one sentence defines the action and outputs, one gives concrete sample queries, and one provides a critical caveat about stale caches. There is no fluff, and the most important behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (network tracing, cache dependency), the description covers the core behavior, expected outputs, use cases, and limitations. It directs users to rebuild with graph_build if needed, and the output schema already exists for return values. This is complete for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'from a point', which hints that x and y define a location, but it does not explicitly map x/y to that point, nor explain units or coordinate system. This adds some meaning beyond bare numbers but is insufficient for a 0%-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool follows the network from a point through the graph_build cache, and lists concrete outputs (curve count, total length, open ends). It also distinguishes itself from the sibling tool graph_build by explicitly mentioning 'Rebuild with graph_build if the drawing changed', making its unique resource and scope 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly answers when to use the tool ('what is downstream of here', 'is this the same run as that') and gives an alternative: 'Rebuild with graph_build if the drawing changed'. This provides clear when-to-use and when-to-avoid guidance, including a named alternative 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 carries the full burden, and it delivers: it discloses flushing the reactor queue, removing all lambdacad memory reactors application-wide, stopping bracketing, and confirming tags/journal files stay untouched. This is rich, non-destructive behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by a compact paragraph of essential behavioral details. Every sentence contributes meaningful information without redundancy, making it appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no annotations, the description covers purpose, side effects, scope (application-wide), and exceptions (tags/journal files untouched). The existence of an output schema handles return values, so this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds semantic value by explaining what 'disable' does beyond the schema, making the empty schema irrelevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Turn the drawing's memory journal OFF, cleanly,' which is a specific verb+resource statement. It further clarifies the scope (application-wide) and the action (flushing, removing reactors), clearly distinguishing it from sibling tools like memory_enable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is for disabling the memory journal and provides context about the cleanup process, but it does not explicitly mention alternatives (e.g., memory_enable) or state when not to use it. This meets 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It transparently describes the reactor registration, journal-file side effect, ability to capture GUI/user edits, and persistence across sessions. This exceeds the typical 'enable' description by revealing the full operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action, followed by the mechanism, persistence, and next-step guidance. Every sentence contributes meaningful information without filler or repetition, making it both concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-enabling tool with no annotations, the description is complete: it covers purpose, mechanism, persistent side effects, call frequency, and integration with downstream tools. An output schema exists, so omitting return-value details is acceptable. The only minor gap is not naming memory_disable explicitly, but the sibling list covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there are no parameter semantics for the description to clarify. Per the baseline rule for zero-parameter tools, a score of 4 is appropriate; the description adds no param detail because none exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear action verb and resource: 'Turn ON the drawing's autonomous memory journal.' It then explains the mechanism (registers a database reactor that appends entity events to a journal file), distinguishing it from drawing-creation and editing siblings. It also points to related tools like memory_disable, tag_entity, and world_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'call it once per CAD start' and explains the intended workflow ('Then use tag_entity ... and world_report'). However, it does not explicitly state when not to use it or name an alternative, such as memory_disable, even though that sibling exists. The guidance is strong on 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.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Psalmustrack/lambdacad-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server