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

The description ('Get') aligns with the readOnlyHint annotation, but it does not disclose additional behavioral traits such as the format of the bounding box (e.g., coordinate order or units). The annotation already covers the safety profile, so the description adds minimal extra context beyond confirming the read 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, complete sentence that conveys the tool's purpose without unnecessary words. It is front-loaded and efficient.

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

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

The description is sufficient for a simple query tool with no parameters and an expected output schema. It explains what the tool does, though it could mention the output format or coordinate system context. However, completeness is high given the tool's simplicity.

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

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

There are no parameters, and the schema coverage is 100%. The description does not need to add parameter semantics. The baseline of 4 is appropriate for a parameterless tool.

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 action ('Get') and the resource ('bounding box of all entities in the drawing'). It is specific and distinguishes this tool from siblings like layout_list or analysis_measure_distance, which serve different purposes.

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 that this tool is for retrieving the overall extents of a drawing, but it does not explicitly state when to use it versus alternatives like analysis_measure_area or analysis_entity_stats. No exclusions or prerequisites are mentioned, leaving usage decisions to the agent.

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

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

Annotations already declare readOnlyHint=true. Description adds that counts are sorted and output structure. No contradictions, but lacks disclosure of boundary conditions (e.g., behavior with empty drawings or performance).

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?

Three sentences, front-loaded with main action and output structure. The marketing sentence is slightly extraneous but not harmful. Efficient overall.

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 parameters and an output schema, the description explains output format. However, it assumes knowledge of entity types and layer names; no mention of scope (all entities? visible only?). Still, fairly complete for a simple analysis 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?

No parameters, schema coverage 100% trivially. Description adds no parameter info, but baseline 3 is appropriate as schema already covers parameters.

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?

Clearly states it analyzes the drawing and returns entity counts grouped by type and layer, specifying the return structure. Sibling tools like analysis_layer_stats and analysis_select_by_type are differentiated by combining both groupings.

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 over alternatives. Despite marketing claim, it doesn't explain context or prerequisites. Missing explicit when-to-use or when-not-to-use information.

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?

Beyond the readOnlyHint annotation, the description discloses the important uncapped behavior: 'a window over a busy drawing returns every hit.' It also suggests performance-oriented usage with fields/compact. This adds behavioral context without contradicting 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 only two sentences: a clear one-sentence definition followed by an actionable warning. It is front-loaded with the core purpose and contains 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?

Given the rich input schema, readOnlyHint annotation, and existence of an output schema, the description covers the critical non-obvious behavior (uncapped results) and mitigation. No major contextual gap remains for an agent to invoke the tool safely.

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 already provides 100% description coverage for all six parameters, including details for x1/x2/y1/y2, fields projection, and compact envelope. The description's mention of fields/compact reinforces their use but adds no new parameter meaning beyond what schema states.

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 'Find all entities within a rectangular region', giving a specific verb and resource scope. The parenthetical '(crossing selection)' clarifies the selection semantics and distinguishes this analysis query from sibling selection tools like selection_window.

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 operational advice ('Project with fields and/or compact before widening the window') and warns about the uncapped result set, which implies when to use lightweight projections. However, it does not explicitly compare against sibling tools such as selection_window or entity_list, leaving the choice to the agent based on naming.

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

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

Annotations already provide readOnlyHint=true, and the description adds no further behavioral context (e.g., performance, auth, or side effects). It only restates the read-only nature implicitly.

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

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

The description is a single, front-loaded sentence with no extraneous words. Every word adds 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?

Given the tool has an output schema, the description adequately covers what is returned (entity count, types present). It could mention scope (all layers or only those with entities), but is otherwise complete for its simplicity.

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?

No parameters exist, so schema coverage is 100%. The description adds value by specifying that the output includes 'entity count, types present', which is not in the schema.

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

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

The description uses a specific verb 'Return' and resource 'statistics for each layer', and provides concrete examples 'entity count, types present'. It clearly distinguishes from siblings like analysis_entity_stats (per entity) and layer_list (list only).

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 for retrieving per-layer statistics, but does not explicitly state when to use this tool over similar siblings (e.g., analysis_entity_stats, layer_list) nor when not to use it.

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

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

Beyond the readOnlyHint annotation, the description discloses that coordinates are in WCS and that extrusion is reported, which is useful behavioral context. It does not contradict annotations and adds value by explaining a subtle coordinate frame detail.

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 exceptionally concise: two sentences that front-load the core purpose and then provide essential clarifications. Every sentence adds information and no words are 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 read-only single-parameter tool with an output schema, the description is complete. It explains the tool's raison d'être, differentiates from entity_get, and clarifies coordinate behavior. There is no missing critical 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?

The input schema already covers the only parameter 'handle' with a description. The tool description adds no further parameter detail beyond 'one handle', so schema coverage (100%) carries the load. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: returning the full DXF attribute set for a single handle, analogous to AutoCAD's LIST command. It distinguishes itself from sibling 'entity_get' by noting that 'entity_get deliberately does not carry' dxf_attributes, making the purpose 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?

The description implies usage context by contrasting with entity_get: use this tool when you need the raw DXF attribute set that entity_get omits. It also provides coordinate system context (WCS). However, it does not explicitly list exclusions or when to prefer alternatives, so it falls short of a full 5.

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?

Adds substantial context beyond annotations: it describes the non-drawing nature, the bulge parameter effect, exactness for straight edges, and a specific under-reporting example (28% on a semicircular edge). It also mentions `assumes` to convey what is taken on faith. No contradiction with readOnly/idempotent hints.

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 well-structured with three concise paragraphs: clear function statement, comparison to alternative, and accuracy caveats. Every sentence adds value, with no fluff 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?

Covers purpose, usage, limitations, parameter semantics, and alternative tool. The tool is simple (one parameter) and the description is sufficiently complete for an agent to select and invoke it correctly, especially with output schema and annotations present.

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

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

The description enriches the schema's `points` parameter by explaining the bulge (DXF convention), arc edge behavior, and warns about omitting bulge on curved geometry. This goes well beyond the basic schema definition.

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+resource: 'Area and perimeter of a polygon you supply the vertices for.' It clearly distinguishes from `analysis_measure_entity` by stating this tool measures the numbers in the call, not the drawing.

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

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

