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

With no annotations, the description carries the full burden and does substantial work: it discloses that the drawing database is mutated, that changes persist to DWG/DXF on save, and that destination layers are auto-created and centroid/extents auto-computed. It stops short of stating what happens on malformed input (atomic vs. partial creation), whether the operation is undoable, or any permission requirements.

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

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

Long but front-loaded and fully sectioned: purpose, behavior, usage, grammar, parameters, returns. Every line of the shorthand grammar table earns its place by specifying a distinct callable entity form, and no sentence is redundant with another.

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

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

An output schema exists, so return values need not be explained, yet the description still summarizes them. For a one-parameter, annotation-free tool with a free-form string DSL, the mutation semantics, side effects, routing, and input grammar are all covered — nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 0% (the single 'entities' parameter is typed only as string), so the description must compensate and does: it defines the per-line shorthand grammar with ten concrete examples, coordinate formats ('x,y' / 'x,y,z', semicolon-separated point lists), and defaults (color=white, layer=0). This is far beyond what the schema conveys.

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

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

The first sentence states a specific verb (Create) and enumerates the concrete resource set (2D/3D primitives, text, dimensions, leaders, native tables). Combined with the explicit sibling routing section, an agent can distinguish this from manage_entities, manage_blocks, and manage_layouts without opening any schema.

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

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

Provides an explicit 'When to Use' clause plus four named alternatives (manage_entities, manage_blocks, manage_layouts, manage_xrefs) each with the condition that selects it. Nothing about tool selection is left to inference.

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

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

With no annotations, the description carries the full burden and does well: it declares read-only CAD behavior, states that it persists a standardized JSON file to the configured output directory, and flags the filesystem-write side effect explicitly. It omits overwrite/collision behavior, permissions, and error handling, which keeps it short of a 5.

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

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

Front-loaded purpose sentence followed by clearly labeled Behavior, Usage Guidelines, Parameters, and Returns sections. Well organized and mostly tight, though the Returns paragraph partially duplicates what the output schema already conveys.

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

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

An output schema exists, so return-value explanation is not required, yet the description still adds mutation/persistence/side-effect context and full parameter semantics. Together with the sibling routing, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it documents all four parameters with units ('floor-to-ceiling height in meters'), valid CTE climate zone examples ('A3', 'C1', 'D3'), and building typology values ('vivienda_individual', 'bloque_viviendas', 'terciario') that are not represented as schema enums. Defaults are restated from the schema, which slightly duplicates structured data.

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

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

States a specific verb (Extract) and resource (CAD thermal building envelope parameters) with the intended domain (CE3X energy certification). It also names the sibling tools (export_data, inspect_drawing, manage_entities) it should not be confused with, so the agent can route correctly without opening schemas.

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

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

Provides an explicit 'When to Use' condition (bridging CAD floor plans to CE3X/CTE DB-HE/RD 390 workflows) and an explicit 'Sibling Routing' block that names alternatives and the conditions selecting them (export_data for generic takeoffs, inspect_drawing for spatial queries). Nothing is left to inference.

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

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

With no annotations provided, the description carries the full burden and does so: it states read-only-ness for geometry, that excel/bc3/pdf formats write persistent files to the output directory, that files may be created/overwritten, and that json is purely in-memory. This is exactly the safety and side-effect context an agent needs before invoking.

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

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

Heavily structured with labeled sections and front-loaded, but somewhat verbose: the Returns section is redundant with the existing output schema and the mutation/persistence/side-effects bullets could be tightened. Still, nearly every line earns its place for a 4-parameter, no-annotation tool.

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

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

Given a mutation-capable export tool with no annotations and a 0%-covered schema, the description covers purpose, routing, side effects, per-parameter semantics, and return shape. An agent has everything required to call it correctly; the output schema further covers return structure.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: every parameter (scope, format, filename, paper_size) is explained with its allowed values, defaults, and per-value behavior (e.g. what each format produces, pdf paper standards). It adds substantial meaning beyond the bare property names in the schema.

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

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

The description opens with a specific verb and enumerates the concrete resources extracted (drawing measurements, bill of quantities, budget standards, vector PDF sheets), and explicitly names sibling tools it is not (export_ce3x_envelope, show_drawing_viewer, inspect_drawing). An agent can disambiguate without reading any schema.

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

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

It provides an explicit 'When to Use' section plus a 'Sibling Routing / Alternatives' list naming three alternatives with the exact condition that selects each (CE3X energy certification, browser visualization, spatial queries). Nothing is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It explicitly declares that the operation is strictly read-only, has no persistent side effects, and computes spatial relationships in-memory from the active CAD or DXF model, covering the key safety and side-effect concerns for a mutation-capable-looking tool.

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

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

