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

Annotations already indicate readOnlyHint=false, confirming a write operation. The description adds that it creates various annotation types but does not disclose side effects such as drawing mutations, required permissions, or transaction behavior. No contradiction with annotations.

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

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

The description is compact, well-organized as a bulleted list, and every line provides operational detail. The header immediately conveys purpose, and the operation list is scannable.

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 description effectively covers the various operations and their data shapes, but lacks information about return values, prerequisites, or side effects. Since no output schema is present, return behavior should be clarified. Overall, it is adequate for understanding operations but not fully complete.

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

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

Schema description coverage is 0%, and the description compensates by documenting the operation-specific data fields for each operation (e.g., coordinates, text, dimensions). It also enumerates all allowed operation values, which the schema lacks. However, common parameters like doc_id and lease_token are not explained.

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 begins with 'Annotation: text, dimensions, and leaders' and lists six specific create operations, making the tool's function unambiguous. It clearly differentiates from sibling tools (entity, layer, block) by focusing on annotation objects.

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 usage through the operation examples but does not explicitly state when to choose this tool over alternatives like 'entity' or 'drawing'. No exclusions or alternative tool recommendations 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?

Annotations only include readOnlyHint=false and a title, so the description must carry behavioral disclosure. It does reveal that operations include reads and writes (list, insert, update_attribute, define), but it does not explain return values, side effects such as overwriting on define, permissions, or error behavior. This is partial but not complete 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 a compact summary followed by a scannable operation list. Each operation is described in one line with its data structure, and there is no filler or redundant prose. The formatting makes the multiple operations easy to parse.

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 multi-operation tool with eight parameters and no output schema, so the description needs to cover a lot. It does provide operation inventory and data payloads, but it omits return behavior, coordinate system/units, how entity_id is used, and the full entity schema for define. These gaps make it incomplete for a complex CAD block tool.

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

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

