autocad-site-mcp

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

With no annotations, the description carries the burden, and it partially meets it: 'creates or configures' implies upsert semantics for layers that already exist, which is genuinely useful context. It says nothing about permissions, error behavior for duplicate/invalid names, or whether prior layer settings are overwritten.

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 that front-loads the verb and resource before the attribute examples. No filler, though it spends most of its length on values the schema already supplies.

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

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

For a single-required-parameter mutation tool with fully covered schema and no output schema, the essentials are present. Missing are preconditions (active drawing) and whether existing layers are modified, which matters given zero annotation coverage.

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 name, color, linetype, and lineweight. The description largely repeats those same enumerations without adding format constraints or defaults, 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+resource ('Creates or configures CAD layers') and enumerates the configurable attributes, so the agent immediately knows what the tool operates on. No sibling tool touches layers, so differentiation is not needed, but the description stops short of naming scope/limits.

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

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

No guidance on when to use this tool versus alternatives such as cad_execute_script or cad_run_commands, and no prerequisites (e.g., an open drawing) are stated. The agent must infer usage 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?

No annotations are provided, so the description carries the full behavioral burden. It hints at performance ('Fast') and mutation ('insertion'), but says nothing about permissions, whether insertion is atomic or partial on error, whether it modifies the current drawing, or what it returns. For a batch write tool with zero annotation coverage this is a significant gap.

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

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

The purpose is front-loaded, but the bulk of the description is a verbatim enumeration of the 26 entity types that already appears in the schema's 'type' field description. This duplication is pure waste and makes the description long without adding selection 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?

For a single-parameter batch tool with a rich nested schema but no annotations and no output schema, the definition covers input shape by deferring to the schema. It omits return information (e.g., created handles/IDs) and error/partial-failure behavior, which an agent would want before a batch write.

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 per-entity fields (dir, data, gradient, tolerance, etc.) are already documented in the schema; baseline 3 applies. The description's only added semantics is that LINE, POINT and POLYLINE3D accept a z coordinate, which is genuinely useful but marginal.

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

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