Explicitly states when to use this tool vs. the alternative: 'To measure something that exists, use analysis_measure_entity(handle)...' and clarifies that this tool is for supplied vertices, not existing geometry.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds no additional behavioral context beyond stating the action, but it does not contradict annotations. Thus, score 3 for not enhancing what annotations provide.

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?

Extremely concise: a single sentence that fully captures the tool's purpose with no unnecessary words. Perfectly front-loaded.

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 simplicity, full parameter documentation, and an output schema (implied), the description is largely complete. However, it could optionally mention that the result is a scalar value, but this is a minor gap.

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

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

Schema coverage is 100%, with each parameter clearly described in the schema. The description adds no further meaning beyond the schema, so baseline score 3 is appropriate.

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

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

The description clearly states the tool measures Euclidean distance between two points, using a specific verb and resource. It is unambiguous and distinguishes itself from sibling tools like analysis_measure_area.

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 vs alternatives (e.g., analysis_measure_area or other measurement tools). Lacks context or exclusions, providing zero decision support.

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

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

Annotations already mark readOnlyHint and idempotentHint, but the description adds substantial context: it reads real geometry including bulges, and it discloses accuracy flags (exact, assumed_closed, self_intersecting) with concrete implications (bowtie measures 0.0). It also clarifies platform dependencies for ACIS-backed entities. 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 long but tightly organized and front-loaded with the core action. Every paragraph adds necessary detail: supported types, error semantics, accuracy flags, and parameter implications. The use of paragraphs and explicit terms (exact, assumed_closed, self_intersecting) keeps it scannable without waste.

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 (multiple entity types, platform-specific behavior, accuracy nuances), the description is exhaustive. It covers what is measurable, what is not, how errors are surfaced, what accuracy flags mean, and how flatten_tolerance affects results. The output schema presumably details return fields, so no need to explain them in text.

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 schema has 100% parameter coverage, but the description enriches this by explaining flatten_tolerance's role in accuracy (how finely a shape is flattened and when it applies). It also ties handle to 'from create/list/select' in the schema, and the description clarifies that the measurement itself depends on the handle's entity. This goes beyond a bare 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 'Measure something already in the drawing, by handle,' which is a specific verb + resource + method. It then enumerates measurable entity types and contrasts with unsupported ones, making the tool's purpose and scope unmistakable. It also differentiates from siblings like analysis_measure_area by emphasizing handle-based measurement and including details about geometry accuracy.

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 explicit when-to-use (you have a handle and want to measure a supported entity) and when-not-to-use guidance: REGION and 3DSOLID refuse with a capability gap flag, and LINE/TEXT/INSERT yield a plain error. It also references a manual alternative (shoelacing vertices) and explains why this tool is superior, giving clear decision support.

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?

Beyond the readOnlyHint annotation, the description discloses important behavioral traits: the MAX_LIST_LIMIT cap, the fact that the plain list cannot indicate truncation, the log-stream warning invisible to most clients, and the compact mode's 'total' and 'truncated' fields. This is rich, non-obvious context that significantly aids correct use.

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 and well-structured: one sentence stating the core function, then a focused paragraph about the cap and the compact workaround. Every sentence earns its place, with no fluff 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?

The tool is a read-only selection operation with an output schema, so the description need not explain return values. It covers the essential caveat (truncation) and gives explicit guidance for the common pitfall. Combined with the schema and annotations, the description makes the tool's behavior fully understandable.

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 adds value beyond the schema by explaining the cap implications and why compact should be used when the count matters, supplementing the schema's already detailed compact parameter description. It does not add much for layer_name or fields, but the extra compact context justifies a slightly higher score.

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 'Get all entities on a specific layer,' a specific verb+resource that exactly matches the tool name. It also states the return type (entity list with handles) and differentiates from siblings like layer_list and analysis_select_by_type.

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?

Provides clear context for when to use the tool (to get layer entities) and gives a conditional usage guideline: 'use compact=True when the count matters.' However, it does not explicitly discuss alternatives or exclusions relative to sibling tools, so it falls short of a 5.

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?

Beyond the readOnlyHint annotation, the description discloses important behaviors: the result is capped at MAX_LIST_LIMIT (default 5000) and that only compact=True reports total and truncated. This lets the agent anticipate truncation and the difference in output shape, which is valuable contextual information.

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 the core purpose, and every sentence carries useful information. The second sentence adds limit and compact behavior without redundancy, fitting within two concise paragraphs.

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, together with the rich schema and readOnly annotation, fully covers what an agent needs: what the tool does, what the output shape is (list with handles), limitations (cap), and the way to get truncation info. The presence of an output schema means return-value details are not required in the description.

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 already provides 100% description coverage for all parameters, so the description does not need to add param-level details. It does add a note about compact behavior, but this does not extend the meaning of the schema parameters. This aligns with the baseline 3 for high 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 clearly states 'Get all entities of a specific type' with a specific verb and resource, and mentions the output includes handles. This distinguishes it from siblings like analysis_select_by_layer by the selection criterion (type vs layer), making its purpose 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?

The description conveys when to use the tool (when you need entities of a specific type) but does not explicitly contrast it with alternatives such as selection_filter or entity_list. The reference to analysis_select_by_layer is for behavioral similarity, not for guiding tool choice. Thus the usage context is clear but exclusionary guidance is missing.

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 say readOnlyHint=false, so the description carries the burden of behavioral disclosure. It explains that originals stay in model space, unresolved handles appear in `skipped`, and the call fails if none resolve — all valuable context beyond the 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 appropriately sized: three focused paragraphs. The first sentence states purpose, the second adds key behavioral contrast, and the third handles error semantics. Every sentence contributes without fluff.

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 (creating a block definition, 4 params, output schema present), the description covers all essential operational context: non-destructive behavior, alternative to AutoCAD BLOCK, skipped handles, and failure condition. No missing critical information.

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%, with each parameter (name, handles, base_x, base_y) already described meaningfully. The description adds no extra parameter-specific detail, 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?

The description opens with a specific verb+resource: 'Create a new block definition from existing entities in the drawing.' It clearly distinguishes itself from siblings like block_insert (placing copies) and the AutoCAD BLOCK command (which consumes originals).

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

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

