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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that – it does not disclose that this writes a new entity into the drawing, that layer may be auto-created, or what the created dimension is returned as.

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?

A single efficient sentence with the core action front-loaded and no filler, though the parenthetical is slightly redundant with the enum.

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, rich annotations, and 88% schema description coverage, the structured fields carry most of the load. Still, for an 8-parameter mutation tool the description says nothing about the required location point or how kind affects rotation, leaving small 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?

Schema coverage is 88%, so the schema already documents params like location, color, text_height and rotation in detail. The description's enumeration of the kind values merely restates the existing enum, adding no new meaning. Baseline 3 applies.

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 ('dimension') and the resource (the distance between p1 and p2), so an agent knows this creates a dimension annotation. It distinguishes itself from siblings like draw_line or add_text, though 'dimension' used as a verb is mildly idiosyncratic.

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 among the many annotation/geometry siblings. The parenthetical kind list is a parameter detail, not usage 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 readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the agent knows this mutates state non-destructively but is not safely repeatable. The description adds nothing beyond that — no note on whether the hatch is associative to the boundary, what happens on overlapping fills, or whether the boundary entity is consumed.

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?

A single front-loaded sentence with zero waste. It is well-formed but so terse that it leans into under-specification rather than true 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. For a 6-parameter mutation tool, however, the description omits preconditions and side effects that an agent would want before calling 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?

Schema description coverage is 67%, with color, layer, pattern, and boundary documented in the schema while angle and scale rely on name/type/default. The description contributes no parameter detail at all, so it neither helps nor misleads — baseline 3.

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 (fill) and resource (closed boundary with hatch pattern or solid fill), which cleanly separates it from the draw_* primitives and add_text/add_dimension siblings. It stops short of explicitly naming which sibling to use instead, 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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives. An agent gets no signal about prerequisites (e.g. that the boundary must already exist) or when a solid fill is preferred over a pattern.

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 the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), which the description does not contradict. The description adds the useful anchoring convention (top-left corner at insertion point) but says nothing about what happens on overlap, whether text can be edited later, or layer creation side effects mentioned only in the schema.

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

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

A single, front-loaded sentence with zero filler that puts the resource and the distinguishing positioning rule in the first clause. It is efficient, though arguably too terse to route the agent among siblings.

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 and 83% parameter coverage, the description need not explain returns or most parameters, and the annotation set covers the safety profile. What is missing is sibling differentiation from add_text and any indication of when each text type is appropriate, which is material for a 38-tool CAD surface.

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 high at 83%, including \P line breaks, ACI color values, width/height defaults, and the [x,y,z] insert format, so the schema does the heavy lifting. The description only echoes the insert point and adds no parameter meaning beyond that, which is the baseline when the schema is well documented.

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

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

The description states a specific verb and resource ('Add multiline text (MTEXT)') and adds the distinctive geometric anchor ('top-left corner at the insertion point'), which is meaningful for a text tool. However, it never distinguishes itself from the sibling add_text, leaving the agent to infer that MTEXT (paragraph) differs from single-line text.

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

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 tool versus add_text, the obvious alternative for label text. No prerequisites (e.g., an open drawing) or exclusions are given, so selection between the two text tools is left entirely 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 the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description needn't restate safety. It adds real value with 'left baseline' insertion semantics, but says nothing about whether a drawing must be open, what happens on a non-existent layer beyond the schema, 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?

One short, front-loaded sentence with no filler. It is efficient, though at the cost of omitting guidance that would earn its place.

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

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

Output schema exists so return values need not be explained, and annotations carry the safety profile. However, for a 6-parameter creation tool, the description omits units, layer prerequisites, and the add_mtext alternative, leaving meaningful 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?

Schema coverage is only 50%; color, layer and insert are documented in the schema, but height and rotation (and the units they are expressed in) appear in neither schema description nor tool description. The description mentions only the insertion point, so it fails to compensate 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?

States a specific verb+resource (add single-line text) and pins the geometry ('at the insertion point, left baseline'), which implicitly distinguishes it from the sibling add_mtext. It never names add_mtext explicitly, so sibling differentiation is left to inference rather than stated.

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 when-to-use or when-not guidance beyond the implicit 'single-line' qualifier. With add_mtext as an obvious sibling, the description should route the agent ('use add_mtext for multi-line/paragraph text') but does not.

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 safety and repeatability are covered. The description's useful addition is enumerating the two backend modes it can report, but it discloses nothing further about how the status is obtained or any failure modes (e.g. what happens when no drawing is 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?

A single front-loaded sentence that lists exactly the three pieces of state returned, with no filler. Every clause earns its place.

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

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

Given zero parameters, rich annotations, and an existing output schema, the description covers the essential behavioral surface; return-value detail is rightly left to the schema. Only the absence of any usage context or sibling differentiation keeps it short of 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?

The tool takes zero parameters, so there is no parameter semantics to document; the baseline for parameterless tools applies. The description correctly avoids inventing any argument behavior.

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 names a specific verb (report) and exactly what is reported: active backend (AutoCAD via COM vs headless DXF), connection state, and open drawing. That is far more specific than the bare name, though it never explicitly distinguishes itself from the sibling get_drawing_info, which an agent might reasonably confuse it with.

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 — an agent can infer this is a diagnostic probe to run before other CAD operations, but the description gives no when-to-use statement, no prerequisites, and does not point to or away from any of the 38 sibling tools. Adequate but with a clear gap.

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 a non-read-only, non-destructive, non-idempotent mutation, so the safety profile is covered. The description usefully adds that copies are produced and that the new entities are returned, but it does not state whether the originals are left untouched, what happens with large handle sets, or any transaction/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?

Two short sentences, front-loaded with the core action and followed by the return behavior. No filler, no repetition of schema or annotation 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?