The opening clause 'Fast batch insertion of multiple CAD entities' gives a specific verb (batch insertion) and resource (CAD entities). The batch qualifier implicitly separates it from singular creation siblings like cad_create_block or cad_insert_block, though no sibling is named explicitly. Clear but not differentiated from alternatives by name.

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 cad_solids, cad_generate_parametric, cad_execute_script or cad_run_commands. The description states what it does but never addresses selection context or prerequisites (e.g., requires an open 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?

With no annotations, the description carries the full burden. It discloses that the block is 'reusable' and that attributes are optional, but says nothing about side effects on the current drawing, duplicate-name behavior, persistence, or permissions. For a definition-creating mutation this is a notable gap.

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

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

A single well-formed sentence with the core verb front-loaded and zero redundancy. It is efficient, though its brevity leaves the tool under-specified rather than over-explained.

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 4 parameters including nested objects, no annotations, and no output schema, yet the description never addresses basePoint semantics, expected entity object shape, error behavior, or what happens to the created block. Too thin for this complexity.

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

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

Schema description coverage is 100%, so name, entities, basePoint, and attributes are already documented structurally. The description only restates that attributes are optional ATTDEFs, adding essentially no syntax or format detail beyond the schema, which is the expected baseline here.

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 ('Defines a reusable Block') plus the payload it accepts (geometric entities, optional ATTDEF). It does not explicitly distinguish itself from the sibling cad_insert_block, so an agent must infer that this creates a definition rather than placing an instance.

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 guidance, no prerequisites (e.g. must a drawing be open first), and no reference to cad_insert_block as the follow-up alternative. The agent gets the purpose but nothing about context of invocation.

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

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

With no annotations, the description carries the full burden and does well: it discloses the sandbox ('separate Node process that cannot write files, start programs or read anything outside the CAD sources'), a 30 s execution limit, and that 'changes to the drawing are kept' (mutation persistence). It omits error behavior and what execution returns, which keeps it from a 5.

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

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

Front-loads the purpose, then constraints, then the available API surface, then the persistence note. Every sentence carries information; the variable list is dense but directly actionable and nothing is filler.

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

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

No output schema exists, so ideally the description would say what a successful run returns; it only states that drawing changes persist. Otherwise it is well matched to a single-parameter sandbox executor: constraints, timeout, and API surface are all covered.

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?

Only one parameter with 100% schema coverage, so the schema baseline is 3. The description goes beyond it by enumerating the injected globals (CAD, M, G, E, S, D, L, parametric, solid(recipe), console), which is genuinely useful for writing the script.

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 ('Executes JavaScript to generate ... geometry') and scopes it to 'large or procedural geometry (loops, patterns, algorithms)', which cleanly separates it from siblings like cad_generate_parametric and cad_batch_add_entities. An agent can tell what this tool is for 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?

Gives clear context for when it applies (procedural/looped/algorithmic geometry) and adds a value rationale ('without spending context tokens'). However, it never explicitly says when to prefer cad_generate_parametric or cad_run_commands over this, so no exclusions or routing are provided.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the exact DXF dialect and target-CAD compatibility, but omits whether an existing file at filePath is overwritten, what happens on write failure, and whether the operation mutates server state.

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

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

A single, front-loaded sentence with no filler; the format specificity earns its place. Nothing is wasted.

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

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

For a one-parameter export tool whose parameter is fully documented in the schema and with no output schema to explain, the description covers the essential format and compatibility facts. It only lacks routing guidance and overwrite/side-effect 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% and the single filePath parameter is documented in the schema, including the output directory default. The description adds no syntax or format detail beyond what the schema already provides, 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?

States a specific verb+resource ('Exports the current drawing') plus a precise output format ('AutoCAD 2000 (AC1015) ASCII DXF'), which implicitly separates it from cad_export_stl and cad_export_svg. It does not explicitly name those siblings, so it falls just short of the top band.

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

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

There is no guidance on when to choose DXF over the sibling exporters (STL/SVG), no prerequisites, and no mention of error or overwrite handling. The agent must infer usage entirely from the format 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?

No annotations are provided, so the description carries the full behavioral burden. It hints at a scope constraint ('closed 3D solids') but says nothing about permissions, whether an existing file is overwritten, what happens to open/non-solid geometry, or what failure modes 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?

A single, front-loaded sentence with no filler. It is appropriately sized, though it could have used its brevity budget to note an alternative export 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?

There is no output schema, so the description could have said what is returned (e.g., confirmation of the written path), and it omits overwrite/permission behavior. For a simple export tool with fully documented params, it is adequate but leaves 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 four parameters are already documented in the schema (ids, scale, binary default true, filePath). The description's mention of 'binary or ASCII' merely echoes the binary parameter, adding no syntax or format detail beyond the schema 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 (Exports) and resource (closed 3D solids) plus the output format (binary/ASCII STL). The STL format implicitly distinguishes it from cad_export_dxf and cad_export_svg, but it never names or contrasts those siblings 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 phrase 'for 3D printing' implies a use context, but there is no explicit when-to-use/when-not guidance and no reference to the alternative export tools (dxf, svg) that an agent must choose between.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the render target (drawing or paper space layout) but says nothing about whether the drawing must be open, whether an existing file is overwritten, or what the return result is. It also leaves ambiguous whether 'drawing or paper space layout' means the caller chooses or the tool exports both.

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 waste, front-loading the verb and the output artifact so the agent can triage immediately.

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?

There is no output schema, no annotations, and only two well-documented parameters, so the essentials are covered. What remains unclear is the layout-selection semantics and any precondition like an open drawing, which matters 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 100%, and the filePath description is notably detailed (names CAD_MCP_OUTPUT_DIR and its default). The description adds no parameter meaning beyond that, so the baseline 3 for schema-driven parameters 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 (renders) and resource (drawing or paper space layout) and the output artifact (SVG vector file). This clearly separates it from cad_export_dxf and cad_export_stl by format, though it never names those siblings 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 phrase 'for instant preview and inspection' implies the use case and indirectly contrasts with CAD-interchange and 3D-print exports. However, there is no explicit statement of when to prefer this over cad_export_dxf, and no exclusions or 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions generation but does not state whether it creates a new drawing, modifies the active one, requires existing geometry, what side effects occur, or what the return format is.

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 resource come first and the enum list follows. It is appropriately sized, though it could be slightly more informative without becoming bloated.

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

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

There are no annotations and no output schema, and the tool involves a nested 'params' object with open-ended structure-specific parameters. The description does not explain return values, side effects, or how params should be shaped for each type, 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 100%, so the baseline is 3. The description repeats the type enum values but adds no syntax, constraints, or meaning for the nested 'params' object 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 the specific verb 'Generates' and the resource 'complex parametric structures', then enumerates the five supported structure types. An agent can distinguish it from sibling CAD tools such as cad_create_block or cad_export_dxf.

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, prerequisites, or alternative tools are given. The list of structure types implies scope but does not route the agent among the many sibling CAD 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?

No annotations are provided, so the description carries the full behavioral burden. 'Returns' implies a non-mutating read, and the enumerated return contents give real transparency about output, but the description says nothing about permissions, cost, behavior when no drawing is open, or whether the data is cached/live.

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 starts with the verb and the target resource, then lists the returned fields compactly. Every clause is substantive and there is no filler or repetition.

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 and no annotations, the description compensates by enumerating the returned statistics, which is exactly what an agent needs to know before calling. The remaining gap is minor: no note on failure modes (e.g. no active drawing) or on whether the reported statistics are scoped to model space vs. layouts.

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, which is the baseline-4 case; there is no signature to explain and nothing the description could add. The schema is empty, so no parameter-level detail is 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 gives a specific verb ('Returns') and resource ('statistics of the current drawing') and then enumerates the exact content: entity count, breakdown by type, layers, bounding box extents, blocks, and layouts. This clearly separates it from the sibling tools, none of which are read-only inspectors, though it does not name any sibling 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: an agent can infer this is the introspection tool to call when it needs an inventory of the open drawing. There is no explicit 'use this when...' clause, no statement of preconditions (e.g. a drawing must already be open), and no mention of alternatives, so the guidance 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?

With no annotations, the description carries the full behavioral burden. It implies a drawing mutation but does not state whether the block definition must pre-exist, what happens on an unknown block name, whether the insert is undoable, or what the tool returns, leaving key failure modes undisclosed.

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 names the operation (INSERT) and the transform fields with zero filler. Every clause 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?

Reasonable for a nested-object mutation tool with no output schema, but without annotations or an output schema the description should have covered the prerequisite that the block already exist and the behavior on invalid input. Those gaps keep it at minimum-viable 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 coverage is 100%, so all five parameters are documented in the schema, which sets the baseline at 3. The description restates scale, rotation, and attribute values but adds no new semantics such as coordinate conventions or attribute-tag matching rules.

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 ('Places an instance (INSERT) of a block into the drawing'), and the 'instance of a block' framing implicitly separates it from cad_create_block, which defines a block rather than instantiating one. It stops short of naming that sibling explicitly, so the differentiation requires a small 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 statement of when to use this versus alternatives and no prerequisite guidance, such as whether the named block must already exist (e.g., via cad_create_block or cad_open_dxf). The agent must infer usage conditions from the verb 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?

With no annotations, the description carries full burden. It implicitly conveys a read-only listing and discloses return contents (name, aliases, description), which is useful, but says nothing about whether an active drawing is required, pagination, or result size.

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, front-loaded with the core action and output, followed by the optional-filter semantics. No filler sentences and nothing repetitive.

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 read tool with no output schema and no annotations, the description covers what is returned and how the filter behaves, which is most of what an agent needs. The missing piece is workflow context — e.g. using this to discover commands before calling cad_run_commands.

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

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

Schema coverage is 0%, so the description must carry the lone parameter — and it does well: it explains that the filter matches the name, an alias, OR words in the description, backed by concrete examples. It omits edge details such as case sensitivity or partial-match behavior, so not a full 5.

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

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

States a specific verb and resource ('Lists every implemented AutoCAD command') plus what the listing contains (aliases and description). The verb 'list' implicitly separates it from write/execute siblings like cad_run_commands and cad_execute_script, but 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 only implied: the filter examples ('layer', 'dim') suggest a discovery/lookup purpose, but the description never states when to call this versus cad_run_commands or cad_execute_script, and no prerequisite (e.g. a drawing must be open) is mentioned.

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

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

With no annotations, the description carries the full burden and does disclose the critical destructive trait: existing entities are cleared and layers reset. It stops short of saying whether this touches an on-disk file or only in-memory state, and whether the drawing is persisted or merely session-scoped.

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 destructive effects front-loaded after the core action. No filler, nothing that fails to 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?

For a simple one-parameter initializer with no annotations and no output schema, the description adequately conveys the action and its destructive scope. The remaining gap is whether the drawing is tied to the filename on disk or just an in-memory session, but that is a minor omission.

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 the single 'name' parameter is fully documented there, so baseline is 3. The description adds nothing about whether the name is optional (0 required params) or what happens when it is omitted.

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 ('Initializes') and resource ('a fresh CAD drawing space') along with the immediate effects (clearing entities, resetting layers). It implies distinction from cad_open_dxf, but never names or explicitly contrasts with that sibling, leaving the boundary 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?

The word 'fresh' implies this is for starting a new drawing rather than opening an existing one, and the destructive side effect suggests caution, but there is no explicit when/when-not statement or reference to cad_open_dxf as the alternative for loading existing files.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the current drawing is replaced ('in place of the current drawing'), what the call returns (counts, conversion details), and a data-loss risk (objects that cannot be read would be missing from a saved file). It omits permission/error behavior and whether the current drawing is discarded without prompt, keeping it at a 4 rather than 5.

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

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

A single dense sentence, but every clause earns its place: the scope, the follow-up workflow, the return contents, and the warning about unreadable objects. Front-loaded with the core action; slightly run-on, which keeps it just under a 5.

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

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

No output schema exists, yet the description summarizes the return payload (counts, conversions, warning list), which is exactly what an agent needs to interpret the result. It covers the end-to-end workflow; only error/failure handling for a missing or malformed file is left unspecified.

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

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

Schema coverage is 100% and the filePath description already documents path resolution and the server folder convention, so the baseline would be 3. The description adds a genuine constraint the schema lacks — the file must be ASCII DXF in the R12–2018+ range — which tells the agent what inputs are actually valid.

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 ('Opens an existing ASCII DXF file') and immediately disambiguates the operation with 'in place of the current drawing', which separates it from cad_new_drawing and the export siblings. An agent can tell exactly what this does without opening the schema.

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

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

Names the downstream tools and the intended workflow ('edited with cad_run_commands and saved with cad_export_dxf'), which gives clear context for when to reach for it. It stops short of explicit exclusions (e.g. when to prefer cad_open_shared or cad_new_drawing instead), so it is strong context rather than full when/when-not 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?

No annotations are provided, so the description must carry the full behavioral burden. It discloses the source and that the drawing loads into the current session, but omits auth/permission requirements, whether it replaces or adds to the session, and error behavior—significant gaps for a session-mutating operation.

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

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

A single front-loaded sentence with zero filler; it packs verb, resource, source, destination, and identifier into one efficient clause.

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

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

Purpose and parameter usage are clear from the description plus schema, and no output schema exists to explain. However, with no annotations and no usage guidance, the definition stops short of the context needed to know when this beats cad_open_dxf and what side effects to expect.

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 baseline is 3. The description restates 'share ID or URL' (matching the id parameter) but adds no syntax or meaning beyond the schema for apiUrl or editToken.

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 ('Opens'), resource ('shared drawing'), source ('Cloudflare D1 storage'), and destination ('current CAD session'). It implicitly distinguishes itself from cad_open_dxf, but no sibling tool is named, 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 when-to-use guidance, no alternatives named (e.g., cad_open_dxf for local DXF files), and no prerequisites stated. The only clue is that it requires a share ID or URL.

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

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

With no annotations, the description carries the full burden and does disclose that this is a destructive operation (revoke + delete) against persistent storage (Cloudflare D1) and that it is gated by ownerToken. However it stops short of stating irreversibility, whether the share record is removed from the sharing index, or what happens with an invalid/expired token.

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 action first, the target second, and the credential last. No filler, no restatement 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 destructive, unannotated, output-schema-less tool this is on the thin side: an agent learns what it does and what credential it needs, but not the reversibility profile, failure modes, or confirmation semantics that matter for an irreversible delete.

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 both required parameters and the optional apiUrl are already documented in the schema. The description adds only the fact that ownerToken is the authorizing credential for the delete, which is marginal value beyond the schema's own 'Owner token received when creating the share'.

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 pair (revokes and deletes) against a specific resource (a shared drawing), plus the mechanism and required credential. This clearly separates it from sibling share-management tools such as cad_share_drawing, cad_update_shared, and cad_open_shared.

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

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

The description gives no when-to-use framing, no mention of when not to use it, and no pointer to alternatives like cad_update_shared for non-destructive changes. The only contextual cue is the ownerToken requirement embedded in a sentence about purpose, which is incidental 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?

With no annotations provided, the description carries the full behavioral burden and does well: it explains statement separation, Enter handling, follow-up answer placement, selection methods (ALL or P), and that it returns 'the command log and any problems.' It does not explicitly state permission requirements, undo behavior, or whether changes are destructive, but for a command runner the execution semantics are unusually well disclosed.

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

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

The definition is dense but front-loaded: purpose first, then syntax rules, examples, and specialized 3D context. Every section is relevant, though the long example strings and command lists could feel heavy. For a complex command-scripting tool, the length is justified and structured.

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 complex, has no output schema, and has no annotations, so the description must do the heavy lifting. It covers syntax, behavior, return values, object selection, 3D points and commands, and points to cad_list_commands for command discovery. Nothing essential for correct invocation appears missing.

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

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

Schema description coverage is 100%, so the baseline would be 3, but the description adds significant meaning for the commands parameter: separators, tokenization, Enter semantics, examples, 3D point syntax, and relevant command families. The select parameter is mostly documented in the schema, and the description only briefly ties it to pre-selection and P. The extra syntax detail for commands makes this above 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?

The description opens with a specific verb and resource: 'Runs AutoCAD command-line input in the current drawing, exactly as typed in the app.' It clearly distinguishes this from generic script execution by tying it to AutoCAD command-line syntax and the current drawing context. An agent can immediately tell this tool executes typed CAD commands.

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

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

The description gives substantial usage context through syntax rules and examples, but it does not explicitly state when to prefer this tool over siblings like cad_execute_script or cad_batch_add_entities. The only alternative named is 'Use cad_list_commands to see every command,' which is about discovery rather than execution choice. Usage is implied rather than contrasted.

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

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

With no annotations, the description carries the full load and partially meets it: it discloses the persistence layer (Cloudflare D1), the host (autocad.site) and that both view and edit URLs are returned. It omits the security-relevant behavior an agent needs — that the edit URL grants write access, whether the share is public/unauthenticated, and that cad_revoke_shared is the undo 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?

Two tight sentences with the core action front-loaded and the return artifact second. The trailing 'with users or other agents' is mild padding but does not obscure the message.

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?

No output schema, and the description does cover the return shape, which is good. However, for a mutation tool with zero annotations it says nothing about prerequisites, access scope of the generated links, or expiry/revocation interaction, leaving notable gaps an agent must guess at.

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 name, apiUrl and expiresDays are already fully documented in the schema. The description references none of them and adds no format or interaction detail (e.g. what happens if name collides), 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 and resource ('shares the current drawing') plus the storage backend and the artifact produced (view and edit URLs). This distinguishes it from cad_open_shared, cad_update_shared and cad_revoke_shared, though those distinctions are left implicit rather than 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 guidance, no prerequisites (e.g. must a drawing be open/saved first), and no mention of when to prefer cad_update_shared or cad_revoke_shared. The phrase 'current drawing' faintly implies context but gives the agent nothing actionable about 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?

With no annotations, the description carries the full burden. 'Inspects' implies a read-only operation and it usefully discloses what each mode returns (e.g., volume, bounds, centroid, closed/curve error). However it says nothing about permissions, contract of 'curve error', or any error/edge behavior beyond the field names.

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 opens with the verb and resource, then packs the three modes and their outputs efficiently. Dense but every clause 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?

There is no output schema, and the description partly compensates by listing per-mode return fields, but it omits pagination behavior (left to the schema's from/limit) and any sibling routing. Adequate but with clear 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 parameters are already documented in the schema. The description loosely maps action values to their outputs but adds no syntax or format 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 (Inspects) and resource (3D solids), and enumerates the three modes (list, measure, check) with their returned fields. This clearly distinguishes it from the export/create/stats siblings, though it never explicitly names an alternative.

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 three action values imply when each mode applies (enumerate vs. quantify vs. validate), but there is no explicit when-to-use/when-not guidance or named alternative among the many cad_* siblings. Usage must be inferred.

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

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

With no annotations, the description carries the full disclosure burden, and it does surface two real behavioral facts: an editToken credential is required and the target share must already exist. It says nothing about whether the uploaded drawing replaces existing share contents, whether the operation is reversible, or what happens on token failure — significant gaps for a write/upload 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?

A single tight sentence with no filler, and the target resource and required credential are front-loaded. Minor redundancy in 'uploads and updates' costs it the top mark.

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?

There is no output schema and no annotations, so the description is the only behavioral source, and it covers the core action plus authentication. It omits the outcome of the call (success signal, response shape) and the overwrite semantics that an agent would need before invoking a share-mutating 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 schema already documents id, apiUrl, and editToken, establishing a baseline of 3. The description references the editToken and implies the id via 'existing shared drawing' but adds no format, default, or constraint detail beyond 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 pair (uploads/updates) and a specific resource (the current CAD session drawing written into an existing shared drawing), which is enough to separate it from cad_share_drawing and cad_open_shared. It never names a sibling explicitly, so differentiation is inferential 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?

The phrase 'using its editToken' and the word 'existing' imply the precondition that a share must already exist and the caller must hold an edit token, which is useful implied usage guidance. There is no explicit when-to-use versus cad_share_drawing, cad_open_shared, or cad_revoke_shared, and no stated failure conditions.

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