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

Annotations already set destructiveHint=true, so the description is not required to restate that. It adds value by disclosing limits on destructive actions: deletion is restricted to agent-owned entities and source-backed text updates require provenance. This gives operational constraints beyond the annotation, though it doesn't detail error/rollback behavior.

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

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

The description is two sentences with zero filler. It front-loads the core purpose and then delivers key constraints, making it both concise and well-ordered. Every word earns its place.

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

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

With six distinct actions and an unstructured params object, the description is far too brief. It only hints at two use-case constraints but says nothing about how to invoke each action, what params to pass, or what the result looks like. The high complexity demands significantly more explanation than given.

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 mentions no parameter details whatsoever. The params object is unstructured (additionalProperties: true) with six possible actions, yet the description provides no guidance on what each action expects or how to construct params, leaving the agent entirely without 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 clearly states a specific verb 'apply edit' and a specific resource 'active managed AutoCAD work copy'. It further distinguishes itself from sibling tools (query, export, session, project) by being the modification tool, and it adds constraints about deletion and source-backed text updates, making its scope unambiguous.

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

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

Usage is implied by the tool name and the context of sibling tools—this is obviously the edit tool for the warehouse CAD work copy. However, the description does not explicitly state when to use it versus alternatives, nor does it mention when not to use it, leaving some routing to inference.

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

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

No annotations are provided, so the description carries the full responsibility for behavioral disclosure. It mentions path restrictions and prerequisites for native solids, but does not disclose whether the operation modifies data, creates files, has side effects, or requires specific permissions. For an export tool, it is likely to create files, but this is not stated. The description adds some transparency about constraints but lacks detail on side effects and safety.

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 short sentences with no filler. It efficiently states the core function and key constraints, front-loading the action and important prerequisites. Every word adds value, making it appropriately concise and well-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?

Given the tool has a nested params object, an action enum with five values, and no output schema, the description is insufficient. It does not explain the purpose of each action, what parameters to pass for each, or what the return format will be. While it notes path restrictions and prerequisites, it omits crucial operational details needed for correct invocation, especially for the 'params' object which is entirely opaque.

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 33% (only project_file has a description). The tool description does not explain the 'action' enum values or the structure of the 'params' nested object. It vaguely references requirements for native solids (footprint, height, elevation) but does not map these to specific parameters. With low schema coverage, the description fails to compensate, leaving agents uncertain about how to fill the params object and what each action entails.

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 the tool's function: exporting the managed work copy or building a native 3DSOLID DWG. It specifies two primary modes and distinguishes this from sibling tools (warehouse_project, warehouse_cad_session, etc.) as an export operation. However, it does not enumerate all action enum values (data, dxf, pdf, snapshot), leaving some ambiguity about the full scope of export types.

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 some context for when to use the tool, indicating that native solids require source-verified footprint, height, and elevation, and that all paths are restricted to the authorized root. However, it does not explicitly contrast with alternative tools or provide explicit when-to-use versus when-not-to-use guidance. The conditions given are more about prerequisites than about choosing this tool over siblings.

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

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

The description adds a meaningful caveat beyond the readOnlyHint annotation: 'Geometry measurements remain calculations, not verified business facts.' This warns the agent that measurement results are not authoritative, which is valuable. However, it does not elaborate on behaviors for each action (e.g., whether 'highlight' changes the UI selection state) or other side effects beyond the read-only annotation.

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 sentences with no waste. The first sentence front-loads the core operations and target, and the second delivers an important caveat. Both sentences earn their place and the structure is clear.

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 five distinct actions and an open-ended params object, the description is too sparse. It does not define what each action does, what parameters they expect, or what the return looks like (no output schema). It also does not clarify prerequisites like an active session or what 'managed work copy' means. The description is incomplete for an agent to call this tool correctly without further inference.

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

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

Schema description coverage is 0%, and the description does not compensate. It lists verbs that roughly correspond to the action enum (e.g., 'inspect' vs 'get', 'highlight' vs 'select') but does not explain each action's purpose or the expected structure of the params object. The generic params is left entirely unexplained, and the wording mismatch between the description and enum values adds confusion.

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 the tool's purpose: to list, inspect, highlight, measure, or compare entities in the active managed AutoCAD work copy. The verb set is specific and distinguishes it from sibling tools like warehouse_cad_edit (modification) and warehouse_cad_export (export). The read-only nature is implied by the verbs and consistent with the annotation.

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 guidance on when to use this tool versus the sibling tools. The description only mentions the active managed AutoCAD work copy, but does not explain when to choose query over edit/export/session/project. The name 'query' suggests a read-only role, but the description lacks any 'use this when...' or 'use X instead' 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, the description carries the full behavioral burden. It does disclose key safety behaviors: it never opens the customer source as a write target, rejects TrueView, and shutdown can only quit a document-free instance launched by this Agent. These are valuable but do not cover the full range of actions or their side effects, so partial transparency.

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 three sentences with no fluff. The core purpose is front-loaded, followed by key constraints. It is efficient and avoids redundancy.

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

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

For a tool with 7 actions, a nested params object, and no output schema, the description is insufficient. It does not explain what any of the actions do, what parameters they need, or what the return looks like. The agent is left guessing on crucial execution details, so completeness is low.

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

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

Schema coverage is only 33% — only project_file is described in the schema. The description adds no information about the 'action' enum values or the 'params' object (which is untyped with additionalProperties true). The agent has no idea what each action requires or how to structure params, and the description fails to compensate for this 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?

The description states the tool connects to writable full AutoCAD and manages 'exactly one automatically-created work copy', giving a specific verb and resource. It also clarifies it rejects TrueView and never writes to the customer source, which helps distinguish it from other CAD tools. However, it does not explicitly name sibling tools to differentiate, so it stops 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?

The description provides constraints (never write to source, TrueView rejected, shutdown limits) but gives no guidance on when to choose this tool over the sibling tools like warehouse_cad_edit or warehouse_cad_query. There is no explicit 'use this when...' or 'use that instead...' guidance, leaving the agent to infer the tool's scope.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that long jobs are single-worker and that audit output is not an independent acceptance denominator, which are useful caveats. However, it omits other behavioral aspects like side effects, permission requirements, or reversibility, leaving transparency incomplete.

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 concise (two sentences) and front-loads the key actions. It avoids unnecessary words, but the brevity somewhat undermines clarity. The structure is acceptable for a short description, though it could benefit from a brief explanation of the actions.

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

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

Given the tool's complexity (10-action enum, nested params object, no output schema), the description is far from complete. It does not describe each action's purpose, the format of params, or expected outcomes. The note about job_id and audit output provides some context, but an agent would still need significant external knowledge to invoke this tool correctly.

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

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

The input schema covers only 25% of parameters (only project_file has a description). The description does not explain the 'action' enum values, the purpose of job_id, or the 'params' object. It mentions job_id in passing but provides no guidance on how to construct or interpret it. This is insufficient for an agent to correctly fill parameters, especially given the low schema coverage.

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

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

The description lists specific verbs (validate, audit, rebuild, verify, package, control) acting on 'one declared warehouse CAD project', giving a clear resource and a set of operations. It distinguishes this tool from siblings that handle sessions, queries, edits, and exports by focusing on project-level actions, though the broad action list makes the primary purpose less crisp than a single-verb description.

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 does not indicate when to use this tool versus the sibling tools (warehouse_cad_session, warehouse_cad_query, etc.) or when not to use it. The only usage hint is that long jobs are single-worker and return job_id, but there is no explicit guidance on scenario selection or alternative routing.

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