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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write. The description adds genuinely useful context beyond that: the wall is NOT trimmed (a side effect an agent would otherwise assume), and the layer is auto-created. It does not discuss repeat-call behavior or idempotency, but the key surprising behavior is disclosed.

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-loads the most important, non-obvious fact (the wall is not trimmed) in the first line, then tapers into Args and Returns. Every item earns its place, though the Args block partially duplicates the schema's own field descriptions.

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 purpose, prerequisite workflow, side effects, all five parameters with units and conventions, and the return payload shape. For a geometry-creating tool with an output schema, nothing an agent needs 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?

The reported schema coverage is 0%, but the nested $defs do carry field descriptions; the description largely restates them (hinge, width, closed_angle, swing_angle, layer) while adding unit examples ('900 (mm)'), the CCW sign convention, and the 'door layer' default. It grounds 'hinge-side jamb' in the gap workflow, adding context the schema alone does not.

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 ('Draw a door') and immediately enumerates the exact geometry produced ('leaf line + quarter-circle swing arc anchored at the hinge'). This distinguishes it cleanly from autocad_draw_wall and autocad_draw_room, which an agent could otherwise confuse with door geometry.

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?

Explicitly describes the prerequisite workflow: the wall is not trimmed, so the agent must leave a gap (naming autocad_draw_wall as the tool to do it with) sized to the door width, then anchor at the gap jamb. This is a clear when-to-use and how-it-composes-with-a-sibling instruction.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the safety profile is covered; the description usefully adds the non-obvious semantics that count includes the original and that (count-1) copies are produced, plus the returned handle ordering. It still omits whether the original entity is modified in place or whether the operation is undoable.

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 core purpose sentence is front-loaded and waste-free, and the Args block is scannable. The Returns block partially duplicates the existing output schema, which is the only real redundancy.

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 full annotations and a declared output schema, the description covers purpose, count semantics, parameter meanings and the response shape. 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?

The top-level `params` wrapper has no description in the schema (coverage reported as 0%), so the description has to carry meaning — and it does, enumerating handle, count with its 2-500 range, and dx/dy/dz spacing. Most of this restates the nested $defs descriptions, so it compensates rather than adds much new.

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 ('Create a linear array of copies of an entity') and immediately disambiguates scope with '(the original counts as the first instance)', which cleanly separates it from autocad_array_polar and from repeated autocad_copy_entity calls.

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 linear scope implies when the tool is appropriate, but the description never names an alternative or a condition for choosing it — notably it does not contrast with the sibling autocad_array_polar or explain when an agent should array versus copy repeatedly. Usage is inferable, not stated.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the mutation/safety profile is covered. The description adds real context beyond that: the original entity is retained and (count - 1) new copies are appended, and the call returns a JSON status with the original plus copy handles — telling the agent the write is additive rather than a replacement.

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 one-line purpose followed by a compact Args block and a one-line return summary; no filler sentences and no repetition of prose. The Args list is dense but every line maps to a distinct, decision-relevant field.

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 mutating geometry tool with an output schema and annotation coverage, the description supplies the key operational facts: what is created, that the source is preserved, and the return shape. It stops short of noting error cases (invalid handle, no active drawing) or how to undo, which are minor omissions given the surrounding toolset includes autocad_undo.

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?

Reported schema coverage is 0% at the tool level, so the description has to carry parameter meaning, and it does: it restates handle, center, count (total instances including the original, 2-500) and angle (total DEGREES, 360 = even spacing). The units/inclusivity semantics are the important disambiguators, even though they largely mirror the nested schema text.

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 — 'Create a polar (circular) array of copies of an entity around a center point' — and the qualifier 'circular' immediately separates it from the sibling autocad_array_linear. An agent can select it correctly 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?

The description says what the tool does but never states when to prefer it over alternatives such as autocad_array_linear or repeated autocad_copy_entity calls, nor any precondition (e.g., an open/active document, a valid handle). Usage is only implied by the phrase 'polar (circular) array'.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, but the description adds a genuinely useful guarantee beyond them: 'Never distorts or scales the points — it only reports whether they fit, so dimensions are never silently changed.' That directly addresses the biggest fear with a fit-checking tool wrapped around geometry APIs.

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 behavior and the no-mutation guarantee before the Args/Returns sections. Slightly boilerplate-heavy docstring structure, but every sentence carries information and nothing is 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?

