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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond that: nothing about what redefining an existing block does to prior insertions, what happens to source entities after create, or whether deleteSource actually deletes files.

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 resource and its modes, with no filler. The brevity is only mildly under-specified rather than wasteful.

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

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

A 10-parameter, multi-mode mutation tool with nested objects and no output schema needs substantially more than a single sentence. The agent cannot tell which parameters are required per action or what the tool returns, so the definition is incomplete 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?

Schema description coverage is 0% across 10 parameters, so the description must carry the load and it does not. Only indirect hints appear ('from entities' → sourceHandles, 'import a DWG' → sourcePath); scale, rotation, basePoint, insertionPoint, attributes, and deleteSource are entirely unexplained in both schema and description.

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 resource (block) and enumerates the operations it performs (create definition, insert, redefine, import DWG). An agent can tell it deals with block definitions rather than raw geometry, though it never differentiates itself from siblings like cad_draw or cad_edit.

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 lists four operations but gives no condition for choosing among them, no mapping of operations to parameters, and no guidance on when to use cad_block versus cad_draw/cad_edit. Worse, 'redefine' is named in prose but absent from the action enum, leaving the agent unsure which action value achieves it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the key behavioral fact that this runs without contacting AutoCAD, which explains why it is offline-safe and deterministic. It could go further on return shape, but the offline guarantee is genuinely useful extra 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, information-dense sentence with the offline constraint front-loaded at the end and no redundant phrasing. Every clause ('exact 0.0.3', 'limits', 'coordinate conventions', 'verified export behavior', 'without contacting AutoCAD') 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 zero-param, read-only, offline manifest tool with no output schema, the description covers purpose, scope of returned data, and the critical offline behavior. Nothing an agent needs to decide whether to call it is missing.

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

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

With zero parameters, the baseline is 4. The description correctly implies a static, parameterless manifest lookup – nothing to pass in. No further parameter context is needed.

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 ('Return') and resource ('feature matrix, limits, coordinate conventions, verified export behavior'), with a clear distinguishing constraint: it does not contact AutoCAD. Among siblings like cad_status, cad_inspect, cad_view, this is unmistakably the static/manifest tool rather than a live-connection tool.

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

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

The phrase 'without contacting AutoCAD' indirectly signals when to use it – for pre-flight capabilities lookup before needing a live connection. However, it does not explicitly contrast with cad_status or cad_connect, leaving the boundary with those siblings implied rather than stated.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=false, and idempotentHint=false, so the safety profile is known. The description adds critical context: commands are blocked unless explicitly allowlisted in the plugin configuration. It doesn't explain what happens on failure, what the return format is, or how waiting for completion affects behavior, so it earns a 3 despite the useful allowlist note.

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 concise sentences with no waste, and the primary constraint (use only as fallback) is front-loaded before the allowlist condition. Very efficient and readable.

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 no annotations coverage for safety details, no output schema, and 0% schema description coverage, the description should do more to explain the parameters, the command string format, expected return behavior, and the consequences of destructive commands. The allowlist note is valuable but insufficient for a high-risk, unannotated 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 0% and all three parameters (command, arguments, waitForCompletion) lack any documentation in both the schema and the description. The description does not mention any parameter, leaving the agent to infer their format and constraints, which is especially problematic for a command-string-based interface.

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: 'Run an AutoCAD command sequence'. It also distinguishes from specialized siblings by positioning itself as a fallback when those cannot express the operation. The scope of 'command sequence' is slightly ambiguous, but the core purpose is clear.

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

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

Explicitly says to use this only when a specialized MCP tool cannot express the operation, which effectively implies using the specialized sibling tools first. However, it doesn't name specific alternatives or provide concrete examples of what that means in practice.

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?

The description discloses a genuinely important behavioral trait beyond the annotations: it is stateful and mutates how all subsequent calls are routed. The annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) only imply a non-read-only, non-idempotent operation; the routing effect is the real value added. It still omits edge behavior such as what happens if processId is stale or the process exits.

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: the action is front-loaded and the second sentence justifies it without redundancy. Nothing is 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?