Explicitly provides usage context: 'use `block_insert` to place copies, and delete the originals yourself if you want the command's behaviour.' This tells agents when to use this tool versus an alternative. Also notes 'Works on both engines,' giving compatibility guidance.

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

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

Annotations already indicate destructiveHint=true. Description adds minimal context beyond stating the operation; does not discuss irreversibility or needed permissions.

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?

Single sentence of 10 words, front-loaded with the core action. No wasted words.

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 simplicity, single parameter, and presence of output schema, the description is complete and sufficient.

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 provides 100% coverage with a clear description of the handle parameter. Description does not add additional semantic value 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?

Description clearly states the verb 'explode' and the resource 'block reference', distinguishing it from sibling tools like block_insert or block_find_references.

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

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

No explicit when-to-use or alternatives provided. Usage is implied but could benefit from guidance such as using transactions for undoability.

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

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

Annotations declare readOnlyHint=true, so the safe-read nature is already known. The description adds meaningful behavioral detail about the scan limit and the meaning of the compact envelope's total, going beyond the annotation and helping the agent interpret results correctly.

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: the first states the purpose, the second a key caveat. No fluff, front-loaded, and every sentence 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 output schema present and annotations covering read-only behavior, the description covers the main behavior and limitation. It's complete enough for an agent to invoke correctly, though a tiny bit more detail on default behavior (e.g., what happens with no matches) would make it fully comprehensive.

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%, with each parameter thoroughly described (e.g., fields projection syntax, compact envelope shape). The description supplements by explaining the scanning boundary and total semantics, adding context to the compact parameter.

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: 'Find all insert references to a specific block definition.' This clearly distinguishes it from siblings like block_list (which lists definitions) and block_insert (which creates references), so the agent understands exactly what this tool does.

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 for locating where a block is inserted, and adds a crucial limitation about the 200-INSERT scan bound, giving context for expected scope. However, it doesn't explicitly name alternatives or when-not-to-use, which keeps it just short of a 5.

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 is consistent with the readOnlyHint annotation, indicating a read operation. It adds minimal behavioral context beyond what annotations already provide.

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

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

The description is a single, clear sentence with no wasted words. It could be slightly more structured, but it is concise and front-loaded with key 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?

Given the tool's simplicity (one input, one output with schema), the description is largely complete. The output schema covers return values, so no additional explanation is needed.

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% for the single parameter 'handle', and the description does not add additional meaning beyond the schema's description. Baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Get', the resource 'attribute values from a block reference', and the output format '{TAG: value} dict'. It distinguishes from siblings like block_list and block_set_attributes.

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 when you have a block reference handle, but does not explicitly state when to use or not use this tool, nor mentions alternatives. It provides no exclusions or context for selection.

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 description says 'Insert,' implying mutation. However, no further details on side effects, required preconditions (e.g., block definition must exist), or error states.

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?

Single sentence, no wasted words. Could be slightly more informative while remaining concise.

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 mutation tool with 8 parameters and no output schema description, more context is needed. Lacks info on return value, block existence requirement, or behavior on failure.

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 baseline is 3. Description adds minimal value by mentioning optional attributes, but otherwise repeats schema info.

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?

Description clearly states 'Insert a block and optionally set attribute values,' using specific verb and resource. It distinguishes from sibling tools like entity_create_block_ref by mentioning attribute setting, but does not explicitly differentiate.

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 like entity_create_block_ref or block_list. No prerequisites or conditions 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?

The description goes beyond the readOnlyHint annotation by disclosing that the output is never truncated, and it explains how the compact envelope always reports truncated=false. This adds valuable behavioral context about completeness and a specific output detail.

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 the primary purpose in the first and a key behavioral note in the second. It is concise, front-loaded, and contains 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?

The tool is simple with only two parameters, both fully documented in the schema, and an output schema is present. The description covers the essential behavior (listing all blocks, never truncating), making it complete without needing to explain return values.

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 already provides 100% coverage of the two parameters, including descriptions and defaults. The tool description does not add any additional parameter-level meaning beyond what the schema offers, so it stays at the baseline for full 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 clearly states the tool lists all block definitions in the drawing, enumerating specific attributes (name, origin, attribute count, entity count). It is distinct from sibling listing tools by targeting blocks specifically, making the verb+resource combination unmistakable.

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 establishes a clear use case: retrieving all block definitions. However, it does not explicitly mention alternatives or situations where a different tool would be more appropriate, so it lacks the explicit when-not-to-use guidance needed for a 5.

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

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

Annotations already indicate readOnlyHint=false, so description's 'Update' is consistent. However, no additional behavioral context (e.g., error handling, what happens if attribute tag doesn't exist) is added 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?

Single sentence of 6 words is extremely concise. While efficient, it could add more structure or information without becoming verbose.

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?

Tool is simple with only 2 parameters and output schema exists, so description need not explain return values. However, side effects or prerequisites could be mentioned.

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 covers parameter descriptions fully (handle string, attributes object). Description adds no extra meaning beyond what schema provides.

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

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

Description uses specific verb 'Update' and identifies resource 'attribute values in a block reference' clearly. It distinguishes from sibling tools like block_get_attributes (read) and block_create_from_entities (creation).

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 vs alternatives (e.g., block_insert, block_get_attributes). No conditions or exclusions 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?

The description adds valuable behavioral context beyond annotations: handles may arrive in any order, the tool orders them, refuses non-closing chains, and names gap coordinates. Since annotations only provide destructiveHint=false, this information significantly helps the agent understand error 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 concise and front-loaded, with two short paragraphs covering the core action and key behavioral notes. There is no redundant wording 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?

An output schema is present, reducing the need to explain return values. The description covers the main workflow, order-independence, and error behavior. It could specify which entity types are accepted (e.g., lines, arcs) but overall is sufficiently complete for the tool's 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?

The input schema already fully documents both parameters (handles and tolerance). The description adds a relevant note about handle ordering but does not elaborate on the tolerance parameter's semantics beyond the schema's built-in description.

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

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

The description clearly states the tool's function: 'Chain the given entities into one closed polyline.' The specific verb 'chain' and resource 'entities into one closed polyline' distinguish it from sibling tools like boundary_trace or entity_create_polyline.

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

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