Since an output schema exists, the description need not document the return payload, yet it still names the JSON keys (fits, boundary_usable_extents, requested_extents) for convenience. Combined with annotations and the no-mutation guarantee, an agent has enough to call this correctly; only the fits=false follow-up behavior is unspecified.

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 Args block adds meaning beyond the schema: points are 'corners (or any representative points)', layer is the boundary layer, and crucially margin is 'annotation margin to subtract, matching the value used when the boundary was created' — a usage constraint the field description alone does not convey. Minor gap: no note on the point-count limit or coordinate units.

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 ('Check whether proposed geometry fits inside the sheet boundary's usable area') and immediately distinguishes this verification tool from the many create/move/scale siblings. An agent can tell from one line that this is a read-only fit test, not a geometry mutation.

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?

Usage is implied by the check workflow (validate proposed geometry against an existing boundary), and the margin note hints at the prerequisite of matching the boundary creation value. However, it never explicitly says when to call this instead of, say, autocad_create_boundary or the array/scale tools, nor does it state what to do when fits=false.

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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: "Never launches AutoCAD — it only checks whether a running instance can be attached to," which prevents an agent from assuming this call spins up a session, plus the backend_selection_mode values that explain how the backend was chosen.

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 purpose and the critical non-launching constraint are front-loaded in two tight sentences, with the usage condition directly after. The Returns block largely restates the output schema, which is slightly redundant, but it is well structured and not bloated.

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 zero-parameter, read-only diagnostic with annotations covering safety and an output schema present, the description supplies everything needed: what it does, what it will not do (launch AutoCAD), and when to call it. No gaps remain for correct invocation.

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 tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. Nothing in the description misleads about inputs.

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 diagnostic verb and resource: reporting the active backend and whether live AutoCAD is reachable. This is clearly distinguishable from the many action siblings (create_line, save_document, etc.) because it is framed as a status check rather than a mutation or query of drawing content.

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?

"Use this before drawing to confirm you are actually about to draw inside live AutoCAD rather than the headless ezdxf fallback" gives a concrete when-to-use condition tied to the drawing workflow. It doesn't name an alternative tool or a when-not-to-use case, but no sibling provides overlapping diagnostics, so the guidance is effectively complete.

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?

Annotations already declare destructiveHint=false and readOnlyHint=false, so the 'original is left unchanged' claim is consistent and reinforcing rather than novel. The description goes beyond the annotations by disclosing the return payload shape (status, type, new handle, source), which is genuinely useful even though an output schema exists.

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-loads the operation and the key side-effect guarantee in one sentence, then documents args and return in a compact, scannable block. No filler sentences and nothing buried.

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-nested-param mutation tool with annotations and an output schema, the description covers what is needed to invoke it correctly: the entity reference, the displacement vector, the default for dz, and the effect on the original. It stops short of operational context such as whether the copy inherits layer/attribute data or whether a source entity handle is required to exist.

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 schema's nested CopyEntityInput properties are described in schema properties but the top-level schema description coverage registers as 0%, so the description's restatement of handle, dx, dy and dz (including the dz default of 0) is doing real work. It does not add format detail beyond the schema, such as handle validity constraints or unit semantics beyond 'drawing units'.

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 ('Copy an entity') plus the scope of the operation (offset by dx/dy/dz). The clause 'The original is left unchanged' immediately separates it from autocad_move_entity and autocad_array_linear without the agent needing to open either 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?

Usage is implied rather than stated: the non-mutating nature of the original is contrasted against move, which hints at when to prefer this tool, but no alternative tool is named and no conditions or exclusions are given. Adequate minimum, but an agent gets 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.

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

Annotations already declare readOnly=false, destructive=false, idempotent=false and openWorld=false, so the safety profile is covered. The description adds useful behavior detail — angles are in DEGREES with 0 = east/+X and CCW positive, and layer defaults to '0' — plus the response shape, but omits prerequisites such as requiring an active document and whether an out-of-range/degenerate radius errors out.

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 operation in one sentence, then a compact Args/Returns block; nothing is padded. The Returns line is somewhat redundant given an output schema exists, but it is short and harmless.

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-struct mutation tool with full annotations and an output schema, the description supplies the geometry conventions, the default layer, and the return shape — everything needed to invoke it correctly. Return-value explanation is not required since an output schema exists, so its presence is a bonus, not a gap-filler.

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?

Measured schema coverage is 0% (the single top-level 'params' field is a bare $ref), so the description has to carry the parameter burden — and it does, enumerating center, radius (>0), start_angle, end_angle with unit conventions, and the default layer. It mirrors the nested schema's own field descriptions rather than adding syntax beyond them, which keeps it at 4 rather than 5.

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 — "Draw an arc" — and adds the defining geometric semantics (counter-clockwise from start angle to end angle), so an agent knows exactly what geometry will be produced. It does not explicitly differentiate itself from siblings like autocad_create_circle or autocad_create_polyline, but those are distinct enough by name that the gap is minor.

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 no when-to-use guidance at all: nothing about prerequisites (an open/initialized drawing), when an arc is preferable to a polyline or boundary, or what happens if no document is active. The description only explains the mechanics of the call, not the context for making it.

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?

Annotations already cover safety (idempotentHint, destructiveHint=false, readOnlyHint=false), and the description adds value beyond them: it discloses the idempotent reuse semantics and the COM-backend zoom-to-extents side effect. The replace=true destructive behavior is also spelled out.

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-loads the core purpose and idempotency rule before the Args/Returns blocks. The structure is easy to scan, though the Returns block partially duplicates the output schema.

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 purpose, idempotency behavior, the replace flag, parameter meanings, and backend side effects. Since an output schema exists, the explicit Returns text is redundant but not harmful, and no critical invocation detail 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 Args section maps each shape value to its matching fields (corner1/corner2, center/radius, points) and gives defaults for margin, layer, and replace. This compensates for the reported low schema description coverage by clarifying how parameters interrelate.

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 ('Create (or reuse) a sheet boundary') and names the target layer. It is easily distinguished from geometry siblings like create_polyline or create_circle because it operates on the SHEET_BOUNDARY concept rather than raw 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?

Explicitly explains the reuse-vs-replace decision: 'if a boundary already exists on the target layer, it is reused... pass replace=true to delete and recreate it instead.' This tells the agent when the call is a no-op and how to force recreation, though it doesn't contrast against sibling creation tools.

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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the description does not need to restate that. It adds the return JSON shape and the radius>0 constraint, but omits any note about draw-order effects, layer auto-creation, or side effects beyond what the schema states.

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 one-line purpose, then structured Args/Returns sections. Efficient and scannable with minimal waste, though the Args block duplicates field documentation that also lives in the schema.

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?

With an output schema present the return shape is covered, and the description still echoes it for convenience. Combined with annotations covering safety, an agent has what it needs to call this simple one-parameter tool 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?

Top-level schema description coverage is reported as 0% (only the sole 'params' object is a parameter), so the description compensates by enumerating center, radius, and layer semantics. However, these largely restate the nested schema descriptions rather than adding new meaning like coordinate system or units nuance.

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+resource ("Draw a circle"), which naturally distinguishes it from siblings like autocad_create_arc, autocad_create_line, and autocad_create_polyline. It is clear but does not explicitly name or contrast with any sibling tool.

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 no when-to-use guidance, no prerequisites, and no mention of alternatives such as autocad_create_boundary or arc tools. The agent is left to infer everything about tool 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.

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds useful behavior beyond that: the boundary is implicitly closed, the layer is auto-created for both entities, and the exact return payload is given. It does not, however, state that each call creates new entities or that a document must be open.

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 operative sentence is front-loaded and the Args/Returns sections are tidy, but the parameter list duplicates schema content that the agent already receives, so a few lines do not earn their 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?

For a single-parameter write tool with annotations covering safety and an output schema present, the description covers purpose, parameter defaults, and return shape. Only the precondition of an active drawing/connection is unstated, which is minor given the surrounding tool set.

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 Args block restates the schema field-for-field (vertex range 3-1000, defaults 'SOLID', 1.0, 'HATCH') with no new syntax or format detail beyond what the schema properties already document. The reported 0% coverage is a measurement artifact of the single top-level 'params' property; the nested parameter descriptions are already rich, so this is redundant rather than compensating.

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 names a specific verb and resource ('Draw a closed boundary polyline and fill it with a hatch pattern'), and the two-part action implicitly distinguishes it from the sibling autocad_create_boundary, which only draws the boundary. An agent can tell what this produces 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?

There is no guidance on when to choose this over autocad_create_boundary or autocad_create_polyline, and no prerequisites are stated (e.g., requiring an open document or a live connection, which the sibling list implies matters). Usage is only implied by the verb.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the bar is lower. The description still adds real value beyond them: the create-or-update branch, and the 'warning' emitted when the requested linetype is unavailable with fallback to CONTINUOUS.

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 behavior in the first sentence, then structured Args/Returns blocks. Slightly redundant to include a Returns section when an output schema exists, but no sentence is wasted.

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 an output schema exists, the return description is optional, and the description covers the key non-obvious facts (upsert status, linetype fallback warning). It omits any statement about required document/session context, which is the one gap for a state-mutating layer tool.

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 Args block restates name/color/linetype and their defaults (7, CONTINUOUS), but the visible input schema documents each of these more richly (pattern, min/max, ACI color mapping, fallback rule). The description adds little meaning the schema does not already carry.

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 a layer') and adds the upsert nuance ('or update its color/linetype if it already exists'), which distinguishes it from autocad_delete_layer / autocad_set_layer_state. It never names a sibling explicitly, so routing depends on the agent inferring from 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?

There is no when-to-use, prerequisite, or when-not-to guidance. Nothing tells the agent whether a drawing must be open first, or when to prefer this over set_layer_state / set_current_layer. The upsert clause describes behavior, not selection criteria.

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?

Annotations already declare the write/safety profile (readOnly=false, destructive=false, idempotent=false). The description adds a genuinely non-obvious behavior beyond them: the target layer is auto-created if missing, plus a concrete return payload shape. It does not cover error/failure behavior, but the added side-effect disclosure is real value.

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?

Purpose is front-loaded in the first sentence, followed by tightly scoped Args/Returns blocks. The Returns line is mildly redundant given an output schema exists, but no sentence is wasted.

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 draw tool with an output schema, the description covers what it draws, its inputs, and the return shape adequately. The missing pieces are usage context and sibling routing rather than anything an agent strictly needs to invoke it.

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?

Top-level schema coverage is reported at 0%, so the description must carry weight, and it does enumerate start/end/layer plus an example point format and the default layer. It still omits the optional z/elevation field and drawing-unit semantics that the nested schema documents, so compensation is partial.

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 concrete verb+resource ("Draw a straight line segment"), which is unmistakable against drawing siblings like create_circle or create_arc. However, it never names or contrasts those siblings, so it falls short of full differentiation.

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 no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g. polyline for multi-segment geometry). Usage context is entirely 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the mutation/safety profile is covered. The description's additional content (2-1000 vertices, defaults, closed flag) largely restates structured data, though it does note the operation creates a new entity with a handle, which is mildly useful context about persistence.

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 core purpose is front-loaded in a single sentence, and the Args/Returns structure is easy to scan. It is slightly padded by restating schema constraints and documenting a return value that the output schema already covers, but nothing is genuinely wasteful.

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-param create tool with an output schema and full annotation coverage, the description supplies enough to call it correctly: vertex list, ordering, closed flag, target layer, and the resulting entity type. Because an output schema exists, the Returns paragraph is redundant rather than necessary, keeping this just short of a 5.

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?