The description is appropriately sized for a tool with seven parameters and four distinct modes. It is front-loaded with purpose, then behavior, usage, modes, and returns, with no redundant filler; each section earns its place.

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

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

Given the 0% schema coverage, no annotations, and an output schema already present, the description supplies everything the agent needs: mode routing, parameter meaning, behavioral guarantees, and usage alternatives. It does not need to describe return values because an output schema exists.

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

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

Schema description coverage is 0%, so the description must compensate fully, and it does. It explains every parameter in context: allowed mode values and their specific behaviors, required point format for point/snap modes, optional handle filters, snap_types values, tolerance semantics, and layer filtering.

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

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

The description states a specific verb (inspect) and enumerates the concrete resources it operates on: spatial dimensions, geometric intersections, and object snaps. It clearly distinguishes this tool from siblings through explicit routing guidance, so an agent can identify it without opening the schema.

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

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

It provides an explicit 'When to Use' section and directly names alternatives such as show_drawing_viewer, manage_entities, and prompt_user, with the condition that selects each. This fully answers when to use this tool versus its siblings.

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

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

With no annotations, the description carries the full burden and does well: it discloses that this is a mutation, that results persist to the DWG/DXF on save, and that annotation layers are auto-created as a side effect. It stops short of failure modes, required permissions/active-drawing prerequisites, and undo/rollback semantics, which keeps it from a 5.

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

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

Front-loaded with a one-line purpose, then clearly sectioned Behavior, Usage Guidelines, Actions, Parameters, and Returns. It is long, but the length is justified by 9 parameters; a few lines (e.g. restating defaults already in the schema) are mildly redundant.

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

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

Given 9 parameters, no annotations, and an output schema (so return-format detail is optional), the description is nearly complete, covering actions, side effects, and sibling routing. It omits prerequisites like requiring an open/active drawing session and behavior on error, which a mutation tool of this complexity could reasonably state.

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

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

Schema description coverage is 0%, so the description must compensate and it does: every parameter is explained with meaning, units, and defaults (offset in drawing units, text_height, prefix/suffix examples, layer defaults per action, style='overall' vs 'segments', handles=None meaning process all spaces). This adds substantial meaning the bare schema lacks.

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

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

States a specific verb+resource ('Create automated architectural annotations, centroid room labels, and linear dimension chains') and enumerates the three concrete actions it can perform. It also names the sibling tools it is NOT (draw_entities, manage_entities) so an agent can route correctly without opening schemas.

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

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

Explicit 'When to Use' conditions are given (label room centroids with areas, generate dimension chains, add leader callouts) plus a dedicated Sibling Routing section that names draw_entities, manage_entities, and the area_table operation as alternatives with the distinguishing condition for each.

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

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

With no annotations, the description carries the full burden and does so well: it discloses mutation semantics per operation, flags which commands are read-only (list, info, get_attrs), states persistence in the DWG/DXF database, and reveals a side effect (auto-creating the destination layer on insert). Missing only permission/auth requirements and error-failure behavior, which keeps it short of a 5.

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

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

Well front-loaded with Purpose, Behavior, Usage Guidelines, and Grammar headings, so an agent can stop reading early once it has what it needs. The grammar section is long but each line maps to a distinct operation, so little is padding; a slightly tighter parameter/default treatment would earn a 5.

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

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

For a single-parameter dispatcher tool with an output schema, the description supplies everything needed to invoke it correctly: operation grammar, defaults, examples, side effects, and routing to alternatives. The return values are covered by the output schema, and the description only summarizes them, which is appropriate.

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

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

Schema coverage is 0% and the single parameter is a freeform `operations` string, so the description must compensate and largely does: it documents the shorthand grammar command-by-command, enumerates valid values for `include`, lists defaults (scale=1.0, rotation=0, layer=0, color=white), and gives worked examples. Minor gap: the schema declares type string while the description also allows a JSON array form, and valid color/layer token syntax is only shown by example.

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

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

States a specific verb set (create, insert, inspect, manage) against a specific resource (reusable CAD blocks and attribute tags), and explicitly names the sibling tools it should not be confused with (draw_entities, manage_entities, manage_xrefs). An agent can distinguish it from every listed sibling without opening a single schema.

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

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

Has a dedicated 'When to Use' section with concrete trigger scenarios (doors, windows, sanitaryware, symbols) and a Sibling Routing block that names three alternatives with the condition that selects each. Nothing about tool selection is left to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses that entities are mutated, that delete|handles is DESTRUCTIVE and permanently removes handles, that changes persist on save, and that copy/paste touches internal CAD clipboard buffers while area_table creates a schedule table. It does not cover permissions/auth requirements, undo/rollback, or what happens when one operation in a multi-op batch fails.

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

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

