AutoCAD MCP Ultra

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation1/5
Several tools are near-duplicates (block_insert vs entity_create_block_ref, system_run_lisp vs lisp_execute_code), and save/export and selection/query families overlap heavily (drawing_save vs drawing_save_as vs drawing_export_dxf; selection_window/polygon/filter/entity_select_smart/analysis_select_*). At 162 tools, an agent cannot reliably pick the intended tool without reading every description.
Naming Consistency3/5
The server mostly uses readable snake_case and strong domain prefixes (drawing_, entity_, layer_, block_, dimension_), but the verb/object order and granularity vary: block_list vs block_create_from_entities, entity_create_block_ref vs block_insert, selection_window vs entity_select_smart, and drawing_audit vs validation_check vs drawing_critique. It is not chaotic, but the consistency is only partial.
Tool Count1/5
162 tools is far beyond the 25+ threshold and well into extreme-mismatch territory for a single server. The surface mixes core CAD primitives with highly specialized one-off workflows (gear drawings, P&ID, Grasshopper, ISO title blocks), forcing enormous tool-selection overhead.
Completeness4/5
Core CAD lifecycle coverage is broad: files, entities, layers, blocks, text, dimensions, hatches, layouts, viewports, selection, transactions, validation, and export are all represented, and most create/read/update/delete paths are complete. Minor gaps exist (no rename for layers/blocks, no dimension text editing, limited geometry editing for polylines/splines), but agents can usually work around them by delete/recreate.
Average 3.9/5 across 162 of 162 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only annotation is destructiveHint=false, and the description does not disclose whether the tool creates drawing entities, modifies the current drawing, or depends on an open document. It does not clarify placement behavior, units, or side effects beyond stating what the view is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise and easy to parse, though it is so minimal that brevity comes at the expense of useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, four required, and zero schema descriptions, a single noun phrase is not enough for an agent to invoke the tool correctly. The description omits parameter relationships, units, optionality semantics, and any behavior context, leaving a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the six parameters. It does not explain required inputs like center_x, center_y, bore_diameter, and face_width, nor the optional keyway_depth and keyway_width, so it adds no meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool produces a 'Side cross-section view of a keyed bore', which clearly identifies the resource and the specific view orientation. It lacks an explicit verb, but the intent is clear and it is distinguishable from the sibling keyway_draw_keyed_bore by the 'side section' framing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of alternatives such as keyway_draw_keyed_bore or gear_draw_section_aa. The description does not mention prerequisites, common 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.
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 high-level purpose. It does not mention side effects, whether geometry is modified or baked, required CAD state, or what happens to the pipeline after building.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler or repetition. It is front-loaded with the verb and resource, though it could have used the brevity to add a bit more operational specificity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, four undocumented optional parameters, and no annotations, the description is far from complete. While an output schema exists and may cover return values, an agent still lacks enough information to know what 'operations' should contain, how layers are used, or what the pipeline build entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for any of the four parameters: color, operations, source_layer, and target_layer. Parameter names hint at their roles, but the description does not compensate for the complete lack of schema documentation, especially for the vague 'operations' object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Build') and a specific resource ('structured Grasshopper computational pipeline'), and indicates the tool bridges AutoCAD geometry and parametric algorithms. It is distinct from the more granular gh_cad siblings, though it does not explicitly name or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus related gh_cad tools such as gh_cad_set_param_and_solve or gh_cad_tracked_bake. There are no prerequisites, exclusions, or alternative conditions described.
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 behavior. 'Query' implies a read-only operation, but the description does not state whether it has side effects, whether it reads from the current document or a static catalog, or what the output contains. The existence of an output schema helps, but the description itself adds minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler and the core subject front-loaded. It loses a point because it is so terse that it omits parameter semantics and usage guidance, but as a concise opening statement it is well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter query tool with no annotations, the description is incomplete. It does not explain what search and subcategory do, what kind of results are returned, or how this query relates to the other gh_cad workflow tools. The presence of an output schema covers return structure, but the input semantics and workflow context remain missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. The two parameters, 'search' and 'subcategory', are completely unexplained; the description does not mention filtering, accepted values, wildcard behavior, or how they relate to the 87+ components. An agent would have to guess at the meaning and format of both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query') and the resource ('87+ AutoCAD Grasshopper battery components from Rhino.Inside.AutoCAD'). The resource is specific enough to distinguish it from the many drawing and entity tools. However, it does not explicitly contrast with sibling gh_cad tools like gh_cad_build_pipeline or gh_cad_set_param_and_solve, leaving some differentiation to inference from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for discovering available components before building a Grasshopper pipeline, nor does it name any sibling tool as an alternative. Usage context is only weakly implied by the tool name and sibling list.
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 only indicate readOnlyHint=false, so the description carries most of the burden for behavioral disclosure. It does not state whether the leader is added to the active drawing, what happens if the drawing is not ready, or what the implementation-level distinction between COM and ezdxf means for the caller. The 'explicitly-labelled' phrase hints at a tagging behavior but never explains it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is front-loaded with the core action, so it is concise. However, it is under-specified: jargon such as 'native COM' and 'explicitly-labelled ezdxf composite' is included without explanation, which sacrifices usefulness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A multileader creation tool with six parameters needs more context than this. The description does not explain the two creation modes, the expected coordinate system, drawing state requirements, or the meaning of the labelled composite. Even though an output schema exists and would document return values, the callers still lack enough information to predict behavior and choose parameters confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds nothing about parameters. Three fields (arrow_size, landing_gap, text_height) have no schema descriptions, and the tool description does not compensate by explaining their units, defaults, or interactions. The schema's existing descriptions for text, layer, and points are clear, but the missing fields remain ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear verb and resource: it creates a multileader, and the MLeader concept is distinct from the sibling drawing/entity tools. However, the 'native COM MLeader or an explicitly-labelled ezdxf composite' phrasing introduces ambiguity about what the caller will actually get, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over entity_create_text, entity_create_mtext, dimension_auto, or other annotation tools. The description implies the use case only through the tool name and title, but gives no context, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Drive', without stating whether this mutates the drawing, requires an existing dynamic block, how the sync behaves, or what side effects occur. This is a significant transparency gap for a tool that likely modifies block state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant phrasing. It is front-loaded with the core action and resource, though additional structured detail would have improved it without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—a nested properties object, zero schema coverage, no annotations, and an output schema—the description is too sparse. It omits preconditions, property formatting, return behavior, and how Grasshopper definitions map to block properties, leaving an agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'block_name' parameter or the structure of the 'properties' object. It offers only a conceptual hint that properties relate to AutoCAD dynamic blocks and Grasshopper parameter definitions, but it does not describe value formats, mapping semantics, or required keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Drive'), target ('AutoCAD dynamic block properties'), and mechanism ('via Grasshopper parameter definitions'), which distinguishes it from general CAD drawing tools. However, 'Drive' is somewhat vague—it does not clarify whether this reads, writes, or synchronizes properties—so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for controlling dynamic block properties through Grasshopper parameter definitions, but it gives no explicit when-to-use guidance, no exclusions, and no mention of alternatives like gh_cad_set_param_and_solve. The usage scenario is inferable but not 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 provided, the description carries the full burden of behavioral disclosure. The words 'arbitrary' and 'directly' hint that execution is unrestricted and in-process, which implies destructive potential, but the description never discloses side effects, safety risk, error handling, or impact on the current drawing/session. For an arbitrary code execution tool, this is a significant transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 8-word sentence with zero wasted words and the core action front-loaded immediately. It is admirably concise, though arguably under-sized for a tool with the risk profile of arbitrary code execution — every word earns its place, but more words were warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema presumably covers return values, so that is not the gap. But for a high-complexity, high-risk tool with zero annotations, the description omits side-effect disclosure, error behavior, and selection context versus sibling tools. It conveys only the basic function, leaving an agent without enough context to call it safely or route to alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does clarify that the lone 'code' parameter holds AutoLISP code, naming the language the schema omits. However, it adds nothing about expected format (expression vs. full program, multiline handling, escaping) or how results map to the output schema, leaving the compensation incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Execute arbitrary AutoLISP code directly inside AutoCAD 2024+.' It clearly communicates the action, target, and version requirement. However, it does not differentiate from the closely overlapping sibling 'system_run_lisp', which likely also executes LISP routines, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the highly relevant siblings 'system_run_lisp' and 'lisp_load_macro'. The description gives no selection criteria, no exclusions, and no context on when raw code execution is preferable over higher-level alternatives. It is simply a bare statement of capability.
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, but it only states the basic action. It never discloses whether a new entity is created, whether existing geometry is modified or destroyed, whether a drawing must be open or in a P&ID mode, or what drawing side effects occur (e.g., layer usage, tag placement). The mention of 'flow arrow and pipe specification tag' is the only behavior beyond the tool name, leaving safety and side-effect questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero filler; the verb 'Route' leads and every word contributes. Given the 0% schema coverage and seven parameters, a second clarifying sentence about line_number or routing behavior would have been justified without harming conciseness, which is why it is not a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity — seven parameters, four required, no annotations, and zero schema parameter descriptions — so the entire context burden falls on this one sentence. It omits when to choose this over entity_create_line, what routing produces geometrically (straight vs. orthogonal), and the meaning of line_number, though the presence of an output schema does reduce the return-value burden. For an agent selecting among a large CAD/P&ID toolset, this is not complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only maps flow_arrow and pipe_spec to real-world concepts ('flow arrow', 'pipe specification tag'). The four coordinate parameters are self-naming, and the default '4"-CS150' hints at pipe_spec format, but line_number's semantics (display format, usage, relationship to the tag) are entirely unexplained. This partial compensation keeps it above a 1 but well short of adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Route') with a clear resource ('a P&ID process line') and names distinctive features (flow arrow, pipe specification tag). It is the only pid_route_* tool among siblings, so it is readily distinguishable from the pid_insert_* symbol tools and generic entity_create_line. It loses the fifth point only because it never explicitly contrasts itself with entity_create_line for generic line work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given, and no sibling alternative is named. The intended context is implied by the P&ID domain prefix and the phrase 'process line' — an agent would infer it is for process-line routing on P&ID drawings. Among 100+ siblings including entity_create_line and the pid_insert_* family, richer routing guidance would have helped but the implication is sufficient for a 3.
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 annotations already flag destructiveHint=true, and the description adds useful context by noting the loop is bounded and transaction-safe. However, it does not clarify what 'transaction-safe' means in practice—whether the tool starts its own transaction, requires transaction_begin/commit, or rolls back on failure—or what side effects a repair has on 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence conveys the core behavior without filler. Every word adds meaning: 'bounded' hints at max rounds, 'transaction-safe' signals safety, and 'critique/repair/re-critique' describes the loop.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and parameter descriptions, the tool definition is incomplete for a complex mutation tool. It does not explain how dry_run interacts with the loop, what triggers completion (min_score, max_rounds), or how transactions are scoped, leaving an agent uncertain about correct invocation and rollback behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meaning, and schema coverage is only 60%, leaving min_score and max_rounds undocumented in the schema. Focus, dry_run, and allowed_repairs have schema descriptions, but min_score's threshold meaning and max_rounds' relationship to the loop are not clarified; the vague 'bounded' in the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: it runs a bounded critique/repair/re-critique loop rather than a one-shot critique, which distinguishes it from drawing_critique. It could be more explicit by naming sibling tools such as drawing_critique or drawing_plan, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus drawing_critique, drawing_preflight, or drawing_plan, and no exclusions or alternatives are named. The reader must infer that the loop is meant for iterative refinement; the description does not state this directly.
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 provide only the title, so the description carries the full burden of behavioral disclosure. It states the save operation but does not disclose overwrite behavior, whether the current file is replaced, what happens if the file already exists, or whether the operation is destructive. For a mutation-like operation, this is a meaningful 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the only parameter-related detail is stated efficiently. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter tool with an output schema, so the description does not need to explain return values. However, the lack of differentiation from drawing_save_as and the absence of any mention of overwrite or default-path behavior leave the description slightly incomplete for an agent selecting between sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'path' parameter, so the schema already documents its behavior well. The description adds the phrase 'specify a new path,' which is mildly useful but largely redundant with the schema's 'Optional save path; uses current path if omitted.' This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save the current drawing') and the optional path parameter. However, it does not explicitly differentiate this from the sibling drawing_save_as, which appears to serve a very similar purpose when a new path is specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use drawing_save versus drawing_save_as, nor any mention of what happens when omitting the path versus specifying one. The phrase 'Optionally specify a new path' actually blurs the line with drawing_save_as, so an agent cannot confidently decide which tool to invoke based on the description 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?
Annotations only declare readOnlyHint=false, so the description carries the burden of behavioral disclosure. It states that a closed boundary polygon is required, but it does not explain what happens if the boundary is not closed, whether the boundary is consumed or preserved, or what side effects occur beyond creating the hatch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant phrasing. It front-loads the core action and resource, and every word contributes meaning. There is no unnecessary detail or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents parameters and an output schema exists, so return-value documentation is not needed. However, the description does not help an agent navigate the many related hatch and entity-creation tools, nor does it clarify behavioral requirements like boundary validation. It is minimally viable but leaves selection and edge-case reasoning to the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented with meaningful descriptions. The function description adds no parameter-level detail beyond what the schema provides, which is acceptable but not additive. The baseline of 3 applies because the schema handles parameter semantics completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create') and resource ('hatch fill pattern') with a meaningful scope qualifier ('inside a closed boundary polygon'). It clearly signals creation rather than editing or modifying, which distinguishes it from tools like hatch_edit or hatch_set_gradient, though it does not explicitly name any sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when this tool should be used instead of related hatch tools such as hatch_add_boundary, hatch_set_gradient, or hatch_edit. The phrase 'inside a closed boundary polygon' implies a prerequisite, but the description does not say when to prefer this tool over alternatives.
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 annotation readOnlyHint=false already signals mutation, so the description is not required to restate that. It adds minor behavioral context by revealing the two possible table representations (COM vs ezdxf composite), but it does not explain what 'explicitly-labelled' means or how the choice is made, and it says nothing about side effects or coordinate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and gets straight to the point. However, the phrase 'explicitly-labelled ezdxf composite table' is dense and may require unpacking, so it is not perfectly clear despite being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameter details and an output schema exists, the description fails to clarify the operational distinction between the two table types or when each is produced. For a 9-parameter creation tool, this missing behavioral context is a notable gap that an agent would need to resolve to use the tool fully correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 78% and every parameter has its own description, so the schema carries the parameter-level burden. The tool description adds no parameter-specific meaning beyond the schema, which is acceptable given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Create') and a specific resource ('table'), distinguishing it from the many entity_create_* siblings like line, circle, and text. The clause about native COM vs ezdxf composite table adds specificity, though the jargon may be opaque to agents unfamiliar with the CAD library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other entity creation tools, nor any mention of prerequisites or conditions determining whether to create a COM table versus an ezdxf composite table. The description leaves usage entirely to inference.
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?
Annotations only provide destructiveHint: false, so the description carries most of the burden. It adds 'Deterministic' (repeatable output) and 'no helix symbol' as behavioral traits beyond the annotations, but discloses nothing about whether geometry is created in the drawing or how the output behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler; the key differentiator is placed compactly. It is appropriately short, though borderline under-specified as a noun phrase rather than an actionable statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, a drawing-creating tool, and minimal annotations, the description is too thin: no guidance on geometry placement, units, or what gets inserted into the drawing. The output schema covers return values, but the agent is left to infer most behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about any of the 8 parameters (module, teeth, center_x, keyway, bore, pressure_angle). Parameter names are self-explanatory, but the description fails to compensate for the total lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (spur gear front view) and a distinguishing trait (no helix symbol), which separates it from gear_draw_helical_front_view. However, it lacks an explicit verb like 'draws/creates', leaving the action implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(no helix symbol)' implies that helical gears with a helix symbol belong to gear_draw_helical_front_view, but no alternative is named explicitly and no when-to-use/when-not-to guidance is 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?
Annotations provide only a title, so the description carries the full burden of behavioral disclosure. 'Activate' implies a state change but does not clarify whether this switches between Model and paper space, affects subsequent commands, or is non-destructive. This is thin for a tool that changes the active drawing context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single four-word sentence that is entirely meaningful and front-loaded. There is no wasted text or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with a fully documented schema and an output schema present, the description covers the core invocation semantics. However, it omits useful context such as requiring an existing layout tab, how to discover valid names, and the effect of switching the active layout on later operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter name and description already explaining that it accepts 'Model' or a paper-space layout name. The tool description adds no parameter-level information, but the schema is sufficient, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Activate a layout tab' states a specific action and resource, clearly matching the tool name and title. It is distinguishable from layer_set_current and layout_create/layout_delete because it concerns activating an existing layout tab, though it does not explicitly reference 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as layout_list to discover layout names, layout_create if the layout does not exist, or viewport_set_scale for paper-space adjustments. No exclusions or contextual triggers 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the insertion action but does not explain coordinate reference, insertion point behavior, layer placement, units, default symbol behavior, or what happens in the current drawing upon insertion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The parenthetical valve-type list is the only extra content and it earns its place by enriching valve_type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a CAD symbol insertion tool, the description omits important context such as coordinate system, insertion semantics, layer behavior, and prerequisites. The output schema exists but does not substitute for missing placement and drawing-context guidance, and no annotations are present to cover safety or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only partially compensates by listing gate, globe, check, ball, and butterfly, which helps clarify valve_type. However, it provides no semantic meaning for x, y, size, or rotation, leaving five parameters mostly unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Insert'), a specific resource ('ISA 5.1 process valve'), and enumerates the supported valve varieties. This clearly distinguishes it from sibling tools such as pid_insert_pump, pid_insert_tank, and pid_insert_instrument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to prefer this tool over alternatives, nor does it mention when not to use it. Context must be inferred entirely from the tool name and sibling list; there is no explicit or implicit usage context beyond 'insert a valve'.
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?
Annotations declare readOnlyHint=false, so the agent already knows this mutates state; the description's 'insert' verb is consistent and adds no contradiction. The parenthetical adds useful behavioral context that the block definition must already exist, but it does not cover error handling, layer defaulting, or behavior for a nonexistent name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 15-word sentence with the verb front-loaded and zero filler. It is efficient, though the saved space could have carried sibling differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and 100% parameter coverage carry most of the load for this moderate-complexity tool. The main gaps are the ambiguous relationship with block_insert and unstated failure behavior when the named definition does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all seven parameters are already documented in the input schema, placing the baseline at 3. The description adds no parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Insert a block reference') and the parenthetical clarifies the operation creates an instance of an existing definition rather than a new definition. However, it does not differentiate from the closely named sibling block_insert, so an agent scanning the tool list could pick the wrong one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus block_insert or block_create_from_entities. There are no usage conditions, prerequisites, or exclusions anywhere in the description.
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 states that the macro is loaded and executed but does not mention potential side effects on the drawing, authorization requirements, or the implications of running arbitrary LISP code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler. Every word contributes to defining the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool loads and executes code, the description lacks important context about side effects and fails to differentiate it from lisp_execute_code or system_run_lisp. The output schema may cover return values, but the description alone is insufficient for safe and correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for file_path (0% coverage), so the description must compensate. It does add meaning by specifying that the parameter is an external .lsp AutoLISP macro file, but it leaves out path format, resolution, or validation details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Load and execute') and the target resource ('external .lsp AutoLISP macro file'), so the core purpose is unambiguous. However, it does not explicitly distinguish itself from similar siblings like lisp_execute_code or system_run_lisp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an external .lsp file path is available, but it gives no explicit guidance on when this tool should be preferred over alternatives. Siblings such as lisp_execute_code and system_run_lisp exist, leaving the agent to infer the file-based distinction.
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 readOnlyHint annotation already declares the read-only nature, and the description adds no behavioral detail beyond that, such as behavior for unknown variables, return formatting, or error handling. There is no contradiction, but also no additional transparency value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler words or redundant information. It is appropriately sized for a simple one-parameter read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set, readOnlyHint annotation, and presence of an output schema, the description is largely sufficient for an agent to call the tool correctly. It is missing only a brief note about when to prefer this over system_set_variable or system_status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter 'name' includes concrete examples like DIMSCALE and LTSCALE. The description itself does not discuss parameters, so it relies entirely on the schema, which is sufficient for a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get') and a clear resource ('AutoCAD system variable value'), making the tool's purpose immediately understandable. It does not explicitly distinguish itself from system_set_variable or other sibling tools, but the get/set contrast is strongly implied by the verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as system_set_variable, system_status, or system_capabilities. It only restates the basic operation without giving context, preconditions, 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?
The description discloses that the tool creates a drawing entity, which is consistent with readOnlyHint=false. It adds the ISO 129/ISO 286 tolerancing context, which is useful. It does not describe side effects or constraints like fit being mutually exclusive with tol_*, but the schema already covers those 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds meaning: the action, the entity type, and the optional tolerance capability are all conveyed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents all 13 parameters and an output schema exists, so invocation details are largely covered. However, the description is too terse to fully contextualize tool selection given the large sibling list, especially the close neighbor dimension_aligned. It is adequate but leaves the selection guidance gap to the agent's inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds a small amount of high-level context by mentioning ISO 129 and ISO 286 fit, which helps interpret the tolerance-related parameters, but it does not meaningfully extend what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Create a linear dimension.' It also notes optional tolerancing, which adds useful scope. However, it does not explicitly differentiate itself from the sibling dimension_aligned tool, relying on the name alone for that 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like dimension_aligned, dimension_angular, or dimension_radius. The description implies its use by naming 'linear dimension' but provides no conditions, exclusions, or comparison to sibling 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?
The annotations block appears to duplicate the input schema and provides no standard hints like readOnlyHint or destructiveHint. The description only states that a point marker is created; it does not disclose coordinate system assumptions, current-layer behavior, units, or whether anything is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the key action and positional arguments front-loaded. There is no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool, the description plus schema is mostly adequate: required coordinates and optional styling parameters are covered. However, with no meaningful annotations and no output schema, return behavior, coordinate system, and current-drawing side effects are left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all parameters, including defaults for color and layer. The description adds only that the point is created at (x, y), which is essentially restating the schema's parameter descriptions. No additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('point marker entity') and includes the key positional arguments (x, y). This clearly distinguishes it from sibling entity creation tools like entity_create_line or entity_create_circle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as point_from_snap or other entity_create_* tools. There are no exclusions, prerequisites, or context cues to help an agent choose correctly.
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?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's job is to add context beyond that. 'Create a parallel copy' usefully implies the original entity is preserved, and the line/circle/polyline scope is stated. However, it does not disclose how the offset side is determined when side_x/side_y are omitted, what happens for unsupported entity types, or whether the new entity is selected afterward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 15-word sentence that front-loads the verb and resource, then specifies the operand types and the distance qualifier. Every word carries meaning; there is no filler, redundancy, or buried critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations cover the safety profile, the core operation is adequately stated. The main gap is the ambiguous interaction between the sign of distance and the optional side_x/side_y point: the description does not clarify which takes precedence or what happens when a side point is omitted. For a moderate-complexity tool, this is a meaningful but not crippling omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents handle, distance, side_x, and side_y. The description contributes nothing about parameters beyond the schema's 'positive = outward/right' distance semantics. Per the rubric, the baseline of 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('a parallel copy of a line, circle, or polyline'), and the phrase 'parallel copy... at the given distance' captures the essence of offset in a way that inherently distinguishes it from sibling operations like entity_copy, entity_move, or entity_mirror. It does not explicitly name sibling alternatives, so it stops just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as entity_copy, entity_mirror, or entity_move. There are no exclusions, prerequisites, or scenarios mentioned. The agent must infer appropriate usage entirely from the tool name and the sibling list.
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 disclosure burden. It does reveal the key behavioral chain — setting the slider triggers a re-solve and a live TrackedBake update — but it does not disclose side effects such as whether prior baked geometry is overwritten, whether the operation is reversible, or what happens when auto_bake=false. For a mutating tool on a live drawing, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One 14-word sentence with zero filler; the action is front-loaded before the consequence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be documented. However, the description omits prerequisites (a pipeline built by gh_cad_build_pipeline, a valid slider name) and the meaning of auto_bake=false, leaving an agent to guess about important behavior for a tool that mutates a live CAD session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps 'slider' to slider_name and the 'TrackedBake update' to the value/auto_bake effect, but pipeline_id is never explained and no parameter is explicitly defined beyond what the bare schema names. Partial compensation is present, not full.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set a Grasshopper parameter slider') with a clear resource and adds the behavioral consequence ('re-solve with live AutoCAD TrackedBake update'). It is clearly distinguishable from siblings like gh_cad_build_pipeline or gh_cad_tracked_bake, though it never names those alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the Grasshopper-CAD siblings (gh_cad_build_pipeline, gh_cad_tracked_bake, gh_cad_query_components). No prerequisites, exclusions, or alternative conditions are stated — an agent must infer that a pipeline and slider must already exist.
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 says the tool 'register and track' handles and mentions idempotency, but it does not clarify side effects, whether it modifies drawing state, how duplicate group_ids are handled, or what state the tool maintains. This is too thin for a stateful registration tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the core purpose without filler. Every word contributes meaning, and the key concept of idempotent tracking is placed at the end for impact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, this is a stateful tracking tool with no annotations and zero parameter-level documentation. The description leaves out critical operational context: what group_id represents, how layer factors into baking, and how tracked handles enable idempotent updates. An agent would need more information to invoke it correctly in a real workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives some context for 'handles' by calling them 'baked AutoCAD entity handles', but it never explains the meaning of group_id, the role of layer, or how handles and group_id relate. Two of three parameters remain effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Register and track') and a concrete resource ('baked AutoCAD entity handles'), and ties it to a clear objective ('idempotent Grasshopper updates'). This distinguishes it from sibling gh_cad_* tools like gh_cad_build_pipeline or gh_cad_set_param_and_solve, whose names suggest different workflow steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for idempotent Grasshopper updates' implies when the tool is relevant, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. No sibling tools or exclusions are mentioned, so the guidance remains implicit rather than directive.
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 on its own. It only states the creation action and gives no detail about side effects, behavior on duplicate names, whether the layer becomes current, or what the response contains. For a mutation operation this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant wording. It front-loads the primary action, but it omits any contextual or behavioral details that could make it more informative without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool, the description covers the basic operation, but it lacks information about return values, error conditions (e.g., duplicate layer names), and interaction with the current layer state. With no annotations or output schema, an agent has insufficient context to anticipate the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions and defaults for name, color, linetype, and lineweight, including value enumerations for color and lineweight. The description adds no parameter-specific meaning beyond the phrase 'specified properties', so it neither improves nor degrades schema coverage. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('a new layer'), clearly distinguishing it from sibling tools that modify, freeze, lock, delete, or list layers. The phrase 'with specified properties' signals the tool's scope 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this tool when a new layer is needed. However, there is no explicit guidance about when not to use it, such as duplicate name handling or alternatives like layer_modify or layer_set_current. The context is adequate for obvious cases but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Insert' signals a mutation, but the description does not clarify what is created, where it is placed, whether it modifies the active drawing, or what side effects occur. It adds little beyond the obvious action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that is front-loaded with the action and resource, and the examples add useful context without waste. It is appropriately concise for a simple insertion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists and the parameter list is simple, the description still lacks critical context: no coordinate system or unit hints, no explanation of loop_num, no behavior details, and no usage alternatives. The agent can select the tool but must guess at important calling conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only clarifies the tag format with examples; x, y, radius, and especially loop_num are left to inference from their names and defaults. This is insufficient for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Insert') and a precise resource type ('ISA 5.1 instrument bubble') with concrete tag examples. This clearly differentiates it from sibling tools like pid_insert_valve, pid_insert_pump, and pid_insert_tank.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the instrument-bubble terminology and the sibling pid_insert_* tools, but there is no explicit statement of when to choose this tool over alternatives or any exclusion criteria. An agent can infer the intended use, but guidance is not 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?
With no annotations provided, the description carries the full burden of disclosing behavior. It states the insertion action but does not mention side effects (e.g., creating a block reference, affecting the active layer), coordinate system, units, or how existing entities might be affected. The word 'insert' implies a mutation but leaves important behavioral detail unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tightly written sentence with no filler, front-loading the core action and object. Every phrase earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, 0% schema coverage, and a moderately parameterized tool, the description is too thin. An agent still lacks critical operational detail such as what 'radius' means, how rotation is interpreted, and whether the insertion is relative to a coordinate system. The presence of an output schema helps with return values but not with input semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds value by listing plausible values for pump_type (centrifugal, diaphragm, metering), but it gives no explanation for x, y, radius, rotation, their units, or how they affect the inserted pump. This is insufficient for a 5-parameter tool with an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Insert') and a specific resource ('ISA 5.1 process pump'), and further enumerates the supported pump subtypes (centrifugal, diaphragm, metering). This clearly distinguishes it from sibling insertion tools such as pid_insert_valve, pid_insert_tank, and pid_insert_instrument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for adding a pump symbol to a P&ID drawing, which is enough context to identify the general use case. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it point to alternatives for other symbol types.
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 only states that a tank is inserted and provides no behavioral detail beyond that. With no annotations available, the description does not disclose whether this is a drawing mutation, how placement coordinates are interpreted, whether any redraw or regeneration occurs, or what the operation returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no filler or redundancy. It efficiently communicates the core purpose without wasting tokens.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, zero required, and no annotation coverage, the description is too sparse. It omits tank type semantics, coordinate system context, and any guidance on how the inserted tank behaves in the drawing, leaving an agent to guess at important invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information beyond the schema field names. The x, y, width, and height parameters are somewhat self-explanatory, but tank_type is entirely unexplained with no enum values, and the description does not clarify units, coordinate origin, or allowed tank type strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Insert') and a clear resource ('an ISA 5.1 process tank or vessel'). It clearly distinguishes this tool from sibling P&ID insertion tools like pid_insert_valve and pid_insert_pump by naming the tank/vessel 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the tool name and the ISA 5.1 process tank reference, making it obvious this is for adding tanks rather than valves, pumps, or instruments. However, the description does not explicitly state when to prefer this tool over alternatives or mention any constraints such as drawing setup requirements.
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?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds that this tool provides information about capabilities and available tools, which is useful context, but it does not disclose any other behavioral traits such as whether this is a static snapshot or a live query. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the action and the target resource clearly and is appropriately sized for a simple, parameterless introspection tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and readOnlyHint annotation, the description is mostly complete for a simple informational tool. However, the lack of disambiguation from system_capabilities and system_status leaves a meaningful contextual gap, since an agent cannot tell which introspection tool is the right one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The empty input schema already confirms no arguments are needed, and the description does not need to add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource ('AutoCAD MCP Pro capabilities and available tools') and a specific verb ('Get detailed information'), so an agent knows what the tool is for. However, it does not distinguish this from sibling tools like system_capabilities or system_status, which could easily be confused with the same purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to prefer system_about over similar sibling tools, and it names no alternatives or exclusions. Usage context is only implied by the verb 'Get', which is too weak for a tool family with several introspection-style siblings.
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 provide only a title and no readOnly/destructive hints, so the description must disclose behavioral traits. It confirms the file-export action but does not mention whether existing PDFs are overwritten, whether the drawing is modified, or what is returned; it also leaves the active-document requirement implicit. The only added detail about backends (COM vs ezdxf) lives in the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence containing only the essential action and scope, with the output format stated up front. No filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters and the schema already documents both, but with no output schema and no annotations, the description leaves the agent to infer return behavior and side effects. For a simple export command the essentials are present, but an explicit note about file creation/overwrite or a pointer to the layout-specific rendering behavior would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the description is not required to repeat them. The main description's 'current drawing (or a paper-space layout)' loosely aligns with the layout parameter, but it adds no syntax, format, or default semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Export ... to PDF') and identifies both model space and paper-space layout modes, which clearly distinguishes it from screenshot/deliver siblings. The parenthetical scope disambiguates what will be exported. It is not a tautology or vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a PDF of the current drawing or a named layout is needed, but it does not explicitly contrast with sibling tools like view_screenshot, drawing_finalize, or drawing_deliver, and gives no exclusions. An agent must infer the appropriate context from the 'to PDF' phrasing alone.
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?
Annotations already declare readOnlyHint=true, and 'validate' aligns with that read-only profile. However, 'normalize' is ambiguous—whether it mutates data or returns normalized values is not clarified. The description adds workflow context but no deeper behavioral details such as default resolution or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly worded sentence with no filler. The main action and timing are front-loaded, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and annotations cover the read-only safety profile, so return values and side-effect warnings are not required in the description. However, the description does not clarify how this tool relates to workflow neighbors (drawing_plan, drawing_finalize, validation_check) or what 'normalize' entails, leaving some ambiguity for an agent selecting among similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already documents most parameters. The description only references 'requirements' generically and does not add meaning to individual parameters beyond what the schema provides, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('validate and normalize') and identifies the resource ('requirements') with a clear workflow marker ('before committing a drawing plan'). It conveys the tool's role effectively, though it does not explicitly distinguish it from similar validation/checking siblings like drawing_audit or validation_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before committing a drawing plan' implies a specific workflow stage, giving some usage context. However, there is no explicit statement of when to prefer this tool over alternatives, nor any exclusions or mention of sibling 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?
Annotations contain only a title and no readOnly/destructive hints, so the description carries the full behavioral burden. It discloses that unused objects are removed but does not state that purging is destructive/irreversible, whether it can be undone, or whether confirmation is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states the action and scope with no filler. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description covers the basic operation well. However, it omits the destructive nature and any guidance on when purging is appropriate, leaving a small but meaningful completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to explain. Per the baseline for parameterless tools, no additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Purge') and identifies the exact resource: all unused objects (layers, blocks, linetypes, styles) from the drawing. It clearly distinguishes this from siblings like drawing_audit or entity_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to run a purge versus alternative cleanup/audit operations, nor any preconditions or exclusions. The usage context (e.g., before finalizing or saving) is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that this is a write operation (readOnlyHint=false) and not flagged destructive. The description adds meaningful geometric behavior — uniform scaling from a base point — but does not disclose whether the original entity is modified in place, whether undo is supported, or whether there are entity-type restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The core action, uniform scaling, and base-point anchoring are all expressed efficiently and up front.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation, and the schema plus annotations supply parameter and mutation context. However, for a transform tool in a large sibling set, it omits practical context such as whether the original entity is altered or a new entity is produced, and whether any entity types are unsupported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the input schema, including the factor semantics with exclusiveMinimum. The description's 'uniformly' clarifies that the factor applies isotropically, but it adds little parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('scale') and resource ('entity'), and adds the two key distinguishing qualifiers: uniform scaling and a base point. This is enough for an agent to tell it apart from sibling transform tools like entity_move, entity_rotate, entity_mirror, or entity_offset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of alternatives such as entity_move, entity_rotate, entity_mirror, or entity_copy. The only implied usage context comes from the tool's name and one-line 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?
The description adds useful behavioral context beyond the sparse annotation (destructiveHint: false): it asserts determinism and lists the exact geometry the resulting section contains. However, it does not disclose prerequisites (e.g., that the referenced gear/front view must already exist), failure conditions, or how the section interacts with the current drawing state, leaving gaps in behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first states the core purpose and dependency, the second lists output components. Concise, front-loaded, with no filler or repetition of structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus schema covers the essential workflow — create a front view, capture metadata, draw the section — and the presence of an output schema covers return values. What's missing is geometric context the agent needs: the reference frame for x_offset, alignment conventions for the section relative to the front view, and behavior on invalid metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — all three parameters (gear_metadata, x_offset, face_width) already carry meaningful descriptions, including face_width units and the metadata provenance. The tool description itself adds no parameter-level meaning, so the baseline 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation — a 'Deterministic side cross-section of a gear created by gear_draw_*_front_view' — and enumerates the output contents (boundaries, bore lines, keyway notch, ANSI31 hatch), which distinguishes it from the front-view drawing tools in its sibling set. It stops short of a 5 because it doesn't explicitly contrast itself with related section tools like keyway_draw_section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through the dependency expressed in the description and the gear_metadata parameter, which states the metadata must come from gear_draw_helical_front_view or gear_draw_spur_front_view. There is no explicit statement of when to prefer this tool over section-view or keyway alternatives, so the guidance is adequate but not directive.
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?
Annotations provide destructiveHint: false and readOnlyHint is absent (meaning not read-only). The description 'Fill a hatch with a gradient instead of a pattern.' adds minimal behavioral context beyond the annotations. It does not disclose any side effects, such as whether the original pattern is permanently replaced or whether the operation is reversible, which would be valuable for a mutation tool. With annotations covering destructive hint, the description adds some but not substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's core function. It includes the key contrast ('instead of a pattern') without wasting words. This is appropriately sized for a tool with a well-documented input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (8 params, 3 required) and a full output schema, the description adds minimal contextual information beyond the schema. It is complete enough to understand the tool's primary purpose, but lacks details on when to use it compared to hatch_edit or entity_set_properties. Since an output schema exists, return values don't need explanation. However, a brief note on prerequisite conditions (e.g., the hatch must exist) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add any detail about parameter semantics, but since every parameter has a description in the schema, the baseline of 3 applies. The description does not explain how parameters interact (e.g., how one_color relates to color2 being unused), but the schema descriptions are sufficiently clear for an agent to proceed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill a hatch with a gradient instead of a pattern.' clearly identifies the tool's action (fill), resource (hatch), and the specific effect (gradient instead of pattern). It distinguishes this from sibling tools like entity_create_hatch (which creates a hatch) and hatch_edit (which edits hatch properties in general), though it doesn't explicitly name an alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for when to use this tool: when you want to fill a hatch with a gradient instead of a pattern. However, it does not distinguish when to use this over hatch_edit or entity_set_properties, which could also modify a hatch's fill. There are no explicit exclusions or alternatives, so the agent must infer that this is the specialized gradient tool from the tool name and sibling list.
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?
Annotations declare destructiveHint=false, and the description adds that this is an additive creation of a paper-space tab. However, it omits other behavioral context such as whether the new layout becomes active, whether duplicate names are rejected, or whether an open drawing is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundancy. It is front-loaded with the action and resource, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, this description is minimally sufficient for basic invocation. However, it lacks context about prerequisites, postconditions, and failure behavior, which an agent might need to call the tool reliably in a real workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, name, is already fully described in the input schema with an example ('A3-Sheet'), and schema coverage is 100%. The tool description adds nothing beyond what the schema provides, so it stays at the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Create,' and clearly identifies the resource as a 'new paper-space layout tab.' This distinguishes it from related sibling tools such as layout_copy, layout_set_current, and viewport_create, which operate on different aspects of layouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus related alternatives, nor any prerequisites such as requiring an open drawing. It does not explain when layout_create is preferable to layout_copy or viewport_create, leaving the agent to infer this 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. 'List' clearly implies a read-only action and avoids any destructive implication, but it does not disclose behavior like whether the category parameter filters results, whether all available items are always returned, or whether the listing is hierarchical. The scope (ISA 5.1 & CTO P&ID) is a useful addition, but the behavioral detail is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It is efficient, though it is so brief that it misses useful parameter and usage context; those omissions are better penalized under other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity read-only listing tool and an output schema exists, so return-value details do not need to be in the description. However, the single optional parameter is left semantically unexplained and no usage guidance is given. The description is minimally viable but has clear gaps for an agent deciding how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what the optional `category` parameter does. The word 'categories' in the description and the parameter name give a weak hint that it may filter by category, but valid values, the effect of null/default, and whether it is a filter are never stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), names the exact resource ('available ISA 5.1 & CTO P&ID categories and symbols'), and clearly differentiates this from the pid_insert_* and pid_route_pipe siblings by framing it as a listing/exploration tool rather than a drawing-creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'available' implies this should be used to discover what symbols/categories exist, likely before inserting P&ID objects, but it never explicitly says when to use this tool versus alternatives or names a sibling. Usage is reasonably inferable but not stated.
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?
The description is transparent about the denylist, quotes-as-data behavior, and warns it is 'NOT a security boundary' with write channels beyond the denylist. However, the annotation readOnlyHint:true directly contradicts this, since executing arbitrary AutoLISP can mutate drawing state. This is a serious annotation contradiction, so the score is 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose, immediately gives an example, and uses every remaining sentence to convey necessary safety context. It is appropriately sized for a potentially dangerous escape-hatch tool with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an arbitrary LISP execution tool, the description covers backend, usage example, guardrail limitations, and recommends safer alternatives; the output schema handles return formatting. The main gap is the contradiction with readOnlyHint and the lack of explicit error/rollback behavior, but overall it is reasonably complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single 'expression' parameter with 100% coverage, giving a baseline of 3. The description adds meaningful extra semantics by explaining that text inside double quotes is treated as data and by providing a concrete example, which clarifies how to construct the expression string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Execute') and resource ('AutoLISP expression') and adds the constraint 'COM backend only'. The example makes the intended use clear. However, it does not explicitly distinguish itself from similar siblings like lisp_execute_code or lisp_load_macro, so differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance to 'Prefer the typed tools', steering agents toward safer alternatives and implying this is a fallback. The COM backend restriction is a concrete usage constraint. It does not name specific typed tools or state exactly when raw LISP is the only option, leaving some room for inference.
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 annotation readOnlyHint=false signals a write operation, and the description's 'Set' verb matches that. However, the description does not disclose potential side effects such as global impact on drawing state, persistence of the change, or behavior when an invalid name/value is provided. For a mutation tool, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the core operation and includes helpful examples without excess wording. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter with full schema coverage, an output schema, and a readOnlyHint=false annotation, the description conveys the essential purpose. However, it omits behavioral context such as side effects and any restrictions on valid system variables, which prevents it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters well: 'name' as the system variable name and 'value' as the new variable value. The description adds illustrative examples but no additional semantic meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('AutoCAD system variable'), with concrete examples like DIMSCALE, LTSCALE, and MEASUREMENT. This makes its purpose unambiguous and distinguishes it from the sibling system_get_variable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for modifying system variables rather than reading them, which contrasts with system_get_variable. However, it does not explicitly state when to choose this over alternatives or mention any constraints on which variables can be set.
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 annotations already declare readOnlyHint=true, so the safe read behavior is established. The description adds modest context by clarifying that it reports per-layer aggregate counts and types, which goes slightly beyond the annotation. No contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every element — 'each layer', 'entity count', and 'types present' — adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool with an output schema, the description is sufficiently complete. It states the scope and the kind of statistics returned, and no parameter or invocation detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline of 4 applies for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') plus a clear resource ('detailed statistics for each layer') and names the actual content (entity count, types present). It is distinguishable from siblings by the layer-level scope, though it does not explicitly differentiate from analysis_entity_stats or analysis_list_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over siblings such as analysis_entity_stats or analysis_list_properties. The intended usage is implied by the name and description, but no selection conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already convey that the operation is not read-only, so the description does not need to restate that. It adds modest value by mentioning that attribute values can be set, but it does not disclose whether the block must already exist, how failed insertions behave, or other side effects beyond the annotation's mutation signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the primary action first and the optional behavior second. There is no redundant phrasing or filler, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full parameter schema, output schema, and annotation indicating mutation, the description is mostly sufficient for an agent to select and invoke the tool. The main gap is the lack of explicit context that the inserted block must refer to an existing block definition, but this is reasonably inferable from the tool name and the presence of block_list and block_create_from_entities among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptive names and descriptions, so the baseline is 3. The description adds little beyond reinforcing that 'attributes' relates to attribute values; it does not clarify units, coordinate context, or block-definition requirements beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Insert a block') and a resource, with the optional attribute-setting behavior clearly called out. It is unambiguous about the core operation, though it does not explicitly distinguish itself from sibling tools like entity_create_block_ref or block_create_from_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when inserting a block reference, but it provides no explicit guidance about when to prefer this tool over alternatives such as entity_create_block_ref or when not to use it. Sibling differentiation is left entirely to the agent's inference from the tool name and 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?
Annotations include destructiveHint=true, and the description adds useful behavioral context by naming result statuses ('success', 'failed_validation', 'failed_export') and stating that failure intentionally keeps all generated artifacts for diagnosis. However, it does not explain what destructive action may occur, such as overwriting files in output_dir or clearing prior bundles.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core function, followed by failure statuses and artifact-retention behavior. Every sentence adds useful information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complete input schema and an output schema present, the description covers the essential operation, possible result statuses, and failure behavior. The remaining gaps—explicit destructive-effect disclosure and sibling differentiation—are partially covered by annotations and purpose clarity, so this is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all five parameters. The description adds no parameter-specific meaning beyond the schema, which keeps this at the baseline rather than higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a hashed, validated delivery bundle and verify DXF save/reopen parity.' This clearly distinguishes it from siblings like drawing_export_dxf, drawing_audit, and drawing_finalize, which do different work. The title 'Deliver Auditable Bundle' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives such as drawing_export_dxf, drawing_audit, or drawing_finalize. It implies a final delivery/validation workflow but gives no explicit exclusions, prerequisites, or comparison with overlapping 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?
Annotations only provide a title, so the description carries the behavioral disclosure burden. It does reveal important traits: DWG is only supported on the live COM backend, .dwg paths are refused without the dwg capability, and ezdxf sniffs content rather than extensions, which can produce a document that doesn't exist in the expected format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is clear and front-loaded, but the 'T0.2:' paragraph is verbose and jargon-heavy. The mislabelled-file caveat is useful but could be stated more concisely without the changelog-style prefix.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description covers the key contextual concern: backend-dependent DWG support and the refusal behavior. It does not mention what happens to the currently open drawing, but the description and schema together are adequate for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the single path parameter with 100% coverage, including the DWG backend caveat. The description restates this information without adding new parameter-level specifics such as path format, absolute vs. relative paths, or file-existing requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Open an existing DXF drawing file') and adds the DWG/backend condition. It is clear this loads an existing drawing, but it does not explicitly differentiate from siblings like drawing_new or drawing_save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by saying 'existing drawing file', but it does not state alternatives such as drawing_new for creating a new drawing, nor does it explain when not to use this tool. The backend condition for DWG is useful but not framed as routing 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?
The description adds the 'lightweight 2D' qualifier and a concrete closed-rectangle example, giving some context beyond the readOnlyHint=false annotation. However, it does not disclose behavior around null color/layer defaults, coordinate system assumptions, or minimum point requirements, which would be useful for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one defining sentence plus an illustrative example. Every part earns its place, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with full schema coverage and an output schema, the description is largely sufficient for an agent to invoke it correctly. The main gap is the lack of explicit routing guidance and default-value behavior, but the core invocation is clearly conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already fully documented in the schema. The example clarifies the points format and shows how 'closed=true' affects the result, but it essentially restates schema information rather than adding new semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create a lightweight 2D polyline through the given points.' This clearly identifies the tool's function and differentiates it from siblings like entity_create_line or entity_create_rectangle by using the distinctive polyline concept. The example further reinforces the intended behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to prefer this tool over alternatives such as entity_create_line, entity_create_rectangle, or entity_create_spline. The example implies a use case but does not state when a polyline is appropriate or when another entity creation tool should be chosen 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?
Annotations declare readOnlyHint=false, correctly flagging this as a mutation operation, and the 'Create' verb is consistent with that — no contradiction. The description adds only the DTEXT/TEXT primitive clarification, which carries mild behavioral weight (single-line semantics), but discloses nothing about side effects such as whether omitted color/layer fall back to current drawing settings or which space the entity is created in. With annotations covering the basic safety profile, the added context is thin but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Eight words in a single sentence, with the verb, the key differentiator ('single-line'), and the primitive mapping all front-loaded. There is zero filler and nothing duplicating schema fields. This is exemplary sizing for a simple create tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple 7-parameter create operation; the schema documents every parameter with defaults and an output schema exists, so the description's minimalism is not costly. The main omission is explicit routing to entity_create_mtext for multi-line text, which the agent must infer from the 'single-line' qualifier alone. For this complexity level, the definition is largely complete with that single usage gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — x, y, text, color, layer, height, and rotation all have meaningful descriptions and defaults in the schema itself, so the description need not repeat them. The description adds no parameter-level detail, but at this coverage level the schema carries the burden fully. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (create), a resource (text entity), and the crucial qualifier 'single-line,' which distinguishes it from the entity_create_mtext sibling. The parenthetical '(DTEXT/TEXT)' maps the tool to the underlying CAD primitive, removing ambiguity about which command family this invokes. It stops short of explicitly naming entity_create_mtext as the alternative, which would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'single-line' qualifier implies this tool is for simple text labels, implicitly excluding multiline/paragraph text, so an agent can infer basic usage context. However, the description never explicitly says when to choose this over entity_create_mtext or other entity_create_* siblings, and provides no when-not conditions or alternative routing. The usage guidance is implied, not stated.
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 aligns with annotations: it is a write/destructive operation and returns a count. It adds the return-count contract and batching behavior, which is useful, but it does not disclose partial-failure or irreversibility details beyond what destructiveHint already signals. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences each add value: the first states the action, the second the successful return value. No filler, redundant clauses, or repetition of the schema/annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-required-parameter destructive batch delete with an output schema and annotations, the description plus schema covers the main contract. It stops short of explaining behavior when a handle is invalid, whether deletion is atomic, or whether the count reflects only successful deletions, but overall it is sufficient for a low-complexity call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, handles, is already documented as a list of entity handles to delete, so the description adds no additional parameter semantics. Baseline 3 is appropriate because the schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete'), names the resource ('multiple entities'), and adds the batching scope ('in one call'), so the core action is unambiguous. It does not explicitly contrast with sibling entity_delete, though the name and 'multiple' phrasing make the distinction inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in one call' implies the tool is for batching deletions, which is a usage signal. However, no when-to-use/when-not-to-use guidance or alternative (e.g., entity_delete for a single entity) is provided, so the agent must infer selection from the name.
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?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the scope ('all properties') but does not disclose edge-case behavior such as what happens for an invalid handle, partial results, or performance implications. No contradiction exists, and the description adds modest behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loaded with the operation and target. It earns its place entirely; nothing could be removed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool with an output schema present, the description covers the core need. The only notable gap is the lack of explicit error behavior for a nonexistent handle, but the output schema and annotations already carry much of the contextual load.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the only parameter 'handle' is fully documented in the schema. The description adds the phrase 'specific entity' but does not clarify handle format or lookup semantics, so value beyond schema is minimal — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get') on a specific resource ('all properties of a specific entity' identified by handle). It clearly conveys the tool's function and is distinguishable from sibling tools like entity_list or analysis_entity_stats, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have a specific entity handle and need all its properties, and the readOnlyHint annotation confirms safe use. However, it provides no explicit when-to-use vs alternatives or exclusion criteria, leaving the agent to infer routing from 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?
The annotations already indicate a mutating but non-destructive operation, and the description does not contradict them. It adds the geometric semantics of rotating around a base point, but it does not disclose whether the original entity is modified in place, whether undo is available, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler or redundant wording. The core operation and its main semantic constraint are stated directly and efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward transformation tool, the combination of a clear one-sentence description, fully documented required parameters, annotations, and an output schema covers the essentials. The main gap is the absence of any guidance about coordinate systems or effects on related entities, but this is not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains each parameter, including the counter-clockwise convention for angle_deg. The description only repeats the general concepts of base point and angle without adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rotate), the target (an entity), and the two key parameters (base point and angle). It reads as more than a restatement of the name, though it does not explicitly contrast with sibling transform tools like entity_move or entity_scale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: when an entity needs to be rotated around a base point, this is the tool. However, the description gives no explicit when-not-to-use conditions or alternatives, making it less helpful for an agent deciding among the many sibling entity-operation 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?
Annotations provide only a title, so the description carries the behavioral burden. It does disclose the key state change: entities are visible but cannot be selected or modified. However, it does not mention behavior for unknown layer names, idempotence, or side effects on existing selections or editing workflows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and includes only the essential behavioral clarification. There is no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter command with an output schema, the description sufficiently explains the operation's effect for basic invocation. It is slightly thin on alternative routing and edge-case behavior, but those are not critical for calling the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter 'name' with 100% coverage. The description adds no additional meaning about the parameter beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('lock') and resource ('a layer') and defines the behavioral effect: entities remain visible but cannot be selected or modified. This clearly differentiates it from unlock, freeze, hide, and modify operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool instead of related layer commands such as layer_freeze, layer_hide, or layer_unlock. An agent would have to infer the appropriate context from the tool name and sibling list.
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 only a title annotation and no read-only/destructive hints, the description carries the disclosure burden. 'Turn on a layer' clearly describes the state change, but it does not mention error behavior for unknown layers, behavior on already-visible layers, or any permissions/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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that front-loads the verb and resource, with zero filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, non-nested tool with a complete schema and an output schema, the description supplies the essential state-transition context ('previously turned off') needed to select it. It could add a brief note on already-on or frozen layers, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single required 'name' parameter as 'Layer name to turn on' (100% coverage). The tool description adds no extra semantic detail beyond what the schema provides, so it stays at the schema-driven baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Turn on') and resource ('a layer'), and anchors the operation to the 'previously turned off' state, so an agent can tell it targets visibility rather than freeze/lock state. It does not explicitly name a sibling for contrast, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the right condition for invocation: use when a layer is currently off. However, it gives no explicit guidance about related layer tools (e.g., layer_thaw or layer_hide), no when-not-to-use conditions, and no alternatives.
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 clearly states that the tool toggles the lock state of the viewport's display scale, which is the core side effect. However, annotations do not provide read-only or destructive hints, and the description does not explain consequences such as whether locked viewports ignore scale changes or whether the operation is reversible beyond calling this again.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundant words; the key scope ('display scale') is placed immediately after the verb. Every word earns its place, and it is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter boolean toggle with an output schema and fully described parameters, the description covers the essential operation. It still leaves the implication of a locked viewport unstated and lacks alternative routing, but these gaps are minor for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters: handle's source is given and locked's meaning/default is explicit. The description adds no additional parameter detail, so it sits at the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb pair ('Lock or unlock') with a specific resource ('a viewport's display scale'), which is more specific than the title. This distinguishes it from sibling viewport_set_scale, which would set the scale value rather than toggle its lock state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance or conditions are given: the description does not say when to choose this over viewport_set_scale or viewport_list, nor mention prerequisites such as the handle referring to an existing viewport. The intended use is only implied by the action itself.
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 annotations declare readOnlyHint=false and destructiveHint=false, so the safety profile is already structured. The description adds that the operation changes the display to a given rectangular region, which is useful but not deeply detailed; it does not state whether the viewport state is persistent or whether any viewport is specifically targeted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that immediately conveys the tool's purpose. Every word contributes meaning, with no filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zoom operation with an output schema and 100% parameter coverage, the description is nearly complete. It could mention coordinate conventions or that this affects the current viewport, but the core calling context is clear enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds only the generic notion of a 'rectangular window region' and does not explain corner ordering, coordinate system, or units beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Zoom') and a precise resource ('display the specified rectangular window region'), clearly distinguishing it from siblings like view_zoom_extents and view_zoom_and_screenshot. There is no ambiguity about what operation is being 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as view_zoom_extents or view_zoom_and_screenshot. An agent must infer the intended use case from the tool name and parameter schema alone.
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?
Annotations already mark readOnlyHint=true, so the read-only safety profile is covered. The description adds useful behavioral context beyond that: the tool returns total_entities, by_type, and by_layer with sorted ordering, which helps set expectations for the response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the action, and clearly structured. The 'unique to AutoCAD MCP Pro' claim is extraneous and does not help an agent invoke the tool, but it does not obscure the operational content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only analysis tool with an output schema, the description is complete. It names the output fields, explains the grouping and sorting, and is adequately scoped to the active drawing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered by definition. The description usefully documents the return object fields, which is the only input-free semantics an agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action and output: analyzing the drawing and returning entity counts grouped by type and layer, sorted by count. It is clear enough to distinguish from drawing creation or modification tools, though it does not explicitly differentiate from the closely related analysis_layer_stats 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus analysis_layer_stats, analysis_select_by_type, or drawing_info. The uniqueness claim is about market positioning, not about usage context or alternatives.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the useful 'Uncapped' behavior and the workflow hint about returning handles, which goes slightly beyond the annotations and schema. It does not describe pagination or truncation behavior, though the compact parameter and output schema already carry some of that information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core purpose is stated first, and the second sentence provides actionable workflow guidance. 'Uncapped' is terse but meaningful behavior information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, output schema presence, and readOnlyHint annotation, the description covers the essential selection purpose and common next step. It lacks explicit routing among the many selection-related sibling tools, but an agent can invoke this tool correctly using the schema plus the description's guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself documents predicate, fields, and compact in detail. The description adds practical guidance beyond the schema by recommending fields=['handle'] for the typical dimension_auto workflow, which helps the agent choose parameter values more effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Select entities') and the method ('by semantic predicate instead of memorising handles'). This clearly distinguishes it from handle-based entity access, though it does not explicitly differentiate it from sibling tools like analysis_select_by_type or analysis_select_by_layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'instead of memorising handles' implies use when the caller has semantic criteria rather than known handles, and 'the usual next step is dimension_auto(handles)' provides concrete workflow context. However, it does not explicitly state when to prefer this over selection/analysis siblings, nor mention 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?
Annotations already communicate that the operation mutates state but is not destructive. The description adds the useful detail that the effect targets only new entities, but it leaves the likely precondition that the layer must already exist implicit and gives no error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to explaining the operation and its scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool this is nearly complete, and an output schema exists so return values do not need explanation. The gap is the unstated existence precondition: the agent is not told it should verify via layer_list or create the layer first, which could lead to a failed call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the only parameter, 'name', as 'Layer name to set as current' (100% coverage). The tool description adds no parameter-specific meaning or format guidance, so it meets the baseline without enhancing it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('set') and the target resource ('active/current layer'), and scopes it to new entities. It is clear enough to be distinguished from layer_create, layer_modify, and layer_delete, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'For new entities' provides a clear usage context: call this before creating entities when you want them placed on a specific layer. It does not explicitly state when not to use it or mention layer_list/layer_create, so it stops short of full alternative routing.
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?
Annotations only provide the title, so the description carries the full burden. It discloses the core behavioral effect (unlocking enables selection/modification) but does not state side effects, prerequisites, or that it does not affect freeze/visibility state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with the verb first and the purpose immediately after; no filler, repetition, or unnecessary explanation. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter operation with an output schema, the description covers the basic purpose. It is slightly incomplete because it does not disambiguate from layer_thaw/layer_show or note any preconditions, but the low complexity makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents the single 'name' parameter with 100% coverage ('Layer name to unlock'). The description adds no parameter-level detail, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Unlock a layer') and its intended effect ('allow entity selection and modification'), which clearly distinguishes it from siblings like layer_lock by naming the opposite operation. It is more specific than a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: unlock is appropriate when a locked layer blocks entity selection/modification. However, there is no explicit when-to-use/when-not-to-use guidance and no reference to alternatives such as layer_thaw or layer_show, which could also affect editability in some CAD workflows.
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?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds a brief note on what is returned but does not disclose details like latency, failure modes, or what 'full status' means operationally (e.g., what happens if backend is unreachable). With readOnlyHint covering the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, followed by a concise list of return categories. Every sentence earns its place and there is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless status/health tool, the description covers the core purpose and return categories. An output schema exists, explaining return values. It could additionally clarify how this differs from system_capabilities and system_about, but that gap is minor given the simple scope. Overall, it is complete enough 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (vacuous). There are no parameter semantics to clarify, and the description sensibly focuses on return values instead. For a no-parameter tool, the description provides enough guidance on what the call will yield.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full status of the AutoCAD MCP Pro server and backend connection' with a specific verb and resource, and then enumerates the returns: backend name, connection status, capabilities, document info. It distinguishes itself from sibling tools like system_capabilities and system_about by focusing on status and connection details, though it doesn't explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the go-to health/status check tool, and the context of sibling tools like system_capabilities and drawing_info provides some differentiation. However, it does not explicitly state when to use this versus alternatives, such as when system_capabilities would be more appropriate. The usage context is only implied by the title 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?
The readOnlyHint annotation already communicates that the tool does not modify the drawing, and the description adds value by detailing what each check does. It does not disclose behavior when the checks parameter is omitted or whether all checks run by default, but the read-only safety profile is covered by the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main action, and uses a scannable bullet list where each entry earns its place. It avoids restating the title or repeating schema information unnecessarily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single optional parameter with full schema coverage, an output schema, and a read-only annotation, the description provides enough to select and invoke the tool correctly. The main residual gap is the unspecified default behavior when the checks array is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage by listing the check names, so the baseline is met. The description goes further by defining each allowed value semantically, which helps an agent choose the correct strings. It leaves the null/omitted behavior of the checks parameter unspecified, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run quality checks') and resource ('the current drawing'), then enumerates the available check types with concrete meanings. It does not explicitly distinguish itself from similar siblings like drawing_audit or drawing_preflight, but the named checks make its purpose identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The bullet list provides implied usage: an agent can infer this tool is appropriate when empty_layers, zero_length, or duplicate_entities checks are needed. However, it gives no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as drawing_audit or drawing_preflight.
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?
Annotations already mark the tool as read-only, and the description adds useful behavioral context beyond that: the MAX_LIST_LIMIT cap of 5000 and the fact that only compact=True reports total/truncated. It also notes that results are returned with handles. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the core behavior front-loaded, followed by the cap/truncation caveat. The 'as with analysis_select_by_layer' shorthand avoids duplicating documentation, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with a fully described input schema and an existing output schema, the description covers the remaining runtime constraints: result cap, truncation reporting, and handle inclusion. It does not discuss ordering or multi-type queries, but those are not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mostly restates the compact behavior already documented in the schema ('only shape that reports truncation') and adds no new meaning about fields or entity_type values beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence uses a specific verb ('Get'), a resource ('all entities'), and a selection criterion ('specific type'), and the handle-return note clarifies exactly what the agent receives. Naming analysis_select_by_layer as the analogous tool helps place it, though the distinction is not fully spelled out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the natural use case: fetching all entities of a given entity type. It references analysis_select_by_layer, signaling a sibling family, but it never states when to prefer this tool over alternatives like entity_list, selection_filter, or analysis_select_by_layer, nor when it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the mutating nature is covered. The description confirms the tool creates an entity but adds little beyond that: no mention of effects on the active drawing, coordinate system assumptions, or layer behavior. This is acceptable for a simple creation tool but adds only minimal behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action ('Create an angular dimension') and clarifies scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward creation tool with a fully described schema and an output schema present, the description is nearly complete. It lacks only explicit mention of prerequisites like an active drawing or that the dimension is added to the current layer by default, but these are likely standard for the domain and not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description (e.g., 'Angle vertex X', 'First ray endpoint X'). The tool description does not add additional parameter-level meaning; it only restates the geometric concept already captured by the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('angular dimension'), and further specifies that it measures the angle between two lines from a vertex. This clearly distinguishes it from sibling dimension tools such as dimension_linear, dimension_aligned, or dimension_radius.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's intended use clear through the phrase 'measuring the angle between two lines from a vertex,' which implies when to use it. However, it does not explicitly compare against alternatives or state exclusions, so an agent must infer usage from 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?
Annotations provide only readOnlyHint: false, so the description carries the burden of indicating mutation. It does clearly state that the tool creates a dimension and adds the behavioral nuance of optional tolerancing (e.g., ⌀20 H7). It does not describe side effects like layer handling or combination rules, but it is not misleading and adds some behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the core purpose and adds the key tolerance capability in a compact example. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema comprehensively covers parameters and an output schema is present, so the description does not need to explain return values or parameter details. The description sufficiently orients the agent toward the operation and the tolerance feature. It is slightly terse regarding tolerance configuration options, but the schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters in detail. The description adds a useful high-level example of tolerancing but does not explain individual parameters, which is acceptable because the schema already does that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a diameter dimension for a circle.' It clearly identifies the operation and the geometric target, and 'diameter' distinguishes it from siblings like dimension_radius, dimension_linear, and dimension_aligned without requiring the agent to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this when a diameter dimension on a circle is needed. However, it does not explicitly say when not to use alternatives such as dimension_radius or dimension_aligned, nor does it mention any prerequisites or exclusions. The guidance is adequate but not 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 readOnly or destructive annotations, the description carries the full burden of behavioral disclosure. It clearly states the primary effect (creating a DXF file from the current drawing), but it does not disclose whether an existing file at the path is overwritten, whether the drawing remains unchanged, or how failures are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the action, the target, and the output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter export operation with an output schema available, the description plus the schema is sufficient for an agent to call it correctly. It covers the key context (current drawing, DXF format, required path), though it does not touch on overwrite behavior or prerequisites beyond the current drawing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with the path parameter described as 'Output .dxf file path'. The description adds no additional meaning to the parameter beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Export'), a clear resource ('the current drawing'), and an explicit output format ('DXF file'). This differentiates it from the sibling drawing_export_pdf and other drawing management tools without relying on the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'current drawing' implies the tool should be used when a drawing is active and the user needs DXF output, which provides clear context. However, it does not mention alternatives like drawing_export_pdf or drawing_save_as, nor does it state exclusions or conditions for choosing this tool over those 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?
The description adds useful behavioral context beyond the annotations: it notes that count is unbounded and recommends fields=["handle"] when geometry is already known. However, it does not elaborate on side effects, error conditions, or what happens to the original entity beyond calling them "copies."
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The second sentence provides a practical tip, though it assumes familiarity with the rectangular array's "result-shaping" behavior, which slightly reduces self-contained clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complete input schema and an output schema available, the description does not need to repeat return details. It covers the main operation and a key edge case, but it leaves some behavioral details, such as rotation direction and handling of the original entity, to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters, so the baseline is 3. The description adds extra meaning by explaining that count is unbounded and by giving concrete guidance on the fields parameter, which is not fully captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Create a polar (circular) array of copies around a center point." It clearly identifies the operation and differentiates it from the rectangular array sibling by explicitly naming the polar/circular geometry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the basic use case clear and references the rectangular array's result-shaping behavior, but it does not explicitly state when to choose this tool over alternatives like entity_array_rectangular or entity_copy. The usage context is implied rather than fully articulated.
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 annotation readOnlyHint=false already signals a mutating operation, and the description adds that the operation creates a circle at a specific center and radius. It does not describe side effects beyond creation, but for a simple 'create' tool this is acceptable and not contradictory with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It communicates the core operation and the essential parameters immediately while leaving parameter details to the fully covered schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity creation tool with a fully described schema and an output schema present, the description covers the essential invocation context. The main gaps are lack of usage guidance and no mention of optional parameter behavior, but the schema fills those gaps adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured schema already documents all five parameters. The description adds minimal meaning beyond the schema, mainly linking cx/cy to center coordinates and radius to the given radius, but it does not enrich optional parameters like color or layer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Create a circle at (cx, cy) with given radius.' This clearly differentiates entity_create_circle from sibling creation tools like entity_create_arc, entity_create_ellipse, and entity_create_rectangle by entity type and defining 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a circle entity needs to be created, but it does not explicitly state when to choose this over alternatives or mention any exclusions. For a straightforward creation tool this is minimally adequate, but there is no explicit routing 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?
The annotations already indicate a write operation via readOnlyHint=false, so repeating that is unnecessary. The description adds the geometric interpretation of the major axis vector, which is useful, but it does not disclose defaults, drawing-state requirements, or side effects beyond what the annotations already signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action front-loaded and no filler. Every word serves a purpose: identifying the entity type and clarifying the key geometric parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers all parameters and an output schema exists, so return-value documentation is unnecessary. The description provides the essential geometric concept for correct invocation. Minor gaps such as the meaning of a null ratio default or drawing-state prerequisites are not critical for this simple creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds the 'vector from the center' framing for major_x/major_y, but the schema already describes them as 'relative to center.' It adds no extra meaning for ratio, color, or layer, though those are already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Create an ellipse.' It also adds a meaningful geometric detail about major_x/major_y defining the major axis vector from the center, which distinguishes this from sibling entity creation tools like entity_create_circle or entity_create_line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an ellipse is needed, but it does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. An agent must infer selection primarily from the tool name and resource type.
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?
Annotations supply readOnlyHint=false, so the description is consistent with a mutating create operation. It adds one behavioral detail beyond the schema—'Returns entity info with handle'—but does not describe other side effects or prerequisites such as requiring an open 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and endpoints and adds a useful return-value note. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter create tool this is fairly lean, but the schema and output schema carry the parameter and return details. The description lacks usage context distinguishing line from polyline or arc, yet covers the essential operation and return handle, so it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter including z1/z2 defaults and color/layer/linetype semantics documented. The description only restates the core x/y endpoints and adds no new parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('a line') with exact endpoint coordinates, making the tool's function unmistakable. The resource name also differentiates it from the many entity_create_* siblings listed in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given, and no alternative tools are mentioned. The intended use is implied by the name and description, but an agent is not told to prefer this over entity_create_polyline or entity_create_arc for multi-segment or curved geometry.
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?
Annotations declare readOnlyHint=false, so the description needn't restate that this mutates the drawing. The description conveys the fit-point-to-spline behavior but does not disclose details like whether the spline is degree-3, whether endpoints are included automatically, or how the result is returned. With an output schema present, some of that burden is reduced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that names the entity, the construction method, and the input data. No filler, no repetition of schema details, and the core behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with an output schema, full schema documentation, and straightforward inputs, the description is nearly sufficient. It could add a note about the minimum number of fit points or default layer/color behavior, but the current level is adequate for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents fit_points, layer, and color. The description adds the key semantic detail that the spline passes through those fit points, which is valuable. However, it does not clarify coordinate space, units, or constraints on the points (e.g., at least two points). Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a resource ('NURBS spline curve'), and the defining behavior ('passing through the specified fit points'). This clearly distinguishes it from sibling creation tools like entity_create_line or entity_create_ellipse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for creating splines with fit points, which is enough context for an agent choosing among entity creation tools. However, it does not explicitly state when to prefer this over alternatives (e.g., polyline, arc, or ellipse) or mention any constraints (e.g., minimum number of fit points).
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?
Goes beyond the destructiveHint annotation by disclosing the hiding behavior and the refusal condition for invalid point counts, explaining why fewer than three points is rejected. This prevents an agent from passing degenerate geometry that would silently produce a useless mask.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first states the purpose, the second handles an important edge case. No redundancy, filler, or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Contains the essential behavioral context and edge-case handling for a tool with only two well-documented parameters. It does not explicitly state the return value (and no output schema is present), but the core call semantics are complete and unambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters well ('layer' default and 'points' format). The description adds the context that points form the outline and reinforces the 3-point minimum, but provides no new parameter-level semantics beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Create'), resource ('WIPEOUT'), and its defining behavior ('hides drawing content behind its outline'), distinguishing it clearly from sibling entity creation tools like entity_create_hatch or entity_create_polyline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to choose this tool over alternatives, such as when a wipeout is preferable to a hatch or other masking approach. The 'Refuses fewer than three points' note is a boundary condition, not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'permanently,' which conveys irreversibility beyond the destructiveHint annotation's basic destructive classification. It also makes the handle-based targeting explicit, though it does not describe failure modes or cascade effects; annotations already cover the read-only/destructive profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence states the action and the key qualifier ('permanently') before the parameter. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive operation with a high-coverage schema, an output schema, and safety annotations, the description covers what the tool does and how to identify the target. It is slightly light on guidance about batch alternatives, but that gap is already captured in usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the handle parameter is already described in the schema as 'Entity handle to delete.' The description's 'by its handle' reinforces the parameter's role but adds no new format, source, or validation details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('delete'), names the resource ('entity'), and specifies the selection mechanism ('by its handle'). It clearly distinguishes from sibling tools like entity_delete_many because it identifies single-entity deletion by handle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over alternatives. The presence of entity_delete_many suggests a related batch operation, but the description does not mention it or provide selection criteria.
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?
Annotations already establish non-read-only and non-destructive hints, so the description only needs to add extra behavior. It adds that a mirrored copy is returned, but it does not mention the effect of delete_original (preserving or deleting the original) or any other side effects. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler: the operation, the mirror-line definition, and the return behavior are front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter transform with complete schema coverage, an output schema, and safety annotations, the description plus structured data is largely sufficient. The only notable omission is explicit linkage between delete_original and the original entity's fate, though the schema default already covers this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (handle, x1, y1, x2, y2, delete_original) already documented. The description's mention of a line defined by two points maps to x1/y1/x2/y2 but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Mirror an entity') and the geometric method ('across a line defined by two points'), plus the output ('returns the mirrored copy'). This clearly distinguishes it from sibling transforms like entity_move, entity_copy, and entity_rotate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the obvious use case—mirroring an entity—but gives no explicit guidance on when to prefer this over sibling tools such as entity_copy or entity_rotate, nor any exclusions or conditions. Usage is implied by the operation name rather than stated.
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?
Annotations already signal a non-read-only, non-destructive mutation, and the description is consistent with them. The phrase 'one or more' adds partial-update context, but the description does not state whether omitted/null properties are preserved, or how invalid values or entities are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence contains the verb, target, and complete property scope. There is no filler, redundancy, or restating of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a focused property-update tool, the combination of description, 100% schema parameter documentation, and an output schema is sufficient for correct invocation. The main missing context is usage guidance and explicit no-change semantics for omitted properties, but these are relatively minor at this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already fully documented with details such as ACI color meanings and lineweight units. The description merely lists property names and adds no parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Change') with a clear resource ('properties of an entity') and enumerates the exact property set: layer, color, linetype, lineweight, visibility. This distinguishes it from geometric editing siblings like entity_move, entity_scale, and entity_edit_geometry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The property list gives an implied use case: call this tool when modifying entity display/classification properties rather than geometry. However, it provides no explicit exclusions or alternatives, such as when to prefer entity_change_space, entity_edit_geometry, or layer_modify.
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?
Annotations only provide destructiveHint=false, so the description carries most of the behavioral disclosure burden. It adds valuable detail: every edge is validated before anything is written, and a malformed list fails as a whole rather than leaving a half-built path. This discloses atomicity and error behavior beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence gives the exact action, and the second paragraph explains the design rationale and validation guarantee. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich input schema, an output schema present, and the validation/atomicity behavior disclosed, an agent has enough to call this tool correctly. The main gaps are explicit routing among boundary-related siblings and whether the added boundary replaces or supplements existing hatch boundaries, but these are not fatal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the edges parameter already documented with concrete shape examples and handle described as 'Handle of an existing HATCH.' The description adds only the notion of typed edges and validation, not new parameter-level semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Add'), a resource ('hatch boundary'), and the core mechanism ('built from typed edges'), so the purpose is clear. It does not explicitly name sibling tools such as boundary_from_entities or hatch_edit, leaving differentiation mostly to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The rationale paragraph implies when this tool is useful: when curves must not be silently straightened, and the handle parameter implies an existing HATCH is required. However, it does not explicitly say when to prefer this tool over boundary_from_entities, boundary_trace, or hatch_edit, nor does it state 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?
Annotations carry only the title and no safety hints, so the description bears the full burden. It clearly discloses the freeze effects: invisible, unselectable, and faster regeneration. This is useful behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with no filler. The core action is front-loaded and the behavioral effects are provided in a parenthetical that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers what the tool does and its key behavioral effects. It lacks comparison to closely related layer state tools, but the operation itself is adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single 'name' parameter already described as 'Layer name to freeze'. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Freeze a layer') and adds distinctive behavioral detail: invisible, unselectable, faster regeneration. This clearly differentiates from siblings like layer_hide or layer_lock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but gives no guidance on when to choose it over alternatives such as layer_hide, layer_lock, or layer_thaw. The performance benefit hints at one use case, but no explicit when/when-not or alternative routing is 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?
Annotations already signal that the tool mutates state but is not destructive, so the description carries a lighter burden. It adds helpful context by specifying 'existing layer' and limiting the mutation to color, linetype, and/or lineweight, but it does not disclose behavior such as what happens if the layer does not exist or whether omitted properties remain unchanged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, repetition, or unnecessary structure. Every word contributes to identifying the action, target, and affected properties.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple property-update tool, the combination of a clear one-sentence description, a fully documented schema, safety annotations, and an output schema is largely sufficient for correct invocation. The only notable gap is edge-case behavior, such as null semantics or errors for nonexistent layers, which the current text leaves implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with clear descriptions, so the baseline is already solid. The description adds useful meaning with 'and/or', clarifying that the caller may modify any subset of color, linetype, and lineweight in a single call, which is not explicitly stated in the field descriptions. It does not add units or ranges for lineweight, but that is a minor gap given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('modify'), a targeted resource ('existing layer'), and the exact properties affected (color, linetype, lineweight). It is easily distinguished from sibling layer operations like layer_freeze, layer_lock, and layer_hide, which target different behaviors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but gives no explicit guidance on when to choose it over related alternatives such as layer_set_current, layer_create, or entity_set_properties. No exclusions, prerequisites, or routing signals are provided, so usage context must be inferred entirely from the name and schema.
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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the window/crossing distinction, which is useful behavioral context, but does not go deeper into edge cases or state effects. With annotations covering safety, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. It front-loads the core concept (polygon selection) and immediately distinguishes it from rectangle selection, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a selection tool with a readOnly hint, full schema coverage, and an output schema, the description is sufficiently complete. It conveys the key differentiator and behavior. A small gap is that it does not explicitly state that the polygon must have at least 3 points, but this is covered in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters clearly. The description does not add additional parameter-level semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool performs a selection operation using a polygon, and contrasts it with rectangle-based selection. It is clear about the resource being selected, though it does not explicitly name sibling tools like selection_window or selection_filter for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when selection should be based on a polygon rather than a rectangle. It does not explicitly state when not to use it or name alternatives, but the polygon-versus-rectangle framing gives sufficient guidance for common cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (only destructiveHint false), so the description carries the behavioral burden. It adds value by disclosing that bootstrap=True seeds specific linetypes and layers, and that disabling it produces a vanilla DXF. It does not mention how the new drawing interacts with the current open drawing, but what it does disclose is meaningful and not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action. The second sentence is slightly redundant with the schema but is concise and useful for reinforcing default behavior. No filler or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, an output schema exists, and the input schema fully documents parameters. The description covers the main behavioral nuance (bootstrap) and the optional template. The only minor gap is not addressing what happens to the current drawing state, but given destructiveHint false and the presence of an output schema, this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters already have descriptive text. The description mostly restates what the schema provides (template path, bootstrap layer/linetype seeding), so it adds little beyond the structured field documentation. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create') and resource ('new empty drawing'), and specifies the optional template (.dwt). The word 'empty' helps distinguish it from drawing_open or drawing_save_as, and the bootstrap explanation adds clarity about what the tool produces beyond a blank document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this when starting a new drawing. However, there is no explicit guidance about when to prefer this over siblings such as drawing_open, drawing_save_as, or template_apply_layers. With nearly 170 sibling tools, some routing guidance would materially help an agent.
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?
Annotations already declare readOnlyHint=true, so agents know this operation is safe. The description adds the useful context that the snap is deterministic and prevents drawing errors, but it does not disclose return format, failure modes, or how ref_x/ref_y affect behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core action is front-loaded, and the practical guidance about avoiding coordinate guessing is immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With complete parameter documentation, an output schema, and readOnly annotation, the description plus structured data fully equips an agent to call this tool correctly. No meaningful context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully explains all four parameters. The description adds no parameter-level detail beyond 'entity' and 'snap point', which is acceptable because the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: compute a deterministic snap point on an entity. It is distinct from coordinate-guessing and from generic entity creation, but it does not explicitly differentiate itself from sibling tools like point_intersection or point_tangent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells agents to use this tool instead of guessing coordinates, which is the primary use case. However, it does not mention when not to use it or when point_intersection/point_tangent would be the better choice.
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?
Beyond the readOnlyHint annotation, the description discloses the empty-result ambiguity that motivated the design and explains that `filtered_by` reports which filters actually ran. This gives the agent useful failure-mode awareness that structured fields do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, and the two supporting sentences each add distinct value: one explains the design rationale and its failure-mode implication, the other points to the output field. No filler, though the rationale sentence is slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a read-only, fully-schema-documented filter tool: it covers what it does, why the interface is shaped this way, and what the result tells you. It does not mention how the filtered selection is consumed downstream, but the output schema presumably covers the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each of the five parameters is already documented with type, default, and meaning. The description adds the `filtered_by` reporting behavior, which is output-related rather than per-parameter, so it earns the baseline score but no more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the operation concretely as 'filter the drawing by properties' and anchors it to AutoCAD's familiar QSELECT command, which positions it as the general property-based selection tool. This distinguishes it from geometric selectors like selection_polygon and selection_window and from narrower property selectors like analysis_select_by_layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The QSELECT analogy implies this is the right tool when the selection criterion is entity properties rather than geometry or a single specific attribute. However, it never explicitly names alternatives or states when not to use it, so the agent must infer routing from the sibling list.
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 annotations only provide readOnlyHint=false, so the description carries the burden of explaining the mutation. It does so by stating it 'Creates all layers defined in the template with standard colors and lineweights.' It does not mention behavior around existing layers, duplicates, or overwriting, which prevents a 5, but the core side effect is clear and does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the available templates listed immediately and the effect stated in one sentence. Minor redundancy between 'standard layer set' and 'standard colors and lineweights' keeps it from being a flawless 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema present, the description is adequate: it identifies the template choices and the resulting layer creation behavior. It could be slightly more complete by noting what happens when layers already exist or by referencing the sibling template_list for checking template availability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the description simply repeats the template values already present in the schema ('architectural, mechanical, electrical, piping'). It adds no additional meaning beyond the schema, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Apply') and resource ('standard layer set from a predefined template'), then enumerates the exact templates available. This clearly distinguishes the tool from generic layer creation tools like layer_create or drawing_apply_iso_layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need an architectural, mechanical, electrical, or piping layer set. However, it does not explicitly state when to prefer this over sibling tools such as template_list or drawing_apply_iso_layers, nor does it mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only destructiveHint=false in annotations, the description carries the behavioral burden and delivers: it discloses the non-obvious fact that block definitions are modified (so future inserts don't reintroduce old text), explains why DIMENSION is excluded (avoiding a broken association), and clarifies response semantics via searched_types. It does not explicitly flag that replacements permanently alter drawing content unless dry_run is used, which would justify a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, with the core purpose front-loaded in sentence one and the two follow-ups earning their place: one explains block-definition behavior and response semantics, the other guards against a plausible misuse (DIMENSION). Prose is compact, though the middle sentence packs two distinct ideas into a dense form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with a full schema, an output schema, and a minimal but present annotation set, the description covers scope (types searched), a surprising side effect (block definitions), an exclusion (DIMENSION), and response-field intent. Little is missing for correct invocation; only an explicit irreversibility/preview warning would round it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters (find, replace, layer, dry_run, match_case). The description adds no per-parameter detail beyond what the schema provides, so the baseline 3 applies. The mention of searched_types concerns the response, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence uses a specific verb ('Replace') with a precise resource scope ('TEXT, MTEXT and block attributes (ATTRIB and ATTDEF)'), making the operation and target types unambiguous. The explicit enumeration of entity types distinguishes it from related siblings like entity_edit_text and text_set_background without needing to inspect them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful scope context: which entity types are covered, that block definitions are included, and that DIMENSION text is out of scope with a rationale. However, it stops at implied usage — it never names an alternative tool (e.g., entity_edit_text for single-text edits) or states an explicit condition for when to choose this tool over those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses meaningful behavior beyond the annotations: title text is used verbatim with no LLM transformation, the border frames the printed sheet rather than the model, and the current space is restored afterward. These are exactly the behavioral details an agent needs and none contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences: the specification is stated first, followed by the essential layout nuance and the restoration guarantee. Every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Behavioral guidance is solid and an output schema exists, so return values are covered. However, the tool has 15 parameters and very low schema coverage, and the description leaves most parameter semantics to inference. It also does not mention prerequisites like an open drawing or explicitly pointing to layout_create, though the schema does reference layout_create.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value for 'title' (verbatim usage) and 'layout' (paper-space behavior and space restoration), but schema coverage is only 20% across 15 parameters. Most parameters such as date, scale, units, origin_x, origin_y, material, revision, and checked_by receive no semantic elaboration, so 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as an ISO 7200 / A3 (420x297 mm) title block and implies the operation of applying/creating it. It does not explicitly state an action verb like 'creates' or 'applies', and it does not contrast with sibling tools, but the title and context make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong when-to-use guidance: pass 'layout' when the title block belongs on a paper-space layout, and explains why it belongs there (it frames the printed sheet, not the model). It also reassures that the current space is restored. It does not name alternatives or explicitly say when not to use it, but no sibling tool appears to duplicate title-block creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=false and destructiveHint=false, the description adds meaningful state semantics: it ends the COM undo mark, retains undoability via drawing_undo, and discards the ezdxf rollback snapshot. This clarifies what 'permanent' means and prevents the agent from assuming the changes become un-undoable. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core operation, and each engine-specific line adds a distinct fact about behavior. There is no filler or repetition of schema or annotation data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter commit operation, the description covers the important behavior and an output schema exists to describe the return value. The only gap is that it does not state the precondition that a transaction must already be active, or the behavior if none is. This is minor but enough to keep it below a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add beyond what the schema already conveys. Baseline 4 applies for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names the operation and its object explicitly ('Commit the current transaction'), so an agent knows this finalizes an in-progress transaction. The engine-specific notes clarify what commit means in each backend, and the name distinguishes it from transaction_begin and transaction_rollback, though no sibling is named directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when a transaction is active and changes should be kept, but it never explicitly says 'use this instead of transaction_rollback' or what happens if no transaction is open. A capable agent can infer it from the COM/ezdxf effects, but the guidance is not 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 is consistent with the readOnlyHint and idempotentHint annotations, and it adds meaningful behavioral detail by specifying 'Euclidean distance,' signaling a pure mathematical calculation rather than a geometric entity measurement. It does not mention units or drawing-plane assumptions, but the annotations already cover the safety and side-effect profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant restatement of the tool name. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-point distance calculation with a full output schema and complete parameter descriptions, so the description is mostly sufficient. The only missing piece is explicit guidance on when to use this tool versus naming sibling measurement alternatives, but the low operational complexity keeps this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the four parameters already described as 'Point 1 X,' 'Point 2 X,' etc. The tool description adds no further meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Measure') and a precise object ('Euclidean distance between two points'), which clearly distinguishes it from sibling tools like analysis_measure_area or analysis_measure_entity. The mention of 'Euclidean' also defines the exact math operation rather than leaving it vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'between two points' implies the tool is appropriate when the user has two coordinate pairs and wants straight-line distance, but it does not explicitly compare against alternatives such as analysis_measure_entity or analysis_measure_area. There is no when-not-to-use guidance or exclusion of other measurement 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?
The description correctly indicates a mutating operation, consistent with readOnlyHint=false, but it adds little beyond the annotation. It does not disclose behaviors like failure modes, tag matching rules, or whether unspecified attributes are left untouched. The core mutating behavior is nevertheless clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and front-loaded with the action. There is no filler or redundant elaboration; every word contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with a fully described schema and an output schema, the description is largely sufficient. It could have mentioned the relationship to block_get_attributes or partial-update behavior, but the input schema already conveys the TAG→value update pattern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents both parameters: handle as the block reference entity handle, and attributes as TAG-to-value mappings. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update attribute values in a block reference' uses a specific verb and resource, clearly distinguishing it from read-oriented siblings like block_get_attributes. It also aligns with the tool name and title without being a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's context clear: modifying attributes on a block reference. It does not explicitly name alternatives or state when not to use it, but the operation is specific enough that an agent can infer when this tool is 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 destructiveHint=false provided by annotations, the safety profile is already clear. The description adds behavioral context about the datum's effect on gdt critique outcomes, which goes beyond annotations. However, it does not disclose what the tool returns or whether it requires existing geometry at the x,y location, leaving some behavior 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action ('Place a datum feature symbol') and then the functional purpose. Every sentence earns its place, and there is no redundant repetition of the title or schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a GD&T placement tool with a complete schema and an output schema, the description provides the essential purpose and effect. It connects the tool to the broader critique workflow, which is important for agent decision-making. Minor gaps such as prerequisites (e.g., open drawing, attached geometry) and return behavior are not covered, but the overall context is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The description adds a little context by mentioning the filled triangle and boxed letter, but it does not elaborate on x, y, size, or layer beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Place') and resource ('datum feature symbol (filled triangle + boxed letter)'), and explains the functional consequence ('Establishes the datum so a feature control frame referencing this letter passes the `gdt` critique focus'). This clearly distinguishes it from sibling tools like gd_frame, which places the feature control frame itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the context in which the tool should be used: when a datum is needed so that a feature control frame referencing that letter will pass the gdt critique. It does not explicitly name alternatives or exclusions, but the reference to feature control frames and the critique focus gives an agent enough situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses that the operation creates a dimension entity, which is consistent with readOnlyHint=false. It adds the behavioral nuance that the dimension reflects true distance rather than a projected distance, though it does not mention side effects like placement on the current layer or associativity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every phrase ('aligned dimension', 'true distance', 'between two points') carries meaning. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity creation tool, the description plus fully documented parameters and output schema cover the necessary calling context. The main omission is an explicit note that the dimension is created in the current drawing and uses current dimension settings, but these are reasonable defaults for a CAD tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions already explain the point coordinates and dimension-line position. The description adds only the conceptual 'two points' context, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Create an aligned dimension') and clarifies the exact geometric behavior: it measures the true distance between two points. This distinguishes it from horizontal/vertical linear dimensions and other dimension siblings, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'true distance' implies it is intended for measuring points that are not orthogonally aligned, but it never states when to choose this over dimension_linear or dimension_auto, nor does it mention exclusions. Usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only provide destructiveHint=false, so the description carries the burden of explaining the tool's effect. It adds useful context by stating the ISO 129 standard and the LINE-only limitation, but it does not disclose what happens with unsupported entity types, whether dimensions are created as new drawing objects, or how multiple entities are handled if some are invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the core action, the scope, and the key limitation without redundancy. The essential behavior is front-loaded, and the V1 constraint is stated directly after the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with full schema coverage and an output schema, the description is mostly complete. It covers what the tool does and the most important usage restriction. It would be slightly stronger if it explained the behavior when non-LINE entities are passed, e.g., whether they are ignored or cause an error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by clarifying that 'handles' must refer to LINE entities (V1 limitation) and that the output follows ISO 129 conventions. This is a genuine semantic addition beyond the parameter names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Generate'), a resource ('ISO 129 dimensions'), and a clear scope ('across the listed entities in the chosen style'). It also adds the critical V1 constraint ('LINE entities only'), which differentiates this tool from single-entity dimension tools like dimension_linear, dimension_aligned, and dimension_radius.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you have a list of entity handles and want dimensions in a chain, baseline, or ordinate style. It also gives an exclusion ('LINE entities only'), but it does not explicitly mention alternatives for a single dimension or explain what to do when entities are not supported.
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?
Annotations already indicate readOnlyHint=false, so the mutating nature is known. The description adds the 'optionally toleranced' detail, which is useful context, but it does not disclose placement behavior, interaction with existing dimensions, or other 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that is front-loaded with the core action and resource. It contains no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the fully documented input schema, the presence of an output schema, and the simple annotation-creation nature of the tool, the description is sufficiently complete. Minor gaps like dimension placement or leader behavior are reasonably left to the schema and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 11 parameters are already documented in the schema. The description only adds the 'optionally toleranced' hint, which loosely maps to the tol_* parameters, but adds little beyond schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a specific resource ('radius dimension'), and the target geometry ('circle or arc'), plus the optional tolerancing behavior. This clearly distinguishes it from sibling tools like dimension_diameter and dimension_linear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a circle or arc' provides clear context about when this tool applies. It does not explicitly name alternatives or state when not to use it, but the geometry context is enough for an agent to route correctly in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this tool is read-only and non-destructive. The description adds useful behavioral details beyond that: it returns '[ ]' for clean drawings and is a required check before finalization. This is meaningful operational context the annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences. The first states the action and high-level result; the second gives the critical gate requirement. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the safe read-only annotations, a fully documented single parameter, and an output schema, the description covers what an agent needs to call it correctly. It could be slightly stronger by naming sibling alternatives explicitly, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single 'focus' parameter, including accepted values and the default behavior. The description adds no extra parameter detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb-resource pair ('Run premium-quality checks') and defines the expected result for a clean drawing. It does not explicitly distinguish itself from siblings like drawing_audit or validation_check, but the 'premium-quality' and production-gate framing gives enough identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a concrete usage rule: it is the standard production gate and must return [] before drawing_finalize. It does not enumerate alternatives or say when not to use it, but the gate statement gives actionable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=false annotation, the description discloses a important behavioral trait: rows x cols is unbounded, so even a 40x40 grid returns 1600 full records, making it a result-heavy tool. It also warns that fields=['handle'] is usually sufficient, which is valuable cost-awareness context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: the first sentence states the core action and return value, and the second paragraph adds a high-value behavioral warning with a concrete example. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter create tool with an output schema, the description covers the most important contextual risk—large result sets—and provides a mitigation. It does not explicitly compare against entity_array_polar, but the schema and output schema carry the mechanical details, leaving only minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds one useful semantic hint—that fields=['handle'] is usually enough—but it does not further explain rows, cols, spacing, or compact beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Create a rectangular array of copies' and explicitly says it returns info of all created copies. The 'rectangular' qualifier distinguishes it from sibling entity_array_polar while still identifying this as a create-type tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful invocation guidance, such as recommending fields=['handle'] because the tool is result-heavy. However, it does not explicitly state when to choose this tool over entity_array_polar or other array/create alternatives, so the when-to-use vs alternatives dimension 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?
Annotations already signal that the tool is not read-only (readOnlyHint: false) and not marked destructive, so mutation is expected. The description adds a version/entity-type constraint and return-type hint, but it does not disclose that the default trim=true behavior may trim or modify the source lines; that key side effect appears only in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler: the action and result are front-loaded, and the key limitation is stated immediately after. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, output schema, and annotations, the description is largely sufficient: it clearly states the LINE+LINE-only constraint and the new chamfer LINE result. It would be slightly more complete if it mentioned the default trimming behavior or pointed to entity_fillet for arc fillet cases, but those are covered or inferable from structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured parameter documentation already explains every argument including trim behavior and dist2 symmetry. The description itself adds no parameter-level meaning beyond the general line-line context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Bevel'), names the resource ('a corner with a chamfer line'), and clarifies the resulting object is a chamfer LINE. The explicit 'V1 supports LINE+LINE only' further distinguishes it from related fillet/trim operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys the intended use case: chamfering a corner formed by two line entities, with the explicit limitation 'LINE+LINE only' acting as a when-not for other entity types. It does not name an alternative like entity_fillet for non-line corners, so it stops short of full routing 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?
Annotations already indicate this is not read-only, and the description aligns by saying 'Create', which signals mutation. The description adds the concrete behavioral detail of word-wrap at a specified width, but does not disclose other side effects like whether an entity ID is returned or how defaults behave beyond what the schema already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the key action, resource type, and distinguishing feature (word-wrap at width). Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create-entity tool with a fully documented 8-parameter schema and an output schema present, the description provides enough context for selection and invocation. It could improve by explicitly referencing entity_create_text as the single-line alternative, but the core information is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all eight parameters are already fully documented in the schema. The description only reiterates the width concept without adding new parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a specific resource ('multi-line text entity (MTEXT)') and adds a distinctive behavior ('word-wrap at the specified width'). This clearly differentiates it from sibling tools like entity_create_text, which creates single-line text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys the tool is for multi-line text with word-wrap, which gives an agent contextual grounds to select it over entity_create_text or other create-entity tools. However, it does not explicitly state when not to use it or name alternatives.
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?
Annotations already establish the safety profile (readOnlyHint=false, idempotentHint=false), so the description's burden is lighter. It adds genuinely useful behavioral context beyond annotations: the result is a single 'closed' polyline rather than four line segments or an open polyline, and it delegates to entity_create_polyline. However, it does not disclose effects on current drawing state, error conditions, or coordinate-system assumptions, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The primary action and result shape are front-loaded, and the sibling-routing note earns its place in the second sentence. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple convenience wrapper: the schema documents all parameters with defaults, annotations cover mutation and non-idempotency, and an output schema exists so return values need no explanation. The wrapper note contextualizes behavior via entity_create_polyline. The only minor gap is that axis-alignment/current-UCS assumptions are implied but not explicitly stated, which is reasonably inferable from the two-corner-point geometry.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — all six parameters (x1, y1, x2, y2, color, layer) already have meaningful descriptions with defaults. The description's 'between two corner points' is consistent with the schema's 'First corner'/'Opposite corner' but adds no new parameter-level meaning. Baseline 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create a closed rectangular polyline between two corner points.' The geometry is precisely defined (closed, rectangular, between two corners), and the wrapper note names entity_create_polyline, distinguishing it from the many other entity_create_* siblings without needing their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Convenience wrapper around entity_create_polyline' gives clear context that this is the specialized path for rectangles, implicitly telling the agent to use this instead of hand-building a polyline with entity_create_polyline. It provides a clear usage context but does not explicitly state when-not-to-use or enumerate alternatives like entity_create_line or entity_create_circle.
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 only a title annotation, the description carries the burden of behavioral disclosure. It clearly states the two key effects: entities become invisible but remain processed during regeneration. It does not explicitly mention reversibility or restrictions such as current-layer behavior, but the core state change is honestly and precisely described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence with a behavior parenthetical. Every word contributes meaning, and there is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one required parameter, an output schema, and a precise behavior note, the description is nearly complete. The only missing context is edge-case behavior such as whether the current layer can be hidden or whether this setting persists through save/reopen, but these are minor for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter, including 'Layer name to turn off'. The tool description adds no parameter-specific syntax or format details beyond that, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('turn off') and resource ('layer'), and the parenthetical 'still processed in regeneration' precisely distinguishes this from the sibling layer_freeze tool. An agent can tell exactly what operation it performs without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The behavior note about regeneration provides an implied decision point (use hide when the layer must remain in regeneration, as opposed to freezing), but it never names layer_freeze, layer_show, or layer_isolate, nor states when not to use this tool. Guidance is implicit 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 clearly discloses the side effect that all other layers will be hidden, which is important behavioral context beyond the readOnlyHint=false annotation. It does not mention whether the previous visibility state can be restored, but the core mutating behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that communicates the tool's entire behavior with no filler. Key information is front-loaded and the parenthetical 'layer isolation' reinforces the conceptual name without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutating tool with 100% schema coverage and an output schema present, the description is largely complete. It fully specifies the operation's effect. The only minor gap is not explaining how to undo the isolation, but this does not prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description already states that the named layer stays visible while all others are hidden. The tool description adds no new parameter-level detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('hide') and resource ('all layers'), with a precise exception ('except the specified one'). This clearly distinguishes layer_isolate from sibling tools like layer_hide and layer_show by describing a unique all-except-one behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied by the description: use this when you want to focus on a single layer and hide everything else. However, it does not explicitly state when to prefer this over layer_hide/layer_show, nor does it mention any prerequisites or restoration behavior.
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?
Beyond the sparse annotations (only destructiveHint=false), the description discloses important behavioral details: the viewport centers on the given model-space point and the view height is determined by height/scale. This adds real context about how parameters affect the resulting viewport without contradicting the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the core purpose and then provides the single most important formula for understanding how the viewport is computed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate 8-parameter complexity, full schema coverage, and presence of an output schema, the description covers the essential behavior well. It could mention prerequisites like requiring a valid existing layout, but the current description plus schema is adequate for an agent to call the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the relationship between scale, height, and view_center_x/view_center_y. The formula 'view height = height / scale' clarifies semantics that parameter descriptions alone do not fully convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Place a scaled model-space viewport on a paper-space layout.' This clearly identifies the tool's function and distinguishes it from sibling tools like viewport_set_scale, viewport_lock, and viewport_delete, which operate on 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how the tool behaves but provides no guidance about when to use it versus alternatives. It does not mention that this is for creating a new viewport as opposed to modifying an existing one, nor does it reference viewport_set_scale or any prerequisite such as the layout needing to exist.
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?
Annotations only provide destructiveHint=false, so the description carries the behavioral burden. It discloses two important non-obvious behaviors: annotative entities are not resized, and the layout's main viewport is refused. Missing explicit error/refusal semantics is a minor gap, but the description adds substantial 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action. The two qualifying sentences each add unique, non-redundant constraints, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema, low annotation coverage, and presence of an output schema, the description covers the important edge cases: annotative behavior and the main viewport refusal. It is sufficient for correct invocation, though explicit refusal/error behavior would be a minor improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already documents both parameters with useful examples and source guidance. The description adds the view-height mechanism, which is helpful but not essential; the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Rescale a viewport') and adds precise scope via 'by adjusting its view height' and 'Geometric scale only'. This distinguishes it from related viewport tools like viewport_lock and viewport_delete, and from entity_scale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this should be used for setting a drafting scale on a layout viewport and explicitly warns about the main viewport exception. However, it does not explicitly state when to prefer this over alternatives or what to use for annotative scaling, leaving usage context somewhat 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 readOnlyHint annotation already declares the safety profile, and the description's 'Get' is consistent with it. The description adds scoping context ('all entities') and clarifies the return concept ('extents'), but it does not address edge cases like empty drawings or coordinate system behavior. With annotations covering the primary behavioral trait, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word adds meaning and the parenthetical clarification 'extents' improves precision without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with an output schema present, the description provides all information an agent needs to select and invoke it. There are no hidden inputs, prerequisites, or behavioral warnings missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so there are no parameter semantics to document. The baseline for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('bounding box (extents) of all entities in the drawing'). The 'all entities' scope distinguishes it from selection-based and measurement-based analysis siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when overall drawing extents are needed, but it does not explicitly state when to use this tool versus alternatives like analysis_measure_entity or view_zoom_extents. No exclusions or alternative-routing guidance are provided.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds meaningful behavioral context beyond that: the operation transforms a block reference into its individual component entities, clarifying the expected outcome of the destructive action. It does not detail edge cases such as nested blocks or attributes, but for a one-step explode operation this is reasonably 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and the target resource. Every word contributes meaning; there is no filler, repetition, or unnecessary background.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, an output schema, and annotations that already declare destructive behavior, the description is complete enough for an agent to understand what the tool does and invoke it correctly. The schema covers the parameter, and the description covers the operation's essence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the handle parameter as a block reference (INSERT) entity handle. The tool description itself does not add parameter-specific detail, but because the schema fully covers the parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Explode'), a precise resource ('block reference'), and a clear outcome ('into its individual component entities'). The description clearly distinguishes this from the many block_* sibling tools such as block_list, block_insert, and block_find_references, which perform different 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, and no alternative tool is named. However, the tool's unique purpose among siblings implies usage when a block reference must be decomposed into editable component entities, so the guidance is somewhat implied rather than missing entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a meaningful behavioral limitation: only the backend's default 200 INSERTs are scanned, and the compact envelope's total counts only references found within that scan. This adds real context beyond the readOnlyHint annotation and helps set accurate expectations about completeness and truncation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and the follow-up sentence about the scanning limit earns its place. There is no redundant restatement of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with a rich input schema and an output schema, the description covers the essential behavioral caveat, return-shape nuance, and purpose. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters, including the compact envelope shape and the fields projection syntax. The description adds some nuance about the compact total field, but it does not meaningfully explain parameter usage beyond what the schema already documents, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—'Find all insert references to a specific block definition'—with a clear verb and resource. It naturally differentiates itself from sibling tools like block_list, which lists block definitions, by focusing on references to a definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives, nor any mention of when not to use it. The sibling set includes block_list and entity_list, but the description never explains how this tool relates to them or when one should be 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?
The description goes beyond the destructiveHint=false annotation by explicitly stating the operation is idempotent and that existing layers are not modified. This gives the agent a clear safety model without needing to infer behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences communicate the core action, the conformance criteria, and idempotency without any filler. The key behavioral fact about not modifying existing layers is placed prominently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional, fully documented parameter, an output schema, and annotations covering non-destructiveness. The description's note on idempotency closes the main behavioral gap, making it complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single 'standard' parameter with its possible values (mech, pid, iso13567), and schema description coverage is 100%. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'bootstrap' targeting 'a full ISO-conformant layer set' with 'correct colors and lineweights', making the tool's function clear and distinct from generic layer editing tools. It leaves no ambiguity about what operation is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'bootstrap' implies initial drawing setup, and 'existing layers are not modified' explains a key limitation, but there is no explicit guidance on when to choose this over sibling tools like template_apply_layers or layer_create. Usage context is implied rather than stated.
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?
Annotations already indicate the operation is not read-only and not destructive. The description adds that a new copy is created, that it is displaced by (dx, dy, dz), and that information about the new copy is returned. This gives useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, front-loaded sentence with no filler. It states the operation, the displacement behavior, and the return value efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple copy-with-offset operation, the description, complete input schema, output schema, and annotations together provide enough context. There are no ambiguous behaviors or missing prerequisites that would prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented with meaningful descriptions. The description's mention of (dx, dy, dz) aligns with the schema but adds no extra semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Copy') and resource ('entity'), and specifies the displacement behavior and return value. This clearly distinguishes it from sibling tools like entity_move or entity_mirror.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb 'copy' and the displacement parameters, but there is no explicit guidance on when to choose this tool over alternatives such as entity_move or entity_mirror. No exclusions or alternative routing are provided.
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 only destructiveHint=false in annotations, the description carries meaningful behavioral disclosure: it specifies DIN 6885 compliance and auto-sizing from the bore when width/depth are omitted. It does not describe side effects like creation of entities, but these are conventional for a draw command and no contradiction 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, purpose first and key behavior second, with no filler. Every sentence contributes to selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter drawing operation with an output schema, the description covers the view, standard, and auto-sizing behavior needed to invoke correctly. The only minor gap is not explicitly routing section-view requests to keyway_draw_section, but the front-view cue is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the prose must add meaning. The auto-size sentence clarifies exactly what happens when keyway_width/keyway_depth are null, and center_x/center_y/bore_diameter are self-explanatory naming. The layer default is already visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies what is produced: a bore plus DIN 6885 keyway in front view, and the front-view qualifier helps separate it from the keyway_draw_section sibling. It lacks an explicit main verb such as 'draws' or 'creates', but the tool name and title remove ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The front-view designation is explicit, giving the agent a clear context for selecting this tool over the section-view keyway tool. It does not name alternatives or provide when-not-to-use conditions, so it does not reach the strongest guidance level.
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 goes beyond the destructiveHint=false annotation by explicitly stating that entity handles are unaffected during the rename. This is useful behavioral context, as it tells the agent that the operation has no side effects on drawing entities. The annotation already signals non-destructiveness, but the description adds a more specific guarantee about what remains unchanged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler or repetition of schema details. The core action is front-loaded, and the extra behavioral note about entity handles earns its place by being genuinely informative. It is concise without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter rename operation, the description plus a fully documented schema and an output schema provide everything an agent needs. The old_name is identified as an existing layout tab name, the new_name constraints are in the schema, and the lack of side effects on entity handles is disclosed. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (old_name and new_name) are already fully documented in the input schema with their constraints. The description does not add new parameter-level meaning beyond calling the layout a 'paper-space layout,' which is a minor clarification. With the schema carrying the parameter details, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Rename') and resource ('a paper-space layout'), making the tool's function immediately clear. It also distinguishes this from the many sibling layout tools like layout_create, layout_delete, and layout_copy by focusing on renaming an existing layout. The added detail that entity handles are unaffected further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for renaming an existing paper-space layout, which is the natural use case. However, it does not explicitly state when to choose this tool over alternatives or mention any exclusions, such as not being usable for model space. Given the large sibling set, some explicit guidance about when a rename is appropriate versus other layout operations would help.
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?
Annotations already provide readOnlyHint=true, so safety is covered. The description adds meaningful behavioral context: deterministic candidate selection via ref_x/ref_y and the returned shape {x, y}. It does not specify what happens with parallel/disjoint entities, but the core behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with no filler. The primary operation is front-loaded, supported types are listed, the tie-breaking rule is stated, and the return shape is clearly given.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only geometric computation with a 100%-documented schema and a stated return shape, the description covers the essential selection and output behavior. No critical information needed to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents handle1/handle2 as LINE or CIRCLE and ref_x/ref_y as candidate selectors. The description reinforces the nearest-candidate behavior but does not add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compute') and resource ('intersection of two geometry entities') with explicit supported combinations (LINE-LINE, LINE-CIRCLE, CIRCLE-CIRCLE). It clearly distinguishes this from geometric-point siblings like point_from_snap and point_tangent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: call this when you need a geometric intersection of supported entity pairs. It explains the reference-point selection condition but 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?
The readOnlyHint annotation already signals this is a safe read operation. The description adds the scope 'available' and the fact that contents are included, but provides no additional behavioral context such as whether results are ordered, limited, or derived from the current drawing. This is adequate given the annotation coverage, though not especially rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with an output schema and readOnlyHint annotation, this description is complete. An agent can correctly determine what the tool does and what it returns without needing additional explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The schema fully documents the empty parameter set, and the baseline of 4 for parameterless tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List'), a precise resource ('all available layer templates'), and the scope of the result ('their contents'). This distinguishes it from related siblings like template_apply_layers, which performs an action rather than a read-only listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose clear and implies it should be used when an agent needs to inspect available layer templates. However, it does not explicitly state when to prefer this tool over alternatives such as template_apply_layers or layer_list, leaving the usage context mostly 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?
The annotations already indicate the operation is non-destructive (destructiveHint=false) but not read-only (readOnlyHint=false), meaning it changes viewport state. The description reinforces that it modifies the current view to show all entities, but adds little beyond the annotations—such as whether it affects model space or paper space, or the exact zoom behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a helpful parenthetical clarification. Every word earns its place, and the core behavior is front-loaded with no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, an output schema, and clear annotations, this description is sufficiently complete. It tells an agent exactly what the tool does, and the sibling context provides enough differentiation from other view-related tools. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter documentation is needed. The schema coverage is effectively 100% by having an empty parameter object, and the description adds no conflicting or missing information. This matches the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Zoom') and a precise resource/scope ('to show all entities in the drawing'), and the parenthetical 'fit drawing in viewport' clarifies the intended outcome. This is clearly distinct from sibling tools like view_zoom_window, which would zoom to a selected area rather than all 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'fit drawing in viewport' implies the use case: after changes or when the user wants an overall view. However, the description does not explicitly mention alternatives such as view_zoom_window or explain when this tool would be preferable, so the guidance is implied rather than stated.
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 line is infinite and placed on the CONSTRUCTION layer, which the annotations (destructiveHint=false) do not fully convey. It also hints at a temporary nature ('scaffolding') and a required cleanup step. This goes beyond the basic safety hint, providing important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the core action front-loaded. Every clause earns its place—the scaffolding note and cleanup instruction are crucial without adding bloat. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with a complete schema and annotations, the description is almost fully sufficient. It explains the purpose, usage, and cleanup requirement. The only missing piece is a mention of the output schema or return value, but that is covered by the output schema presence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions for all parameters (x, y, layer, angle_deg). The description adds minimal extra semantics beyond what the schema provides. Baseline 3 is appropriate since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Create an infinite construction line on the CONSTRUCTION layer.' It also differentiates from siblings like construction_clear by mentioning scaffolding and the need to call it before finalize. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: 'Use as scaffolding; call construction_clear() before finalize.' It implies this is not the final entity creation tool, but it does not explicitly mention alternatives like entity_create_line or state when NOT to use it. The usage guidance is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation by stating that the drawing is mutated, repairs are already applied, results are exposed as 'fixes' and 'errors', and saving is required to persist changes. It also discloses a backend-specific behavior where counts arrive as null with detail 'unavailable' rather than zero, which is genuinely useful and not available from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then adds crucial behavioral and output-context details. Every sentence earns its place: mutation warning, save requirement, fixes/errors semantics, and backend null-count behavior. There is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema present, the description is complete: it explains the tool's core behavior, mutating side effects, persistence requirement, output field meaning, and a non-obvious backend quirk. An agent has enough context to invoke it correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter semantics with 100% coverage. The description correctly spends no space on parameters, and the baseline of 4 applies for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Audit the drawing') and the resource, defining what audit means: repair fixable structural problems and report results. It is clear and actionable, but it does not explicitly differentiate itself from sibling tools like validation_check, drawing_preflight, or drawing_critique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you want structural problems fixed and reported, use this tool. It also warns that the tool mutates the drawing and that saving is required afterward. However, it provides no explicit guidance about when not to use it or which alternative tools to prefer for non-mutating validation or 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?
Beyond the annotations, which only include destructiveHint=false, the description discloses several behavioral facts: the PlanSpec is stored on the backend, surfaced for reference, and not replayed as a critique. This adds meaningful side-effect and workflow context that annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences deliver purpose, behavioral context, and workflow ordering with no filler. The most important constraint ('Commit before geometry is created') is front-loaded, and each sentence contributes distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the critical context an agent needs: what to do, when to do it, and what happens to the PlanSpec. It could more explicitly connect to drawing_preflight/spec_hash, but the output schema and 89% parameter coverage fill most remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 89%, so parameters are already well documented in the input schema. The description does not add meaningful parameter-level detail beyond using the term 'PlanSpec', which is acceptable but not an improvement over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Commit a PlanSpec') and a clear temporal constraint ('before any geometry is created'). It also distinguishes itself from critique tools by stating it is 'not replayed as a critique', making the tool's role in the drawing workflow unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear workflow context with 'Always call this FIRST in a premium workflow' and explicitly cautions that the PlanSpec is not a critique. It does not name alternative sibling tools explicitly, but the ordering guidance and exclusion of critique behavior give an agent enough direction to use it 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?
Annotations only provide readOnlyHint=false, so the description adds meaningful behavioral context by defining the angular convention: degrees, counter-clockwise, and relative to the positive X axis. This clarifies how start_angle and end_angle are interpreted. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. Every sentence carries useful information; the purpose leads, and the geometry convention follows.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and parameter descriptions cover all fields, the description is nearly complete. The main minor gap is not explicitly stating the sweep direction or start/end ordering, though the counter-clockwise angle convention strongly implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds value by stating a single consistent convention for angles across both start and end parameters, which is not fully explicit in the end_angle schema entry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create a circular arc.' This clearly distinguishes it from sibling creation tools like entity_create_line and entity_create_circle, and there is no tautology or 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for circular arcs rather than full circles or other entity types, but it does not explicitly state when to prefer this over entity_create_circle or provide exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, but the description adds important behavioral context beyond that: it warns that queries are uncapped and can return every hit in a busy drawing, with a performance-oriented mitigation. This helps the agent anticipate large results and plan output handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and every sentence adds value. The uncapped warning and the fields/compact advice are directly actionable without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, annotations cover the read-only nature, and the input schema fully documents parameters, the description is complete. It even covers the most important operational caveat—uncapped result size—which is exactly the kind of context an agent needs before invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already explains all six parameters, including field projection syntax, unknown-name behavior, and the compact envelope. The description reinforces a useful strategy for fields/compact but does not add new parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Find all entities'), a specific resource ('within a rectangular region'), and even clarifies the selection mode ('crossing selection'). This clearly distinguishes it from broader listing tools like entity_list and selection-based siblings without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear practical guidance: results are uncapped, so users should project with fields and/or compact before widening the window. It does not explicitly name sibling alternatives, but the context around when and how to invoke it safely is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful behavioral context by specifying that all attribute values are returned as a TAG-to-value dictionary, giving the agent a clear expectation of the response shape without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action, target, and output shape. Every word earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only tool with one fully documented required parameter and an existing output schema, the description is sufficient. It tells the agent exactly what the tool does and what to expect, and the annotations cover the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'handle' parameter, describing it as a block reference (INSERT) entity handle. The description adds no additional parameter-level meaning beyond that, so it does not need to compensate, but it also doesn't enrich what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a precise resource ('all attribute values from a block reference'), and the return format ('{TAG: value} dict'). This clearly distinguishes it from siblings such as block_list or block_set_attributes, since it focuses specifically on reading attribute values from an INSERT 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: retrieve all attribute data from a block reference. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to know when this getter is appropriate, especially alongside block_set_attributes for the write counterpart.
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?
Annotations already mark the tool as destructive, and the description adds valuable behavior beyond that: the operation is idempotent. It also explains the required ordering relative to finalization. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: the action, idempotency, and the required ordering. The most important behavior is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, optional-layer tool with an output schema and destructive annotation, the description covers the essential action, idempotency, and the key workflow dependency. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the optional `layer` parameter is already documented as 'Layer to clear'. The description reinforces the default CONSTRUCTION layer but does not add significant semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') with a clear resource ('every entity on the CONSTRUCTION layer'). It clearly distinguishes this scaffold-clearing operation from layer deletion and generic entity deletion tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when this must be called: before `drawing_finalize`, to satisfy the `construction_left` critique. It gives solid contextual guidance, though it does not name alternatives or explicitly say 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解仅提供readOnlyHint=false，没有破坏性提示。描述没有明确说明这是修改操作的影响（如是否可逆、对原图的影响），但也没有与注解矛盾。示例和操作列表提供了基本行为预期，但缺少对副作用或事务性的深入说明。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述结构紧凑：先说明核心功能，再用示例演示，最后给出边界条件和替代工具指引。每句话都有信息量，但示例占用了部分空间，略可精简。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
该工具只有一个参数且schema已完整覆盖，描述提供了操作类型和界线，足以让代理正确调用。但与cad_batch的区分已明确，整体对于简单批量修改场景已足够。缺少的仅是更深入的行为副作用或失败模式说明，这属于轻微不足。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
虽然schema对operations参数的描述覆盖率为100%，但描述中提供的操作含义（dx/dy、base_x/base_y/angle_deg、factor等）和示例补充了schema未详细说明的参数格式，帮助代理正确构造操作字典。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述以具体动词'Apply multiple modifications in a single call'开头，明确了资源和批量操作的核心目的。示例进一步澄清了输入格式，而'Covers move/rotate/scale/delete/set_properties only'清晰界定了范围，足以与cad_batch等兄弟工具区分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述明确说明了支持的操作集合，并直接指出对于其他操作、需要排序或需要步骤间依赖的场景应使用cad_batch。这为代理提供了清晰的何时用此工具以及何时转向替代方案的条件。
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds useful behavioral context by highlighting that the operation preserves the handle ('without deleting and recreating (which would lose the handle)') and by clarifying supported entity types ('Works on both TEXT and MTEXT').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the primary action front-loaded and the usage rationale placed immediately afterward. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-required-parameter mutation tool with full schema coverage and an output schema present, the description covers the essential purpose, supported entity types, and the key benefit of in-place editing. Nothing critical is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents each parameter, including defaults and 'unchanged if omitted' semantics. The description's phrase 'content, height, or rotation' restates the parameter names but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Edit') and resource ('existing text label') and clearly lists the changeable properties: content, height, or rotation. It distinguishes itself from create/delete operations by emphasizing 'in place' and explicitly noting it works on both TEXT and MTEXT.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: 'Use this to rename/relabel without deleting and recreating (which would lose the handle).' This explains when to choose this tool, though it does not name alternative tools or provide explicit when-not-to-use conditions.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false, establishing this is a non-read-only and non-destructive mutation. The description goes beyond annotations by specifying that movement is by a displacement vector rather than absolute coordinates or a target point, giving agents useful behavioral context about how the transformation is applied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence states the verb, object, and relevant parameters with no filler. The essential concept (relative displacement vector) is front-loaded, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple four-parameter transformation tool with full schema descriptions, annotations, and an output schema, the description is complete. It conveys the core behavior, and nothing critical like return value or prerequisites is missing given the structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents handle, dx, dy, and dz with meaningful descriptions. The tool description adds little beyond restating the displacement vector concept, which is already captured in parameter descriptions. It does not clarify units, coordinate system, or sign conventions, but the baseline for full schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and a clear resource ('an entity') plus the exact displacement vector parameters (dx, dy, dz). This precisely distinguishes it from sibling entity tools like entity_rotate or entity_copy, and there is no ambiguity about what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: whenever an entity needs a relative displacement. It does not explicitly name alternatives or exclusion conditions, but among the large sibling list there is no competing move-like tool, so the context is sufficient and no misleading guidance is present.
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?
Annotations only mark destructiveHint=false, so the description carries the behavioral burden. It adds two non-obvious behaviors: identical output across COM and ezdxf, and recording of referenced datums so that critique can match them against datum features. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the core action front-loaded and each additional sentence providing non-obvious information. No filler or repeated schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Together with a 100% documented schema and an output schema, the description is execution-ready: it states what the tool draws, its cross-backend guarantee, and how datums affect downstream critique. No critical invocation details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds one meaningful semantic by explaining that provided datums are recorded for critique validation, but it does not enrich the other parameters beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb ('Draw'), a standard ('ISO 1101'), and a distinct object ('feature control frame'), with an implementation clue ('from LINE + TEXT primitives'). That separates it from entity-creation and drawing-CAD siblings even without naming an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The description implies the use case through 'Draw an ISO 1101 feature control frame' and the note about recorded datums for critique, but an agent must infer the boundary with related tools like datum_feature.
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?
Annotations only mark destructiveHint false, so the description carries most of the behavioral burden. It discloses determinism, the geometric construction detail (40 pts/flank, circle set), optional bore/keyway, and the handle+metadata return shape—valuable beyond the schema. It could mention whether the operation inserts entities into the active drawing, but the handle return implies this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and geometry output, then the downstream workflow note. Every clause earns its place; no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, output schema, and the workflow hint toward gear_draw_section_aa, the description is complete for correct selection and invocation. It captures deterministic behavior, output contents, and return contract without needing to restate parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, and parameter descriptions already include defaults, ranges, and formulas. The tool description adds only 'optional bore + keyway', which mirrors schema default nulls; it contributes little parameter meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific operation: generating a deterministic helical gear front view, with concrete elements (involute outline, pitch/base/outer/root circles, helix symbol, bore/keyway). This clearly separates it from gear_draw_spur_front_view and gear_draw_section_aa.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use this for a helical gear front view, and the returned metadata is explicitly meant for downstream gear_draw_section_aa. It lacks an explicit exclusion such as 'use gear_draw_spur_front_view for spur gears', but the workflow context is enough to route an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide a title, so the description carries the behavioral disclosure burden. It successfully explains the observable effect: the layer becomes visible and selectable again. It does not disclose potential failure modes or permissions, but for a simple state-change tool this is reasonably complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. Every word adds meaning, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one required parameter fully documented in the schema, an output schema present, and a simple, well-defined state transition, the description is complete enough for correct invocation. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter as 'Layer name to thaw' with 100% coverage. The description does not add additional parameter-level meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Thaw'), a specific resource ('a frozen layer'), and the resulting state ('visible and selectable'). This clearly separates it from sibling operations like layer_freeze, layer_hide, and layer_lock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage when a layer is frozen, making it a direct inverse of layer_freeze. It does not explicitly list when not to use it or name alternatives, but the context is strong enough for an agent to select correctly.
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?
Annotations only provide destructiveHint=false, so the description carries the full behavioral burden. It discloses meaningful failure semantics: `skipped` names unclonable DXF types and should be checked instead of trusting `ok`, and `associativity_dropped` counts hatch boundaries that were cleared because they referenced outside objects. This goes far beyond a simple 'copy' declaration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence gives the core purpose, followed by two sentences that explain critical caveats. No redundant or filler content exists; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what is copied, what could fail, and the meaning of the return fields (`skipped`, `ok`, `associativity_dropped`). There is no output schema, so this return-value disclosure is essential. For a copy tool with these edge cases, nothing an agent needs to know to use it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters already have descriptive schema text: 'source' explains it is a layout tab and warns 'never Model', and 'new_name' states its purpose. The description adds no additional parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Copy'), a specific resource ('paper-space layout'), and enumerates the exact content copied: 'page setup, plot settings and all geometry'. This clearly distinguishes it from sibling tools like layout_create, layout_rename, and layout_delete, which perform different 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use it — when an agent needs a duplicate of an existing layout — but the description does not explicitly mention alternatives or exclusion conditions. It relies on the sibling names and the user's inference rather than providing direct routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, and the description adds meaningful scope details: it includes Model space as a layout tab, includes paper-space layouts, and indicates the current layout. This goes beyond the annotation by clarifying what exactly is listed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and informative. Every element adds value: what is listed, which layout types are included, and that the current one is identified. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only list tool with an output schema available, the description fully covers what an agent needs to know to invoke it correctly. The distinction between Model and paper-space layouts preempts likely confusion, and no prerequisites or side effects are relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meaning, and no ambiguity exists around invocation arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (layout tabs), and the exact scope (Model + paper-space layouts and current one). It also differentiates this from sibling tools like layout_create and layout_set_current by focusing on enumeration rather than mutation or selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes its use case implicit: call this when you need to enumerate layout tabs and identify the current one. However, it does not explicitly mention when not to use it or contrast with related list tools like viewport_list or layout_set_current. The intended context is clear enough but not fully 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?
The readOnlyHint annotation already declares the operation as read-only, and the description is consistent with that. The description adds the scope qualifier 'currently loaded in the active drawing,' which is useful. It does not mention ordering, duplicates, or empty-list behavior, but these are minor for a simple query, and the annotation carries the main safety signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The primary action ('Return the names') is front-loaded, and the scope qualifier ('all linetypes currently loaded in the active drawing') is concise and complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, a readOnlyHint annotation, and an output schema present, the description fully covers what an agent needs to invoke this tool correctly. Nothing important is missing: the resource type, the scope, and the operation are all stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%, so there is no parameter-level information for the description to add. The baseline for a 0-parameter tool is 4, and the description appropriately focuses on the return value instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and a specific resource ('names of all linetypes currently loaded in the active drawing'). This clearly distinguishes it from sibling tools like linetype_load (which loads rather than lists) and other list tools (layer_list, block_list) that target different object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the exact context for use: retrieving the currently loaded linetypes in the active drawing. It does not explicitly name alternatives or exclusion criteria, but for such a simple query tool the intended usage is unambiguous. A brief pointer to linetype_load would be a minor improvement.
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?
Annotations already provide readOnlyHint=true, and the description adds two behavioral details: the return value is an {x, y} point and the tool raises an error when the input point is inside the circle. These go beyond the annotation and aid correct invocation, though it does not mention the two-tangent ambiguity explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The main action, result shape, and failure condition are front-loaded in a compact and easily parseable form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complete input schema, output schema, read-only annotation, and clear error behavior described, the definition provides enough information for an agent to select and invoke the tool correctly. Nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters clearly. The description's mention of 'external point' and 'circle' maps to from_x/from_y and circle_handle, but it adds no additional parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Compute the tangent point on a circle from an external point.' It clearly distinguishes itself from sibling point tools like point_intersection or point_from_snap by naming the exact geometric operation and the result shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes the applicable case: an external point outside a circle from which a tangent is needed. It also warns when the tool is not usable ('Raises if the from-point is inside'), giving clear context. It does not explicitly name alternative sibling tools, but the use case is clear enough.
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 readOnlyHint=true already present in annotations, the description adds only marginal behavioral context: the result is 'machine-readable' and scoped to the 'active backend'. No side effects or additional behavioral traits are disclosed, but there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that directly states the action and resource. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only introspection tool with an output schema present, the description is fully sufficient. An agent can invoke this tool immediately without missing prerequisites or needing to understand return-value details, since the output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description carries no parameter burden. Baseline 4 is appropriate because no parameter semantics are needed and the schema confirms there are no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and a distinct resource ('machine-readable support modes for the active backend'). It clearly separates this from sibling tools like system_status or system_about, which concern status or general information rather than capability/support-mode discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for the active backend' gives clear context that this is for discovering what the current backend supports, and no exclusions or alternative tools are needed for a zero-parameter introspection call. It lacks explicit when-not-to-use guidance, but the context is sufficiently 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?
Beyond the destructiveHint=false annotation, the description discloses that handles may arrive in any order, that chain ordering is handled internally, and that non-closing chains are refused with an error naming the gap coordinates. It does not explicitly state whether original entities are modified or a new polyline is created, but the annotation reduces that risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences carry substantial, non-redundant information. The primary purpose is front-loaded, and every sentence earns its place without filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a full output schema and a safety annotation, the description covers the essential semantics: input, ordering, closure requirement, and failure behavior. A minor gap is the lack of explicit guidance on where the resulting polyline is created or how it relates to the original entities, but this is not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds meaningful semantic detail by clarifying that handles are order-independent and by tying the close requirement to the tolerance/rejection behavior, which enriches the agent's understanding beyond raw schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and outcome: 'Chain the given entities into one closed polyline.' It also clarifies the tool's unique responsibility—handling arbitrary handle order—which distinguishes it from merely exporting or tracing boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you have unordered entity handles that need to be chained into a closed boundary. It does not explicitly name alternatives or exclusion conditions, such as when boundary_trace would be preferable, so it falls short of full 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?
Beyond the destructiveHint annotation, it discloses exact failure behavior: ToolError on validator/critique errors; warnings only surface under payload['critique']; strict_critique escalates any issue. This is rich, actionable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact paragraphs: the first front-loads the combined operation, and the second summarizes all important failure/success semantics. Every sentence contributes; the critique-focus list is targeted, not padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Together with full schema documentation, an output schema, and the destructiveHint annotation, the description covers what the tool runs, when it fails, and what it returns. Minor ambiguity remains about the default save destination when save_path is omitted, so it is not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters fully. The description reinforces the strict_critique behavior and save/screenshot effects but adds no new parameter meaning beyond what the input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific combined action—validate via an 8-step validator plus six named critique focuses, then save, screenshot, and return the DWG path. This clearly distinguishes it from simpler siblings like drawing_save, drawing_critique, or validation_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It frames the tool as the 'premium completion gate' and explains the strict_critique option, giving clear completion-flow context. It does not explicitly state when not to use it or name alternative tools for validation-only or save-only needs, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only a title, so the description carries the behavioral disclosure burden. It explains a non-obvious behavior: the on-disk format is derived from the file extension and format only overrides when the extension is unrecognized. This is valuable. It does not mention overwrite behavior or permissions, but the core behavioral quirk is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence states the core purpose; the second delivers the critical format-resolution rule. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description is largely complete: it covers the required path, the optional format override, and the format-resolution edge case. It could additionally mention overwrite semantics, but the essential information needed to call the tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful nuance beyond the schema by clarifying that the extension is authoritative and by giving a concrete example ('part.dxf' writes DXF, not DWG). This helps the agent understand the relationship between path and format more deeply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Save'), a clear resource ('current drawing'), and the distinguishing scope ('to a new path/format'), listing the supported formats DWG, DXF, and DWT. This differentiates it cleanly from siblings like drawing_save and drawing_export_dxf without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly signals that this tool is for saving to a new path/format, which implies the appropriate use case versus drawing_save. It does not explicitly exclude alternatives such as drawing_export_dxf, but the 'new path/format' framing plus the format-resolution detail provides clear contextual 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?
Annotations only declare readOnlyHint=false, so the description must carry behavioral weight. It does add performance intent and the batch-composition behavior vs cad_batch, but it does not disclose failure semantics, atomicity, or limits on batch size. This is useful but not rich enough to exceed a mid 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every part earns its place: purpose, required structure, example, and the comparative guidance with cad_batch. It is compact, front-loaded with purpose, and the example is directly useful rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the essential call-shape, example, and relationship to cad_batch. It does not mention edge cases like invalid entity types or partial failures, but those are secondary given the schema richness and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes beyond schema by giving a concrete two-entity example showing exact dict shapes for line and circle, and by emphasizing the required 'type' key in a direct, actionable way.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource pair: 'Create multiple entities in a single call.' It explicitly positions this against cad_batch and the single-entity create tools, making its role in the sibling set 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: use for better performance, use for many entities of the same kind, and use cad_batch when calls differ, must be ordered, or must feed each other. It also notes this tool can be a step inside cad_batch.
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?
Annotations already mark readOnlyHint=false and destructiveHint=false; the description adds that edits happen in place, the handle is preserved, and omitted arguments leave values unchanged. This is meaningful behavioral context beyond the annotations and is consistent with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three terse lines: purpose, per-type parameter mapping, and preservation rule. Every sentence carries information and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, mid-complexity tool with output schema and annotations, the description covers the essential cross-parameter constraints and omit behavior. It doesn't explicitly address invalid parameter/entity-type combinations (e.g., passing x1 for CIRCLE), but that is reasonably inferable from the per-type mapping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with individual descriptions, but the description adds entity-type parameter groups (CIRCLE/LINE/ARC) and the 'left out is unchanged' semantics that the null defaults alone don't convey. That meaningfully augments the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Edit') and resource ('defining geometry of an existing entity'), and clarifies scope with 'in place (no delete/recreate)'. This distinguishes it from entity_create_* and other modify tools such as entity_mirror/entity_trim, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Shows it applies to existing entities and explicitly excludes delete/recreate, and the per-entity parameter mapping guides correct use. It doesn't name sibling alternatives (e.g., entity_create_line vs this) nor give explicit when-not conditions beyond the delete/recreate exclusion, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry destructiveHint=false and a title, so the description bears the transparency burden. It discloses a genuinely non-obvious behavior: applying a background to a TEXT entity 'would report success and change nothing' — a silent no-op failure mode. This is exactly the kind of behavioral insight an agent needs and cannot infer from 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. The primary purpose is front-loaded, and the critical MTEXT-only constraint follows immediately. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with 100% schema coverage and an output schema, the description carries the essential context: the use case, the limitation, and the failure mode. It does not cover behavior for invalid handles or non-MTEXT/non-TEXT entities, but the 'MTEXT only' framing plus the TEXT warning cover the realistic failure cases sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with color, scale, handle, and enabled all documented in the input schema itself. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — 'Mask what is behind an MTEXT' — and explains the purpose (keeping text readable over hatch or geometry). It also distinguishes this tool from anything targeting TEXT entities, which uniquely identifies its scope among siblings like entity_create_mtext and entity_create_wipeout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (when MTEXT needs readability over hatch/geometry) and an explicit exclusion: TEXT has no background-fill attribute, so using it on TEXT would silently do nothing. It does not name an alternative tool (e.g., entity_create_wipeout) for masking behind generic geometry, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering the safety profile, the description adds meaningful behavioral detail: zooming to extents by default, zooming to a window when coordinates are supplied, and then capturing a screenshot. This discloses the operation order and conditional behavior beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and then the use case. There is no wasted text; every phrase contributes to selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with only optional parameters and no output schema, the description covers what the tool does, when to use it, and the parameter-dependent behavior. It does not describe the exact screenshot return format, but that is implied and not critical for using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter is already described. The description adds value by clarifying the conditional behavior: coordinates switch the zoom from extents to a window. This helps an agent understand that providing all four corner coordinates changes the zoom mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Zoom to extents (or window if coordinates given), then capture a screenshot.' This clearly distinguishes the tool from the sibling single-purpose tools view_zoom_extents, view_zoom_window, and view_screenshot by combining both actions into one workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'The most useful tool for visually inspecting drawing state.' This tells an agent when to prefer this tool. It does not explicitly name alternatives or state when not to use it, but the recommendation is strong and intelligible.
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?
Beyond the readOnlyHint annotation, it discloses that coordinates are WCS, extrusion is reported, and the payload is the raw attribute set entity_get omits. This lets an agent correctly interpret the coordinate frame without having to guess from the output 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence establishes the tool in a few words. The second sentence adds two useful behavioral facts, WCS and extrusion, plus the relationship to entity_get, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one required parameter, an output schema, and a read-only annotation, the description covers the important behavioral caveats. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already gives handle a full description, and schema coverage is 100%. The tool description adds no new meaning about handle beyond what the schema provides, so the high-coverage baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: dump/returns the full DXF attribute set for one handle, framed as AutoCAD's LIST. It also distinguishes this from entity_get by noting entity_get deliberately does not carry dxf_attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the obvious alternative, entity_get, and gives the selection condition: use this when you need the raw attribute set that entity_get omits. It does not enumerate when not to use this, but the one clear sibling contrast is enough.
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?
Beyond the readOnlyHint=true annotation, the description discloses a critical hidden behavior: the MAX_LIST_LIMIT cap at 5000 and the fact that the plain list cannot report truncation because the warning only goes to the log stream. It also explains that compact=True exposes the layer's real population via total and indicates truncation via truncated. This is exactly the behavioral context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs with no filler. The first sentence states the operation and output; the second paragraph front-loads the cap and gives actionable guidance. Every sentence contributes necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only selection tool with an output schema and fully described parameters, the description covers purpose, return type, truncation edge case, and the corrective parameter for accurate counts. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is already strong, and the compact parameter's schema description is detailed. The tool description adds further value by explaining why compact matters—it is the only shape that reports truncation—and clarifying that total represents the layer's true population. This goes beyond the schema without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get all entities on a specific layer', a specific verb and resource, and clarifies the return type with 'Returns entity list with handles'. The layer scope distinguishes it from sibling tools that select by type or region, such as analysis_select_by_type and analysis_find_in_region.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong internal guidance about when to use compact=True versus the plain list, explaining the cap and the unreliable log-stream warning. However, it does not explicitly state when to prefer this tool over alternatives like entity_list, selection_filter, or analysis_select_by_type, leaving tool-selection guidance mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining key behaviors: nearest-enclosing-loop selection, edge splitting on crossings, refusal when no loop is found, and error messaging that names gaps. This gives the agent important expectations that the annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core action first, then adds edge-case behavior in short, informative sentences. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema is present and the annotations indicate a non-destructive operation, the description covers the essential invocation semantics, edge cases, and failure behavior. An agent has enough context to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well documented. The description adds some nuance around tolerance by describing the near-close gap failure mode, but it does not add substantially new meaning to the parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "create a closed polyline around a seed point" and names AutoCAD's BOUNDARY/BPOLY as the reference. The seed-point mechanism distinguishes it from the sibling boundary_from_entities, 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/5
Does 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: when a boundary must be created from a seed point and when the nearest enclosing loop is the desired result. It stops short of naming explicit alternatives or when-not-to-use conditions, but the behavioral guidance is strong 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?
Annotations declare readOnlyHint=true, and the description aligns by using 'Get' and listing no side effects. It adds expected return data beyond the annotation, including extents and units, which tells the agent what to expect without calling. It does not mention performance or dependencies, but for a read-only info tool that is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the purpose front-loaded. The return list is compact and information-dense without prose. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema, the description covers both what it does and what it returns. The 'current drawing' scope is explicitly stated. The only omission is explicit when-not-to-use guidance, but the tool's simplicity makes that non-critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the empty schema offers nothing to explain. The description clarifies that the scope is the 'current drawing,' an implicit contextual parameter not captured in the schema. Baseline 4 is appropriate because the description adds useful context for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Get comprehensive metadata for the current drawing' with a specific verb and resource. The enumerated return fields (name, path, entity_count, etc.) remove ambiguity about what 'info' means. It clearly differentiates from sibling mutation/export tools by focusing on read-only drawing-level metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this applies to the current drawing, not a specified file or entity. It doesn't name alternatives or exclusions, but the scope strongly implies use when the agent needs a summary of the active drawing's properties. Since no sibling tool overlaps exactly, the lack of explicit alternative routing is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the sparse annotations by explaining the viewport transformation rationale, per-entity refusal conditions, the freeze_dimensions exception, and the important 'moved and flagged, not refused' fallback for entities outside the viewport or sheet. This gives the agent a realistic picture of side effects and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: the core purpose, the transformation rationale, the refusal conditions, and the flagging behavior. It is front-loaded with the most important information and uses a concrete example to clarify the scaling behavior without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, an output schema, and non-trivial edge cases, the description is complete. It covers what the tool does, how scaling works, which entity types are refused, when the whole operation is refused, and how out-of-bounds results are handled. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic context beyond the schema: it explains the role of the viewport as the mapping source and clarifies what freeze_dimensions does in the context of dimension refusals. This helps the agent reason about parameter relationships and edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, unambiguous statement: 'move entities across spaces, rescaled by the viewport.' This clearly identifies the operation and distinguishes it from sibling tools like entity_move or entity_scale, since it explains the cross-space, viewport-driven transformation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is strongly implied by the description, but it never explicitly states when to prefer this tool over alternatives such as entity_move or viewport_set_scale. The refusal list tells agents when the tool cannot be used, but it does not directly mention alternative tools or conditions that would route an agent elsewhere.
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?
Beyond the annotations (destructiveHint: false), the description discloses an important behavioral guardrail: a segment_length longer than the shortest edge is refused because it would produce a plain polyline misrepresented as a cloud. This tells the agent about a failure mode that is not visible in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and every part earns its place: the first states the core purpose and geometry, the second explains the key edge-case restriction. It is front-loaded and free of fluff or redundant restating of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema description coverage, an output schema, and a non-destructive annotation, the description covers the non-obvious failure mode and the entity's defining behavior. An agent has enough to invoke the tool correctly without needing extra documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters with clear descriptions, so the baseline is 3. The description adds extra semantic value by explaining the relationship between segment_length and edge length, a constraint not present in the schema. This helps the agent reason about valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource—'Draw a revision cloud'—and immediately defines the entity as 'a polyline whose every segment carries an arc,' which clearly distinguishes it from siblings like entity_create_polyline or entity_create_line. This gives an agent a precise, non-tautological understanding of 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by specifying exactly when this tool is relevant: when a revision-cloud polyline is needed. It does not explicitly name alternatives or say 'use entity_create_polyline instead for plain polylines,' so it stops short of the highest score, but the context is unambiguous.
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?
Annotations already signal that this is not read-only and not flagged destructive. The description adds useful behavioral detail: it returns information about the newly created ARC entity, and for radius=0 it returns the first source line instead. It also discloses the LINE+LINE-only limitation, which helps set expectations before 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The core purpose appears in the first sentence, followed by return behavior and a critical version constraint. Every sentence carries useful information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complete input schema, an output schema, annotations, and a description that states the supported entity types and return behavior, the tool definition gives an agent everything needed to invoke it correctly. No critical operational context is missing for the stated LINE+LINE scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the return behavior for radius=0 and by indicating that handle1 and handle2 must both be lines. This gives the agent a better mental model of how the parameters relate to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Round a corner with a tangent arc.' It also distinguishes the tool from siblings like entity_chamfer by describing the geometry produced, and it clearly scopes the tool with 'V1 supports LINE+LINE only.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: fillet two line entities with a tangent arc. It also gives a concrete when-not condition by stating LINE+LINE is the only supported input. It does not explicitly name alternatives such as entity_chamfer, but the use case is clear enough for an agent to select it appropriately.
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?
Beyond the annotations, the description discloses that the cutter behaves as an infinite ray, that only LINE+LINE is supported in V1, and that parallel lines cause an error. The phrase 'keeping the segment' also communicates that the discarded portion is effectively removed, which is important behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler. It front-loads the core operation, then states scope, geometric behavior, and error condition. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a focused 4-parameter trimming tool with an output schema and annotation hints, the description is complete enough: it covers the operation, entity-type restriction, geometric mode, keep-side semantics, and the parallel-line failure case. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all four parameters, so the baseline is 3. The description adds semantic value by explaining the geometric relationship between target and cutter, clarifying that the cutter is treated as an infinite ray, and indicating how keep_x/keep_y select the surviving segment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: trim `target` against `cutter` and keep the segment containing a keep point. It also includes the key differentiator that only LINE+LINE is supported and that the cutter is treated as an infinite ray, which makes it distinguishable from similar sibling tools like entity_extend or entity_fillet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for line-line trimming and explicitly restricts usage to LINE+LINE, which gives the agent a clear boundary. However, it never names alternative tools or explains when to prefer entity_trim over entity_extend or entity_fillet, so the selection guidance remains mostly implicit.
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 annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds meaningful behavioral context beyond the annotations by specifying that the layer must have no entities and that Layer '0' is permanently protected, which are important constraints 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the core action and immediately follows with the most critical constraints, making it easy for an agent to parse and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with an output schema and clear annotations, the description covers all essential operational details: the action, the emptiness requirement, and the protected Layer '0'. Nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the 'name' parameter, describing it as the layer name to delete and noting it must be empty. The description adds the additional constraint that Layer '0' cannot be deleted, which is not present in the schema and helps agents avoid passing an invalid value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('layer'), and reinforces the core operation with the precondition that the layer must have no entities and that Layer '0' is protected. This makes the tool's purpose unambiguous and distinguishes it from sibling layer tools like layer_modify or layer_freeze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the conditions under which deletion is allowed: the layer must be empty and Layer '0' cannot be deleted. It does not explicitly name alternatives or when not to use this tool, but the constraints effectively tell an agent when deletion is invalid, which is strong practical guidance for a destructive operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses key behaviors: corners may be in any order, selection uses drawn position rather than stored coordinates, and zero-area boxes are refused instead of returning an empty list. These caveats materially affect how an agent interprets results and errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, focused sentences front-load the core purpose and then cover only high-value edge cases. Every sentence earns its place; there is no redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a fully documented input schema, an output schema, and a readOnly annotation, the description covers the remaining behavioral context an agent needs: corner ordering, coordinate-space semantics, and invalid-input handling. Nothing required for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by clarifying that the four corner parameters can be supplied in any order and that selection is based on drawn position, which is not obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb/resource: 'AutoCAD's ssget window/crossing selection' and the title 'Select by Window' make the scope unmistakable. This distinguishes it from sibling tools like selection_polygon and selection_filter by its rectangular window/crossing semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for rectangular window/crossing selection, and the corner-order note gives operational context. However, it never explicitly says when to prefer this over selection_polygon or selection_filter, leaving the routing decision to inference.
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?
Annotations already mark destructiveHint=true, and the description reinforces this with a direct warning that all changes since transaction_begin are lost. It also adds backend-specific detail about COM and ezdxf behavior, which is useful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the primary action, and every line earns its place. The warning is prominent and the backend notes add value without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter destructive transaction tool, the description fully covers what happens, when it applies, and what is lost. With an output schema present and no input requirements, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter semantic burden for the description to carry, and nothing else needs explaining.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Rollback'), the target resource ('the current transaction'), and the exact restoration point ('transaction_begin'). It is clearly distinct from siblings like transaction_commit and drawing_undo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies use when the agent wants to discard all changes made since transaction_begin. It does not explicitly name alternatives or exclusion conditions, but the transaction_begin/commit sibling context makes the intended pairing obvious.
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 annotations already flag destructiveHint=true, so the description does not need to restate basic destructiveness. It adds valuable behavioral detail: deleting the main viewport removes the tab's own view state and repairs the current-viewport pointer to avoid dangling references. This goes well beyond the annotation and helps the agent anticipate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear action sentence followed by a focused caveat about the main viewport. There is no redundant phrasing or filler, and the most important operational detail is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's two parameters, full schema coverage, destructiveHint annotation, and existing output schema, the description covers the essential edge case that would otherwise surprise an agent. Nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context for the force parameter by explaining that the main viewport needs force=true and describing what happens when it is deleted. This reinforces the schema description and helps the agent understand when and why to set force.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Delete a viewport.' This clearly distinguishes the tool from sibling viewport tools such as viewport_list, viewport_create, viewport_set_scale, and viewport_lock. No ambiguity remains about what action this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear condition for a special case: the layout's main viewport requires force=true. This tells the agent when to set the force flag. It does not explicitly name alternatives or exclusions, but for a deletion tool with no near-equivalent sibling, the context is adequately clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses important edge-case behavior: the main viewport is included with is_main: true, it represents tab pan/zoom state rather than a drafting viewport, and scale/locked are null on R12 documents rather than fabricated. This is exactly the kind of behavioral context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the one-sentence purpose comes first, followed by two denser but necessary caveats about main viewport semantics and R12 nulls. Every sentence earns its place with no repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a filtered listing tool with a single documented parameter, a readOnlyHint annotation, and an output schema present, the description covers all non-obvious behaviors: inclusion of the main viewport, its special nature, and legacy-format null handling. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter `layout` is already fully documented in the schema with its default and meaning ('Empty covers every sheet'). The description adds no further parameter-level detail, so the schema carries the full burden; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List paper-space viewports' followed by the concrete fields returned (handle, geometry, scale, lock state). This clearly distinguishes it from sibling mutation/viewport tools like viewport_set_scale, viewport_lock, and viewport_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose as a read-only listing operation is clear from the first line and reinforced by the parameter description. However, it does not explicitly name sibling alternatives or state when not to use it; the 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses detailed behavioral traits: result keys, empty-selection behavior (ok=True with guidance message on COM), backend fallback behavior (ok=False on ezdxf), and the nested columnar-envelope behavior for fields/compact. This is far richer than the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with a purpose statement, a compact code example, a bulleted result-key list, and a final note on parameter interaction. It is longer than minimal, but each section adds distinct value and nothing feels redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and read-only annotation, and the description still covers backend availability, empty-selection behavior, result keys, and parameter effects. A caller has all necessary information to invoke the tool and correctly interpret its results across both backends.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful interaction semantics: the columnar envelope lands under the entities key rather than replacing the result, and handles remains readable even when fields=['handle'] is passed. This clarifies parameter effects beyond their standalone schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb ('Read') and resource ('entities the user pre-selected in the AutoCAD viewport'), and the COM-backend qualifier makes the scope precise. The 'pickfirst' explanation differentiates it from sibling selection tools like selection_polygon, selection_window, and selection_filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the use case — scoping work to the user's pre-selected entities instead of the whole drawing — and provides a typical code example. It also warns about the ezdxf headless backend returning ok=False. It doesn't explicitly name alternative selection tools, but the context makes when to choose this tool clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, and the description adds substantial behavioral context beyond that: it reads real geometry including polyline bulges, exposes accuracy flags (exact, assumed_closed, self_intersecting), and documents distinct error modes for unsupported entities. This is exactly the kind of disclosure that helps an agent predict side effects and failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: the purpose is front-loaded, the geometry-fidelity caveat is meaningful, the supported/unsupported type lists are compact, and the accuracy-flag explanation is essential. The description is longer than average but not wasteful — its length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema and clear annotations, the description covers supported input types, capability-gated failures, plain errors, accuracy semantics, and the source of the handle parameter. Nothing an agent needs to call this tool correctly or interpret its results is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds useful context by explaining how flatten_tolerance relates to the reported accuracy flag and why bulge-aware measurement matters, reinforcing the parameter's purpose beyond the raw schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — measure an entity by handle — and enumerates the exact geometry types it supports. The description clearly centers on area measurement while distinguishing it from generic listing/stat tools by its geometry-fidelity guarantees. An agent can tell what this tool does 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong applicability context: lists measurable entity types, explicitly calls out LINE/TEXT/INSERT as errors, and explains that REGION/3DSOLID require a COM capability. It stops short of naming sibling tools like analysis_measure_area or analysis_measure_distance and saying when to prefer them, but the when-to-use and when-not-to-use guidance is otherwise explicit.
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?
Beyond the readOnlyHint annotation, the description discloses a key behavioral trait: the result is never truncated and the compact envelope always reports truncated=false. This is valuable runtime context that is not available from annotations or the schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences. The first delivers the core purpose and expected fields; the second adds the most important behavioral caveat. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only annotation, rich parameter schema with descriptions, and an output schema, the description covers the remaining essential context: output scope, non-truncation, and the compact envelope behavior. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning by explaining what fields exist in the block definitions and by connecting the compact envelope to the never-truncated guarantee. This goes beyond simply repeating schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states a specific action ('List'), a precise resource ('all block definitions in the drawing'), and the returned fields ('name, origin, attribute count, entity count'). It clearly distinguishes this from filtered or reference-based block tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this returns the whole block table and never truncates, which sharpens when to use it. It does not explicitly name alternatives or exclusions, but the purpose and scope are unambiguous enough for a selection decision.
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?
Beyond the destructiveHint annotation, the description discloses the default save behavior, that the drawing is saved to its current path, and that the drawing session becomes unusable until drawing_new or drawing_open is called. This gives the agent a clear mental model of the state transition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and every sentence adds essential information: what happens, what the default does, and what must happen next.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter, an output schema, and a destructiveHint annotation, the description fully covers the tool's behavior, parameter semantics, and postcondition. No important calling context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents save with a default and description, but the prose adds behavioral detail: save=true triggers saving to the current path before closing. This adds value beyond the schema's one-line parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Close the current drawing.' It clearly differentiates from siblings like drawing_open, drawing_save, and drawing_save_as by focusing on the closing action and the resulting session state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the required next action after closing ('you must call drawing_new or drawing_open before any other tool'), which is strong context for sequencing. It does not explicitly contrast with save-only alternatives, but the close/save distinction is implied by the save parameter and sibling names.
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?
Beyond the annotations, the description reveals critical behavioral details: the headless backend environment variable requirement, the shared undo history, and the redo-branch discard semantics. This gives the agent important expectations about failure modes and state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the core purpose is front-loaded in the first sentence, followed by necessary caveats. Every sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description fully covers the operational context: how redo relates to undo, the environment prerequisite, and when redo becomes invalid. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are not a burden on the description. The baseline of 4 applies, and the description correctly focuses on behavioral context rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Reapply the operation you just undid' uses a specific verb and resource, clearly defining the tool's purpose. It also implicitly distinguishes this from drawing_undo by describing the inverse operation while referencing the same undo history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that redo shares history with drawing_undo and requires EZDXF_UNDO_DEPTH, which tells the agent when the tool will work. It also gives an explicit limitation: drawing after an undo discards the redo branch, making it clear when redo is no longer applicable.
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?
Annotations already signal read/write and non-destructive behavior, and the description goes beyond them by listing covered sysvars, explaining the no-arg snapshot mode, and adding the crucial nuance that dim_text_height/dim_arrow_size etc. shape dimensions while text_size affects standalone TEXT only and does not touch dimensions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficiently packed: purpose in the first sentence, context in the second, call modes in the third, and a focused clarifying note on dimension versus text settings. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter, an output schema, and annotations covering the safety profile, the description is complete. It covers read/change modes, snapshot behavior, the friendly-key domain, and the potentially confusing dimension/text distinction. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already describes the settings parameter, friendly keys, and an example. The tool description adds meaning beyond the schema by explaining the semantic distinction between dimension-affecting keys and text_size. This earns a point above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear and specific verb-resource pair: 'Read or change common AutoCAD drawing settings by friendly name.' It further clarifies that it is a convenience facade over system variables, which sharply distinguishes it from sibling tools like system_get_variable and system_set_variable. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit call-mode guidance: 'Call with no argument to get a full snapshot' and 'pass a dict to CHANGE them.' The phrase 'without memorising sysvar names' implies when to prefer this tool over raw system-variable access. However, it does not explicitly name alternative sibling tools or describe exclusion conditions, so it stops short of full 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?
Beyond the annotations, the description reveals the auto-selection behavior for None endpoints, the LINE+LINE support limitation, and the explicit failure condition for parallel lines. These are actionable behavioral details that help an agent predict outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: the core operation is front-loaded, followed by the selection rule and the support/error constraints. Every sentence earns its place; no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and full parameter documentation, the description covers operation, parameter behavior, supported geometry, and error conditions. Nothing needed to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters (100% coverage), but the description adds the important semantic that None end_x/end_y means 'nearest endpoint to the boundary is auto-selected,' which clarifies what 'auto' means beyond the schema. This is real added value, though modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Extend') with clear resources: target and boundary. It immediately distinguishes itself from sibling geometry tools like entity_trim and entity_fillet by naming the operation and the object relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: extend a line target to a line boundary. The 'V1 supports LINE+LINE only' constraint explicitly excludes non-line inputs, and the parallel-line error tells the agent when the operation is not applicable. It does not name alternative tools, but the constraint provides enough routing 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 readOnlyHint=true already covering safety, the description adds substantial behavioral insight: the large per-entity payload cost, the role of bounding_box in that cost, the fact that plain list mode cannot communicate truncation, and that only compact mode reports total, truncated, and next_offset. This goes well beyond the annotations and helps the agent anticipate performance and pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then return shape, then the most important performance caveat, then a concrete usage example, then the paging subtlety. Every sentence carries actionable information; the length is justified by the tool's complexity and the need to warn about expensive results and truncation behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers filters, return fields, field projection, nested properties, performance characteristics, the two result shapes, paging edge cases, and downstream usage of returned handles. An output schema exists and readOnlyHint is declared, so the description does not need to restate return-value structure or safety. Nothing important for selecting and invoking this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all six parameters with 100% coverage, so the baseline is 3. The description adds meaning beyond the schema by explaining why fields projection matters, giving a concrete example with layer_filter, fields, and compact, and clarifying exactly which result envelope supports truncation reporting. This is useful semantic guidance layered on top of an already-complete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List entities in the drawing with optional type and layer filters.' It immediately states what is returned (handle, type, layer, color, type-specific properties) and how handles flow into sibling tools like entity_get, entity_move, and entity_delete. This fully differentiates it as the general entity-listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong practical context: it warns that entity_list is the most expensive server result, shows exactly when to use fields and compact, and explains the paging limitation. It also tells agents to pass returned handles to downstream entity operations. It stops short of explicitly naming alternative list-like tools or saying 'use X instead when...', so it is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the sparse annotation (destructiveHint=false) by revealing the partial-edit contract: omitted parameters are left untouched, so the tool will not reset unspecified values. It also explains the `changed` result semantics, including the empty-list behavior for no-op updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The key action is front-loaded, and the behavioral caveats are stated compactly without repeating schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema covers return shape and the annotations cover the non-destructive hint, the description adds exactly the missing operational context: partial edits are safe, and changed results distinguish real changes from no-ops. The single required parameter and optional fields are sufficiently documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds valuable cross-parameter semantics: omitted parameters are left alone, tying the null/empty defaults to a 'no change' meaning across all optional fields, which is not obvious from the individual schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Edit') and a specific resource ('an existing hatch') with the modifier 'in place,' which clearly distinguishes it from creation tools like entity_create_hatch or hatch_add_boundary. The scope is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing hatch' gives clear context: use this when modifying an already-created hatch, not when creating one or adding geometry. It does not explicitly name alternatives or exclusions, but the implied usage boundary is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a meaningful behavioral guarantee beyond the readOnlyHint annotation: 'Never truncated — a drawing's whole layer table is returned — so a compact envelope here always reports truncated=false.' This tells the agent exactly what to expect about completeness and the truncation field, which is genuinely useful and not present in the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences: the first states the core purpose and returned properties, the second front-loads the critical no-truncation behavior. There is no repetition, fluff, or unnecessary detail—every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a full output schema, the description covers all necessary context: what is listed, what properties are included, and the completeness guarantee. The parameter schemas and annotations handle the rest, so nothing important is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is a 3, but the description adds real value by listing the default returned properties and clarifying that the compact envelope always reports truncated=false, which is not in the schema text. It reinforces and complements the detailed schema documentation for both fields and compact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List all layers' and enumerates the exact properties returned (color, linetype, frozen, locked, visibility). It clearly distinguishes this read-only listing tool from mutation siblings like layer_modify, layer_freeze, layer_delete, and even from linetype_list by focusing specifically on layer state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use context clear—retrieve the complete layer table with all properties—and its 'whole layer table' phrasing signals this is the go-to inspection tool. It does not explicitly say 'use this instead of layer_modify' or list exclusions, but the context is strong enough to guide a capable agent.
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?
It reveals destructive scope beyond the destructiveHint annotation: all entities on the layout are deleted. It also explains refusal conditions, the returned 'current' layout semantics, and that handles from the deleted sheet stop resolving.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short front-loaded sentences: the core action first, then refusal conditions, then post-delete behavior. There is no redundant prose; every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With destructiveHint set, one documented parameter, and an output schema present, the description covers valid inputs, invalid inputs, destructive consequences, and post-delete state transitions. Nothing needed for safe invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents name at 100%, so the baseline is satisfied. The description adds edge-case meaning: blank names are rejected, 'Model' is invalid, and the last remaining sheet is protected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states the exact action ('Delete a paper-space layout') and the destructive scope ('every entity on it'). The 'Refuses model space' clause distinguishes it from any model-space deletion and from sibling delete tools operating on layers, viewports, or entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The constraints ('Refuses model space, a blank name, and the last remaining sheet') define when the tool will not work, giving clear operational context. It does not explicitly name alternatives or state 'use X instead,' so it stops short of a full 5, but the intended use case is unambiguous.
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 readOnlyHint=false, mutation is already implied, but the description adds valuable context beyond annotations: it sets FILEDIA=0, selects the appropriate .lin file based on MEASUREMENT, and verifies the linetype actually loaded. These details reveal behavior an annotation alone cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core purpose, and the following sentences justify the recommended usage and disclose key implementation details. Every sentence earns its place without excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a fully described input schema and an output schema, the description is complete. The agent knows what the tool does, why it is preferable to alternatives, how parameters behave, and what internal safeguards are applied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add much beyond the schema: the file default and MEASUREMENT-based selection are already in the parameter description, and the name parameter is already described with examples. The description provides no additional parameter-level semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Load a single linetype safely." It also clearly contrasts this tool with the raw system_run_command form, which helps distinguish it from both linetype_list (listing) and the raw command alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says "Use this instead of system_run_command('_-LINETYPE _LOAD ...')" and explains why: the raw form can deadlock on the FILEDIA dialog and the -LINETYPE prompt. This gives the agent a clear decision rule and names the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals meaningful behavioral traits: it sets an AutoCAD undo mark in COM, saves a DXF snapshot in ezdxf, and supports rollback of subsequent operations. It also mandates pairing with commit or rollback, which is essential behavioral guidance not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose ('Begin a transaction'). Backend differences are organized clearly under labeled sections, and the pairing requirement is a single closing sentence. No filler or redundant material.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's behavior across both supported backends and states the necessary pairing with commit/rollback. With no parameters and an output schema present, nothing essential is missing for an agent to correctly invoke and reason about this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameter semantics. With no parameters, the baseline is 4, and the description reasonably focuses on behavior rather than arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Begin a transaction (undo mark)', a specific verb and resource that clearly defines the operation. The backend-specific details (COM undo mark vs ezdxf DXF snapshot) further distinguish it from related transaction_commit and transaction_rollback tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining what the transaction does in both backends and explicitly states 'Always pair with transaction_commit or transaction_rollback.' It does not explicitly discuss when not to use it or compare it to drawing_undo, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry idempotentHint=false and destructiveHint=false. The description adds backend-specific behavior (COM native undo vs headless DXF snapshot journal), the off-by-default history, the measured 37x cost of enabling it, and the redo-branch side effect. This goes far beyond what the annotations reveal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence purpose is front-loaded, followed by three tightly focused paragraphs: backend behavior, cost with cheaper alternative, and redo side-effect caveat. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, backend differences, required configuration, performance cost, cheaper alternatives, and the redo-discard side effect, which is nearly everything an agent needs. It does not state the return value or behavior when there is nothing to undo, and no output schema exists to fill that gap; these are minor omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so the 0-parameter baseline of 4 applies. The description adds the EZDXF_UNDO_DEPTH environment variable as the only relevant configuration knob, which is adjacent to parameters but not one itself, so it slightly exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb and resource: 'Undo the last drawing operation.' It is immediately distinguishable from destructive siblings like entity_delete and from transaction_rollback, which the description explicitly names and differentiates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: on the headless backend history is off by default and requires setting EZDXF_UNDO_DEPTH, and it names transaction_begin/transaction_rollback as the far cheaper alternative for a single checkpoint. The redo-discard caveat further informs correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavior not visible in annotations: the need to append '\n' for Enter, the extra blank line or '_X\n' to exit option menus, and the deadlock risk if the prompt is left open. It also reveals the verb denylist as a guardrail, not a security boundary, which is an important caveat for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every sentence carries meaningful information: a usage pattern, a deadlock warning, and a guardrail/security clarification. It is structured with the example first and the warning clearly marked 'IMPORTANT'. Slight redundancy in the example could be trimmed but the length is justified by the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the single parameter's syntax, the most common failure mode (deadlock), the limitations of the denylist, and exactly which sibling tools to use instead. With the output schema and annotations present, nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the '\n' convention, giving examples, and describing the extra blank line requirement for commands ending at option menus. This goes beyond the schema's simple 'AutoCAD command string' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Execute an AutoCAD command string directly (COM backend only)', which clearly identifies the verb (execute), resource (AutoCAD command string), and the technical context (COM backend). It is also differentiated from sibling tools like system_run_lisp by its focus on command strings rather than LISP code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to prefer typed sibling tools (entity_delete, drawing_save_as, block_insert, drawing_purge) and explains why: they validate arguments. It also warns against using this tool for destructive commands, which is clear guidance on 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?
The annotations only declare readOnlyHint=true; the description carries the behavioral burden and does so thoroughly. It discloses backend differences, the handle overlay cap and reporting behavior, the refusal with capability 'handle_overlay' on live AutoCAD, and the Image content block return format. This is far beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense with no fluff. It front-loads the main purpose, then uses each paragraph to explain backend behavior, parameter purpose, and return format. Every sentence contributes to correct invocation or expectation-setting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly states that an Image content block with PNG data is returned. It fully documents the single optional parameter, its constraints, backend-specific behavior, and failure conditions. For a simple screenshot tool with one optional boolean, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already documents overlay_handles with high coverage, the description adds meaningful semantic context: handles are drawn at entity centres, every modify tool consumes a handle, and labels are the bridge between visual entities and actionable hex strings. It also explains failure modes and crowding behavior, enriching the parameter's meaning well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Capture a screenshot of the current drawing view.' It clearly states what the tool does and its scope, and it distinguishes itself from broader export or zoom tools by focusing on the current view. The backend distinction further clarifies behavior 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains backend-specific behavior (COM live window vs ezdxf matplotlib render) and when overlay_handles is available or refused. It does not explicitly name alternatives like view_zoom_and_screenshot, but it gives enough contextual guidance about when this tool is appropriate and when the overlay option will fail.
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?
Beyond the mutation hint (readOnlyHint=false), the description discloses that originals remain in model space, that unresolved handles are surfaced in `skipped` rather than silently dropped, and that a fully-unresolved call fails instead of creating an empty definition. These side-effect and error-handling details materially shape agent expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, and each subsequent sentence adds distinct information: non-consuming semantics, alternative tool routing, and error-handling behavior. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with an output schema, the description covers creation semantics, side effects on source entities, the placement workflow, and failure modes. The existing output schema handles return-value documentation, so nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds real value by explaining the behavior of the handles parameter (unresolved ones go to `skipped`, all-unresolved fails), which goes beyond the schema's bare 'List of entity handles to include in the block.' name, base_x, and base_y appropriately rely on the schema at full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb+resource: 'Create a new block definition from existing entities in the drawing.' The scope is sharpened by distinguishing this from AutoCAD's BLOCK command (non-consuming) and from siblings like block_insert (placement) and block_explode, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the follow-up alternative: 'use `block_insert` to place copies, and delete the originals yourself if you want the command's behaviour.' It also notes cross-engine portability ('Works on both engines'), giving an agent clear context for when and how to chain this call.
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?
Beyond the readOnly and idempotent annotations, the description discloses that the tool measures the numbers in the call, not the drawing, and that results are exact only for straight-edged polygons. It also warns about under-reporting on curved edges when bulge is omitted and references an 'assumes' field, adding meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight paragraphs with no filler. The main purpose is front-loaded, and every sentence adds either capability, usage routing, accuracy caveats, or schema-related context. The formatting makes the key warnings easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a detailed input schema, an output schema, and safe read-only annotations, this description is complete. It covers what the tool does, when to use the alternative, how curved edges affect accuracy, and what assumptions the output reports.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already documents the points array well, the description adds important semantic nuance: it clarifies the tool operates on literal coordinates rather than drawing entities, explains the bulge element's role in arc edges, and quantifies the accuracy penalty of omitting it. This goes well beyond the baseline schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it computes the area and perimeter of a polygon from supplied vertices. It also clearly differentiates itself from the sibling analysis_measure_entity, which measures real drawing geometry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool versus the alternative: use it only when you have literal coordinate vertices, and use analysis_measure_entity(handle) to measure something that already exists in the drawing. This gives an agent unambiguous routing 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?
Beyond the destructiveHint annotation, the description discloses validation-first execution, typed error kinds, on_error semantics, dry_run behavior, verbose output behavior, and the nuances of atomicity across backends. This is far more than annotations alone provide and sets accurate expectations for 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place given the tool's complexity: example, validation behavior, error model, atomicity caveats, exclusions, and sibling alternative. The core benefit is front-loaded, and the structure is skimmable with clear labels.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description correctly focuses on behavior rather than return shapes. It covers success output, verbose mode, validation, dry_run, error typing, atomicity, and exclusions, making it fully actionable for correct invocation in a wide range of scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds deep semantics for steps, bind references, '$name.field' access, '$$' escaping, dry_run validation behavior, and on_error modes. The worked example makes parameter composition concrete, going well beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Execute an ordered list of tool calls in ONE round trip,' which names a specific verb, resource, and key benefit. It also distinguishes itself from entity_batch_create by noting that tool is denser for many homogeneous entities, so the purpose is clear and differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance covers when cad_batch is appropriate and when it is not: it states that raw command/LISP escape hatches and cad_batch itself cannot be called from a batch, and recommends entity_batch_create for large homogeneous sets. This gives an agent concrete routing rules.
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:

[![autocad-mcp-ultra MCP server](https://glama.ai/mcp/servers/CaeliaEve/autocad-mcp-ultra/badges/card.svg)](https://glama.ai/mcp/servers/CaeliaEve/autocad-mcp-ultra)

Score Badge

Copy to your README.md:

[![autocad-mcp-ultra MCP server](https://glama.ai/mcp/servers/CaeliaEve/autocad-mcp-ultra/badges/score.svg)](https://glama.ai/mcp/servers/CaeliaEve/autocad-mcp-ultra)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CaeliaEve/autocad-mcp-ultra'

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