Top-level schema description coverage reads 0%, but the nested properties carry their own descriptions (layer auto-creation, closed behavior, vertex ordering, coordinate examples). The description's Args section mirrors those constraints rather than extending them, adding no syntax or format detail beyond what the schema already states.

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 gives a specific verb+resource ("Draw a 2D polyline through a list of vertices") and clearly distinguishes this from single-segment siblings like autocad_create_line and shape siblings like autocad_create_circle/arc. It stops short of naming an alternative, but the geometry type does the differentiating work.

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?

Usage is implied by "through a list of vertices" – an agent infers this is for multi-segment connected geometry rather than single entities. There is no explicit when/when-not statement and no reference to alternatives such as create_line or create_boundary, so the agent must infer the boundary conditions itself.

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?

Annotations already declare the safety profile (not read-only, not destructive, not idempotent, closed-world), so the description only needs to add mutation context. Instead it largely restates schema fields plus a return shape that the output schema already covers, and says nothing about side effects, undo behavior, or layer auto-creation.

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 format is front-loaded with the verb phrase, then a compact Args list and a Returns line. It is slightly list-heavy and the Returns block duplicates the output schema, but no sentence is wasted or padded.

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?

Because an output schema exists, the return value needn't be explained, and parameters are covered. What is missing for a mutation tool is environmental context — whether a drawing must be active and what happens on invalid layer names — leaving it adequate but not complete.

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?

With reported top-level schema coverage at 0%, the description carries the burden and does so: it names all four sub-parameters, gives intent ("lower-left insertion point"), units ("drawing units"), and defaults (2.5, '0'). The nested schema does contain equal or richer detail (patterns, bounds), so this is compensation rather than genuinely new meaning.

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+resource ("Draw a single-line text"), which cleanly separates it from siblings like autocad_create_line or autocad_create_polyline. It does not explicitly name or contrast an alternative, so it stops short of the top band.

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 no guidance on when to use this tool versus other entity-creation siblings, and no prerequisites are stated (e.g., whether a document must be open or a layer current). The agent gets the mechanics but no routing or context cues.

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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral information beyond that: partial failures are reported rather than raised, which tells the agent to inspect the errors array instead of catching an exception. It does not state permanence/undo implications, which autocad_undo provides.

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: the core action and the failure semantics are in the first two sentences. The Args/Returns sections are clean, though the Returns block partially duplicates the output schema and the Args block restates the schema's handles description.

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?