The description is long but front-loaded with the purpose and organized under Behavior / Usage Guidelines / Grammar / Parameters headers, and the grammar block earns its length by being the only parameter documentation available. There is mild redundancy, as the operation list in 'When to Use' repeats items already covered by the purpose line and grammar.

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

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

An output schema exists, so the brief Returns note is sufficient and no return-value detail is owed. For a mutation tool with zero annotation coverage the description supplies the safety and side-effect context an agent needs, though batch atomicity and error/partial-failure semantics remain unaddressed.

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

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

Schema coverage is 0% and there is a single parameter, yet the description compensates with a full shorthand grammar including argument order and worked examples for every operation, which the schema does not provide at all. The JSON-array alternative form ('JSON array of entity operation objects') is named but never specified, leaving that half of the parameter contract under-documented.

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

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

The opening sentence states specific verbs (modify, select, transform, restyle, compute areas) and the resource (existing drawing entities), which is precise for a multi-operation tool. It also names the sibling tools it is not (draw_entities, manage_blocks, inspect_drawing, manage_layers), so an agent can distinguish it without opening any schema.

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

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

There is an explicit 'When to Use' line enumerating the supported operations, plus a dedicated 'Sibling Routing / Alternatives' section that names four alternatives and the exact condition selecting each (create geometry, insert blocks, non-mutating inspection, layer lifecycle). Nothing is left to inference.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it states that the tool mutates document-collection state, that save persists to disk, that close|false is destructive and discards unsaved edits, and that switching changes active context for all subsequent operations. The gaps are unmentioned auth/permission requirements and any failure or error semantics.

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

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

The definition is front-loaded with the core purpose and then clearly sectioned into Behavior, Usage, Grammar, Parameters and Returns; each block is useful. The Returns block is redundant since an output schema already exists, which keeps it just short of a 5.

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

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

For a single-parameter mutation tool with no annotations, the description supplies the behavior, routing, and per-command syntax an agent needs, and return-value detail is already covered by the output schema. 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.

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

Schema coverage is 0% for the single required parameter, so the description must compensate, and it largely does: it documents the shorthand grammar for each command (new, save|filename|format with default dwg, close|save_changes default false, list, switch|drawing_name) plus the accepted formats. It is weaker on the alternate 'JSON array of file operation objects' form, whose object fields are never specified.

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

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

The description opens with a specific set of verbs (open, save, create, close, list, switch) applied to a named resource (CAD drawing files .dwg/.dxf), so the tool's scope is unambiguous despite the generic name 'manage_files'. It also names the siblings it must not be confused with, letting an agent differentiate without opening any schema.

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

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

The 'When to Use' section enumerates concrete triggers (create blank drawing, save work in progress, close tab, switch active drawing) and the 'Sibling Routing' section explicitly assigns alternatives with the condition that selects them: export_data for plotting/export, manage_xrefs for non-active references, manage_session for connection lifecycle.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses mutation of the layer table, destructive semantics for delete (including the constraint that the layer must be empty and not layer 0), persistence behavior in DWG/DXF, and the immediate viewport side effect of on/off toggling.

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

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

Front-loaded with purpose, then cleanly sectioned into Behavior, Usage Guidelines, Grammar, Defaults, Parameters, and Returns. Every line is functional, though the grammar enumeration is lengthy and could be marginally tighter.

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

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

For a single-parameter mutation tool with an output schema present, the description covers behavioral traits, destructive constraints, usage routing, accepted command syntax, and defaults. Return values are summarized and backed by the output schema, so no agent-critical information is missing.

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

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

The single `operations` parameter has 0% schema coverage, yet the description fully compensates with a complete shorthand grammar (command|arg syntax per operation), a list of valid template presets, an alternative JSON array form, and documented defaults for color and lineweight.

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

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

Opens with a specific multi-verb statement of scope ('Create, modify, toggle visibility, restyle, and apply standardized AECO layer templates') tied to the layer-table resource. An agent can immediately distinguish it from sibling tools like manage_entities and draw_entities.

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

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

Explicit 'When to Use' section enumerates concrete triggers (organize drawing structure, enforce CAD standards, isolate geometry, create target layers). The 'Sibling Routing / Alternatives' block names three alternatives with the exact condition that selects each, leaving nothing to inference.

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

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