For a one-parameter, no-output-schema tool the description covers what it does and why, which is close to sufficient. The remaining gap is discoverability of the required processId, which neither the schema nor the description addresses.

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 required parameter, so the description carries the full burden and adds nothing about processId. It never says where the value comes from (presumably cad_instances) or what form it takes, leaving an agent to guess at the most critical input.

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 action and target ("Bind subsequent MCP calls to one specific AutoCAD process") plus the rationale (avoiding routing to the wrong drawing). It clearly reads as a session-scoping tool distinct from cad_command or cad_draw, but it never names the sibling that supplies the processId (cad_instances) or contrasts itself with cad_view/cad_status.

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 gives an implicit trigger condition ("when multiple instances are running") that tells the agent when binding matters, which is better than nothing. However, there is no explicit when-not guidance, no mention of how to discover the correct process, and no statement about whether the binding persists or can be released.

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=true, and idempotentHint=false, but the description adds no color: it never warns that close may discard unsaved work, that overwrite can destroy an existing file, or that behavior differs per action. The absolute-path requirement is the one genuinely useful addition.

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 tightly written sentences with zero filler and the action list front-loaded. It is efficient, though the extreme brevity leaves useful detail out.

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

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

For a destructive 8-parameter file-management tool with no output schema and no per-parameter documentation, the description is far too thin. An agent cannot infer what each action returns or how the optional flags interact.

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

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

Schema description coverage is 0% across 8 parameters, so the description carries the burden, yet it only clarifies the path constraint. Nothing explains version, template, documentId, readOnly, overwrite, or discardChanges semantics, and the action enum values are documented only in the schema.

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

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

The description gives clear verbs (create, open, save, save-as, close, activate, list) and a specific resource (AutoCAD drawings), which lets an agent distinguish it from cad_draw and cad_edit. It does not explicitly name which sibling handles read-only viewing or instance listing, so sibling routing is left implicit.

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

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

Nothing tells the agent when to choose this tool over cad_view, cad_instances, or cad_command, nor when each action variant applies. The only guidance is a path format constraint, not a usage condition.

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

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

Annotations already establish readOnly=false, destructive=false, non-idempotent, closed-world, but the description adds genuine behavioral facts on top: 'Atomically' declares all-or-nothing batch semantics, which is a real transactional guarantee not expressible via the annotations. It also fixes unit/coordinate conventions (radians, current UCS), though it omits the 1000-entity cap and the fact that repeated identical calls will duplicate 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?

Two short sentences, both front-loaded: the capability first, then the cross-cutting conventions. Every clause carries information and nothing is 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?

For an 11-variant polymorphic schema with no parameter documentation and no output schema, the description is thin: it does not mention that a document must be connected first, does not say whether entity handles are returned (which matters because hatch requires boundaryHandles from pre-existing entities), and does not cover the 1000-item batch limit.

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% – not a single parameter or sub-field is documented in the schema – so the description carries the full burden. It partially compensates by declaring radians for angular fields and UCS for coordinates (which implicitly explains the coordinateSystem enum), but never explains 'space' (model/paper/current), 'zoomToResult', the entities array shape, or hatch boundaryHandles.

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 (create) plus an enumerated resource set (2D entities, annotations, hatches, dimensions, block references), so an agent can tell this is the drawing/creation tool rather than cad_edit or cad_block. It stops short of naming a sibling to contrast with, 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?

There is no statement of when to use cad_draw versus cad_command (raw command execution), cad_edit (modify existing), or cad_block (block definition), nor any preconditions such as requiring an open document via cad_connect. The only cue is the word 'create', which is inference rather than 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 destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the agent knows this mutates state. The description adds one genuine behavioral trait beyond that: 'Atomically', signaling all-or-nothing execution. It does not disclose side effects of erase, interaction with undo history, or what happens when zero entities match and allowEmpty is 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?

Two tight sentences with zero filler, and the entity-selection mechanism is front-loaded ahead of the operation inventory.

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

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

For a mutation tool with a nested, largely undocumented schema and no output schema, the description covers the headline capability but leaves meaningful gaps: the 50-operation cap, the meaning of allowEmpty, and the coordinate formats expected by move/copy/rotate/scale/mirror are all unstated.

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

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