With an output schema present, return values need not be explained (and the description's summary of the JSON shape is a bonus). Annotations cover the safety profile, and the bulk/partial-failure semantics are explained. What is missing is only peripheral: how handles are obtained and the choice versus the singular delete_entity sibling.

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 reported as 0%, but the nested DeleteEntitiesInput does describe handles as 'Handles of the entities to delete (hex strings)' and carries minItems/maxItems. The description's '1-500 hex handles' restates those constraints and adds the hex format, but contributes little beyond the schema. Baseline 3 is appropriate for a single-parameter tool whose schema does the heavy lifting.

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, and scope: 'Delete several entities by handle in one call.' The bulk framing implicitly separates it from the singular sibling autocad_delete_entity, though that sibling is never named explicitly. An agent can tell what the tool does 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?

Usage is implied rather than stated: the bulk/'one call' framing signals 'use this when you already have multiple handles.' There is no explicit when-not guidance, no mention of autocad_delete_entity as the single-entity alternative, and nothing about how to obtain handles (e.g., query_entities).

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds the genuinely useful fact that the deletion "cannot be undone via MCP" — valuable given autocad_undo exists as a sibling. It also states the exact success payload shape. It stops short of describing failure behavior for stale/invalid handles.

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 action sentence followed by the irreversibility warning, then compact Args/Returns blocks. The Returns block is largely redundant given an output schema exists, costing it a point, but nothing padding-like is included.

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 destructive, single-target mutation the irreversibility note is the key disclosure and it is present, and return values need not be explained since an output schema exists. What is missing is routing to the bulk sibling and any note on behavior with an invalid or already-deleted handle.

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?

With one parameter and reported 0% schema description coverage, the description does explain the handle is hex and originates from a create/query tool. That said, the embedded schema field description says essentially the same thing, so the added value over structured data is minimal — enough to reach, not exceed, the baseline.

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?

"Delete one entity by handle" gives a specific verb and resource, and the word "one" implicitly separates it from the bulk autocad_delete_entities sibling. However, it never names that sibling, so the distinction must be inferred rather than read.

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 description offers no when-to-use guidance and never mentions autocad_delete_entities, the obvious alternative for multi-entity deletion. An agent must guess whether to loop this tool or switch to the plural one, and no preconditions (e.g. drawing open, valid handle) are stated.

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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral context not present in structured fields: the two hard failure conditions (non-empty layer, reserved names '0'/'Defpoints') and the success response shape. It omits whether deletion is undoable, but the added failure semantics are substantive.

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?

Compact docstring layout with purpose, preconditions, args, and returns front-loaded; no filler sentences. The Returns line partially duplicates the output schema, a minor redundancy.

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?

With an output schema present, the description need not detail return values, and it still briefly notes them. Annotations cover the destructive/idempotent profile and the description supplies the prerequisite failure modes, leaving only edge cases like undo behavior unstated.

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 description only restates 'name (str): layer to delete', which duplicates the schema's own property description verbatim. It adds no meaning about the naming constraints (pattern, maxLength) or that the layer must already exist, so it does not compensate for the coverage gap even though the parameter is simple.

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 ('Delete a layer'), which is unambiguous against siblings such as autocad_create_layer, autocad_set_layer_state, and autocad_list_layers. It does not name an alternative tool explicitly, so it stops short of full sibling differentiation.

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 failure preconditions ('fails if the layer still has entities on it, or is 0/Defpoints') give implied when-not guidance, letting the agent know it must clear entities first. However, it never states when to delete versus when to use a non-destructive alternative like set_layer_state, so usage guidance remains indirect.

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?

Annotations already declare writability (readOnlyHint=false), non-destructiveness, and non-idempotence. The description adds real behavioral context beyond that: the layer is auto-created if missing, the sign of offset picks which side the dimension lands on, and the return is a JSON status/type/handle object. It still omits preconditions such as an active drawing or connection, which is the main 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?

The core purpose is front-loaded in one sentence, followed by tightly scoped Args/Returns sections with no filler. The Returns clause partially duplicates the existing output schema, which is the only wasted content.

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?

Purpose, the four meaningful inputs, and the immediate effect (layer auto-creation) are all covered, and an output schema exists so return details need not be repeated. What's missing is environmental context — required document/connection state and drawing-unit assumptions — for what is a write operation on the drawing.

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?

Reported schema description coverage is 0%, so the description must carry the load, and it does: it defines p1/p2 as the measured points, offset as perpendicular distance with sign selecting the side, and layer with its 'DIMENSIONS' default. That compensates well for the coverage gap, though it doesn't clarify units or what happens on a zero-length p1-p2.

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 gives a specific verb ('Draw') and resource ('dimension'), plus the geometric constraint ('true-distance', 'parallel to the line between two points') that separates it from angular/radius dimension siblings. It doesn't name those siblings explicitly, so an agent must infer the boundary rather than read it, keeping this 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.

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

Usage is implied by the geometry: measuring the straight distance between two points, at any angle, with an offset. There is no explicit when-to-use/when-not or reference to autocad_dim_angular / autocad_dim_radius as alternatives, and no prerequisites (open document, connection) are stated.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false and idempotentHint=false, so the safety profile is covered externally. The description adds the return shape ( status/type/handle) and notes the layer is created if missing, but says nothing about what entity is modified, undo behavior, or required drawing state.

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 one-line purpose followed by a compact Args/Returns block; every line carries information. The nested indentation style is slightly verbose but there is no 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?

An output schema exists, so the Returns block is redundant rather than necessary. Given annotations cover the mutation safety profile, the description is adequate, but for a tool that writes a new dimension entity it omits where the entity lands (model space vs layout) and any document-state prerequisites.

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?

Reported schema description coverage is 0%, so the description must compensate, and it does: it enumerates vertex, p1/p2 as a point on each ray, offset as arc radius from the vertex and must be > 0, and layer defaulting to 'DIMENSIONS'. The geometric intent of p1/p2 (one per ray) is genuinely clarifying rather than a restatement.

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 gives a precise verb and geometric resource: dimensioning the angle at a vertex between rays to two points. That is enough to distinguish it from autocad_dim_aligned and autocad_dim_radius without opening any schema. It stops just short of explicitly naming those siblings as alternatives.

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 no statement of when to use this versus the other dimension tools, no prerequisite (an open document, current layer state), and no exclusions. Usage is only implied by the geometry described.

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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false), so the description's job is to add context. It does: the tool creates a DIMENSION entity, the layer is auto-created if missing, and the return is a JSON status/handle. Per-permission or failure behavior is not stated, so it falls 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?

The one-line purpose is front-loaded, and the Args/Returns layout is scannable. The Args block partially duplicates the schema, which is slightly redundant, but nothing is padded or confusing.

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, and the description still summarizes the return shape, so an agent knows what to expect after creation. Combined with fully documented inputs, the definition is complete enough; only the absence of failure/permission caveats leaves a small gap.

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?

Reported schema coverage is 0%, so the description must carry parameter meaning, and it does: it documents center, radius (must be > 0), angle as DEGREES with default 45, diameter as a boolean switch, and layer default 'DIMENSIONS'. This compensates well for the coverage gap, though it largely mirrors the schema's own property descriptions.

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 states a specific verb and resource ('Dimension the radius or diameter of a circular feature'), which cleanly separates it from the sibling dimension tools dim_aligned and dim_angular by naming the feature type. It never explicitly names those siblings, so an agent must infer the routing, keeping it just below a 5.

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?

Usage is implied by the constraint 'circular feature' and the diameter flag, which narrows the applicable scenario. There is no explicit when-to-use/when-not-to-use guidance or mention of alternatives like dim_angular for arcs, so it is only minimum-viable.

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?

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description adds some useful structure (two wall loops plus a centered label) but says nothing about what a repeated call does, whether geometry is appended or replaces existing entities, or document-state 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?

Purpose is front-loaded in the first sentence and the Args/Returns layout is scannable with no filler. The Returns block is somewhat redundant since an output schema exists, but the overall size is proportionate to an 8-field 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?

For a moderately complex drawing tool the description covers geometry and inputs adequately, and return values are handled by the output schema. However, it is silent on document/connection prerequisites, layer auto-creation behavior, and duplicate-draw semantics, leaving real operational gaps.

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 description enumerates all eight nested fields with types and defaults, but this largely restates the properties already documented inside DrawRoomInput in the schema (the 0% coverage signal reflects the shallow top-level 'params' wrapper). It adds no format, unit, or constraint semantics beyond the schema, so it neither compensates meaningfully nor subtracts.

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: 'Draw a rectangular room: outer + inner wall loops and an area label.' This clearly distinguishes the composite room geometry from generic siblings like autocad_create_line or autocad_create_polyline, though it does not explicitly contrast with the closest sibling autocad_draw_wall.

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?

No guidance on when to use this instead of autocad_draw_wall, autocad_create_boundary, or manually composing lines/polylines. It also omits preconditions such as needing an open/initialized drawing and connection, so the agent must infer the context entirely.

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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the description is free to add geometry-level behavior, which it does: end caps are suppressed for closed loops and the target layer is auto-created. It does not restate mutation/idempotency semantics, which is acceptable given 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.

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