An output schema exists so return-value details need not be spelled out, and annotations cover the safety profile. The description is nearly sufficient for this two-parameter mutation, with the only real gap being the lack of routing guidance against sibling copy/move 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?

Schema description coverage is 100% and both parameters (handles, displacement) are documented in the schema, including the hex-string format and the [x, y]/[x, y, z] forms. The description adds the notion that displacement is applied to the copies, but nothing beyond what the schema already conveys, so the baseline 3 applies.

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 (copy) and resource (entities) plus the key mechanic (offsetting copies by a displacement vector) and the return (new entities). It is clear what the tool does, but it does not explicitly contrast with close siblings such as move_entities, offset_entity, or mirror_entities, so an agent must infer the distinction between copying and moving/offsetting in place.

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 despite several plausible siblings (move_entities, offset_entity, mirror_entities). The agent must infer that this is the tool to pick when a duplicate rather than an in-place modification is desired.

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 readOnlyHint=false and destructiveHint=false, establishing a mutation that is nominally non-destructive. The description says nothing about the copy semantics, nor that delete_source can remove the source entities after copying — a behaviorally significant detail absent from both the description and 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?

A single front-loaded sentence with zero padding. Its economy is good, though it is arguably under-specified rather than optimally concise for a 4-parameter mutation 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What remains missing is the source-entity copy/delete behavior and the prerequisite for handles, leaving the description minimally adequate rather than 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?

Schema description coverage is 75%, documenting handles ('hex strings'), base_point ('[x, y] or [x, y, z]') and delete_source. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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 verb+resource ('Define a new block') is specific and distinguishes creation from sibling insert_block and list_blocks, which deal with existing blocks. However, it never names those siblings, so the agent must infer the boundary itself.

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 and no mention of alternatives such as insert_block or draw_* tools. It also omits the prerequisite that the referenced entities must already exist in model space, which the agent would have to deduce.

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, openWorldHint=false), so the bar is lower. The description usefully discloses the upsert semantics and the optional current-layer side effect, which the annotations do not. However, it does not say what happens to existing attributes when the layer already exists, and there is tension between the 'update it if it exists' upsert framing and idempotentHint=false.

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?

One sentence, front-loaded with the primary verb and resource, with the upsert caveat and the optional side effect attached efficiently. No filler, though the brevity leaves the update semantics underspecified.

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

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

An output schema exists, so return values need no explanation. But for a mutation tool in a toolset that also contains update_layer and set_current_layer, the description never resolves which tool owns which behavior or what an overwrite does to unspecified attributes, leaving the agent with a real ambiguity.

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 60% (color, linetype, lineweight are documented in-schema). The description adds meaning for the undocumented make_current parameter ('optionally make it current'), but the equally undocumented name parameter gets nothing beyond its self-evident title. This is around the baseline given partial schema coverage.

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 (Create) and resource (layer), plus the non-obvious upsert behavior ('or update it if it exists'). It stops short of differentiating from the sibling update_layer, which performs a similar mutation, so the agent must still guess which to pick.

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 prefer this over update_layer or set_current_layer, even though both siblings cover parts of this tool's behavior (updating a layer, making it current). The description asserts an upsert rule but never says when an agent should call this vs. those alternatives.

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 the safety profile is fully specified without the description. The description adds nothing beyond that annotation coverage — no mention of whether deletion is cascading, reversible, or requires referenced entities to exist.

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 words are technically concise, but this is under-specification rather than conciseness — no sentence earns its place because there is effectively only one sentence carrying almost no 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?

Output schema exists, so return values need not be explained, and annotations cover the destructive profile. However, for a destructive mutation tool an agent still lacks any statement of what is removed, whether dependent geometry is affected, or error conditions — a significant gap given the operation's irreversibility.

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 100% and the single "handles" parameter is documented in the schema as entity handles (hex strings). The description contributes no additional meaning, so the baseline 3 applies.

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?

"Erase entities" restates the tool name (delete_entities) with a synonym and adds no scope, target-type, or effect information. An agent can infer it removes entities, but nothing distinguishes it from the sibling suite (e.g., whether it operates on entity handles vs. layers vs. blocks) beyond 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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling tools. Nothing tells the agent when deletion is appropriate versus moving, copying, or hiding 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 mark this as destructive, non-read-only, non-idempotent, and closed-world, so the safety profile is covered. The description adds the 'unused' precondition, which is useful behavioral context, but it does not explain what happens if the layer is in use, whether deletion is reversible, or any failure modes. This is a modest addition beyond annotations.

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

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

The description is a single front-loaded sentence with no wasted words. It is appropriately concise, though the extreme brevity leaves important context unstated for a destructive operation.

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 explain return values, and annotations cover the safety profile. However, for a destructive tool with one undocumented parameter and many sibling layer operations, the description omits key prerequisites and side effects, such as whether a used or current layer can be deleted. It is not complete enough 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?

There is one required parameter, name, and schema description coverage is 0%, meaning the description should compensate for missing parameter documentation. The description does not mention the name parameter, its expected format, or which layer it identifies, so it adds no meaning beyond the schema's bare property title.

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

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

The description states a clear verb and resource: delete a layer. It implies a constraint that the layer must be unused, which distinguishes it somewhat from create/update/list layer tools. However, it does not explicitly differentiate itself from delete_entities or explain the 'unused' condition, so it is not fully precise.

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 explicit guidance on when to use this tool versus alternatives such as update_layer or delete_entities. The word 'unused' hints at a precondition, but there is no statement of exclusions, prerequisites, or alternatives.

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 this is a mutating (readOnlyHint=false), non-idempotent, non-destructive operation within a closed world, so the safety profile is covered. The description adds the CCW sweep direction, which is genuine behavioral context, but it says nothing beyond that about side effects, layer creation, 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?