The description implies the use case (entities forming a closed loop) but does not explicitly state when to use this tool over alternatives. It does not mention sibling tools or exclusion criteria, so usage context is only implicit.

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 goes well beyond the sparse annotations (only destructiveHint: false). It discloses that the tool creates an entity (polyline), explains the nearest-enclosing-loop behavior, edge-splitting behavior, and error conditions when no loop is found. This gives the agent crucial expectations for how the tool behaves in edge cases.

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 and well-structured: a one-sentence introduction followed by three action-packed sentences describing behavioral nuances. No filler or redundant text; every sentence adds value for selection and usage.

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 is highly informative given the tool's complexity, covering creation, edge cases, and errors. It does not explain return values, but the presence of an output schema means that is not required. It could have mentioned prerequisites (e.g., existing geometry) but that is reasonably inferred. Overall, it is complete enough for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, with clear parameter descriptions for x, y, layer, and tolerance. The description adds minimal semantic value by mentioning 'seed point' and edge-gap errors but does not elaborate on parameter formats or units. Since the schema already carries the parameter meanings, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool creates a closed polyline around a seed point, explicitly referencing AutoCAD's BOUNDARY/BPOLY command. It distinguishes itself from sibling tools like boundary_from_entities (which likely creates boundaries from existing entities) by focusing on the seed-point method.

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 by describing the seed-point workflow and the resulting boundary, but it does not explicitly state when to use this tool versus alternatives like boundary_from_entities or entity_create_polyline. There are no exclusions or named alternatives, so the guidance is implied rather than explicit.

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 extensive behavioral detail beyond annotations: validation runs first, error types are typed, atomicity is reported but not assumed, and rollback behavior differs between backends. This goes far beyond the destructiveHint annotation and provides critical 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?

Although lengthy, every section earns its place: code example, validation semantics, error types, atomicity, exclusions, and alternative tools. The structure uses bold headers and a clear logical flow, making complex information digestible.

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 covers all critical aspects of a complex orchestration tool: validation, error taxonomy, atomicity, dry_run, verbose, nesting limitations, and alternatives. With an output schema present, not detailing return format is acceptable. No gaps identified.

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%, but the description enriches parameters with a concrete example, explains 'bind' referencing syntax ($name, $name.field, $name.list.0), and clarifies '$$' as a literal dollar sign. It also explains the semantics of on_error options like rollback and its caveats.

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 'Execute an ordered list of tool calls in ONE round trip,' which is a specific verb+resource statement clearly distinguishing it from other tools. It also names sibling tool entity_batch_create as an alternative, providing clear differentiation.

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

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

Explicitly states when to use cad_batch vs alternatives: 'For a few hundred entities of the same kind, entity_batch_create is denser still.' It also lists exclusions: 'NOT CALLABLE from a batch: the raw command/LISP escape hatches, and cad_batch itself. Call those directly.' This is exemplary usage guidance.

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

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

Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds 'Idempotent' and the sequencing requirement, which are valuable behavioral details beyond what annotations provide. No contradictions.

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 action, no wasted words. Every sentence adds value: action, idempotency, and usage order.

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 covers the core action, idempotency, and order dependency. However, it doesn't clarify whether the 'layer' parameter changes which layer is cleared or always clears CONSTRUCTION, creating a slight ambiguity. Also lacks mentions of prerequisites like needing an open drawing, but that is somewhat assumed.

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% with the parameter 'layer' described as 'Layer to clear'. The description doesn't add new meaning beyond the schema, only mentioning the CONSTRUCTION layer in the action. Adequate but no extra value.

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 'Delete every entity on the CONSTRUCTION layer' with a specific verb and resource. It distinguishes itself from siblings like construction_xline (creates) and drawing_finalize (finalizes), leaving no ambiguity.

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

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

The description explicitly states 'Must be called before drawing_finalize to satisfy construction_left critique', providing clear when-to-use guidance. It doesn't discuss when not to use or alternative methods, but the context is sufficient for a cleanup tool.

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

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

Annotations only provide destructiveHint: false. The description adds that the line is on the CONSTRUCTION layer and intended as scaffolding, which provides behavioral context beyond annotations. However, it does not detail what happens when the tool is invoked multiple times or how the infinite line behaves.

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 only two sentences, front-loading the core purpose and then providing a key usage guideline. No redundant 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?

Despite being brief, the description covers the tool's purpose, its intended use as temporary scaffolding, and how to clean it up. With an output schema present and simple creation semantics, this is complete for the agent's needs.

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 the schema already documents all parameters. The description does not add any additional parameter semantics beyond what is in the schema (e.g., no explanation of x, y, angle_deg formats).

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 action 'Create an infinite construction line' on a specific layer ('CONSTRUCTION'), distinguishing it from regular line creation tools like entity_create_line. The mention of 'scaffolding' and 'construction_clear()' further clarifies its role.

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 explicitly says 'Use as scaffolding' and instructs to call construction_clear() before finalizing, providing clear context for when to use this tool. It does not explicitly exclude other scenarios, but the guidance is sufficient for typical 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?

Annotations already indicate non-destructive (destructiveHint=false). The description adds context about establishing a datum for critique, but does not disclose further behavioral details like impact on existing entities or prerequisites.

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, efficiently conveying the action and purpose with no extraneous words. The purpose is front-loaded.

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 standardized GD&T symbol tool with good parameter descriptions and an output schema, the description sufficiently covers the tool's function and its role in the GDT workflow.

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?

Input schema has 100% coverage with clear descriptions for all parameters (x, y, size, layer, letter). The tool description does not add significant meaning beyond the schema, hence baseline 3.

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

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

The description clearly states it places a datum feature symbol with specific components (filled triangle + boxed letter) and relates it to GDT critique, distinguishing it from other drawing tools like dimensions or GD&T frames.

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 explains the purpose of establishing a datum for GDT critique, giving clear context for when to use. However, it does not explicitly mention when not to use or alternatives.

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

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

The description states 'Create', which indicates a write operation, consistent with the annotation readOnlyHint=false. However, no additional behavioral details are disclosed (e.g., that a dimension entity is added to the drawing, or any side effects like requiring a current layout). With annotations already providing the read-only status, the description adds minimal value beyond that.

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

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