Front-loaded one-line summary, then Args/Returns sections that are scannable and free of filler. The Args block is partially redundant with the schema but not wasteful enough to hurt.

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-composite-argument drawing operation with an output schema, safety annotations, and a fully documented nested schema, the description covers purpose, inputs, and result shape. The only real gap is comparative guidance against its sibling drawing primitives.

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 prose docstring enumerates every nested field of the single `params` object with types and defaults (points 2-200, thickness default 100, closed default false, layer default 'WALLS'), compensating for the top-level `params` property having no description of its own. Most of this duplicates the nested schema, but it makes the composite argument legible at a glance.

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?

Names a specific verb and resource ("Draw a wall along a centerline path") and describes the resulting geometry (two parallel faces plus end caps). This distinguishes it from the generic autocad_create_polyline / autocad_create_line siblings without needing to open 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?

Usage is implied by the geometry description (a centerline-based wall), but there is no explicit when-to-use or when-not-to-use guidance relative to the many nearby siblings (autocad_create_polyline, autocad_draw_room, autocad_add_door). No prerequisites or ordering constraints are stated.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and repeatability profile is fully covered. The description's added behavioral content is largely the return shape (mostly duplicated by the existing output schema), with only the 'extents ... | null' nuance being genuinely new; no auth or rate-limit context is given.

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: purpose sentence, usage sentence, then a Returns block, with no filler. The explicit Returns section is somewhat redundant given an output schema already exists, costing a little on strict economy.

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 parameterless, read-only, idempotent summary tool with an output schema and full annotation coverage, the description supplies everything an agent needs to call it correctly, including the 'call first' sequencing cue. No meaningful gap remains.

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 tool takes zero parameters, so per the baseline there is no parameter semantics to clarify; the empty schema is self-evident. The description makes no misleading param claims, warranting the 0-param baseline of 4.

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 (summarize) and resource (active drawing) and enumerates the fields it reports: backend, units, layers, entity count, extents. It is distinguishable from narrow siblings like autocad_list_layers, though it does not explicitly address the overlap with autocad_connection_status, which also reports backend state.

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?

Gives a clear, actionable directive: 'Use this first to learn which backend is active and what the drawing contains,' establishing the orientation context. It stops short of naming alternatives or stating when-not to use it, but the sequencing guidance is strong.

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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered structurally. The description adds value beyond that by naming the exact return shape and the error convention ('Error (...)' when the handle is unknown), which tells the agent how failures surface.

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-loads the one-line purpose, then Args and Returns blocks – easy to scan. Slightly verbose in re-explaining the handle already documented in the schema, but nothing is wasted.

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 getter with an output schema, the description covers purpose, input provenance, return keys, and error behavior. Complete enough to invoke correctly; the only omission is explicit sibling routing.

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?

Coverage signal is 0%, so the description must carry the parameter. It gives the format and provenance (hex string from a create/query tool, e.g. '1A4'), which the schema only partially echoes. It adds the 'where to get it' meaning beyond the bare pattern.

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 (Get) and resource (one entity) with scope qualifier 'by handle, including its geometry'. This cleanly separates it from the plural sibling autocad_query_entities and the mutation tools like autocad_move_entity.

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 'handle from a create/query tool' note implies where input comes from, so an agent can infer this is a follow-up lookup after creation or querying. However, it never explicitly contrasts with autocad_query_entities or states when-not to use it, leaving the alternative routing 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?

Annotations already declare idempotentHint=true, destructiveHint=false and readOnlyHint=false; the description adds real value on top by explaining *why* it is safe (reuses the active document rather than discarding it, reuses an existing boundary instead of duplicating). It discloses the mutation is non-destructive and repeatable, which is beyond the raw annotation flags.

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 purpose sentence is front-loaded and the rest is organized as Args/Returns. The docstring-style type annotations (InitializeDrawingInput, CreateBoundaryInput) add a little scaffolding weight but each line carries usable information.

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 composing wrapper, the description covers composition, idempotency, reuse behavior, and the returns shape; an output schema exists so return details needn't be spelled out. What is missing is any statement about prerequisites (e.g., a live document/connection) or failure behavior, but overall it is nearly complete.

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?

Top-level schema description coverage is 0%, so the description carries the burden and does so: it marks boundary as required, units as optional with an Engineering-template default, and points to autocad_create_boundary for the nested shape. The nested $defs themselves are fully documented, so the agent has adequate guidance.

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: 'apply drawing units, then create/reuse the sheet boundary.' It names the two sibling tools it composes (autocad_set_drawing_units, autocad_create_boundary), so an agent can immediately place it relative to those siblings.

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?

Frames the tool as a 'one-call setup' convenience that composes the two underlying operations, giving clear context for when it is preferable to calling them individually. It stops short of an explicit when-not or a direct 'use this instead of the two separate calls' routing statement, so it 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.

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

Annotations already declare readOnly=false, idempotent=false, and destructive=false, so the safety profile is covered. The description adds that a new INSERT entity is created and returns a JSON status/handle, but it does not disclose side effects such as layer auto-creation or external file import behavior. With annotations carrying the safety burden, 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.

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

The purpose sentence is front-loaded and the Args/Returns structure is clear and scannable. The Args list is necessary given the nested parameter object. The Returns block is somewhat redundant because an output schema exists, but it is not wasteful enough to lower the score further.

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 block-insertion tool with a nested parameter object and mutation annotations, the description supplies the core action, all parameter semantics, and the return shape. It does not cover error cases or usage routing, but an output schema and the annotations already carry much of the remaining burden.

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 description documents all nested fields with types, defaults, and constraints, including that rotation is in degrees counter-clockwise positive and that x/y/z scale values must be positive. It also adds backend nuance about COM accepting .dwg, which is not obvious from the top-level schema signal. It largely mirrors the schema's own $defs descriptions, so it is strong but not fully additive.

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: 'Insert a block reference.' It also distinguishes the two insertion modes (defined block name vs. external drawing file path). However, it does not contrast itself with any sibling tool, so it falls short of 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.

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

There is no explicit when-to-use guidance, no when-not-to-use guidance, and no alternatives named. The description implies usage from the operation itself but leaves routing decisions entirely to the agent.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered by structured fields. The description's main addition is the return shape, which duplicates the existing output schema, and it says nothing about behavior when the block has no attributes or a bad handle is supplied.

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 purpose is front-loaded in one clean sentence, and the Args/Returns blocks are compact. The Returns section is somewhat redundant given an output schema exists, slightly diluting conciseness.

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 simple one-argument read tool with full annotations, a return description and a published output schema, the definition covers what an agent needs to invoke it correctly. Only edge-case behavior (missing attributes, invalid handle) is 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?

With a single parameter and low reported schema coverage, the description restates the parameter as a 'handle of a block reference (INSERT entity)'. That INSERT-entity qualification adds real meaning, but the rationale, hex format and provenance of the handle are largely left to the schema and the Args block reads close to a restatement.

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 gives a specific verb (List) and resource (attribute tags/values) scoped to a block reference, so an agent immediately knows this is a read of INSERT attributes rather than a mutation. It stops short of naming the sibling autocad_set_block_attribute explicitly, which would have pushed it to a 5.

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?