A single front-loaded sentence with no filler; the direction and endpoints are stated immediately and 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 return values need not be explained, and the schema covers most parameters. However, for a 7-parameter geometry mutation tool the description is thin on the drawing-state context (which drawing, default layer) and the angular convention's interaction with the two required angles.

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 86%, so the schema already documents center, color, layer, linetype, and the angle conventions. The description only restates the start/end angle relationship, adding no syntax or units beyond what the schema fields provide; baseline 3 is appropriate.

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 (draw) and resource (circular arc) with the orientation semantics (counter-clockwise from start_angle to end_angle). It is clearly distinguishable from draw_circle, draw_ellipse, and draw_line by name and shape, though it does not explicitly contrast itself with 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?

No guidance on when to choose an arc over draw_circle, draw_ellipse, or a polyline approximation, and no prerequisites or constraints (e.g. which drawing must be open, current layer behavior) are given. Usage must be inferred entirely 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 declare a non-idempotent, non-destructive write, and the description usefully adds that results (or errors) are returned per operation. However, it never explains what stop_on_error actually does, whether the batch is atomic or partially applied, or what happens on the 500-item cap — facts that matter for a mutation tool.

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

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

Two short sentences, front-loaded with the core action and the return contract. Every sentence earns its place with no filler.

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

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 shape need not be described here. But for a batch mutation with a stop_on_error switch and a 500-item limit, the description leaves key operational questions unanswered, so it is only minimally adequate.

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 only 50%, and the description adds no parameter meaning at all. The operations item schema is richly documented inline, but stop_on_error is completely undocumented in both schema and description, leaving a behavioral switch the agent cannot reason about.

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 many entities') and the batch framing ('in one call'), which distinguishes it from the single-entity siblings like draw_line or draw_point. It stops short of explicitly naming the batch use case versus the single tools, but the purpose is unambiguous.

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

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 threshold suggesting when batching beats repeated single-tool calls, and no mention of alternatives. The batch nature implies usage, but nothing tells the agent when this is preferred over the individual draw_* 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 it a non-readonly, non-destructive, non-idempotent write, so the safety profile is partially covered. The description adds nothing beyond that: no statement about required drawing state, whether the circle is drawn on the current layer by default, or what happens on invalid radius/center.

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?

It is a single front-loaded clause with zero padding, so it is structurally clean. The brevity is under-specification rather than genuine efficiency, which caps it below a 4.

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 geometry-creation tool this is too thin: no coordinate system or unit context, no dependency on an open drawing, and no routing among the many draw_* siblings. The output schema does excuse it from explaining return values, but the input-side context is missing.

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

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

Schema coverage is 80% and the schema itself documents color, layer, center, and linetype well, so the baseline of 3 applies. The description contributes no additional parameter meaning, but it also isn't needed to compensate for large gaps.

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?

"Draw a circle" names a verb and resource, but it is a verbatim restatement of the tool name draw_circle and adds no distinguishing scope. It gives no way to tell it apart from siblings like draw_arc, draw_ellipse, or draw_polygon.

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 preconditions (e.g. an open drawing being required), and no mention of alternatives such as draw_arc or draw_batch. The agent is left to infer everything 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 cover the safety profile (not read-only, non-destructive, non-idempotent, closed-world), so the description does not need to restate those. Beyond that it adds nothing: it does not say the entity is added to the current/selected layer, nor anything about repeated calls creating duplicates despite idempotentHint=false.

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?

A single front-loaded sentence with zero waste. It is efficient, though for a six-parameter drawing primitive it errs on the side of being too terse to earn real informational value.

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

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

An output schema exists, so return values need not be explained, and the fully-covered schema means parameters are self-documenting. Still, a mutation tool that creates drawing entities gives no sense of what is created, where it lands, or how it relates to sibling primitives, leaving the definition minimally adequate.

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 100%, so the schema already documents center, major_axis, ratio, color, layer, and linetype. The description adds no extra meaning (e.g. angle convention for major_axis or ACI semantics), so the baseline 3 is correct when the schema does the heavy lifting.

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

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

States a clear verb and resource ('Draw a full ellipse'), and the word 'full' distinguishes it from partial-arc siblings like draw_arc. However, it does nothing to differentiate from draw_circle or draw_polygon, which a drawing agent must also weigh when choosing a primitive.

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, when-not-to-use, or alternative-tool guidance. The name implies its own usage, but nothing tells the agent when an ellipse is preferable to draw_circle, draw_arc, or draw_polyline, nor any preconditions.

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, non-destructive, non-idempotent), so the bar is lower, but the description adds nothing beyond them. It omits relevant behavior such as the default layer, coordinate expectations (2D vs 3D), or that a missing layer gets created (only stated in the schema).

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

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

A single front-loaded sentence with zero waste, but it is under-specified for a 5-parameter CAD drawing operation rather than genuinely well-sized. Brevity here reads as thinness more than 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?

An output schema and annotations exist, so return values need not be explained, but the description fails to cover drawing context an agent needs: target layer defaults, coordinate system/units, and how it differs from sibling drawing tools. Given the crowded sibling set, this leaves 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?

Schema description coverage is 100% (start/end coordinate format, color ACI/name options, layer creation behavior, linetype names), so the schema carries the meaning. The description contributes no additional parameter insight, making the baseline 3 appropriate.

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 ('Draw') and resource ('straight line segment'), which is unambiguous about the resulting entity. However, it does not distinguish itself from nearby siblings like draw_polyline or the line-producing variants, leaving sibling selection to 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 when-to-use guidance and no mention of alternatives such as draw_polyline for multi-segment geometry. The agent must infer from the name alone that this is the right tool for a single segment.

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=false, and destructiveHint=false, so the description carries a lower burden. It adds nothing beyond that: no note that it mutates the active drawing, that a new layer may be created, or that repeated calls pile up duplicate points.

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?