Schema description coverage is 0% across three parameters with deep nesting, so the description must compensate and only partially does. It explains 'exact handles' vs 'constrained filter' for target and its operation-name list maps onto the operation discriminators, but allowEmpty, the filter fields (layer, types, window, colorIndex, textContains), and the geometry parameters (base, angle, factor, first/second, eraseSource) remain undocumented anywhere.

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 (edit) and resource (entities), states the two selection modes (exact handles or constrained filter), and enumerates the supported operation set. It is clear what the tool does, though it never contrasts itself with the generic sibling cad_command, which an agent might reach for instead.

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 description tells you the tool edits entities and how targets are selected, but gives no when-to-use guidance, no rule for choosing handles vs filter, and no exclusions relative to cad_draw, cad_command, or cad_undo.

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 write. The description adds a genuinely useful constraint (destination must be an absolute path), but it is silent on overwrite semantics even though an 'overwrite' parameter exists, and on whether long exports are rate-limited or how failures are surfaced.

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 tight sentences with the format list first and the path constraint second; nothing is padded. However, that brevity is achieved by omitting rather than by precision, so it is efficient but arguably under-sized for a 7-parameter tool.

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

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

With 7 parameters, 0% schema coverage, nested options, and no output schema, the definition leaves the agent unable to infer how to use layout, selection, version, or overwrite. Only format and path are addressed, so it is not complete enough to call the tool confidently.

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

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

Schema description coverage is 0% across 7 parameters, so the description must carry the burden and it largely does not. It touches only 'format' (and even then omits 'stl', which is in the enum) and 'path', leaving layout, options, version, overwrite, and selection completely unexplained in both the schema and the description.

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 (active drawing or a layout) plus the output formats, so the agent immediately knows this produces files rather than viewing or editing them. It does not explicitly contrast itself with siblings such as cad_view or cad_draw, but the export framing is naturally distinct.

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

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

The description says what can be exported ('active drawing or a layout') but never says when to choose this over alternatives or what prerequisites apply, aside from the absolute-path requirement. There is no guidance on when a layout-only export is appropriate versus a full drawing export.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds one behavioral hint (handles are reusable for edits) but does not state pagination behavior (limit/offset), whether entity geometry is omitted by default, or what happens with large drawings. For a read tool with 8 params and nested filters, this is thin.

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

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

Two short sentences, no filler, front-loaded with the verb and the enumerated resource scope. Efficient.

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 tool with 8 parameters, a nested filter object, an enum scope, and 13% schema description coverage, the description is far too sparse. No output schema exists, so the description should describe what gets returned (metadata shape, pagination, handle usage), but does not. Only one workflow hint (handles for edits) is provided.

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 13%; six of eight parameters (limit, scope, filter, offset, handles, includeExtents, includeGeometry) have no description in the schema and the description contributes nothing about any parameter. The description mentions 'handles' and 'system variables' loosely but does not explain scope enum values, filter semantics, pagination, or the geometry flag. It fails to compensate for the low 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 (Read) plus a concrete resource list of CAD drawing metadata (system variables, layers, blocks, layouts, styles, entities). Clear what the tool does, though it doesn't explicitly contrast with cad_edit/cad_document beyond the hint 'Use handles returned here for precise edits.'

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 second sentence implies a workflow: read here, then edit using returned handles. But no explicit when-to-use vs siblings (e.g., cad_document, cad_measure, cad_instances) is given. Implied usage only.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds value beyond that by scoping the result to processes registered with this MCP server and disclosing the returned fields (PID, active drawing), which matters since no output schema exists.

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

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

Two sentences, each earning its place: the first defines the output, the second defines when to call it. The purpose is front-loaded ahead of the usage rule.

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

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

For a parameterless read-only discovery tool with full annotation coverage, the description supplies everything needed: what is listed, what is returned, and when to prefer it over cad_connect. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify about inputs, and it correctly implies no arguments are needed.

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 (running AutoCAD 2024 processes) plus the scope constraint (registered with this MCP server) and returned fields (PID and active drawing). An agent can distinguish this discovery tool from cad_connect or cad_status 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?

Explicitly names the trigger condition and the follow-up tool: 'Use this before cad_connect when multiple AutoCAD windows are open.' The when-to-use and the related alternative are both stated, leaving nothing to inference.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say which actions are destructive (delete/rename vs. isolate/restore), what happens to entities on a deleted layer, or whether changes can be undone via cad_undo.

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 that front-loads the action and resource with no filler. It is well-structured, though it spends its limited budget restating the enum rather than clarifying behavior.

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

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