Usage is only implied: the handle is described as 'handle of a block reference (INSERT entity)', which signals the tool operates on block references. There is no statement of when to prefer this over autocad_get_entity or autocad_query_entities, and no preconditions are given.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description's only added behavior is the return shape, which largely duplicates the output schema. No pagination or scoping caveats are mentioned, so it stays at baseline.

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?

Two short sentences, front-loaded with the action and scope. The 'Returns' block is somewhat redundant given an output schema exists, but it costs little and does not bury the main point.

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 no-argument, read-only listing tool with annotations covering the safety profile and an output schema documenting the return, the description is essentially complete. The only minor redundancy is restating the return format already captured by the output schema.

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?

There are zero parameters, so the baseline is 4 by rule. Nothing in the schema needs explaining, and the description does not introduce phantom parameters.

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 (List) and resource (all layers in the active drawing) plus the returned fields (color, linetype). It is trivially distinguishable from mutation siblings like autocad_create_layer or autocad_delete_layer.

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 intent is implied by 'list all layers', which for a zero-param read tool makes the use case fairly obvious. However, it never states when to reach for this versus siblings such as autocad_get_document_info or autocad_query_entities, and there are no explicit exclusions.

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?

Annotations already mark it as non-read-only, non-destructive, and non-idempotent. The description adds the important behavioral fact that the original entity is left unchanged and gives the return JSON shape, though it omits error conditions and document prerequisites.

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 purpose and key invariant are front-loaded in the first two sentences, followed by a compact Args/Returns block. Every section supports correct invocation without 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 creation tool with nested point inputs and an existing output schema, the definition supplies purpose, input meaning, and output shape adequately. It falls just short of 5 by omitting edge-case or error behavior.

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?