A single clause with zero padding and the resource front-loaded, but it is under-specified rather than genuinely concise. One sentence does the work, yet it borders on the tautological terseness penalized in the calibration examples.

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

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

The tool is simple (one required param), the schema is fully documented, annotations cover the safety profile, and an output schema exists, so the description needn't explain return values. However, it omits the mutation and layer-creation side effects that matter for a drawing-modifying 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 description coverage is 100%, so the baseline is 3; both color and layer have rich inline descriptions and location format is documented. The description adds no extra parameter meaning beyond what the schema already provides.

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

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

States a specific verb and resource ('Place a POINT entity'), which is unambiguous and distinguishable from siblings like draw_line or draw_circle by resource name. It does not, however, differentiate itself from alternatives such as draw_batch when multiple points are needed.

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 draw_batch, insert_block, or other entity-creation siblings, nor any mention of prerequisites (e.g., requiring an open drawing). Usage must be inferred entirely 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 readOnly=false, destructive=false, and idempotent=false, so the mutation profile is covered. The description adds that the result is a closed polyline, but does not disclose that repeated calls will create separate polygons or other behavioral details beyond the annotations.

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

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

A single front-loaded sentence with no redundant or filler content. It states exactly what the tool does and nothing more.

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 drawing tool with an output schema and annotations covering safety, the description is nearly complete. It correctly identifies the output as a closed polyline; the main gap is the absence of usage guidance relative to sibling drawing 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?

Schema description coverage is 86%, so the input schema already documents nearly all parameters. The description adds no parameter detail beyond the schema, which is acceptable given the high coverage 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?

States a specific verb and resource: 'Draw a regular polygon as a closed polyline.' This clearly distinguishes it from sibling drawing tools such as draw_circle, draw_rectangle, draw_line, and draw_polyline.

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 purpose implies when to use it — when a regular polygon is needed — but there is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative such as draw_polyline for arbitrary polylines.

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 readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the genuinely useful 2D-vs-3D behavior (auto-escalates to 3D when Z varies), which is not in the annotations. It does not, however, note that a missing layer is created as a side effect.

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?

A single tight sentence with zero waste, leading with the core action and appending the one non-obvious behavioral detail. Nothing 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?

An output schema exists, so return values need no explanation. For a 5-parameter drawing tool the description is minimally adequate: it covers the core action and 2D/3D nuance but omits sibling differentiation and side effects (auto layer creation), which an agent would want.

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 at 60%, color, layer, linetype, and points items are already documented; only 'closed' is undocumented. The description's '3D if Z varies' adds a small amount of meaning about the points array, but otherwise repeats what the schema conveys. Baseline 3 for partial coverage is appropriate.

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 polyline through the points.' The 2D/3D parenthetical further specifies the operation's nature. It does not explicitly differentiate from siblings like draw_line or draw_polygon, but the multi-point phrasing implicitly distinguishes it.

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 the closely related draw_line, draw_polygon, or draw_rectangle siblings, and no stated preconditions. It simply describes what the tool does, leaving routing entirely 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, idempotentHint=false and destructiveHint=false, so the agent knows this is a non-idempotent mutation that mutates the drawing. The description adds only that the output entity is a closed polyline; it says nothing about authorization, layer auto-creation side effects, or what is returned beyond what the output schema carries.

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?

A single sentence with the verb, resource, geometry and construction format all front-loaded; no filler or redundant restatement.

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 draw tool with full schema coverage, an output schema and safety annotations already present, the description covers the geometry needed to call it correctly. It leaves only minor gaps around preconditions (an open drawing/current space) and the default layer 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?

Schema description coverage is 100%, so the schema already documents color (ACI/name list), layer, linetype and the 2D/3D coordinate format. The description's only added meaning is that the two corner points are opposite corners (order-independent), which is a marginal gain over the schema.

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

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

States a specific verb and resource ('Draw an axis-aligned rectangle') and adds the construction detail that it is emitted as a closed polyline from two opposite corners. An agent can distinguish it from draw_polyline or draw_polygon by the axis-aligned geometry, though no sibling 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?

Usage is implied rather than stated: the 'axis-aligned' qualifier signals this tool is for non-rotated rectangles, which is a weak selection cue against draw_polygon/draw_polyline. There is no explicit when-to-use/when-not or prerequisite (e.g., requires an open drawing) 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 this is not read-only, not idempotent, and not destructive, so the safety profile is covered. The description adds the useful backend-to-format availability mapping, but says nothing about whether an existing file is overwritten, where the export lands, or what path semantics are — meaningful gaps for a file-writing 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?

A single front-loaded sentence with the verb first and no wasted words; the arrow notation packs the format lists compactly. It is slightly cryptic/abbreviated, but earns its brevity.

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

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

An output schema exists, so return values need not be described. For a 2-parameter export tool the description covers format availability adequately but leaves the path parameter's role and file-overwrite behavior unaddressed.

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

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