The description is a single, clear sentence with no wasted words. It fits on one line and is easily parseable by an agent. Every word contributes to the purpose.

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 that an output schema exists (not shown), the description doesn't need to explain return values. However, it lacks context about the layer parameter (optional) and the fact that this tool creates a persistent entity. For a 7-parameter creation tool with a sibling set of 10+ dimension-related tools, more contextual hand-holding would improve usability.

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 all 7 parameters with descriptions (100% coverage), such as 'First point X' and 'Dimension line position X'. The description does not elaborate on these beyond the schema, so it provides no added semantic value. Baseline 3 is appropriate as the schema is self-sufficient.

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 action ('Create') and the resource ('aligned dimension') and explains the purpose ('measures the true distance between two points'). This distinguishes it from linear dimensions (orthogonal) and other dimension types, though it could be more explicit about the alignment concept.

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 dimension tools (e.g., dimension_linear for orthogonal distances, dimension_angular for angles). The description does not specify context, prerequisites, or alternatives, leaving the agent to infer from the name alone.

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

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

Annotations already indicate readOnlyHint=false, matching the creation behavior. The description adds no further behavioral context beyond what's obvious from the verb 'Create', such as potential side effects or prerequisites.

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

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

The description is a single succinct sentence front-loading the purpose with no unnecessary words 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?

Given the presence of an output schema and full parameter coverage, the description is complete enough for a straightforward creation tool. Minor improvement could clarify the angle range, but not essential.

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 parameters have descriptions. The description adds no additional meaning beyond what the schema provides; baseline score of 3 is appropriate.

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

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

The description clearly states it creates an angular dimension measuring the angle between two lines from a vertex, using specific verb-resource pair and distinguishing from other dimension tools like linear, aligned, radius, diameter.

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 for angular dimensions but does not provide explicit guidance on when to use this tool versus alternatives (e.g., dimension_auto) or when not to use it.

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

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

The description adds that the tool generates dimensions and supports only lines, but it does not explain what exactly happens (e.g., creates dimension entities) or side effects. Annotations state destructiveHint: false, which is consistent. The description is adequate but not rich in behavioral 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?

Two short sentences convey the core functionality and a critical constraint. Every word is essential; no redundancy or fluff.

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 covers the main purpose and a key limitation (only lines). Given the tool has an output schema (not shown), the description does not need to detail return values. It is complete enough for a straightforward auto-dimensioning tool, though it could mention that it creates multiple dimension objects.

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 parameters are documented in the input schema. The description does not add further details beyond the schema, such as the meaning of 'style' or 'offset'. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool generates ISO 129 dimensions across entities in a chosen style, and specifies 'V1 supports LINE entities only.' This distinguishes it from sibling dimension tools like dimension_linear or dimension_aligned, which handle single dimensions or other entity 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 clear guidance that the tool works on LINE entities only, implying it should be used when auto-dimensioning multiple lines. However, it does not explicitly mention when not to use it (e.g., for other entity types) or name alternative tools like dimension_linear for single lines.

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 indicates it's a 'create' operation, consistent with the readOnlyHint=false annotation. However, it provides no additional behavioral context such as side effects, permissions, or error conditions.

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?

Single sentence, front-loaded with action and example. Every word earns its place.

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

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

For a tool with 11 parameters and an output schema, the description is adequate but could mention prerequisites (e.g., existing circle), or common use cases.

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 description doesn't need to add much. The tolerance example hints at the fit parameter but doesn't explicitly link to schema fields.

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 creates a diameter dimension for a circle, with an example of tolerance. It distinctly differentiates from sibling tools like dimension_radius, dimension_linear, etc.

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 context is implied (for circles requiring diameter dimension) but no explicit guidance on when to use this versus alternatives like dimension_radius for arcs or circles with smaller radii.

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 (mutation), which the description supports with 'Create'. It adds tolerance context (ISO 129 and ISO 286 fit) but fails to disclose other behavioral traits like prerequisites (open drawing) or that the dimension is an entity added to the drawing.

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

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

The description is a single, front-loaded sentence that efficiently conveys the core action and optional feature. Every word is meaningful, with no 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?

Given the tool's complexity (13 parameters, 6 required) and the presence of an output schema, the description is minimal. It omits spatial context (e.g., points define extension lines, dim_x/dim_y position the dimension line) that would help an agent fully understand the geometry.

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% with detailed parameter descriptions (e.g., fit, tol_mode). The description adds no new parameter information beyond mentioning tolerance standards, so it does not compensate beyond the baseline for schema-rich tools.

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 'Create a linear dimension, optionally toleranced', which is a specific verb ('Create'), a distinct resource ('linear dimension'), and a key distinguishing feature ('optionally toleranced'). This differentiates it from sibling tools like 'dimension_aligned' and 'dimension_angular'.

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 explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest alternative tools for different scenarios, such as 'dimension_aligned' for rotated measurements.

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

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

Annotations already indicate readOnlyHint=false, so the description aligns by stating 'Create'. However, it adds minimal behavioral context beyond that—only mentioning 'optionally toleranced'. It does not disclose what happens if geometry is invalid, whether the dimension is associative, or other 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 single, front-loaded sentence (12 words) that efficiently conveys the essential operation. Every word adds value, with no redundancy or extraneous 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?

Despite having 11 parameters, 4 required, and an output schema, the description is too brief. It omits critical context such as the geometric relationship between center and chord points, that the dimension is placed in the current drawing, and how the tool interacts with existing entities. This leaves the agent with insufficient information 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 input schema already documents all parameters thoroughly. The description adds no new parameter meaning beyond hinting at tolerance capability. According to guidelines, baseline is 3 when coverage is high.

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 purpose with a specific verb ('Create') and resource ('radius dimension for a circle or arc'), and it distinguishes itself from sibling dimension tools (linear, aligned, angular, diameter) by specifying the geometry type.

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 for creating radius dimensions but provides no explicit guidance on when to use this tool versus alternatives like dimension_diameter or dimension_linear. No 'when-not-to-use' conditions or references to siblings are included.

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?