The input schema has zero description coverage and treats data as an opaque object, but the description compensates with operation-specific shapes like insert: {name, x, y, scale?, rotation?, block_id?} and update_attribute: {entity_id, tag, value}. Generic parameters such as doc_id and lease_token remain unexplained, but the most important data parameter is well detailed.

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 'Block definition, insertion, and attribute management,' clearly identifying the resource and core actions. The subsequent operation list (list, insert, get_attributes, update_attribute, define) makes the tool's purpose concrete and distinguishes it from sibling tools like entity or layer. It lacks a single imperative verb but is not vague.

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 operation list implies when the tool is appropriate (e.g., 'list all block definitions' or 'insert_with_attributes'), but there is no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. Usage context is only implied by the operation names.

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 only readOnlyHint: false in annotations, the description carries the load and does so well. It discloses specific behaviors such as activate 'without changing window focus', save behavior ('else QSAVE'), and render_preview's style restoration. These details go beyond the annotation and help the agent predict side effects.

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 well-organized, front-loaded list. While lengthy, every line introduces a distinct operation with a brief explanation, avoiding filler or redundancy. The monospaced operation names aid quick scanning, and the overall structure is appropriate for a tool with many sub-functions.

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 and minimal schema/no output schema, the description covers each operation's purpose and most data inputs, which is substantial. It lacks details on return values and doesn't explain concepts like 'managed output workspace', but the operation list is largely sufficient for an agent to invoke the 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 provides no descriptions (0% coverage). The description compensates by specifying data structures for many operations (e.g., activate's doc_id, expected_revision; open's path; audit's filters), and implicitly defines operation values. However, include_screenshot is never mentioned, and not all operations have their data payloads fully specified, leaving gaps.

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

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

The description explicitly states 'Drawing file management' and then enumerates 17 distinct operations (create, open, save, plot_pdf, etc.), each with a specific verb and resource. This clearly distinguishes the tool from siblings like entity, layer, and product, leaving no ambiguity about its scope.

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 is provided on when to use this tool versus sibling tools, nor on how to choose among the many operations. The list of operations is self-explanatory as a menu, but there are no contextual triggers, prerequisites, or exclusions, leaving the agent to infer usage.

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 lists mutating operations (erase, move, scale) and readOnlyHint is false, but it adds no behavioral context beyond operation names. It doesn't disclose that erase is destructive, whether modifications require lease_token or expected_revision, or any side effects. The description adds minimal value beyond the annotations.

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

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

The description is long but well-structured, organized by operation categories (create, read, modify). It front-loads the summary and each line is informative. While lengthy, it avoids fluff and uses a consistent format, making it reasonably concise for the breadth of functionality.

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 with 16 parameters and many operations, but the description leaves gaps: no return value formats, no explanation of generic parameters like lease_token, strict, or expected_revision, and no error semantics. It is sufficient for operation selection but not for full understanding of behavior or outputs.

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 0% schema description coverage, the description fully compensates by mapping each operation to its relevant parameters (e.g., create_line: x1, y1, x2, y2, layer; create_circle: data with cx, cy, radius). This is essential for the agent to construct valid calls and adds significant meaning beyond the generic 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 clearly states 'Entity creation, querying, and modification' with a specific resource (entities). It lists concrete operations for create, read, and modify, fully distinguishing it from sibling tools like layer or block. The purpose is immediately evident.

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 usage through the enumerated operations but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. For example, it doesn't say 'use layer for layer operations.' It provides context but lacks explicit when-to-use 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 indicate readOnlyHint=false, and the description adds that cleanup requires confirm:true and targets managed test artifacts, while journal_status is inspect-style. It discloses the destructive confirmation requirement but lacks further side-effect or output details.

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

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

The description is compact, front-loaded with a clear summary, and uses a short bullet list for operation details. Every sentence contributes meaningful 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?

With no output schema and minimal parameter metadata, the description provides enough to invoke both operations with expected data shapes. However, journal_status return values and error behaviors remain 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 0% and operation has no enum, so the description carries full parameter meaning. It maps each operation to specific data fields like idempotency_key and job_id/confirm, adding value beyond the generic 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 states the tool inspects idempotent operations and cleans managed test artifacts, and it lists two concrete operations. This distinguishes it from sibling tools focused on drawing entities and system resources.

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 provides operation-specific data payloads, implying when to use each operation. However, it does not explicitly state when to prefer this over alternatives or mention exclusions.

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

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

Annotations only indicate readOnlyHint: false. The description lists mutating operations (create, freeze, lock) and their data inputs, but does not disclose potential side effects, prerequisites, or failure modes. It adds some transparency beyond the annotation but lacks depth.

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

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

The description is front-loaded with a one-line purpose, followed by a compact, well-organized list of operations. Every line adds value, no filler text, and the structure makes it easy to scan.

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

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

Given the multiple operations and no output schema, the description covers the main operation semantics and data shapes. However, it does not describe return values, error conditions, or the expected behavior of operations like 'list' beyond 'List all layers with properties.' Some context is missing for a full understanding.

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 0% schema description coverage, the description compensates by specifying the exact data structure for each operation (e.g., 'create — data: {name, color?, linetype?, lineweight?}'). This gives meaning to the 'operation' and 'data' parameters, though it does not explain other parameters like doc_id or lease_token.

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 'Layer creation and management' and then enumerates 7 specific operations (list, create, set_current, set_properties, freeze, thaw, lock, unlock). This clearly identifies the tool's purpose and differentiates it from sibling tools like entity or block by focusing exclusively on layers.

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 operation list implies the tool is for layer-related tasks, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The context is clear but not directly 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 only declare readOnlyHint=false, which the description's mutating operations (setup_layers, insert_symbol, etc.) align with; no contradiction. However, the description does not disclose side effects (e.g., whether setup_layers clears existing layers, how insert_symbol interacts with the symbol library, or transaction requirements). It adds little behavioral context beyond the annotation's mutation hint.

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 dense and well-organized: a one-sentence purpose followed by a compact, sorted operation list with required data fields. Each line is necessary for an agent to invoke the tool; there is no redundant prose. The front-loaded purpose is good. The length is justified given the tool's multi-operation 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?

This is a complex tool with 8 parameters, no output schema, and a multi-operation dispatch model. The description fails to explain what the tool returns (e.g., whether it returns an entity ID, success status, or screenshot), how doc_id and lease_token affect operations, or which operations require an existing document. These gaps leave an agent without critical operational context.

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 0% schema coverage, the description compensates effectively by specifying the data payload structure for each operation (e.g., data: {category, symbol, x, y, scale?, rotation?}) and enumerating valid operation values. This adds meaning the input schema entirely lacks. However, it omits semantics for generic top-level parameters like doc_id, lease_token, and idempotency_key, and the operation values are not formal enums.

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

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

The opening sentence 'P&ID drawing with CTO symbol library' clearly establishes the domain, and the detailed operation list (insert_symbol, draw_process_line, insert_valve, etc.) specifies concrete capabilities. This distinguishes it from sibling tools like generic drawing or layer by focusing on P&ID-specific symbols and workflows. However, it lacks a single, direct statement of what the tool as a whole does, relying instead on the enumerations.

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 no guidance on when to use this tool versus alternatives among sibling tools (e.g., drawing, layer, annotation). It does not state exclusions or preferred contexts. The operations imply usage but do not explicitly contrast with other tools, leaving the agent uncertain about the boundary between pid and more generic drawing tools.

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

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

Annotations only declare readOnlyHint=false, but the description adds substantial behavioral context: honest verified/unsupported capability matrix, structured capability errors without stable selection, material rendering reported only when backend-verified, and review verdicts independent from geometry/STEP validity. These disclosures go far beyond structured metadata and are not contradicted by the annotations.

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

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

The description is organized as a front-loaded summary followed by a compact bullet-style list of operations with inline annotations. Every line adds information and there is no filler or repetition. The length is appropriate for a multi-operation dispatcher.

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 complex dispatcher with 7 parameters, no output schema, and no enums, the description covers the operation inventory, several key data formats, and critical caveats (authority, verification, module_reservation). Remaining gaps include exact return shapes and semantics for operations like query_edges_by_semantic_role and review_summary, but overall it is substantially complete.

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

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

With 0% schema description coverage, the description compensates by documenting operation names and data payloads for several operations (create_feature data fields, set_motion axis/angle/limits/clearance, render_view orientations and visual_style). However, some operations lack parameter detail, and common fields like doc_id, lease_token, and idempotency_key are not explained, leaving partial compensation.

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 identifies the product domain ('Parametric consumer-product features, motion screening, views, and reviews') and enumerates specific operations, distinguishing it from sibling tools by domain. However, it is a multi-operation dispatcher rather than a single verb+resource, so it lacks the precision of a focused tool 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?

It provides explicit guidance for specific cases: USB cutouts require supplier-controlled or physically measured authority, and concept dimensions must use module_reservation instead. It does not offer a broad when-to-use/when-not-to-use statement, but the operation list and these exclusions give clear contextual usage signals.

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 only provide readOnlyHint=false, so the description adds valuable behavioral context: fillet/chamfer currently error out, and native edge edits reject volatile indices. The 'safe COM API' phrase hints at safer operations, and optional erase_profile? flags suggest deletion behavior. However, it does not disclose side effects like whether boolean subtract destroys inputs or whether extrude consumes the profile, so full behavioral clarity is still missing.

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

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

The description is front-loaded with a one-sentence summary, then uses a scannable code-style list for each operation. No filler words; the fillet/chamfer warnings are directly relevant to operation selection. It is long but dense and appropriately structured for a multi-operation tool.

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

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

For a multi-operation CAD mutation tool with no output schema, the description thoroughly documents operation inputs but says nothing about return values or how resulting solids are referenced in subsequent operations (e.g., how primary_id or profile_id values are obtained). It also omits unit conventions or the need for an active drawing context beyond the doc_id parameter. The operation list is comprehensive, but the missing flow/return semantics leave a real gap.

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

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

The input schema has 0% description coverage — data is just an arbitrary object/null. The description compensates thoroughly by providing a field-level mini-schema for every operation, e.g., create_box {center, length, width, height, layer?} and boolean {primary_id, tool_id, operation}. This is exactly the meaning the schema lacks, even though generic parameters like doc_id and lease_token are left to 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 opens with 'Create and combine native AutoCAD 3D solids through the safe COM API,' which is a specific verb-resource pairing. The enumerated operations (create_box, create_cylinder, extrude, revolve, sweep, boolean) clearly distinguish this from sibling tools like entity or product, making it unambiguous that 'solid' is exclusively for native 3D solid modeling.

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 explicitly names product.rounded_box as an alternative for analytic radius geometry and warns that fillet_edges/chamfer_edges return capability errors until stable semantic edge selection exists. It also states that general native edge edits never accept volatile edge indices, providing clear when-not guidance and an alternative tool.

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

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

The annotation declares readOnlyHint=true, but the description lists operations such as ensure_ready (starts AutoCAD, opens a document, loads dispatcher) and execute_lisp (executes arbitrary AutoLISP code) which are clearly mutating. This is a direct contradiction between the description and annotations, eroding trust in the tool's safety profile.

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 uses a compact list format where each operation gets a single informative line. Every sentence earns its place, and there is no filler or repetition. The structure enhances scannability for an AI agent.

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 with 11 operations and no output schema, so the description should disclose return values and parameter behavior more thoroughly. It gives short descriptions for each operation, which is a good start, but lacks details on what each operation returns (except runtime which mentions 'details for spawn diagnostics') and does not cover the data and include_screenshot parameters comprehensively. This is a minimum-viable but incomplete specification.

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 0% schema description coverage, the description carries the burden of explaining parameters. It does enumerate the valid operation values (adding meaning beyond the raw string type) and documents data:{code} for execute_lisp. However, it does not explain the data parameter for other operations and completely omits include_screenshot, leaving significant gaps.

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

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

The description opens with 'Server status and management' and enumerates 11 specific operations, making the tool's purpose and scope unmistakable. It clearly distinguishes itself from domain-specific siblings like product, drawing, and layer by focusing on system-level operations.

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

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

The description implies usage context for several operations (e.g., preflight for checking without starting AutoCAD, supervisor_status for reading external heartbeat), but it never explicitly contrasts this tool with sibling tools or states when to avoid using it. There is no direct when-to-use/when-not-to-use guidance, leaving the agent to infer applicability from the operation names.

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?

It discloses that 'execute' is 'atomic' and goes 'through the native worker', and calls begin/commit/rollback 'Compatibility undo transaction operations'. It does not explain side effects, failure modes, or permission needs. The readOnlyHint=false annotation already signals write behavior, so the description adds moderate 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?

The description is compact, starts with a one-sentence summary, and uses a bulleted list to efficiently document all five operations. Every line conveys needed information without redundancy or 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?

The tool has six parameters and five sub-operations, no output schema, and zero schema descriptions. The description covers each operation's purpose and key required parameters, but lacks return-value expectations, transaction_id semantics, and error-handling behavior, making it incomplete for fully autonomous agent use.

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 0% schema description coverage, the description is the only source of parameter meaning. It clarifies that data can carry {name?} for create and 'data.operations' for execute, and lists required parameters (idempotency_key, doc_id, expected_revision). However, it never explains transaction_id and gives only partial detail about the shape of data.

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

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

The description clearly states the tool handles 'identity and atomic native AutoCAD transactions' and lists five distinct operations (context, create, execute, begin/commit/rollback). This makes the tool's purpose specific and understandable, though it doesn't explicitly contrast with sibling tools like drawing or entity.

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

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

The description gives operation-level usage hints, e.g., 'create' requires idempotency_key and 'execute' requires doc_id, expected_revision, and idempotency_key. However, it does not state when to prefer this tool over alternatives, nor does it mention exclusions or general use-case scenarios.

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

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

Annotations only state readOnlyHint=false, so the description carries the transparency burden. It discloses that get_screenshot is diagnostic-only, and the set_visual_style data includes expected_revision and lease_token, hinting at concurrency controls. It does not detail side effects of set_visual_style, but overall it adds meaningful behavioral context beyond the annotations.

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

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

The description is compact and front-loaded with the core purpose, followed by a scannable bullet list of operations. Each operation line is concise and informative, with no filler or redundant content.

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

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

The tool features six distinct operations and a free-form data parameter; the description covers each operation's behavior and points to an alternative for screenshots. It omits return value and error details, but there is no output schema and the descriptions are sufficient for an agent to select and invoke the correct operation.

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 0% schema description coverage, the description compensates by mapping zoom_window to x1,y1,x2,y2 and outlining the data object for set_visual_style. It does not explain the coordinate units or all possible data fields, but it provides enough for an agent to understand the primary parameter usage.

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 statement that the tool handles viewport control and diagnostic window capture, then enumerates distinct operations (zoom_extents, fit_drawing, zoom_window, set_visual_style, show_window, get_screenshot). This clearly distinguishes it from sibling domain tools like drawing or entity.

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

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

It gives clear context for each operation and explicitly recommends drawing.render_preview over get_screenshot for normal use. However, it does not explain when to prefer view over drawing for other viewport tasks, so there is a minor gap in alternative guidance.

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