Schema coverage is 50%: format has a schema description ('Defaults to the path's extension') while path is undocumented. The description adds value by narrowing which formats are valid per backend (e.g., headless lacks dwg/bmp/wmf), but does not clarify whether path is the input drawing or the output destination.

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 (Export) and resource (the drawing) and enumerates the output formats supported, so an agent immediately knows what the tool produces. However, it does not distinguish itself from closely related siblings like save_drawing or render_preview, leaving the agent to infer the boundary.

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, when-not-to-use, or alternative-tool guidance. The backend/format mapping hints at a condition (AutoCAD vs headless mode) but is a capability constraint rather than a directive on when to pick this tool over save_drawing or render_preview.

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 openWorldHint=false, so the safety profile is fully covered without the description. The description adds essentially no behavioral context beyond the field list, which the output schema already conveys, and says nothing about caching, freshness, or failure when no drawing is active.

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?

A single compact sentence with no filler; the returned fields are front-loaded. It is efficient, though as a bare field inventory it reads more like a schema blurb than a 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, required parameters at zero, and annotations covering the safety profile, the description only needs to frame what the tool is for. It does that adequately, though it leaves unaddressed when to prefer it over cad_status or other inspection 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-argument tool is 4. The description correctly implies no input is required.

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 names the specific resource (the active drawing) and enumerates the exact fields returned (name, path, units, current layer, entity count, extents), so an agent can tell what it gets back. It lacks an explicit verb and does not distinguish itself from similar read tools such as cad_status or list_layers, which keeps it 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?

There is no when-to-use statement, no prerequisite, and no mention of alternatives, even though sibling tools like cad_status and list_entities overlap in scope. The agent is left to infer that this is the metadata query for the current drawing.

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 structurally. The description adds that this is a single-record handle lookup and enumerates the returned attributes, which is useful but partly duplicated by the existing output schema.

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

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

A single sentence with zero filler, front-loaded with the verb and the lookup key. Every word earns its place.

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

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

An output schema exists, so the enumerated return fields need not be explained, and annotations cover the safety profile. For a one-parameter read tool the definition is nearly sufficient; the remaining gap is the absence of any handle format or error/not-found 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?

Schema description coverage is 0% for the single 'handle' parameter, so the description must compensate. It does convey the parameter's role (identifies which entity to fetch via 'by handle') but gives no format detail such as expected handle syntax, and 'handle' as a bare property name is otherwise unexplained in the schema.

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

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

States a specific verb ('Get'), a specific resource ('one entity'), and the attributes returned (type, layer, color, geometry) keyed by handle. The singular 'one entity' implicitly distinguishes it from the sibling list_entities, though it never names that alternative 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?

No when-to-use, when-not-to-use, or alternative routing is provided. The agent must infer from 'one entity by handle' that this is the lookup path when a handle is already known and list_entities is not appropriate; nothing in the text confirms that.

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 no behavioral context beyond that, such as whether the block must already exist, whether missing layers are created, or what side effects occur.

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 single sentence is front-loaded and contains no wasted words. It is extremely concise, though arguably too sparse for a six-parameter mutation 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?

An output schema exists and annotations cover the safety profile, so the description need not explain return values or read-only status. Still, for a CAD insertion tool with sibling create_block/list_blocks, the description lacks context about prerequisites and the distinction between inserting and creating a block.

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 provides no parameter information at all. Schema description coverage is 67%, leaving parameters like scale and rotation undocumented, and the description does not compensate for those gaps.

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 specific verb and resource: 'Insert a block reference.' An agent can tell this is about placing a block, not listing or creating one. However, it does not explicitly differentiate from sibling tools such as create_block or list_blocks, so it falls 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives like create_block. The agent must infer from the name alone that this is for inserting existing block definitions.

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, fully covering the safety and side-effect profile of this call. The description adds no behavioral context beyond that, but with zero parameters and a trivial read, there is little else to disclose and nothing is contradicted.

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?

A single short sentence with zero waste, front-loading the action and resource and placing the downstream use case immediately after. Nothing to trim.

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 explain return values, and the no-param schema keeps invocation simple. It would be marginally stronger if it stated whether the listing includes blocks from external references, but it is essentially complete for this call.

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 no parameters, so per the rubric the baseline is 4. The description correctly implies an unfiltered enumeration by not mentioning any filtering or scoping arguments.

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 (block definitions), and explicitly ties the output to its consumer, insert_block. It's clearly distinguishable from list_layers and list_entities by resource, though it doesn't explicitly contrast with create_block, which also deals with blocks.

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 phrase 'available for insert_block' implies the natural workflow (list before inserting), giving implied usage guidance. However, there is no explicit when-to-use or when-not-to-use statement, nor any naming of an alternative tool.

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 behavior, so the safety profile is covered. The description adds that results are capped 'up to limit' and include geometry, which is useful truncation context, but says nothing about ordering, total counts, or how filters combine.

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?

A single short sentence with the scope front-loaded and no filler. It is efficient, though borderline under-specified for a tool with three optional filters.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a list tool with three optional filters and a truncation cap, the description gives no guidance on filter combination, result ordering, or what happens when the cap is hit, leaving meaningful 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?

Schema description coverage is 67%: layer and entity_type carry descriptions (including the entity_type type list) while limit is self-documenting via default/min/max constraint. The description's 'filtered' and 'up to `limit`' wording restates rather than extends what the schema already provides, so the baseline 3 applies.

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 (model-space entities) plus the notable payload detail that geometry is included. It implicitly separates itself from get_entity (single) and list_layers/list_blocks (other resource types), but never names a sibling or states the contrast 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?

The parenthetical '(filtered, up to `limit`)' hints that filtering and truncation are expected, but there is no explicit when-to-use, when-not, or guidance on choosing this over get_entity when a single entity is wanted. 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the returned attribute set, which is already available in the output schema, and does not disclose pagination, ordering, or other behavioral context.

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

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

A single front-loaded sentence with no filler. It states the resource and the key returned attributes immediately, making it easy to scan.

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 zero-parameter, read-only listing tool with rich annotations and an output schema, the description is complete enough. It states what is listed and what attributes are included, so an agent has everything needed to invoke it correctly.

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

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

The tool has zero parameters, so there is no parameter semantics to clarify; the baseline for a parameterless tool is 4. The description correctly adds no conflicting or irrelevant parameter information.

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 ('layers'), and names the returned attributes such as color, linetype, and layer states. The resource clearly distinguishes it from sibling list tools like list_blocks and list_entities.

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

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

No explicit when-to-use, when-not-to-use, or alternative tool is named. The simple read-only purpose makes usage implicit (call it when you need layer information), but there is no routing guidance against siblings such as get_drawing_info or cad_status.

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. The description usefully explains the default source-preserving behavior that justifies the non-destructive hint, but says nothing about permissions, what happens to the originals when delete_source=true, or how the mirror is computed in 3D.

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?

A single front-loaded sentence that packs the operation, the axis, and the default behavior with 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 return values need no explanation, and annotations carry the safety profile. The description is nearly complete for a 4-parameter transform, though it could note the optional destructive behavior enabled by delete_source.

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 75%, and the description compensates for the one undocumented parameter by explaining delete_source's effect on the originals. p1/p2 and handles formats are already covered by 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 (mirror), the resource (entities), and the exact transform axis (the line p1-p2), which cleanly separates it from siblings like move_entities, rotate_entities and copy_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?

Usage is only implied: 'keeps the originals unless delete_source' hints at the copy-vs-move distinction but never states when to choose this over copy_entities or offset_entity.

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 full safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the safety burden is lifted. Beyond that, the description adds no behavioral context: it does not say what happens to entities on locked or frozen layers, whether the move is undoable, or what the result contains.

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?

A single short sentence with the operation front-loaded; nothing is wasted or buried. Size is appropriate for the amount of information conveyed.

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 and the input schema is fully documented with annotations, the description need not explain return values or safety. However, for a bulk mutation of handles, it says nothing about failure modes (invalid/locked handles) or whether the operation is atomic, leaving the agent to guess at edge-case 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?

Schema description coverage is 100% — both 'handles' (entity handles, hex strings) and 'displacement' ([x, y] or [x, y, z]) are documented in the schema. The description's '[dx, dy(, dz)]' merely restates the schema, adding no syntax, unit, or axis-convention detail beyond it, so baseline 3 applies.

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

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

The description states a specific verb and resource ('Move entities') plus the exact mechanism ('by a displacement vector'), so an agent immediately knows what the tool does. It does not differentiate from siblings such as offset_entity or rotate_entities, which also transform entities, so a routing distinction is missing.

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 or when-not-to-use guidance, and no mention of the obvious alternative (offset_entity) for offsetting rather than displacing. The agent must infer selection from the tool name alone.

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

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's added burden is smaller. It contributes one real behavioral fact — the new drawing becomes active — but says nothing about what happens when a drawing is already open or whether unsaved work is affected.

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?

One sentence, front-loaded with the action, zero filler. Nothing could be removed without losing 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?

An output schema exists, so return values need not be explained, and with one optional param the definition is nearly sufficient. The minor gap is that it omits the template parameter entirely, which an agent only discovers by reading the 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?

Schema coverage is 100% and the single optional parameter is documented there ("Optional .dwt template (AutoCAD) or .dxf (headless)"). The description never mentions the template option at all, so it adds no meaning beyond the schema; baseline 3 applies.

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 ("Create a new ... drawing") with two qualifiers that matter: it is empty and it becomes the active drawing. That contrast implicitly separates it from open_drawing, though it never names that sibling, so it lands just short of 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: an agent can infer that "new, empty" means start-from-scratch rather than load an existing file, but there is no explicit when-to-use statement, no guidance on when to prefer open_drawing, and no mention of template prerequisites.

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 a non-destructive, non-idempotent, non-read-only write. The description usefully adds that this creates a *parallel* copy rather than a plain duplicate and that it is restricted to lines, arcs, circles and polylines, which is real behavioral information. It does not say what happens for an invalid handle or an unsupported entity type.

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?

A single front-loaded sentence with zero waste, verb and resource first. Its brevity is appropriate in form; the missing content belongs to other dimensions rather than to structural 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?

An output schema exists so return values needn't be described, and annotations cover the safety profile. What is missing is the handle semantics and any routing guidance against the many sibling duplication/modification tools, which for a 2-required-param mutation tool leaves a noticeable 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?

Schema coverage is 50%: distance is documented ('the sign picks the side') but handle has no description at all. The description adds no parameter meaning, so it neither explains what a handle is nor where to obtain one (e.g. list_entities/get_entity), leaving the required-property gap unpatched.

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 parallel copy of a named set of entities. The parenthetical (OFFSET) ties it to the familiar CAD operation and the enumerated geometry types (line, arc, circle, polyline) implicitly distinguish it from the generic copy_entities/scale_entities siblings, though no sibling is named.

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 when-to-use or when-not guidance. The description never says how this differs from copy_entities or move_entities, nor that unsupported entity types (text, hatch, block references) will fail despite being listed siblings that also support duplication-like operations.

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. The description adds one piece of behavioral context beyond them: the call mutates session state by making the drawing active. It does not disclose whether an already-active drawing with unsaved changes is discarded, nor what happens on a missing/invalid 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?

One front-loaded sentence with zero filler, well matched to a one-parameter tool. It is arguably terse for a state-changing operation, 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 return values need not be explained, and annotations carry the safety profile. For a simple 1-param tool the description is nearly complete; the only real omission is how an already-open/active drawing is handled.

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 100%: the schema already documents the single required 'path' parameter as 'Path to a .dwg/.dxf file'. The description adds no format, resolution, or relative-vs-absolute path guidance, so the baseline 3 applies.

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?

Clear verb+resource: 'Open an existing drawing and make it active.' The word 'existing' implicitly contrasts with the sibling new_drawing, so an agent can distinguish the two without opening a schema. It falls short of 5 only because no sibling 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?

There is no statement of when to use this tool versus alternatives (e.g., new_drawing), no prerequisites, and no note about what happens to the currently active drawing. Usage is only faintly implied by 'make it active'. This is essentially no 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 readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered. The description adds only that the render targets the *current* drawing and yields a PNG, but says nothing about resolution, whether a file is written, or whether a viewer is opened — modest added value against an already-strong annotation set.

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?

A single front-loaded sentence with no filler; the verb and output format appear immediately and every word carries 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 simple zero-parameter, non-destructive render tool with full annotation coverage, the description is sufficient: an agent knows it returns a PNG of the current drawing for visual verification. The only gap is the absence of an output schema combined with no statement of what the return payload actually looks like.

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 nothing for the description to disambiguate and the baseline is 4. Schema coverage is nominally 100% because the object is empty.

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 (Render) plus resource (the current drawing) and names the output artifact (PNG image). The purpose is unambiguous, though it never distinguishes itself from the sibling export_drawing, which an agent could reasonably confuse with a preview render.

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 clause 'so you can check the result visually' implies the usage context: call it to verify drawing state after mutating operations. However, it gives no explicit when-to-use trigger, no exclusions, and no mention of the alternative export_drawing for producing a file.

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). The description adds no behavioral context beyond what annotations and schema provide—it does not explain mutation effects, reversibility, or what happens to existing entity geometry.

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?