Not only is destructiveHint=false but description adds 'idempotent — existing layers are not modified', which is a key behavioral trait beyond 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?

Two sentences with no fluff; front-loaded with core purpose and key property (idempotent).

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?

Simple tool with one param and output schema; description covers purpose and idempotency. Could mention exactly what layers are created or that it only creates missing layers.

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 description adds no additional meaning to the 'standard' parameter beyond what's already in the schema.

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

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

Description clearly states it bootstraps a full ISO-conformant layer set with correct colors and lineweights, and distinguishes from siblings like layer_create or template_apply_layers by focusing on a complete standard set.

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

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

Implies usage for initial setup via 'bootstrap', but no explicit when-to-use or alternatives mentioned. Does not differentiate from template_apply_layers or other layer 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?

The description goes far beyond the readOnlyHint:false annotation by explicitly stating 'This mutates the drawing,' explaining that fixes are already applied and require a save, and detailing the live COM backend quirk with null counts and detail: 'unavailable'. It also describes the result lists (fixes and errors) and their meaning, providing exceptional 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 compact and front-loaded: it opens with the core action and output, then warns about the mutation, explains the fixes and errors lists, and ends with a backend-specific note. Every sentence carries necessary information and there is no 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?

Given zero parameters and the presence of an output schema, the description supplies all essential context: what the tool does, that it mutates the drawing, what the return fields mean, and how to retain the changes. It is fully sufficient for an agent to invoke this tool correctly in 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?

The tool has zero parameters and the input schema coverage is complete, so there are no parameter semantics to clarify. The description focuses on behavior and outputs, which is appropriate. A score of 4 reflects the no-parameter 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 uses a specific verb and resource: 'Audit the drawing' and clearly states the outcome: 'repair every fixable structural problem, and report it.' It distinguishes the tool from read-only analysis or validation tools by emphasizing that it mutates the drawing. The action is unmistakable.

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

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

The description implies when to use the tool—when you want to fix and audit structural issues—and provides actionable guidance to save afterwards to persist fixes. However, it does not explicitly name alternatives or state when not to use it, such as when a non-mutating review (e.g., drawing_critique) would be preferred. This is adequate but not fully explicit.

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 destructiveHint=true, and the description confirms the close action. It explains the save behavior and mandatory follow-up calls, but does not explicitly warn about unsaved data loss if save=False.

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

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

Two concise sentences cover purpose, parameter behavior, and post-usage requirement. No wasted words.

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 simplicity and the presence of an output schema, the description provides essential info. However, it could briefly note that unsaved changes are lost if save=False.

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 only parameter 'save' is described in context (default True, saves before closing), adding meaning beyond the schema description.

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

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

The description clearly states the tool closes the current drawing, with an option to save. This distinguishes it from siblings like drawing_new, drawing_open, and drawing_save.

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 states the post-condition: after closing, you must call drawing_new or drawing_open before other tools. This provides clear sequencing guidance.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds that the tool returns an empty list for clean drawings, which clarifies the output behavior. No additional behavioral details are needed.

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 concise sentences with no redundant information. It front-loads the core purpose and immediately adds the critical usage context.

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 simplicity (1 optional param, output schema present, annotations), the description is mostly complete. It could explicitly clarify the difference from similar checks like drawing_audit, but it's sufficient for agent 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?

The schema covers the single parameter 'focus' with 100% documentation, including possible values and default. The description does not add any parameter information beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool runs premium-quality checks on a drawing and returns zero issues for a clean drawing. It references drawing_finalize as a gate, but does not explicitly differentiate from sibling tools like drawing_audit or validation_check.

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 a usage hint: 'must return [] before drawing_finalize', indicating it's a pre-finalization gate. However, it does not mention when not to use it or compare with alternative validation tools.

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

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

Annotations already declare destructiveHint=true, warning about destructive behavior. The description adds context about failure behavior ('keeps all generated artifacts for diagnosis') and result statuses, which goes beyond annotations.

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

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

Two concise, front-loaded sentences that convey the core purpose and key behavioral notes with zero 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?

Given the tool has an output schema (not shown but present), the description is sufficient. It covers the main outcomes and failure modes, but could mention that the bundle includes a manifest.json to be 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 coverage is 100%, so baseline is 3. The description does not add extra meaning beyond what the input schema already provides for parameters like output_dir, formats, etc.

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 it creates a 'hashed, validated delivery bundle' and 'verify DXF save/reopen parity', which is a specific verb+resource combination distinct from sibling tools like drawing_save or drawing_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?

The description implies this tool is for producing an auditable bundle with validation, which differentiates it from simpler export tools. However, it does not explicitly state when to use it or mention alternatives, leaving some ambiguity.

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 lack readOnlyHint or destructiveHint, so the description must disclose behavioral traits. It only states 'Export' without explaining side effects like file overwriting or error handling. The mutation implication is weak.

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

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

The description is a single sentence with no wasted words, directly conveying the tool's purpose. It is front-loaded and efficient.

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

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

For a simple one-parameter tool with an output schema, the description is largely adequate. It identifies the action, resource, and output. Minor improvement would be to clarify that it exports the current drawing's state.

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 parameter description 'Output .dxf file path' is already clear. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'Export', the resource 'current drawing', and the output format 'DXF file'. It effectively distinguishes from sibling tools like drawing_export_pdf and drawing_save_as.

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 alternatives such as drawing_export_pdf or drawing_save_as. There is no mention of prerequisites, limitations, or context for 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?

No annotations (readOnlyHint, destructiveHint) provided, so description should disclose side effects. It only states export without mentioning whether the original file is modified, required permissions, or file overwrite behavior. Minimal transparency beyond the action.

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

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

Two short sentences: one for purpose, one for parameter details. No redundant words, front-loaded with primary action.

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

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

Output schema exists, so return values are documented. Description covers main functionality and param semantics. Lacks mention of file overwrite behavior, error conditions, or prerequisites. Adequate for a simple export tool but missing some edge-case 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?

Schema covers 100% of parameters, so baseline 3. Description adds extra context for layout parameter: explains COM vs ezdxf rendering differences. This adds value beyond schema properties. However, path parameter gets only a brief description.

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

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