With no annotations provided, the description carries the full burden and does so: it discloses mutation scope, marks action="delete" as destructive with the exact blast radius (all entities/viewports) and its guard rails (cannot delete active layout or Model tab), notes persistence on save, and warns about the active-tab UI side effect. Only permission prerequisites and failure modes (e.g. duplicate name) are unstated, which is minor.

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

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

Well front-loaded and organized under Behavior / Usage / Actions / Parameters headings, with the destructive warning surfaced early. It is long, and the per-action required-parameter list partly restates information in the Parameters section, but most of the length is warranted by 12 undocumented parameters.

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

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

For a 12-parameter multi-action mutation tool with no annotations and 0% schema coverage, the description supplies everything needed: action enumeration, per-action required params, defaults, formats, destructive semantics, and side effects. An output schema exists, so the brief Returns line is sufficient.

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

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

Schema description coverage is 0% across 12 parameters, so the description must compensate entirely, and it does: every parameter gets meaning, allowed values, defaults, and concrete format examples (e.g. "x,y", "cx,cy,w,h", "PL-01"). The per-action required/optional mapping is additional value the schema does not express.

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

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

The first line names a specific resource domain (paperspace layouts, presentation sheets, viewports, AECO title blocks) and the per-action breakdown pins down each operation precisely. It is clearly distinguishable from siblings like manage_view, draw_entities, and export_data, which it explicitly names.

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

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

The Usage Guidelines section states when to call it (compose sheets, configure paper formats, insert viewports, add title blocks, switch sheets) and provides explicit sibling routing with conditions for three alternatives. Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does so well: it discloses mutation scope, that connection state persists across subsequent calls, and the concrete side effects (launching a CAD process, terminating a session, opening a browser dashboard). It stops short of failure modes, permissions, or what happens when no CAD app is installed, which is the only remaining gap.

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

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

Clearly front-loaded with labeled sections (Behavior, Usage Guidelines, Actions & Parameters, Returns) that make it scannable. It is long, but the length is largely justified by enumerating ten distinct session actions; the Returns section is somewhat redundant given an output schema exists.

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

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

Covers lifecycle, persistence, side effects, action catalogue, and routing to alternatives — ample for a composite session tool, and the presence of an output schema means return values need no elaboration. Missing only error/failure behavior and prerequisite conditions for connect.

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

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

Schema coverage is 0% and the single 'operations' parameter is an opaque string, so the description must compensate — and it does, explaining that it is a shorthand string or JSON array of session action objects, then enumerating all ten actions with their own parameters (count default 1, host, port). The only weakness is that the exact string/JSON grammar of 'operations' remains implicit.

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

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

States a specific verb+resource ('Manage CAD application lifecycle, COM connection, viewport controls, and undo/redo history'), and the sibling-routing section explicitly separates it from manage_view, manage_files, and draw_entities. An agent can distinguish this from every named alternative without opening a schema.

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

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

Explicit 'When to Use' plus a 'Sibling Routing / Alternatives' block naming three siblings and the exact condition that selects each ('For pure camera, zoom... prefer manage_view'). This is textbook when/when-not/alternatives guidance.

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

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

With no annotations provided, the description carries the full burden and does so: it states the mutation is viewport-only and explicitly 'Does NOT modify drawing database entities,' notes persistence until manual adjustment or close, and discloses side effects including the base64 framebuffer return from screenshot/preview. That is exactly the mutation-safety context annotations would otherwise supply.

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

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

Front-loaded with the core purpose and organized under clear headers (Behavior, Usage Guidelines, Shorthand Grammar, Parameters, Returns), so it is scannable. It runs long, with some overlap between the Behavior section and the grammar list (e.g., screenshot/preview described twice), but given 0% schema coverage the grammar list is load-bearing rather than filler.

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

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

For a one-parameter, command-string tool with no annotations, the description covers purpose, mutation scope, persistence, side effects, invocation grammar, and routing to alternatives. An output schema exists, and the description appropriately limits itself to a one-line Returns note instead of duplicating return structure.

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

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

Schema description coverage is 0% for the single 'operations' parameter, so the description must compensate and does: it documents the accepted string grammar command-by-command (ze, zw|x1,y1|x2,y2, zc|x,y|mag, preset, style, screenshot, undo/redo) including defaults for undo/redo count. This adds far more than the bare 'type: string' schema.

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

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

Opens with a specific verb+resource+scope: 'Control CAD camera viewport, display zoom, 3D viewpoint presets, and visual shading styles.' The explicit sibling-routing block distinguishes it from manage_layouts, show_drawing_viewer, and export_data, so an agent can select it without opening any schema.

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

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