A single precise sentence with zero redundancy. The operation is front-loaded and every word earns its place.

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

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

For a simple transform tool with full schema coverage, an output schema, and annotations covering safety, the description is nearly sufficient. However, it omits usage context relative to sibling transform tools and does not clarify whether entities are modified in place or copied, leaving minor 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?

Schema description coverage is 100%, so all three parameters are fully documented in the input schema. The description's phrase 'about a base point' maps to the base_point parameter but adds no syntax or format detail beyond the schema, warranting the baseline 3.

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

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

The description states a specific verb ('Rotate') and resource ('entities') with scope ('about a base point'). It is distinguishable from siblings like move_entities or scale_entities by the verb alone, but it does not explicitly differentiate itself or mention alternatives, so it falls 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?

There is no guidance on when to use this tool versus alternatives such as move_entities, copy_entities, or mirror_entities. The description only states the operation, leaving context and prerequisites 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 flag destructiveHint=true and non-read-only, but the description adds genuinely new behavioral context: backend restriction, blocked command classes, and the env-var gate for LISP. It does not, however, describe failure behavior or how commands are acknowledged, which would complete the picture for a destructive tool.

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

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

Two compact sentences with zero filler; the core purpose and the backend constraint are front-loaded before the edge-case env-var note.

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 annotations carry the safety profile, so the description does not need to explain returns. It covers the backend and permission constraints well; the only gap is not steering the agent toward dedicated tools when they 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?