Description clearly states 'Export the current drawing (or a paper-space layout) to PDF.' It specifies the verb (export), resource (drawing/layout), and format (PDF), distinguishing it from sibling 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?

Implicitly indicates use for PDF export, but lacks explicit exclusion or alternatives. Mentions layout parameter but no guidance on when to use model vs paper space. Sibling tools provide context but no direct comparison in description.

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 provide destructiveHint=true; description adds validation behavior, error conditions, and strict_critique toggle. No contradictions. Fully informs about 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?

Two concise paragraphs: first covers core function, second covers error behavior. No redundancy, efficiently front-loaded.

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 output schema exists, description explains validation process, error handling, and return value (DWG path). Fully adequate for complex 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 covers all 4 parameters with descriptions. Description adds context like 'Optional contract' and explains strict_critique default behavior, supplementing schema well.

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 it runs both validator and critique, saves, screenshots, and returns DWG path. It lists specific validator steps and critique focuses, distinguishing it from simple save or export tools.

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

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

Describes as 'Premium completion gate' implying final step. Mentions error raising conditions and strict_critique behavior. Lacks explicit comparison to alternatives, but usage context is clear.

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 readOnlyHint annotation already signals read-only behavior. The description adds valuable context by listing the exact metadata returned (name, path, entity_count, etc.), which goes beyond the annotation. No side effects or contradictions.

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 plus a bulleted list) with no wasted words. It front-loads the purpose and efficiently conveys the return fields.

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 covers the return fields, which likely overlap with the output schema. It could mention that a drawing must be open, but given the simplicity and the existence of an output schema, it is sufficiently complete.

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

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

The tool has no parameters, and schema coverage is 100% (empty schema). The description does not need to explain parameters, so it meets the baseline for a no-parameter tool.

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 'Get comprehensive metadata for the current drawing' and lists the specific fields returned. This verb+resource pairing is distinct from sibling tools like drawing_close or system_status, making the purpose 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?

The description implies the tool is for retrieving metadata, but does not provide explicit guidance on when to use it versus alternatives (e.g., system_status or drawing_settings). No exclusions or when-not-to-use context is given.

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

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

The description adds detail beyond annotations: it specifies that the drawing is created from scratch and details the bootstrap layers/linetypes. The annotation already states destructiveHint=false, so there is no contradiction. The behavior is accurately described.

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 clearly separated. The first sentence states the core purpose, the second details the bootstrap behavior. Every word is informative 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?

Given the output schema exists (not shown), description does not need return values. It covers creation, template, and bootstrap sufficiently. Could mention that the new drawing becomes current, but it's adequate.

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

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

With 100% schema coverage, baseline is 3. The description adds significant value by explaining the effect of 'bootstrap' and what it seeds (standard linetypes and layers), and clarifies 'template' as optional path. This goes 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?

The description clearly states the tool creates a new empty drawing, optionally from a template. The verb 'Create' and resource 'new drawing' are specific. It distinguishes from siblings like 'drawing_open' or 'drawing_save' by emphasizing 'empty' and the bootstrap feature.

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 explains when bootstrap is applied by default and when to disable it for 'vanilla DXF'. However, it does not explicitly contrast with 'drawing_open' or other creation methods, but the intent is clear.

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 provide only a title, so the description carries the full transparency burden. It discloses a non-obvious behavior: ezdxf sniffs content rather than extensions, meaning a mislabelled DXF-in-a-.dwg would be parsed and return a document that doesn't exist in that format. This adds valuable insight beyond the basic 'open' action, though it doesn't mention success/failure responses or 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 mostly concise, with the core purpose in the first sentence and a valuable technical caveat in the second paragraph. The 'T0.2' version marker is unnecessary noise, but the overall structure is effective in front-loading the primary action and then detailing important edge-case behavior.

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

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

For a simple one-parameter open tool, the description covers the primary use case, the conditional DWG support, and a subtle parsing gotcha. With an output schema present, there is no need to explain return values. The description is complete enough for an agent to correctly invoke the tool and understand when it will fail.

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 already provides a rich description for the single 'path' parameter, covering the .dxf/.dwg distinction and backend requirements (100% coverage). The description itself does not add new parameter details beyond echoing the schema, 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?

The description clearly states the tool's action: 'Open an existing DXF drawing file.' It also specifies the conditional DWG support, distinguishing it from sibling tools like drawing_new and drawing_save. The verb and resource are explicit and immediately understandable.

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 clear context: use for existing DXF files, with DWG only on the live COM backend. It also gives a practical exclusion by stating that a .dwg path is refused on backends lacking the `dwg` capability. While it does not explicitly compare to drawing_new, the wording 'existing' implies the alternative use case for new drawings.

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 explains that the PlanSpec is stored, surfaced for reference, and not replayed as a critique, adding behavioral insight beyond the destructiveHint annotation. It also notes the timing requirement.

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?

Three concise sentences, front-loaded with purpose, each adding value without 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?

Given the complexity (9 params, well-covered schema, output schema present), the description sufficiently explains the tool's role. Could mention idempotency but adequate.

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

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

Schema coverage is high (89%), so the description does not need to elaborate on parameters. It adds no parameter-specific information, meeting the 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 clearly states the tool commits a PlanSpec before geometry creation, with the title adding context. It distinguishes from sibling drawing and entity creation tools by being a preparatory planning step.

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 instruction 'Always call this FIRST in a premium workflow' provides clear usage context but does not explicitly state when not to use or mention 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?

The annotation readOnlyHint: true declares the tool as read-only. The description mentions 'normalize', which could be misinterpreted as a modification, but likely refers to output normalization without side effects. The description adds limited behavioral context beyond the annotation, such as 'validate' implying a check-and-report function. A score of 3 is appropriate because the annotation carries most of the transparency burden.

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

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

The description is a single, efficient sentence (9 words). It earns its place by conveying the core purpose without verbosity. However, it could be slightly improved by front-loading the key action more prominently, hence not a perfect 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?

With 8 parameters, 1 required, and an output schema present, the description is minimal. The output schema relieves the need to explain return values, but the description does not mention that the tool returns validated/normalized requirements or any error reporting. It is adequate but leaves the agent wondering about the full capabilities.

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

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