A dedicated 'When to Use' list enumerates concrete triggers (zooming to extents, switching to axonometric views, changing shading, undo/redo), and 'Sibling Routing / Alternatives' names three alternatives with the condition that selects each. This is explicit when-to-use plus when-not-to-use coverage.

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

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

With no annotations provided, the description carries the full behavioral burden and succeeds. It discloses mutation of the reference table and block definitions, marks detach|name as destructive with unbinding of geometry/images, notes persistence of link paths on save, and states that external files are read from disk during attachment.

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

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

The description is long but well-sectioned and front-loaded, with behavior, usage, and grammar clearly separated. The Returns section is redundant because an output schema exists, but this is a minor efficiency issue rather than a structural flaw.

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

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

The description is very complete for a complex tool with no annotations and no schema parameter descriptions, and the output schema covers return values. However, it does not fully specify the dictionary or list input shapes beyond saying they contain action and parameters, leaving a small gap for non-shorthand invocations.

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

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

Schema description coverage is 0%, and the single input parameter is an unconstrained anyOf string/array/object. The description compensates by giving a clear shorthand grammar for every supported action, including attach, raster, list, reload, and detach, along with required arguments such as path, coordinates, scale, rotation, and name.

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

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

The description starts with a specific verb and resource: managing external CAD references (DWG XREFs) and raster cartography or orthophoto underlays. It later distinguishes this tool from manage_blocks and manage_files, so an agent can route correctly without opening sibling schemas.

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

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

It explicitly states when to use the tool: overlaying external project files as linked references without duplicating geometry. It also names alternatives and their selection conditions: manage_blocks for embedded reusable CAD blocks and manage_files for independent drawing documents.

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

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

No annotations are provided, so the description carries the full burden and meets it: it declares the operation read-only with respect to drawing geometry, states there are no persistent side effects, and crucially discloses the blocking behavior ('Pauses execution ... awaiting user mouse click or keyboard input') plus graceful ESC/cancellation handling. For a tool that halts the agent loop on human input, this is exactly the behavioral context needed.

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

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

Front-loaded with the purpose, then cleanly sectioned into Behavior, Usage Guidelines, Grammar, Parameters and Returns, so an agent can skim to what it needs. Slightly heavier than necessary: the Returns section restates information that an output schema already supplies, and the shorthand grammar, while useful, is dense.

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

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

An output schema exists, so the description does not need to own return-value documentation, and it covers everything else a caller needs: the blocking/human-in-the-loop nature, the cancellation path, exact input grammar, and routing away from non-interactive siblings. Nothing required to invoke it correctly is missing.

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

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

Schema description coverage is 0% on a single, loosely-typed anyOf parameter, so the description must compensate and does: it explains that input is a shorthand string/dictionary/list and gives the full 'action|message|optional_args' grammar with four concrete action variants and expected return payloads per action.

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

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

States a specific verb (Prompt) with a specific resource (the human user) and enumerates the exact interaction types: mouse clicks, coordinate picking, command line input in CAD. This is clearly distinguishable from siblings like inspect_drawing and show_drawing_viewer.

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

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

Explicit 'When to Use' block names human-in-the-loop workflows, and the 'Sibling Routing / Alternatives' section routes three named siblings (inspect_drawing for programmatic queries, manage_entities for programmatic selection, show_drawing_viewer for browser canvas) with the condition that selects each. Nothing is left to inference.

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

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

With no annotations present, the description carries the full burden and does so: it declares read-only semantics for CAD geometry, discloses that a standalone HTML file is written to disk, and warns that open_browser=True spawns an external browser process. These are exactly the side-effect details an agent needs before calling.

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

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

Front-loaded with the core action, then organized into Behavior, Usage, Parameters and Returns sections that are easy to scan. Minor redundancy between 'Saves a standalone HTML viewer file' and 'Writes a self-contained HTML file to local disk.'

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

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

For a two-parameter, zero-annotation tool, the description covers purpose, side effects, routing, parameter meaning and a brief return summary (status, path, entity count, launch result). An agent has everything needed to call it correctly.

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

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

Schema coverage is 0%, so the description must explain both parameters, and it does: filename is an output file name or relative path, open_browser controls automatic browser launch. It adds path semantics beyond the bare schema types, though the defaults it restates are already visible in the schema.

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

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

States a specific verb and resource: 'Generate and launch an interactive HTML5 CAD Canvas viewer in the web browser.' This is clearly distinguishable from siblings like inspect_drawing or manage_view, which are named explicitly later.

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

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

Provides an explicit 'When to Use' condition (human requests interactive panning/zooming or clicking) and a routing block that names three alternatives with the exact condition that selects each. Nothing is left to inference.

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