Schema description coverage is 100% and already gives the format (e.g. '_.FILLET R 5 ') and the newline-as-Enter convention, so the baseline of 3 applies. The description adds no additional meaning about the 'command' parameter beyond what the schema provides.

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 (send) and resource (raw input to the AutoCAD command line), which cleanly separates it from all sibling tools that operate on structured entities or drawings. The '(AutoCAD backend only)' qualifier further narrows scope, so an agent can identify this as the escape-hatch tool without opening the schema.

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

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

It specifies two hard preconditions (AutoCAD backend only, POWER_CAD_ALLOW_LISP=1 for AutoLISP) and notes that shell/script/loader commands are blocked, which is real routing guidance. However, it never says when to prefer this over the many dedicated siblings (draw_line, create_layer, etc.) or that raw commands should be a fallback.

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=false, destructiveHint=false, covering the safety profile. The description adds useful behavioral context about in-place versus save-as behavior, but does not disclose what happens if the path already exists (overwrite or fail), which is the main risk for a save operation.

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?

One short sentence, front-loaded with the primary action and qualified by an optional modifier. No filler or 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, zero-required tool with full schema coverage, complete annotations, and an output schema, the description covers what an agent needs. The only meaningful omission is overwrite/confirmation behavior when the target path already exists.

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

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

With a single parameter at 100% schema description coverage, the schema already documents 'path' including the .dwg/.dxf extension constraint and the omit-to-save-in-place default. The description only echoes that in prose, so the baseline of 3 applies.

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 (save) and resource (the active drawing), and the parenthetical clarifies the scope with an optional save-as. It does not explicitly distinguish itself from the closest sibling export_drawing, leaving that inference to the agent.

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: 'optionally under a new name' hints at save-in-place vs save-as, but there is no explicit when-to-use guidance or a named alternative to prefer for export/format-conversion scenarios.

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 this is a non-read-only, non-destructive, non-idempotent mutation, so the safety profile is covered. The description adds a genuine behavioral trait beyond that: scaling is 'uniform' (one factor for all axes) and anchored 'about a base point', which tells the agent the base point is the fixed reference. It does not say what happens to entities whose handles are missing or how the factor behaves below 1.

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?

A single front-loaded sentence with no filler or redundancy; every word carries information. It is arguably terse to a fault, but it is not padded or back-loaded, so it satisfies the conciseness bar well.

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

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