For a destructive, non-idempotent mutation tool with no output schema, 0% parameter documentation, and a nested properties object, the definition is far too thin. An agent cannot determine action-specific parameter requirements, side effects on drawing entities, or reversibility.

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

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

Schema description coverage is 0% and there are 4 parameters including a nested properties object with eight sub-fields. The description only echoes the action enum values and never explains how 'name' vs 'newName' pair with specific actions, or what the nested properties (frozen, locked, colorIndex, etc.) do.

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 pairs a set of specific verbs (create, update, delete, rename, set current, isolate, restore) with a clear resource (drawing layers), so an agent immediately knows the domain. However, it offers no differentiation from sibling tools such as cad_edit or cad_draw, which could plausibly also mutate layer-related state.

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

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

The sentence lists available actions but never states when to choose this tool over cad_edit, cad_draw, or cad_undo, nor does it describe prerequisites such as needing an active document or existing layer. Usage is only inferable from the action list.

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, and openWorldHint=false. The description adds nothing about permissions, whether deleted layouts are recoverable, whether activating a layout affects the active document/viewport, or how settings apply. The listing of 'delete' alongside destructiveHint=false is worth noting but not clearly contradictory, since deleting a layout need not destroy drawing content.

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 the resource and operation set front-loaded and no filler. It is efficient, though it spends its words restating the enum instead of adding operational detail.

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?

This is a complex multi-action tool with a nested settings object, conditional parameter requirements, and no output schema. The description covers none of the per-action parameter contracts or return behavior, leaving an agent unable to call configure or rename correctly from the definition alone.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does not. It never explains that 'name' identifies the target layout, that 'newName' is required for rename, or that 'settings' (with media, scale, device, window, plotType, orientation, etc.) is only consumed by the configure action.

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

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

The description names a concrete resource ('paper-space layouts and their plot settings') and enumerates the operations available, so an agent can distinguish it from siblings like cad_layer or cad_block. However, the verb list is essentially a restatement of the action enum rather than an explanation of what the tool accomplishes, and it draws no explicit contrast with related CAD tools.

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

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

There is no guidance on when to use this tool versus alternatives, nor any indication of which action to pick for a given intent. The six operations are listed but no preconditions, sequencing, or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds that mass is optional and derives from density, but it omits relevant behavior such as the 500-entity cap on handles and what happens with unsupported entity types.

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 and then a compact enumeration of outputs; every clause carries information and nothing is redundant.

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

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

With no output schema, the description usefully enumerates the returned metrics, which is the key information an agent needs. It is nearly complete for a read-only measurement tool, with only minor gaps around units and selection prerequisites.

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

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

Schema coverage is 50%: the density parameter is documented in the schema, and the description reinforces its purpose ('optional mass from density'), while handles is only self-evident as an identifier list. With half the parameters documented, the description neither compensates fully nor needs to, so a 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?

The description gives a specific verb (measure) and resource (selected entities) and enumerates exactly what is computed: extents, curve length, planar area, 3D solid volume, centroid, and optional mass. It is clear and self-contained, though it does not explicitly differentiate itself from potentially overlapping siblings such as cad_inspect or cad_solid.

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, and no prerequisites are stated. The phrase 'selected entities' implies the caller must first have a selection, but this is left to inference rather than stated, and no sibling tool is named or excluded.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false. The description adds useful context by stating coordinates are WCS and that one request is atomic, but it does not explain eraseTools behavior, permissions, or whether boolean operations alter existing solids.

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 two front-loaded sentences with no wasted words. It is appropriately concise, though for a six-parameter tool with no schema descriptions it could benefit from a bit more targeted detail.

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 has six parameters, 0% schema description coverage, no output schema, and only high-level annotations. The description omits required parameter semantics, output behavior, and guidance on eraseTools or handle-based boolean operations, leaving significant gaps 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?

Schema description coverage is 0% for six parameters, so the description must compensate. It names the boolean operation values union, subtract, and intersect and implies the create/boolean action split, but it does not explain eraseTools, toolHandles, targetHandle, or the primitive object structures.

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 clearly states that the tool creates editable AutoCAD 3DSOLID primitives or applies boolean operations, which is a specific verb and resource. It is distinguishable from generic CAD siblings by focusing on 3D solids and boolean modeling, though it does not explicitly name the alternatives it is not.

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 two usage modes—creating primitives or applying boolean operations—and notes WCS coordinates and atomic request behavior. However, it does not explain when to choose create versus boolean, prerequisites, or when to use a sibling tool instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is fully carried by structured data. The description adds the concrete scope of what is inspected (bridge, document, version, drawing state), which is useful, but no return format, cost, or freshness details given there is no 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 front-loaded sentence with a specific verb and a coherent list of inspected items. No filler, 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?