With schema description coverage reported at 0%, the description carries the load and documents all three nested inputs: handle, p1, and p2. It also adds a useful semantic constraint absent from the schema by calling for 'two distinct points' defining the mirror line.

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: 'mirror' an 'entity' across a line. The added detail that it creates a copy and leaves the original unchanged helps distinguish it from plain copy or move operations, but no sibling tool is named explicitly.

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 no explicit when-to-use or when-not-to-use guidance and names no alternatives. An agent must infer its role among transformation siblings like autocad_copy_entity and autocad_move_entity without help.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false, so the safety profile is covered. The description adds little beyond the basic transform concept — it doesn't say the entity's handle must come from a create/query tool (that's in the schema), nor what happens if the handle doesn't exist or the layer is locked. Baseline 3 since annotations carry the load and the description adds the 'in place' modifier.

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-loads the operation well but then restates the full schema in an Args block and returns section. Since an output schema exists, the Returns section is redundant. The Args block duplicates the input schema verbatim, which is noise. Single-sentence core is good, packaging is wasteful.

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 mutation tool with destructive=true and an output schema present, an agent has enough to invoke it. But given no annotations explain reversibility or preconditions, the description should say whether move is undoable, whether it requires the entity's layer to be unlocked, or what errors occur on bad handles. It doesn't.

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?

Parameter count is 1 (the nested params object). Schema description coverage is 0% for the top-level, but the nested fields carry descriptions. The description lists handle/dx/dy/dz with types, matching the schema exactly. It adds nothing beyond what the nested schema properties already state — no units clarification beyond 'drawing units', no handle sourcing validation.

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 ('Move an entity') and specifies the operation is 'in place by (dx, dy, dz)'. Among siblings like copy/rotate/scale/mirror, the name and description make clear this is translation by vector. Lacks explicit sibling differentiation but is unambiguous on its own.

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

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

No guidance on when to use this versus rotate/scale/mirror/copy. The agent must infer from the tool name and its own model of CAD operations. No prerequisites, no conditions, no alternatives named.

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 destructiveHint=true already set, the description goes beyond the flag by naming exactly what is destroyed ('Discards any in-memory (unsaved) drawing held by the ezdxf backend') and by describing backend divergence (ezdxf vs COM file extensions, freestanding backend starting state). It does not mention error behavior or permissions, so not 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-loads the purpose, then the destructive caveat, then backend note, then Args/Returns. Every sentence carries information relevant to invoking the tool correctly; nothing is 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?

An output schema exists, so the Returns line is supplementary rather than load-bearing. The description covers mutation behavior, backend variants, and both parameters; only error/edge-case behavior (e.g. what happens when the target path already exists) is absent.

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 description enumerates both params with meaning beyond their names, including the '.dxf (ezdxf) or .dwg (COM)' extension constraint and the full units enum with default. The schema itself also carries rich per-param descriptions, so this largely reinforces rather than rescues 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+resource ('Create a new, empty drawing') and the activation side-effect ('make it the active document'). It does not explicitly distinguish itself from the close sibling autocad_initialize_drawing, so an agent must still infer which one creates versus initializes.

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 description explains conditional parameter behavior (omitting path keeps the drawing unsaved) but gives no when-to-use guidance relative to autocad_open_document, autocad_initialize_drawing, or autocad_save_document. No prerequisites 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.

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

Annotations already establish non-read-only, idempotent, non-destructive, and non-open-world behavior. The description adds useful behavioral context: the opened drawing becomes active, .dxf uses ezdxf and .dwg uses COM, and it returns a JSON status.

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 front-loaded with the core purpose and then uses a compact Args/Returns structure. It contains no filler and is appropriately sized for a simple one-parameter 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?

For a straightforward open-document tool with annotations and an output schema, the description provides enough context to invoke it correctly: file format support, active-document side effect, and return shape. It could more explicitly route the agent away from new/initialize document tools.

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?

With only one parameter and the context signal showing low schema description coverage, the description compensates by explaining that path must be an existing '.dxf' or '.dwg' file. It adds backend-specific format meaning beyond the bare 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: 'Open an existing drawing file and make it the active document.' The word 'existing' clearly distinguishes it from sibling tools such as autocad_new_document and autocad_initialize_drawing.

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 description implies when to use it by saying it opens an 'existing' file, but it does not explicitly compare against new_document or initialize_drawing. No 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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description adds value by disclosing filtering semantics, pagination mechanics, and the has_more/next_offset continuation contract. It does not state failure behavior (e.g., no open document) or total-cost characteristics, so it stops 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?

The lead sentence is front-loaded with the purpose and filters, and the Args/Returns docstring is scannable with no filler. The Returns block partially duplicates the output schema, which is minor redundancy rather than padding.

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?

With annotations covering safety and an output schema present, the description supplies the missing operational context: filter options, pagination loop, and result keys. It is nearly complete, lacking only edge-case or error disclosure for a read tool of this complexity.

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?

Despite the reported 0% schema coverage, the description documents every argument's meaning, including the default page size, the 1-500 cap, the offset pagination intent, and the accepted entity-type tokens. It adds real semantics beyond the raw schema, though it omits invalid-type or invalid-layer handling.

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 gives a specific verb and resource ('List entities in the drawing') plus the filtering scope. It clearly differs from singular readers like autocad_get_entity, though it never names a sibling to route between them explicitly.

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?

Usage is implied by 'optionally filtered by layer or type' and the documented paging arguments, but there is no explicit when-to-use or when-not-to-use guidance versus autocad_get_entity or autocad_list_layers. An agent must infer the selection context.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false and idempotentHint=false, so the safety profile is covered; the description adds genuinely new behavioral context beyond that — two distinct backends with different mechanisms, the matplotlib dependency requirement ('preview' extra), and the reason both can be non-idempotent. It does not address file overwrite behavior or whether a live AutoCAD connection is required for the COM path.

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?

Nicely front-loaded: purpose first, then backend behavior, then Args, then Returns. The Args/Returns sections duplicate what the schema and output schema already express, which is the only redundancy; the prose is otherwise tight and well-organized.

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 render/export tool with annotations and an existing output schema, the description covers the essentials: what it produces, the two backends, the extra dependency, and the return payload (even though the output schema already defines it). Minor gaps remain around overwrite semantics and whether an open document is required, but nothing critical is missing for correct invocation.

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 Args block restates path/width/height, but the values it gives (example '.png', range 100-4000, default 1200x800) are already present in the schema's defaults, min/max, and descriptions. It therefore adds little meaning beyond the structured schema. Reported schema description coverage is 0% (measured at the top-level 'params'), so the description does at least surface the parameter contract, keeping this at a baseline 3 rather than lower.

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 ("Render the drawing to an image file") and adds a distinguishing rationale ("so it can be inspected without AutoCAD"), which no sibling tool provides. An agent can immediately tell this is the visual-output/export tool. It is clearly separable from the many create/query/edit siblings.

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 description gives the operative context: rendering is used to inspect the drawing without AutoCAD, and it distinguishes the two execution paths (ezdxf headless vs COM screenshot) and the prerequisite "preview" extra. There is no other render/preview sibling to route against, so no explicit alternative is needed, but it stops short of stating when-not-to-use or any precondition about an active document/connection.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=false, so the agent knows this is a non-idempotent write. The description adds 'in place' (mutates rather than creating a copy) and the degrees/counter-clockwise convention, which is useful context, but says nothing about axis of rotation or undo behavior.

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 sentence, then a compact Args/Returns layout with no filler. The Returns block is redundant against the output schema but is brief.

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 and annotations covering the safety profile, the description is close to complete: it conveys the action, the pivot, the angle convention, and the success shape. It could note the rotation plane or that the handle must reference an existing entity.

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?

With schema description coverage reported at 0%, the description must compensate and it does: it names all three fields (handle, base, angle) and supplies the critical unit/sign convention ('DEGREES, counter-clockwise positive'). It omits the handle format detail (hex string) that the schema carries, but covers the semantics adequately.

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 ('Rotate an entity in place about a base point') that clearly distinguishes it from siblings like move_entity, copy_entity, scale_entity, and mirror_entity. No explicit sibling routing, but the action is unambiguous.

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 description never says when to use this versus the other transform tools (move, copy, scale, mirror), nor does it state any prerequisite such as the entity needing to exist first or the document context required. Usage is only implied by the verb.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: output format is backend-dependent (ezdxf writes '.dxf', COM writes '.dwg'), which the agent cannot infer from annotations or schema.

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-loads the core action in one sentence, then uses Args/Returns blocks so the optional parameter and result shape are easy to scan. Slightly verbose for a one-parameter tool but nothing is wasted.

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 Returns line is a bonus rather than a necessity, and annotations already carry the safety profile. The backend-dependent extension and the re-save semantics give an agent enough to invoke this correctly; only the never-saved-drawing failure case is left out.

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 reported at 0%, so the description carries the param burden and does so: it marks 'path' optional, explains the omit-to-resave behavior, and notes the extension differs per backend. It omits one nuance present in the schema — that omitting path fails on a never-saved drawing — but otherwise compensates well for the coverage gap.

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?

Names a specific verb and resource ('Save the active drawing to disk'), which cleanly separates it from open_document, new_document, and the query/edit siblings. No explicit sibling routing, but the purpose is unambiguous 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 the parameter-level usage rule ('omit to re-save to the current path'), which is useful context for the single optional arg. However, it never states when this tool should be preferred over alternatives or what prerequisites exist (e.g. an active/initialized drawing or a live COM connection); usage is only implied.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so safety is covered structurally. The description adds that scaling happens 'in place' (mutating the existing entity rather than producing a copy) and sketches the success payload, but says nothing about failure modes, undo requirements, or which entity types are supported.

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 operative sentence is front-loaded and the total length is short. Some space is spent restating parameter and return details already encoded in the schema, but nothing is padded or buried.

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 return note is optional, and the destructiveHint annotation signals mutation. Still, for a destructive in-place edit the description omits error conditions, allowed entity types, and whether a prior autocad_undo/reference handle is needed, leaving real gaps.

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 Args block enumerates handle, base, and factor, but the meanings mirror the schema's own nested descriptions ('Entity handle as returned by a create/query tool', 'Scale base point (fixed point)', 'Uniform scale factor (> 0)'). No extra syntax, units, or examples are added beyond the schema's pattern, exclusiveMinimum, and Point definition.

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 gives a precise verb+resource+modifier: 'Uniformly scale an entity in place about a base point.' 'Uniformly' and 'in place' clearly separate it from siblings like autocad_move_entity, autocad_rotate_entity, autocad_mirror_entity, and the array tools.

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 no when-to-use guidance, no statement of prerequisites (e.g., the entity handle must come from a create/query tool), and no mention of the sibling operations this replaces. The Args block documents inputs but says nothing about when this tool is the right choice.

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?

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false, but the description adds substantial context beyond them: default-disabled gate, exact env var, denylist contents (QUIT, SHELL, NETLOAD), the 'guardrail, not a sandbox' framing, and the ability to run arbitrary AutoLISP and overwrite files. This is exemplary disclosure for a dangerous 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?

Front-loads what the tool does, then the enablement gate, then the safety warning, then args/returns — a logical order. Slightly long, but each sentence carries non-redundant information (enablement, denylist limits, trust requirement), so little is wasted.

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?

Even though the tool is inherently dangerous and takes an opaque string, the description supplies the enablement procedure, the safety boundary, the param shape, and the return format ('JSON {"status": "sent", "command"}'). An output schema exists, so return semantics need not be expanded further.

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% per context signals, so the description must carry parameter meaning. It does name the single `command` param and give an example ('ZOOM E ') plus an AutoLISP form hint, which mirrors the inner schema's own text, but it omits the maxLength=2000 / minLength=1 constraints and gives no format rules for delimiters or terminators.

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?

Specific verb+resource: 'Send a raw AutoCAD command-line string ... to a live AutoCAD session', with the AutoLISP variant and 'COM backend only' scope qualifier. An agent can immediately distinguish this escape-hatch tool from the typed siblings (autocad_create_line, autocad_draw_wall, etc.) that perform constrained operations.

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?

Strong when-and-when-not guidance: disabled unless AUTOCAD_MCP_ALLOW_RAW_COMMANDS=1, and 'Only enable it in a trusted, single-user environment'. It does not, however, explicitly tell the agent to prefer the dedicated typed tools over this raw escape hatch, which is the most relevant alternative in this sibling set.

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?

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds the return payload shape ({"status": "updated", ...}), which is useful, but it never explains what the destructive flag implies (overwrite of existing text) or what happens when the tag does not exist on the block.

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 single-sentence purpose followed by a compact Args/Returns block; nothing is padded. Minor redundancy with the schema property descriptions is the only waste.

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 Returns restatement is optional rather than required. For a destructive mutation, however, the description omits the key operational context an agent needs: that the referenced INSERT must already own an attribute with that tag, and whether undo is available to reverse the change.

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 Args block restates handle, tag and value with essentially the same wording the schema already carries for each property (including the hex-handle pattern note). It adds no syntax, format, or edge-case detail beyond the schema, so it neither compensates for the reported coverage gap nor improves on 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 and resource: set one attribute value on a block reference (INSERT entity). The 'one attribute' phrasing subtly differentiates it from the sibling autocad_list_block_attributes, though it never names that sibling directly.

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?

Usage is only implied: the agent must infer that a block reference handle (from a create/query tool) and an existing attribute tag are prerequisites. No when-not conditions or alternatives (e.g. list_block_attributes to discover tags, insert_block to create the reference) are named.

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?

Annotations carry the safety profile (idempotentHint=true, destructiveHint=false). The description adds two non-obvious behaviors: auto-creation of missing layers and that the effect is on the live UI. It does not disclose what happens on invalid names despite the schema pattern, but the additions exceed the annotation baseline.

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-loads the action in the first sentence with the auto-create caveat, then documents args/return concisely; the Args/Returns block is somewhat redundant given the schema.

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?

With an output schema present, the return-value summary is appropriately brief; the main missing piece is failure behavior for invalid layer names or a UI-less connection, minor for a single-param tool.

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's 'name (str): layer to make current' is the only semantic hint beyond the JSON schema's type and pattern constraints, which is thin but for a single-parameter tool this is adequate.

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 ('Make a layer current'), distinguishes from sibling autocad_create_layer and autocad_set_layer_state, and notes the auto-creation caveat.

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 'Mainly affects a live AutoCAD UI' phrase hints at a live-document precondition, but there is no explicit when-to-use vs autocad_set_layer_state or autocad_create_layer, and no stated exclusions or error conditions.

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?

Annotations already declare idempotentHint=true and destructiveHint=false, so the 'safe to call repeatedly' line is largely reinforcing structured data. The genuinely additive disclosure is that rejected variables are surfaced in the 'verified'/'warnings' payload rather than silently dropped or thrown as errors, which tells the agent to inspect the result rather than assume full success.

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?

Purpose is front-loaded in the first sentence, followed by grouped defaults, idempotency, Args and Returns sections. Well organized and reasonably sized, though the default template is restated in both the description and the nested schema's own description, which is mild redundancy.

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 configuration call, the definition covers purpose, default behavior, idempotency, a field inventory, the exact return shape, and explicit guidance on verifying partial success. Combined with annotations that carry the safety profile, nothing an agent needs to invoke or interpret it 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 measured schema coverage is 0% at the top level (the single 'params' property is an undescribed $ref), but the nested $defs do document each field. The description compensates meaningfully by naming all seven sub-fields and, crucially, spelling out the default template values (Engineering length at 0.000, Decimal Degrees, counter-clockwise, Inches, International) so an agent knows the effect of omitting parameters.

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 ('Apply the Drawing Units dialog settings') plus an extra outcome ('verify each was accepted'). No sibling tool in the list touches drawing units, so this is unambiguously distinguishable from the layer/entity/dimension tools.

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 description implies when to call (to configure drawing units) and tells the agent what happens by default (Engineering template) and that repeated calls are a no-op. However, it never states when in a workflow to invoke it, whether it must precede drawing creation, or any when-not condition.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so safety and repeatability are covered. The description adds genuinely new behavior: partial-update semantics ('Only given fields change') and the notable side effect that a missing layer is auto-created, which an agent could not infer from 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.

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

The definition is front-loaded with the purpose, then a compact Args block and a one-line Returns. The Args block does restate some of what the schema already shows (the boolean meanings), but it is short enough that it costs little.

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 return-value sentence is a bonus rather than a necessity, and annotations already cover the mutation safety profile. The remaining omission is calling out the sibling hand-offs (create_layer/set_current_layer) for a tool that has several nearby layer operations.

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 reported as 0% at the top level, so the description must compensate, and it does: it names each field (name, frozen, locked, off), gives the boolean direction for each, states the auto-create behavior of name, and imposes the 'at least one' constraint that the schema does not express. Minor gap: no mention of the name pattern/length limits.

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 names a specific verb set and resource: freeze/thaw, lock/unlock, on/off for a layer. It is clearly distinguishable from create_layer/delete_layer by the state-change framing, but it never explicitly contrasts itself with autocad_set_current_layer, a closely related sibling, so it stops short of full sibling differentiation.

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?

Usage is only implied: 'give at least one' of frozen/locked/off tells the agent the call must include a state change, and 'auto-created if missing' hints at the create-then-configure workflow. There is no explicit when-to-use vs when-to-use-a-sibling guidance, e.g. versus autocad_create_layer or autocad_set_current_layer.

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?

Annotations declare destructive/non-idempotent/non-readonly, and the description goes further by disclosing the backend dependency, the live-session requirement, and the exact failure mode (NotImplementedError) with ezdxf. That error and environment behavior is information the 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.

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

Front-loaded with the operation and its key constraint, then structured Args/Returns blocks. The Returns section is somewhat redundant given an output schema exists, but nothing is confusing or padded.

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 the operation, backend requirement, parameter bounds, and error behavior; an output schema exists, so the return explanation is a bonus rather than a necessity. It is complete enough to call correctly, with only minor redundancy in the Returns section.

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 reported at 0%, so the description must carry the parameter meaning, and it does: it names the UndoInput wrapper, the 'steps' field, its type, default of 1, and max of 50. The default and max duplicate the schema constraints, so it compensates for coverage without adding much new syntax detail.

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 ('Undo the last N operations') and immediately narrows scope with 'COM backend only'. No sibling tool in the list performs undo, so the purpose is unambiguous within the toolset.

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?

Gives a clear precondition for use: it only works on a live AutoCAD session with the COM backend, and is documented to fail under ezdxf. It does not name an alternative tool, but no sibling covers this operation, so the only real gap is the absence of explicit 'when not to use' framing beyond the backend constraint.

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