An output schema exists, so return values need not be explained, and annotations cover the mutation safety profile. What remains thin is the transform semantics themselves: whether the base point is absolute or relative, and how non-existent handles are handled. Adequate but with visible gaps for a 3-required-param geometry mutation.

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 67%: 'handles' and 'base_point' are documented inline, while 'factor' is only constrained by exclusiveMinimum: 0. The description's word 'uniformly' implies a single scalar factor applied to all axes, which is meaningful, but it adds no format, range, or coordinate-space detail beyond what the schema already supplies. Baseline 3 for partial coverage.

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 ('scale entities') plus the two qualifiers that matter most for disambiguation: 'uniformly' and 'about a base point'. An agent can distinguish it from offset_entity, rotate_entities, or a hypothetical non-uniform scaler. It stops short of naming any sibling explicitly, so it lands at 4 rather than 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 by the verb: resize existing entities rather than move/rotate/copy them. There is no statement of when to prefer this over offset_entity or set_entity_properties, and no prerequisites (e.g. entities must be selected by handle). Minimal but adequate.

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 this as a non-readonly, non-destructive mutation, but the description adds important behavioral context: the chosen layer becomes the default target for new entities without an explicit layer. It does not mention persistence, error conditions, or whether the layer must already exist.

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 a single front-loaded sentence with no wasted words. Both clauses earn their place by stating the action and its key consequence.

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 mutation tool with annotations and an output schema, the description covers the core action and its main side effect. It is nearly complete, though it slightly underspecifies parameter requirements and does not mention scope 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?

Schema description coverage is 0% for the single 'name' parameter. The description only implies that the parameter is a layer name and does not specify constraints such as whether the layer must exist, case sensitivity, or what happens if the name is invalid.

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 specific verb and resource ('Make a layer current') and clarifies the effect on new entities. However, it does not name or contrast with any sibling tools (e.g., update_layer, create_layer), so it lacks explicit 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 description implies when to use the tool by stating that new entities without an explicit layer will go to the current layer. It does not provide explicit when-not guidance or mention alternatives like update_layer for changing layer properties.

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 a mutating (readOnlyHint=false), non-destructive, non-idempotent operation, and the description's 'Change' aligns with that. It adds no context beyond the annotations, such as reversibility of the edit or that the target is identified by handle. With annotations covering the safety profile, a 3 is appropriate.

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?

A single front-loaded sentence with zero waste; the changed properties are listed immediately. It is efficient, though it stops short of any additional useful scoping.

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

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

An output schema exists so return values need not be explained, and annotations cover safety. However, for a 5-parameter mutation tool the description omits the required handle as the targeting key and offers no behavioral detail, leaving it minimally adequate rather than 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?

Schema description coverage is high (80%), so the schema already documents ACI codes, layer auto-creation, linetype names, and lineweight units. The description only restates the four editable properties and adds no format or syntax detail beyond the schema, matching the baseline for high coverage.

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 ('Change') and resource ('an entity's') plus the exact editable properties (layer, color, linetype, lineweight), which separates it from geometry/transform siblings like move_entities or rotate_entities. It does not explicitly name the sibling it complements, but the field list makes the scope 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?

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives (e.g., use move_entities for geometry instead). Usage is only implied by the stated purpose.

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 this is a non-read-only, non-destructive, non-idempotent mutation, so the safety profile is covered. The description adds the set of mutable properties but omits key behavior: that omitted/null parameters leave values unchanged, and that renaming is driven by a separate new_name parameter. No contradiction with annotations.

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

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

A single front-loaded sentence that lists the operations efficiently, with zero filler and no repetition of the tool name.

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 and annotations present, the description need not explain returns or safety. However, for a 7-parameter mutation with low schema coverage, it leaves gaps: no statement that unspecified properties stay unchanged, no handling of nonexistent-layer errors, and no link between 'rename' and new_name.

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 only 29% (7 params, only color and linetype documented), so the description must compensate. It does partially by naming the operations that map to on, frozen, locked, linetype, and new_name, but it never ties 'rename' to new_name nor explains that the required 'name' identifies the target layer and null means no change.

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 specific verb (Change) plus resource (layer) and enumerates every mutable property: color/linetype, on/off, freeze/thaw, lock/unlock, rename. This is enough for an agent to distinguish it from create_layer, delete_layer, list_layers, and set_current_layer without opening a schema.

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

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

Usage is implied by the enumerated operations, and the sibling names (create_layer, delete_layer, list_layers) make the CRUD role obvious, but the description names no explicit when-to-use or when-not-to-use conditions and no alternative tool.

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 are present (readOnlyHint=false, destructiveHint=false, idempotentHint=false) and already cover the safety profile, but the description adds nothing behavioral on top of them — it does not say whether this only changes the camera/view state versus the drawing data, nor what happens on an empty drawing or with multiple viewports.

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?

A single short sentence that front-loads the action and states the outcome with no filler. 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?

For a zero-parameter view command with an output schema, the description is minimally sufficient, but it omits the zoom_window distinction and any note on scope (current viewport vs. all viewports) or behavior on an empty 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline credit applies. No parameter detail is needed or missing.

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

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

The description states a concrete verb (zoom) and target (the view) plus the scope of the result (whole drawing), so an agent knows exactly what the call produces. It does not name or contrast with the obvious sibling zoom_window, so the sibling differentiation is left to inference.

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 or when-not-to-use guidance, and no mention of the natural alternative zoom_window for zooming to a user-specified region. The intent is only weakly implied by 'show the whole drawing'.

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. The description adds that it zooms the view (not drawing data), which is mildly useful, but it omits reversibility, persistence, and coordinate-system details.

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?

A single front-loaded sentence with zero waste. It states the operation and its defining input in one pass.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. For a simple viewport zoom, the description is adequate, though it could mention viewport-only scope or coordinate system.

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 100% and already documents the coordinate formats. The description adds the semantic role that p1 and p2 are two corners spanning the window, which is meaningfully more than the schema provides.

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 'Zoom' and resource 'view to the window spanned by two corners'. It is clear in isolation, but does not name or differentiate from the sibling zoom_extents, so it falls 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?

No explicit when-to-use guidance, exclusions, or alternative tools are mentioned. The sibling zoom_extents exists but is not referenced, leaving the agent to infer the choice from the tool name alone.

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