Schema description coverage is 75%, so the input schema already documents most parameters. The high-level description ('validate and normalize requirements') provides context but adds no specific meaning to individual parameters beyond what the schema offers. The baseline 3 is correct; the description does not compensate for the remaining 25% undocumented parameters.

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 verb-resource pair: 'validate and normalize requirements before committing a drawing plan.' It positions the tool as a pre-commit step, distinguishing it from drawing creation or finalization tools. However, it lacks explicit differentiation from closely related siblings like 'drawing_plan' or 'drawing_critique', preventing a higher score.

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 alternatives. While the name and description imply it should be used before finalizing a drawing, there is no explicit statement of context, exclusions, or prerequisites. This leaves the agent uncertain about the appropriate invocation scenario.

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

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

The description discloses the tool deletes unused objects, but does not explicitly warn about irreversible changes or need for confirmation. Given no annotations (no destructiveHint), the description should be more explicit about destructiveness.

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

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

The description is a single concise sentence that efficiently communicates the purpose without extraneous 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?

Given no parameters and a clear description, the tool's behavior is fully specified. The output schema handles return details, so description is sufficient.

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?

Tool has zero parameters, and the description does not need to add parameter info. Baseline for 0 parameters is 4.

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 action (purge) and specific objects (layers, blocks, linetypes, styles). It distinguishes from sibling tools like entity_delete or drawing_audit by specifying 'unused objects' and listing categories.

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 vs alternatives like drawing_audit or entity_delete. The description implies cleanup of unused items but does not specify conditions or when not to use.

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?

Beyond the destructiveHint annotation, the description discloses important behavior: it shares history with drawing_undo, requires the EZDXF_UNDO_DEPTH environment variable, and explains the redo branch discard rule. This is genuinely useful behavioral context that the annotations do not provide.

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 yet complete: a one-line purpose, a prerequisite, and a behavioral caveat. Each sentence earns its place, and the most important information is front-loaded.

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

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

For a zero-parameter tool, this description covers the essential aspects: what it does, the required backend setting, and the branch-discard semantics. The presence of an output schema reduces the need to describe return values, and no critical gaps remain.

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

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

The tool has zero parameters, so there are no parameter semantics to clarify. The description focuses on the operation and its prerequisites, which is appropriate. A baseline of 4 is warranted since no parameter documentation is needed.

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

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

The description opens with a specific verb and resource: "Reapply the operation you just undid," which clearly defines the tool's action and distinguishes it from drawing_undo. It also explicitly references the undo tool, making the relationship 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?

The description provides clear usage context: it names drawing_undo as the sibling, states the EZDXF_UNDO_DEPTH prerequisite, and warns that drawing after an undo discards the redo branch. However, it does not explicitly list alternative tools or say when not to use this tool beyond the discard condition.

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

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

Annotations already indicate destructiveHint. Description adds that it is bounded (max_rounds) and transaction-safe, providing some behavioral context. However, it does not elaborate on side effects like modification to the drawing or that it may require transactions to be started/committed.

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?

Single sentence is concise and front-loaded with key terms (bounded, transaction-safe). It is appropriate in length for a tool description, though could include more detail without losing conciseness.

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 5 optional parameters, an output schema, and many sibling tools, the description is too brief to be complete. It omits context about working on the current drawing, interactions with transactions, and expected outcomes.

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 description does not add meaning to the parameters beyond the input schema. Only 60% of parameters have descriptions in the schema, and the description gives no extra context on focus, dry_run, etc.

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

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

The description states a specific process: bounded, transaction-safe critique/repair/re-critique loop. It distinguishes from plain critique by indicating iteration, but could more clearly differentiate from sibling tools like drawing_critique or drawing_plan.

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 over alternatives. The description does not mention prerequisites, when to choose this vs manual repair steps, or that it is for automated refinement.

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 beyond the title, the description must disclose behavioral traits. It states 'Save the current drawing' but does not clarify whether this overwrites the existing file, creates a backup, or if it requires a prior save. It fails to explain the destination when no path is given (current path). The destructive nature is implied but not explicit.

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 with two sentences. It is front-loaded with the primary action. However, it could be slightly more precise without significant verbosity, e.g., specifying that it overwrites the existing file unless a new path is given.

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 presence of many sibling tools, no output schema details, and the simplicity of the tool, the description is too minimal. It does not mention return values (despite an output schema existing), error conditions, or the impact of saving (e.g., it may finalize the drawing state). For a potentially destructive operation, more context is needed.

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%, with the path parameter fully described. The description adds minimal value beyond the schema: 'Optionally specify a new path' paraphrases the schema. It does not explain what happens when a new path is given (e.g., changes the drawing's current path or just exports a copy), missing an opportunity to clarify behavior.

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

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

The description clearly states 'Save the current drawing' with a specific verb and resource. However, it does not distinguish from the sibling tool 'drawing_save_as', as both allow specifying a new path. The phrase 'Optionally specify a new path' creates ambiguity about whether this changes the current file's path or just saves a copy.

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 alternatives like 'drawing_save_as' or 'drawing_close'. There is no mention of prerequisites, such as the drawing needing a path already set, or when not to use it. The description lacks any context for appropriate 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?

Annotations provide only title, so description carries full burden. It details that format derives from extension and how 'format' parameter works, preventing confusion. However, it does not clarify whether the current drawing session now points to the new file (typical Save As behavior), which is a behavioral 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 description is concise (three short sentences) with purpose front-loaded. Every sentence contributes essential behavior without 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?

Given the tool's simplicity and presence of output schema, the description covers format logic well. The only missing element is whether the original drawing is unchanged or the session switches to the new file—a minor gap for such a 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 coverage is 100%, and the description adds value by explaining the N2 principle (bytes match name) and the override condition in plain language, going beyond schema descriptions. This helps agent understand parameter interplay.

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 saves the current drawing to a new path/format, listing DWG, DXF, or DWT. It distinguishes from sibling tools like 'drawing_save' (which saves to existing path) and 'drawing_export_dxf' (specific export) by focusing on saving to a new location.

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 explains when format override applies, but does not explicitly contrast with export tools or state prerequisites (e.g., ensure drawing is open). The title 'Save As' implies usage for saving copies, but more direct guidance would improve clarity.

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