For a zero-param read-only status tool with full annotation coverage, the description is close to complete, but with no output schema it should say something about what the check returns (e.g., connection state, version string, drawing name) so the agent knows whether the result answers its question. As written the enumerated items imply returns but don't confirm them.

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?

Zero parameters, so per the rubric the baseline is 4. Nothing to describe and nothing misleading; the description appropriately spends its budget on scope rather than params.

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 ('Check') and enumerates the resources checked: bridge, active document, product version, drawing state. This is clear and specific. It doesn't explicitly differentiate from siblings like cad_instances or cad_capabilities, which could also report on the connection/product, but the enumerated scope is distinctive enough.

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 or when-not-to-use guidance. With zero parameters and a read-only status role, usage is somewhat implied (health/state check), but the agent gets no routing help against siblings like cad_capabilities for 'what can this product do' questions. Implied usage only.

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 destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the agent knows this mutates state. The description adds little beyond 'completed MCP edit operations' scope. It does not state whether undo is limited by session history, whether it affects unsaved changes, or what happens at history boundaries.

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 tight sentence with the core purpose front-loaded. No waste, but minimal given the tool's mutating nature.

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?

A mutation tool with no output schema, no annotations covering step limits or history scope, and no parameter documentation. The description is only minimally complete for calling it correctly.

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

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

Schema coverage is 0% and the description names neither 'action' (undo/redo enum) nor 'steps'. The agent must open the schema to learn the required action enum and the 1-20 step bound. The description should have at least mentioned the action/steps shape.

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: undo/redo of completed MCP edit operations in the active drawing. Clear scope, though does not differentiate from cad_edit or cad_command among 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?

Implies use for reverting or re-applying edits via 'completed MCP edit operations', giving some context, but no explicit when-to-use vs cad_edit, no exclusions, and the action parameter name is left for the schema to explain.

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?

The annotations declare readOnlyHint=false and idempotentHint=false, indicating a non-idempotent mutating operation, but the description doesn't explain what gets modified (e.g., view state vs. drawing data), whether changes are persistent, or what side effects occur. With annotations claiming a non-read-only operation, the description should clarify the behavioral implications, such as whether 'capture' creates a file or 'regen' forces recalculation. This gap is significant for a tool with 8 parameters and no 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?

The description is a single, front-loaded sentence that efficiently lists capabilities without waste. However, it's overly broad and lacks structure to guide correct invocation, such as grouping actions by type or specifying required parameters per action. It's concise but under-specified for the tool's complexity.

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 8 parameters, 0% schema coverage, no output schema, and non-idempotent annotations, the description is inadequate. It doesn't explain parameter requirements per action, return behavior, or how to handle errors or view state persistence. The agent lacks necessary context to call this tool correctly, especially for actions like 'capture' that might produce output files or 'regen' that might alter the CAD model.

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

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

Schema description coverage is 0%, so all 8 parameters are undocumented in both the schema and the description. The description lists action types but doesn't explain how to use parameters like 'path', 'delta', 'width', 'height', 'window', 'handles', or 'viewName' in conjunction with specific actions. For example, it doesn't clarify that 'setView' requires 'viewName' or that 'zoomWindow' requires 'window' coordinates. This leaves the agent guessing about parameter semantics.

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 uses specific viewport-navigation verbs (zoom, pan, orbit) and names the resource implicitly through the CAD context. This distinguishes it from siblings like cad_draw or cad_edit, which perform mutation operations rather than view changes. However, it doesn't explicitly differentiate from cad_layout, which also involves view configuration, leaving some ambiguity.

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 provides implied usage by listing actions that map to the action enum, suggesting this tool is for visual navigation. However, it lacks explicit when-to-use guidance versus alternatives like cad_layout or cad_command, and offers no exclusions or prerequisites. An agent must infer that this is for viewport manipulation rather than model mutation.

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