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

No annotations are present, so the description carries full responsibility. It discloses key behavioral traits: line-weight differentiation by layer, automatic placement in free area, manual position offset, replacement of previous plan views, and the need to check warning and suggested_scale in the output. This is comprehensive for a drawing-placement tool and even flags failure modes.

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

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

The description is dense but not bloated; each sentence adds critical operational detail. The semicolon-heavy second sentence packs placement, position, and scale rationale efficiently. Slightly front-loaded but could be structured with clearer separation of default behavior versus manual overrides.

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, return values need not be explained. The description covers main behaviors and parameters, but lacks any mention of the 'page' parameter, which is required for full invocation context. It also assumes an existing sheet without stating prerequisites, leaving some ambiguity for an agent deciding whether to call create_drawing_page first.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly explains three of four parameters: layers (drawing subset), scale (sheet scale or override), and position (coordinates from bottom-left corner). The 'page' parameter is not mentioned at all, leaving a gap in the parameter semantics, but the other three are meaningfully clarified.

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

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

States a precise verb and resource: 'Put the drawing on the sheet at the sheet's scale' with line weights by layer. It clearly distinguishes from siblings like position_view or set_scale by describing the complete add-plan-view operation, including auto-placement and replacement behavior.

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 place a drawing on a sheet as a plan view. It gives context about auto-placement and manual position, and notes that it replaces any previous plan view. However, it does not explicitly reference alternatives or state when not to use it, leaving the selection among siblings like position_view or create_drawing_page to inference.

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

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

There are no annotations, so the description carries the full behavioral burden. It states the additive action but does not disclose what happens if a title block already exists, whether omitted fields are left blank or reset, or how the target sheet is selected. This is a meaningful gap for a mutation tool.

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

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

A single, front-loaded sentence that names the action, the target, the precondition, and the parameter behavior. There is no redundant or filler 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 9 optional parameters, no annotations, and the sibling update_title_block, the description is too thin. It does not explain how the target sheet is identified, prerequisites, failure behavior, or the relationship to update_title_block, leaving an agent with significant uncertainty about correct invocation.

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

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

Schema description coverage is 0% across 9 parameters, and the descriptions only add 'fill the given fields,' which does not explain formats, units, or meaning beyond the property titles. The property names are somewhat readable, but the description fails to compensate for the complete lack of schema-level documentation.

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 ('Add') and resource ('title block/cartouche') and clarifies the exact scope: adding to a sheet created without one. This distinguishes it from the sibling update_title_block, which would apply when one already exists.

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

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

The phrase 'created without one' provides a clear precondition and implies that update_title_block is the appropriate alternative for existing title blocks. It does not explicitly mention alternatives or exclusions, but the usage context is clear enough for an agent to route correctly.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly communicates that the tool deletes 3D volumes and explicitly preserves the 2D plan. This is meaningful behavioral context beyond the bare verb 'delete', though it omits details like irreversibility 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?

The description is a single sentence that front-loads the destructive action and resource, then efficiently covers scope and the key exclusion (2D plan untouched). Every clause earns its place with no redundancy.

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

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

For a tool with only one parameter and an output schema, the description covers the essential behavior: what is deleted, what is preserved, and the scope choices. It is slightly light on how the 'level' parameter maps to actual level identifiers, but overall the definition is sufficient for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. The phrase 'of one level, or of all levels' directly explains the single 'level' parameter: a string identifies one level, while the default null means all levels. This adds meaning beyond the bare schema, though it does not specify the exact format expected for a level string.

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 ('Delete') and resource ('3D volumes (walls, slab, roof)') with clear scope ('one level, or of all levels'). It also distinguishes itself from 2D operations by explicitly stating the 2D plan is untouched. This clearly separates it from generic delete_object and 2D-focused siblings.

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

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

The description implies the correct use case: removing 3D volume geometry while preserving 2D plans. It does not name alternatives or state explicit when-not-to-use conditions, but the scope options ('one level, or of all levels') give enough 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?

With no annotations, the description carries the behavioral burden and does disclose key traits: the entire plan (walls, doors, windows, texts) is copied and the result is editable. It also states a meaningful default for elevation ('on top of the last level'). It stops short of explaining activation behavior or independence from the source, but the main side effect is covered.

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 the core action in the first clause and a key default in the second. No filler or repeated schema 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?

For a creation tool with no annotations and 5 parameters, the description omits the meaning of required `name` and the `activate`/`height` options. It covers purpose and elevation default, so it is not useless, but an agent cannot confidently set all parameters. Output schema exists, so return values do not need explanation, but parameter coverage is incomplete.

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

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

Schema description coverage is 0%, so the description is the only prose source for parameter meaning. It adds meaning for `source` (the level being copied) and `elevation` (defaults to top of last level), but leaves `name`, `height`, and `activate` unexplained beyond their schema titles. This partial coverage is insufficient for a 5-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 states a specific action: create a level as a copy of a source, copying the entire plan. This clearly distinguishes it from create_level, which creates a fresh level, and from other siblings. The 'ready to be edited' note reinforces the copy purpose.

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 it: when you need a duplicate of an existing level's plan for editing. It does not name alternatives like create_level or set_active_level, nor does it state when not to use it. This 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?

With no annotations, the description carries the burden of behavioral disclosure. It usefully states that copies keep the layer and are shifted by dx/dy, but it does not clarify whether the originals are modified, whether the operation is additive, or what happens with the existing selection.

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. It front-loads the core operation and packs in the offset, count, units, and layer behavior efficiently.

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 and an output schema exists, but the description leaves the required 'names' parameter under-specified and provides no routing guidance relative to similar transformation tools. It is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by giving units for dx/dy and explaining count, but it never explains the required 'names' parameter or explicitly maps it to the 'objects' being copied.

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 clear verb ('Copy') and resource ('objects'), and specifies the offset semantics in mm. The copy-and-shift behavior distinguishes it from siblings like move_object and mirror, though no sibling is explicitly named.

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

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

The intended use case of duplicating objects with a repeated offset is implied, but there is no explicit guidance on when to use this tool versus alternatives like move_object, offset, or mirror, and no exclusions are 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?

No annotations are provided, so the description carries the full burden. It does add useful geometric behavior (counter-clockwise, degrees, angle origin), but it does not disclose side effects on the drawing, whether the arc is added to the current level, or how fit_view influences the result. For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

A single sentence that is efficiently front-loaded with the most essential information: action, direction, and angle convention. There is no filler, and every word contributes to understanding the core operation.

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

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

With six parameters, no annotations, and 0% schema coverage, the description is too sparse. An agent would have to guess the coordinate format for center, units for radius, the meaning of a null layer, and the effect of fit_view. The output schema may help with return values, but not with input decisions.

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

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

Schema description coverage is 0%, so the description must compensate for the six parameters. It only clarifies start_angle and end_angle semantics; center, radius, layer, and fit_view are left entirely to inference from names and schema types. This does not provide enough parameter meaning for an agent to invoke the tool confidently.

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

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

The description names a specific verb ('Draw') and resource ('arc'), and distinguishes itself from siblings by specifying counter-clockwise direction and the angular reference (0 = +x axis). This clearly identifies what the tool does and separates it from create_circle or create_line.

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

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

There is no guidance on when to choose this tool over alternatives such as create_circle or create_polyline, nor any mention of prerequisites like an active layer or open document. The description states the operation but never addresses when it is appropriate.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the intended action and does not explain what drawing a circle does to the document, whether it operates on the active layer, how fit_view behaves, or what output to expect.

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 short and front-loaded, but it is under-specified rather than efficiently complete. It provides minimal information beyond restating the tool's purpose and adds no actionable detail.

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

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

For a 4-parameter creation tool with no annotations, this description is incomplete. It omits coordinate system, layer semantics, fit_view behavior, and any guidance about required versus optional parameters, so an agent cannot reliably invoke the tool correctly.

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

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

The '(mm)' hint gives some unit context for the radius and center coordinates, which the schema does not specify. However, with 0% schema description coverage, the description does not explain center format, layer behavior, or fit_view, leaving most parameter semantics unexplained.

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

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

The description names a specific action ('draw') and resource ('circle'), and the '(mm)' suffix clarifies units. It is distinguishable from sibling tools like create_rectangle and create_arc by the object type, though it does not explicitly name alternatives.

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

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

There is no guidance about when to use this tool versus alternatives such as create_arc or create_polyline. No context, prerequisites, or exclusions are provided, so the agent must infer usage entirely from the name and schema.

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

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

With no annotations provided, the description carries the behavioral burden, and it does so well: it states that the tool cuts an opening, draws jambs/leaf/arc, creates a single moveable object, assigns BIM metadata, and warns when no wall is found. It does not fully address destructive consequences or how the wall is modified beyond cutting, but the disclosed behavior is substantially informative.

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

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

The description is dense but well-structured: the first paragraph explains the tool's core behavior and BIM nature, while a compact parameter list covers semantics and defaults. Every sentence adds useful information, and nothing feels redundant or overlong.

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 10-parameter tool with no annotations and 0% schema coverage, the description is remarkably complete: it covers the main behavior, defaults, parameter meanings, and an error condition. The main gaps are fit_view not being explained and orientation's default value not being repeated in the description, but the output schema reduces the need to describe 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?

Schema coverage is 0%, so the description must compensate, and it explains nearly all parameters: position center on wall axis, width default, orientation as wall direction, wall_thickness for wall vs partition, hinge start/end, swing direction with defaults, mark numbering, height default, and material default. The one notable omission is fit_view, which is not mentioned in the description.

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

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

The description opens with a specific verb and resource: 'Cut a door opening in the wall and draw the classic door.' It clearly identifies the tool as creating a door, distinguishes it from sibling tools like create_window_2d, and adds concrete detail about the resulting door object being a single block and a BIM object.

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 rather than explicitly stated: the tool works on a wall, warns if no wall is found, and suggests using wall_thickness=100 for partitions. However, it does not explicitly contrast this tool with alternatives such as create_window_2d, create_wall_2d, or create_partition_2d, so an agent must infer when this tool is the right choice.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It does reveal non-obvious behavior: a French title block is filled from specific fields, and date defaults to today. However, it does not mention side effects like whether a new page is appended or replaces an existing one, or whether an active document is required.

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: the first sentence states the core operation and key parameters, the second gives the immediate follow-up, and the third explains the scale requirement. Every sentence adds practical value 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?

For a complex 13-parameter tool, the description is quite complete: it covers the sheet creation, the title block content, the follow-up add_plan_view call, and the scale rule for readable dimensions. It does not clarify how the created page connects to add_plan_view or what happens to an existing sheet, but an output schema exists and the workflow is mostly unambiguous.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: size, orientation, scale, and the French title-block fields (projet, adresse, client, titre, dessine, date, numero, indice) are all mapped. The 'name' parameter is not explained and the title_block boolean is only indirectly referenced, preventing a perfect 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 a specific verb and resource: 'Create a sheet' and then enumerates the key attributes (size, orientation, scale, title block). It clearly differentiates itself from sibling tools like add_plan_view by presenting that as a follow-up action rather than part of this tool.

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

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

The description gives explicit workflow guidance: after creating the sheet, 'call add_plan_view', and when creating dimensions/texts, use scale=<print scale denominator>. It does not enumerate when-not-to-use cases or alternatives, but the context is clear enough for an agent to sequence calls correctly.

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

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

With no annotations provided, the description carries the full behavioral burden and does well: it discloses that the fill becomes 'one block on layer poche', the print mechanism ('drawn with pen-thick lines so it prints solid on the sheet and in the PDF'), and that avoid_openings leaves doors and windows empty. Minor gaps remain, such as interaction with pre-existing fills and prerequisites, but the core behavior is well disclosed.

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

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

One dense paragraph with the core purpose front-loaded, followed by compact parameter documentation. Every sentence earns its place and there is no filler, but the inline parameter explanations run together into a wall of text rather than using clear separation or ordering.

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 5-parameter tool with zero schema coverage and no annotations, the description covers nearly everything a caller needs: units (mm), layer, hole semantics, tone options, scale behavior, and opening avoidance. It does not address repeat invocation on the same area or required drawing state, but an output schema exists to cover return values, so the remaining gaps are minor.

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

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

Schema description coverage is 0%, so the description must compensate — and it does thoroughly. Every parameter gets meaning beyond its schema name: points/holes outline-relationship with wall-specific guidance, tone semantics (black solid, grey lighter), scale as a print-scale denominator with a rationale, and the behavior of avoid_openings. This is exemplary compensation for a schema that is silent.

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 verb and resource: 'Solid fill (poché) of an area, as one block on layer poche (mm)'. It grounds the purpose in architectural meaning ('what a plan shows for concrete or masonry cut by the section plane'), which distinguishes it from the sibling tools create_hatch and fill_walls without needing to open schemas.

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 the use context — filling areas that represent concrete or masonry cut by the section plane — and implies why this tool exists. However, it never explicitly says when to prefer it over the closely related siblings fill_walls or create_hatch, and names no alternatives or exclusions.

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

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

No annotations are present, so the description carries the burden. It discloses the single-block layer behavior, world-origin alignment for adjacent hatches, and the non-updating behavior when openings change later. Could add idempotency or overwrite behavior, but overall strong for a creation tool.

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?

All sentences earn their place; the parameter walkthrough is compact and front-loaded with the main purpose and layer. It packs examples and defaults without rambling.

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 seven parameters and no annotations, it covers coordinates, units, defaults, layer, and a timing caveat. With an output schema present, return values need no description. Minor omissions like invalid-input behavior or whether the layer must pre-exist keep it from a 5.

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

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

Schema description coverage is 0%, yet the description documents every parameter with defaults, units, and examples: points, holes, pattern, angle, spacing, scale, and avoid_openings. This fully compensates for the empty schema descriptions.

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

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

The opening sentence states a specific verb ('Hatch') and resource (an area as one Hachure block on a named layer). This clearly distinguishes it from sibling fill tools by emphasizing parallel-line mechanics and the target layer.

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

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

It gives explicit timing guidance—hatch after placing doors/windows—and explains how to structure outer/inner outlines for wall rings using create_wall_loop output. It does not mention alternative tools or exclusion cases, but the context is clear enough for an agent to decide when 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that standard names receive default styles and clarifies color/style formats, but it does not state what happens if a layer name already exists, whether the new layer becomes active, or any side effects. For a state-changing operation, this is a meaningful 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 two sentences with no filler or redundancy. Purpose is front-loaded, followed by compact parameter details that earn their place. It is appropriately sized for the tool's complexity.

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

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

The output schema presumably covers return values, so that part is not missing. However, the description omits operational context such as line_width semantics, duplicate-name handling, and layer activation behavior. The standard-names default-style context adds useful value, but an agent still lacks important behavioral 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 0%, so the description must explain parameters. It successfully explains line_color as [r,g,b] in 0..1 and draw_style as Solid/Dashed/Dotted/Dashdot, and it implies that certain 'name' values yield default styles. However, line_width is left completely undefined, and the name semantics beyond standard defaults are not detailed. The compensation is partial.

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 verb ('Create') and resource ('a layer'), making the primary function unambiguous. It is naturally distinguished from sibling tools like set_layer or get_layers by the 'create' verb, though it does not explicitly name alternatives. The meaning is clear and direct.

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

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

The description gives no guidance on when to use create_layer versus related tools like set_layer or set_visibility, and it mentions no exclusions or prerequisites. The standard-names hint is a naming suggestion but does not help an agent choose among siblings. Usage must be inferred from the tool 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?

With no annotations provided, the description carries the full load and does well: it discloses that an existing name causes an update, that elevation defaults to stacking on the previous level, that activation switches to an empty plan, and that height means floor-to-floor. These are important side effects beyond the schema.

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

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

Three compact sentences convey the core action, parameter semantics, defaults, and side effects. There is no filler, and the most important information appears first.

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 creation, upsert behavior, defaults, and activation side effects well. Minor gaps remain: the height unit is not explicitly stated as mm, and there is no direct guidance on when to use 'set_active_level' instead of the activate flag. The output schema covers return values, so that burden is offloaded.

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

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

Schema description coverage is 0%, so the description must explain every parameter. It does: name gets an example, elevation is defined in mm with a default behavior, height is described as floor-to-floor, and activate is explained as switching to an empty plan. This fully compensates for the schema gaps.

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

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

The description opens with a specific verb and resource, 'Add a level (storey)', which is unambiguous diffusion from 'set_active_level' and 'copy_level'. It also clarifies the update-on-existing-name behavior, so the tool is recognizable as an upsert rather than a plain creation tool.

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

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

The description gives good context: when adding a level, when changing elevation/height, and when activating a level. However, it does not explicitly mention alternatives like 'set_active_level' for pure switching or 'get_levels' for listing, leaving the decision partially 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?

With no annotations, the description carries the full burden. 'Draw' clearly conveys a mutating creation operation, and the named-layer option adds useful context. However, it does not explain what happens when layer is null, nor does it mention the fit_view side effect, which are meaningful 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?

The description is one front-loaded sentence where every clause adds information: the operation, the geometric primitive, coordinate format, units, and layer option. There is no filler or redundancy.

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

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

For a simple drawing tool with an output schema, the core behavior is understandable and identifiable among many siblings. However, the unexplained fit_view parameter and unspecified layer-null behavior leave gaps that an agent would need to infer or probe.

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

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

Schema description coverage is 0%, so the description must compensate. It explains start and end as [x, y] points in mm and layer as optional, but it leaves fit_view entirely unexplained and does not state that the point arrays must contain exactly two numbers. This is partial, not complete, compensation.

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

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

The description states a specific verb ('Draw') and resource ('straight line between two [x, y] points'), includes units (mm), and notes the optional layer. This clearly distinguishes it from siblings like create_polyline, create_circle, and create_rectangle without requiring schema inspection.

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 it by naming the exact primitive, but it never explicitly contrasts it with alternatives such as create_polyline for multi-segment lines or create_wall_2d for walls. Usage is inferable rather than stated, so it meets the minimum but leaves selection partly 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that lines are 'stacked downwards from position' and that the result is one 'Note' block, which gives some layout behavior. However, it does not disclose what happens with alignment, scale, layer, or height defaults, whether the note is editable later, or what the output schema contains. For a creation tool with no annotations, this is a significant gap.

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

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

The description is a single concise sentence that front-loads the core concept (multi-line note) and the key behavior (stacked downwards from position). It earns its place without fluff, though it could add a bit more detail 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?

Given the tool has 6 parameters, no annotations, and no schema descriptions, the description is not complete enough. It explains the basic layout behavior but omits the meaning of align, layer, scale, and height, and does not mention what the output schema contains. An agent would need to infer or guess the semantics of most parameters.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameters. The description only explains the 'lines' and 'position' parameters implicitly ('lines stacked downwards from position'), but it does not explain 'align', 'layer', 'scale', or 'height'. With 6 parameters and zero schema descriptions, the description leaves most parameter semantics unexplained.

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 verb ('create') and resource ('Note' block), and clarifies that it is a multi-line note with lines stacked downwards from a position. It distinguishes itself from sibling tools like create_text and create_room_label by emphasizing the multi-line 'Note' block concept, though it doesn't explicitly name those alternatives.

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: it is for creating a multi-line note block at a position, which is a distinct use case from other creation tools. However, it does not explicitly state when to use this tool versus alternatives like create_text or create_room_label, nor does it mention any exclusions or prerequisites.

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

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

With no annotations, the description carries the disclosure burden and does useful work: start/end are points on the partition AXIS, thickness defaults to 100 mm, and merge=true fuses touching partitions into one outline. It could add more detail about fit_view or the result, but the key mutating behavior is disclosed.

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

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

The description is compact, front-loaded with the primary action, and every sentence adds information: target layer/units, axis semantics, defaults, and merge side effect. No filler or repetition.

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

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

For a 5-parameter drawing tool with an output schema, the description provides enough operational context: required inputs are explained, optional parameters have defaults, and the main side effect is stated. The missing fit_view explanation and lack of explicit alternative routing keep it from being fully complete.

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

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

Schema description coverage is 0%, so parameter meaning falls entirely on the description. It clarifies start/end as [x,y] axis points, thickness default, and merge behavior, covering most of the 5 parameters; fit_view is the only parameter left undefined.

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: 'Draw one interior partition on layer 'cloisons' (mm).' This clearly separates it from sibling wall/door/window creation tools by object type and target layer.

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 only implied by the phrase 'one interior partition' and the reference 'like create_wall_2d' for merge behavior. The description never explicitly says when to choose this over create_wall_2d, create_wall_loop, or other drawing tools, nor does it state any exclusions.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It usefully adds the mm unit and clarifies that closed=True joins the last point to the first. However, it does not disclose behavior for empty or single-point arrays, coordinate interpretation, or the effect of fit_view.

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 compact sentence that front-loads the core behavior, data format, units, and the key optional flag. Every element earns its place with no filler.

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

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

For a simple drawing tool with an output schema and obvious defaults, the description covers the essential input contract and the closed behavior. The main gaps are layer and fit_view semantics, but these are minor given the schema defaults and the low complexity of the tool.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the points array structure and the meaning of closed, but layer and fit_view are left entirely unexplained beyond their schema titles and defaults. This is only partial coverage of the four 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 names a concrete action ('Draw'), the resource ('polyline'), and the exact input format with units ('[[x, y], ...] points (mm)'). It clearly distinguishes this from sibling tools like create_line or create_rectangle.

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 intended use case of creating a multi-point polyline is implied by the description, but there is no explicit guidance about when to choose this over create_line or create_arc, and no mention of when not to use it. The usage context is inferable but not stated.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does well by explaining that (x, y) is the lower-left corner, that width/height default to 10000 x 8000 mm, that a layer is created on first use, and that omitting a layer leaves the rectangle unfilterable by layer. The only notable omission is the behavior of the fit_view parameter.

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: the primary purpose is stated first, followed by a concise second sentence covering defaults, layer behavior, and return content. Every sentence contributes useful 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 no annotations, the description covers plane, units, coordinate semantics, defaults, layer behavior, and return summary. An output schema exists, so return details need not be spelled out. The only real gap is the unexplained fit_view parameter, which keeps it from being fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for x and y (lower-left corner), width/height (default dimensions), and layer (placement and creation semantics). It does not explain fit_view, which remains ambiguous despite its schema default.

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: 'Draw a 2D rectangle in the open FreeCAD', and adds the XY plane and mm units. This clearly distinguishes it from sibling primitive tools like create_line, create_circle, and create_arc, which draw different shapes.

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

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

Usage is implied by the name and description: this tool is for drawing rectangles. However, it does not explicitly state when to choose this over alternatives or mention any exclusions, such as using create_wall_2d for wall-specific rectangles.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explicitly warns that the tool 'Replaces the previous roof,' and explains how base_height, overhang, pitch, and thickness affect geometry. It does not mention failure cases or what `view` does, but the most important side effect is disclosed.

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

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

The description is compact and front-loaded with the core purpose. It uses inline code formatting and packs substantial semantic detail into a single paragraph. It is slightly dense and could be improved with bullet separation, but almost every clause contributes real 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?

For a 9-parameter tool with no annotations and no schema descriptions, the description covers the geometry well but leaves meaningful gaps: the `view` flag is unexplained, and the effect of `replace: false` is ambiguous given the blanket statement 'Replaces the previous roof.' The presence of an output schema reduces the need to describe return values, but these parameter gaps keep it from being 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 0%, so the description must compensate. It explains kind, pitch range and ridge options, flat thickness, overhang units, points as an alternative to wall outline, and base_height as the starting height. It does not explain the `view` parameter, and `replace` is only indirectly covered by 'Replaces the previous roof.'

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

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

The description names a specific action and resource: creating a roof over walls, with detailed behavior for gable and flat variants. It also clearly distinguishes this tool from siblings like create_slab or create_walls_3d by anchoring on roof-specific geometry.

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 establishes clear context ('Roof over the walls') and internal choice guidance between 'gable' and 'flat', plus when to use `points` vs the wall outline. However, it never explicitly names alternative tools or states conditions like 'use create_slab for floors', so cross-tool routing 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?

With no annotations, the description carries the behavioral burden and does well: it reveals the layer, centering behavior, automatic area computation, return value, and the creation of a BIM room object. It is silent on potential duplicate/overwrite behavior and current-level interaction, but it is far more explicit than typical create-tool descriptions.

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

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

The description is compact and front-loaded, with each sentence earning its place: purpose, input mode, fallback mode, return, and BIM semantics. The parenthetical guidance about create_wall_loop is concise and directly actionable.

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 7-parameter tool with no annotations, the description is mostly complete, but it omits scale semantics and does not explicitly state whether points and area_m2/position are mutually exclusive. The output schema helps with return documentation, but these input ambiguities make the definition not fully complete.

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

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

Schema description coverage is 0%, so the description must define the parameters; it explains points clearly, gives examples for usage and floor_finish, and states the area_m2+position alternative. However, scale is left entirely unexplained and position is only named, so the compensation is incomplete.

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

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

The description names an exact deliverable—a room label consisting of name and area, centered, as a block on layer 'textes'—and thereby clearly separates it from generic text tools like create_text or dimension tools. It also states the extra BIM-object feature, 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?

It provides clear selection context: use points from interior wall faces to get automatic area, or supply area_m2 and position directly; optional usage and floor_finish tie into schedules/IFC. It does not explicitly compare to siblings such as create_text or dimension_room, 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?

With no annotations, the description carries the full burden and provides substantial behavioral detail: it explains the z-range calculation, the default top/floor level, the wall-outline fallback with outward margin, and the replace semantics. It leaves one notable behavior undocumented (the `view` parameter) but otherwise gives a strong picture of what the tool does.

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 dense sentences, each earning its place: the first defines the geometry source, the second defines vertical placement, and the third defines replacement behavior. No filler or repetition, and the core 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?

Given the tool's geometric complexity and zero annotation coverage, the description is reasonably complete but has gaps: `view` is undocumented, units for `margin`/`thickness` are not stated, and the prerequisite that walls must exist when `points` is omitted is only implied. An agent could still invoke it incorrectly without this missing 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 description coverage is 0%, so the description must compensate, and it covers most parameters: points, margin, top, thickness, and replace all receive meaningful explanations. Only `view` is left unexplained, which prevents a perfect 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?

Description clearly states a specific verb ('create') and resource ('floor slab under the house'), and the 'under the house' context differentiates it from related tools like create_roof or create_wall_2d. However, it does not explicitly name or contrast any sibling tool, so it stops short of full sibling 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?

No guidance is given on when to choose this tool over alternatives such as create_roof, create_rectangle, or create_wall_2d. The only usage-related note, 'replace=false to add a second slab,' concerns parameter behavior rather than tool-selection criteria.

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

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

With no annotations provided, the description carries the disclosure burden. It discloses output composition, layer/unit context, the warning rule for steep or narrow stairs, and BIM behavior with mark E1/E2 and material Béton. It does not mention whether the active level must exist or whether repeated calls are additive, but the core behavior is clearly conveyed.

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

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

The description is dense but front-loaded with the main action and layer, and every clause contributes useful parameter or behavior information. It could be easier to scan with structured bullets, but no sentence feels 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?

Given 12 parameters, no annotations, and an output schema present, the description is largely complete: it defines geometry semantics, defaults, the warning rule, and BIM result. The main remaining gaps are fit_view behavior and an explicit active-level prerequisite, which keep it from being 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 description coverage is 0%, so the description must compensate, and it does for most parameters: start, angle, stair_type, turn, width, tread, rise, risers, and landing_at are all explained with units or defaults. However, fit_view is left unexplained and mark/material are only indirectly referenced, so it is not a complete substitute for the schema.

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

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

The description opens with a specific verb and resource: 'Draw a stair on the active level as one block Escalier on layer escaliers', then lists the exact drawn elements. It clearly distinguishes itself from sibling create_stairs_3d by describing 2D plan features such as riser lines, walking line with arrow, and the 1.2 m cut line.

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

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

The description gives clear context: it targets the active level, uses layer 'escaliers', and is intended for plan-style stair drawing with a cut line. It does not explicitly contrast with create_stairs_3d or state when not to use it, so it stops short of full alternative routing.

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

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

With no annotations, the description carries the full disclosure burden. It explicitly reveals a destructive side effect ('Replaces the previous ones of that level') and clarifies the generated geometry ('solid blocks from the floor up to each tread'). It does not discuss reversibility or the view parameter, but the core behavior is transparent.

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

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

The description is two sentences with no filler. It front-loads the action and scope, then adds geometry context and the replacement side effect. Every sentence contributes useful 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?

The main action, scope, geometry, and side effect are all covered, and the presence of an output schema means return values do not need detailed explanation. However, the description leaves the `view` parameter undocumented and does not state prerequisites such as whether the active level must already have a floor, leaving some completeness gaps.

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

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

The only parameter, `view`, is not mentioned anywhere in the description. Schema coverage is 0%, and the description does not clarify whether `view` controls a preview, toggles the 3D view, or determines something else. The default value of `true` is not enough to make this optional parameter meaningful.

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 verb and resource: 'Build the 3D steps of every stair of the active level.' It also defines scope, geometry ('solid blocks from the floor up to each tread'), and a distinguishing side effect ('Replaces the previous ones of that level'), which separates it from sibling tools like create_stair.

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

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

The description gives useful context ('active level') but provides no guidance on when to use this tool versus alternatives. It does not mention the sibling create_stair tool or any exclusion criteria, so an agent must infer the appropriate choice 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?

With no annotations, the description carries the full behavioral burden and does substantial work: it explains that text is real vector geometry, prints in PDF, anchors position on the baseline, defines align/angle semantics, specifies height as capital height in mm with a concrete default conversion, and states the default layer. It does not cover every edge behavior, but it is unusually informative for an unannotated tool.

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

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

The description is compact and front-loaded with the most important fact (single-line vector text that prints), then efficiently maps each key parameter to its semantics. Every clause earns its place, with no filler or repetition.

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

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

Given the 7-parameter schema with only 2 required parameters, the description covers most invocation-critical details: defaults, anchoring, units, and layer behavior. An output schema exists, so return shape need not be described. The main gaps are explicit scale semantics and coordinate-system units, but these are minor for a tool with this much inline guidance.

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

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

Schema description coverage is 0%, so the description must compensate. It explains position, align, angle, height, and layer defaults directly, and the '1:50' reference connects to scale. Only the scale parameter itself is left somewhat implicit, but most parameters receive meaningful clarification beyond the raw 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 single-line text object with real vector geometry that prints in PDF. It gives the resource and key behavioral characteristics, and the 'single-line' qualifier helps separate it from richer text/note tools, though it does not name an alternative sibling explicitly.

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

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

There is no guidance on when to use create_text versus alternatives like create_note or update_text. The description implies text creation but does not state conditions, exclusions, or which sibling tool to prefer for other text needs.

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

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

With no annotations, the description carries the full behavioral burden. It does well by disclosing that the wall is drawn as a closed outline, that overlapping/touching walls are fused, that this fusion should happen before doors/windows, and that the tool returns corners, length, thickness, and outline names. It does not explain the fit_view parameter's behavior, so it is not fully exhaustive, but it is substantially transparent.

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: the first sentence states the core function, followed by concise parameter notes, a timing warning, and a return summary. Every sentence adds value and there is 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?

For a 5-parameter creation tool with no annotations, the description is nearly complete: it covers units, layer, geometry semantics, defaults, merge behavior, timing constraints, and return values. The missing fit_view behavior and lack of any mention of errors or coordinate system leave a small but real gap, so it is not a 5.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that start/end are [x,y] points on the wall axis, explains the merge default and its fusion behavior, and gives the effective default thickness of 200 mm. The only parameter left unexplained is fit_view, whose schema default is true but whose behavior is never described.

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 ('Draw'), a specific object ('one straight wall as a closed outline'), and a target layer ('murs' with mm units). The phrase 'one straight wall' distinguishes it from sibling tools like create_wall_loop and create_walls_3d, so an agent can tell what this tool is for.

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

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

The description gives useful context by warning that merging should happen before placing doors/windows, and by explaining when merge will not apply. However, it never explicitly says when to choose this tool over siblings such as create_partition_2d or create_wall_loop; the differentiation is only implied by 'one straight wall'.

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

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

With no annotations, the description carries the burden of disclosing side effects and behavior. It does this well by stating that it draws outer and inner outlines on layer 'murs' and returns axis_points plus interior bounds and area. It also clarifies that thickness defaults to 200 mm, which is useful because the schema default is null. It does not mention fit_view behavior, but overall it is transparent enough.

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 well-structured: purpose first, then parameter semantics, then side effects and return value. Each sentence adds necessary information and there is no filler or restatement of the tool name.

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

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

For a 4-parameter tool with an output schema, the description covers points, alignment, thickness, the drawing side effect, the target layer, and the key return value. The only gap is fit_view, but since it defaults to true and is likely a viewport nicety, the description is nearly complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains points as polygon vertices in mm and in order, defines each alignment value with concrete examples, and states the thickness default. The only parameter it fails to describe is fit_view, which prevents a perfect 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 a specific verb and resource: 'Draw a closed run of walls' with 'clean mitered corners.' This clearly distinguishes it from open-wall creation tools like create_wall_2d or create_line, and the 'house perimeter' example reinforces the intended loop use case.

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

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

The description gives alignment advice ('use this for house 12 x 8 m' with outer alignment), but it never says when to choose create_wall_loop over create_wall_2d, create_partition_2d, or create_rectangle. There is no explicit when-to-use or when-not-to-use guidance for tool 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?

With no annotations, the description carries the behavioral disclosure burden and does so thoroughly: it states the origin (z=0), units (mm), layer selection, door/window cutting rules, and the destructive 'Replaces the previous 3D walls' side effect. It also discloses the return value (volume and z range).

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 packs all essential behavioral and parameter information into three focused sentences with no filler. The main action is front-loaded, followed by cutout details, replacement warning, and return value.

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

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

The description covers the core transformation, parameters, side effects, and return type, so an agent can likely call the tool correctly by relying on defaults. It is slightly incomplete because 'view' is not explained and prerequisites (existence of 2D wall layers) are only implied, not stated.

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

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

Schema coverage is 0%, but the description compensates for height, partitions, door_height, window_sill, and window_height by explaining their role and units. Only 'view' is left unexplained; the schema only provides a default, so an agent would not know what setting it to false does.

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 ('Extrude the 2D walls ... into solids'), names the exact layers and parameters, and clearly distinguishes itself from 2D wall creation siblings by describing the 3D extrusion and cutout behavior. The replacement behavior also clarifies its role among wall-related 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?

The description implies the tool is used after 2D walls exist on the named layers and when a 3D extrusion with door/window openings is needed. It does not explicitly state when to prefer create_walls_3d over alternatives like merge_walls or create_wall_2d, nor give exclusion criteria.

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

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

With no annotations, the description carries the full burden and does disclose key behavior: it cuts a physical opening in the wall, draws jamb/frame/glazing lines, creates a BIM object, and warns if no wall is found. These are meaningful effects beyond a generic 'create window'. It could still state whether the operation is destructive/irreversible or what happens after the warning, but the disclosed behavior is substantial.

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-loads the purpose, and then groups defaults and geometric parameters without wasted prose. Line breaks and inline parenthetical defaults make it easy to scan.

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

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

For a 9-parameter tool with no annotations, the description is unusually complete: it explains the wall-cutting action, the shared BIM conventions, the exact center/axis semantics, and a warning condition. The missing fit_view explanation and the lack of explicit alternative routing are the main gaps; output schema existence reduces the need to document 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?

Input schema coverage is 0%, and the description compensates by explaining eight of the nine parameters with domain-specific meaning, units (mm), and defaults (height 1200, sill 900, width 1200, wall_thickness 200, material PVC). The only unexplained parameter is fit_view, whose name and boolean default may be enough in some contexts but is not described.

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 action—'Cut a window opening in the wall and draw the 2D window'—identifying both the resource and the exact 2D elements created. It is clearly a window-creation tool and is visually distinct from siblings like create_door_2d or create_wall_2d. The 'BIM object like the door' comparison also signals the model of object being created.

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 intended context is clear: use this tool when a 2D window opening needs to be cut and drawn in a wall Alert. The description also implies a prerequisite by warning if no wall is found at the position. It does not explicitly name alternatives or state 'for a door use create_door_2d', but the context is strong enough for an agent to infer when to call 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?

No annotations are provided, so the description must disclose behavioral traits. It does mention that deleting a block deletes its parts, which is a useful side-effect. However, it does not disclose whether deletion is permanent, reversible, or requires permissions, nor does it describe error handling or effects on dependent objects (e.g., dimensions, texts). The description carries minimal burden but falls short.

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 one sentence, efficient and free of fluff. The key detail about blocks is front-loaded in the parenthetical. It is appropriately concise for its 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?

With an output schema present, return values are covered. However, the tool is a destructive operation (delete) and lacks annotations to communicate safety. The description should provide more context about irreversible consequences, prerequisites (e.g., object must exist), and interaction with nested objects (only blocks are mentioned). It is adequate but minimal for a mutation tool.

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

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

The schema has one parameter (names) with no description coverage (0%). The description does not explain what 'names' refers to (object names? layer names?) or how to specify multiple objects. However, with only one simple array parameter, the risk is low. The description adds a hint about blocks, but it does not clarify the parameter format. Given the simplicity, a baseline 3 is appropriate.

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

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

The description states a clear verb ('Delete') and resource ('objects'), and it adds a clarifying detail about block deletion cascading to parts. However, it does not differentiate from sibling tools like move_object, copy_object, or clear_3d, which are also mutation tools. The parenthetical is useful but the core purpose is generic.

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

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

There is no guidance on when to use this tool versus alternatives. Notably, sibling tools like clear_3d (clear the 3D view) and get_objects (query objects) exist, but the description does not clarify that this tool is for removing objects from the model, not clearing the view or other operations. No exclusions or conditions are provided.

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

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

With no annotations, the description carries the behavioral burden and does add useful geometry semantics: the dimension is parallel to p1-p2 and offset > 0 places it left of the direction p1->p2. It does not disclose whether the tool creates/updates a drawing object, what coordinate dimensions p1/p2 require, or how unit/scale affect the result, leaving notable gaps.

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

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

A single front-loaded sentence conveys the core behavior and the key offset convention with no filler. Every phrase contributes meaning.

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

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

The tool has five parameters and zero annotation coverage; the terse description omits prerequisites, the coordinate dimensionality of p1/p2, scale/unit behavior, and placement/creation context. An output schema exists, but the description still under-specifies what an agent needs to invoke this tool correctly among many dimension siblings.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to p1/p2 (true distance endpoints) and offset (left side when positive), but it leaves unit and scale semantics to their schema defaults/enums, and it does not specify the required array length or coordinate system for the point 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 states a specific geometric operation: dimensioning the true distance p1-p2 with a line parallel to that segment. This clearly identifies the tool's purpose and distinguishes it from horizontal/vertical dimension siblings, though it never names an alternative.

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

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

Usage context is implied by 'line parallel to it' – an agent can infer this tool is for dimensions aligned with p1->p2 rather than axis-aligned dimensions. However, no explicit when-to-use, when-not-to-use, or alternative tool names are provided, so the guidance is inferred rather than stated.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It states the tool draws an arc (visual output) and computes the smaller angle, which is useful. However, it doesn't disclose whether the tool modifies existing geometry, requires specific coordinate systems, or has side effects like creating a new object in the document. The description adds some behavioral context but not comprehensive.

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 front-loads the core purpose (angle at vertex) and includes the key behavioral detail (smaller angle, drawn as arc). Every word earns its place; there is 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 has 5 parameters, 3 required, and an output schema exists. The description explains the geometric meaning of the three required parameters but omits 'scale' and 'radius', which likely control the visual size of the arc. Given the output schema exists, return values are covered, but the missing parameter semantics and lack of usage guidance make the description incomplete for an agent to call the tool correctly without additional inference.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. The description mentions 'vertex', 'p1', and 'p2' implicitly by explaining the angle is at the vertex between rays to p1 and p2, but it doesn't explain the 'scale' or 'radius' parameters at all. The description adds meaning for the three required parameters but leaves two optional parameters completely unexplained, which is a significant gap.

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: it creates an angle dimension at a vertex between two rays, drawn as an arc. It uses a specific verb ('Angle at...') and identifies the resource (dimension). It doesn't explicitly differentiate from sibling dimension tools like dimension_vertical or dimension_aligned, but the geometric definition (angle between rays) is distinct enough to infer its purpose.

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: it's for dimensioning an angle between two points relative to a vertex. However, it doesn't explicitly state when to use this tool versus alternatives like dimension_linear or dimension_aligned, nor does it mention any prerequisites (e.g., needing an existing drawing or active view). The context is clear but not fully elaborated.

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

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

With no annotations provided, the description carries the full disclosure burden. It does add genuine behavioral context beyond the schema: the coordinate convention (x values measured along the face at y=edge), the offset sign convention (>0 above, <0 below), and the second-line overall dimension. However, it omits whether the tool mutates the document by inserting a drawing object and what effect default values (offset=null, overall=true) have on output.

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 dense sentences with zero filler; the purpose is front-loaded and the axis/offset semantics follow compactly. The style is telegraphic but efficient. It could be slightly more readable, but every phrase 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 7-parameter tool with no annotations and 0% schema coverage, the description is only partially complete. Output schema exists so return values need no explanation, but the description leaves unit/scale semantics, the behavior of offset=null, and how to choose this over the sibling dimension tools unaddressed. An agent could call it correctly for the common horizontal case but would be guessing on non-default options.

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

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

Schema description coverage is 0%, so the description must compensate for 7 parameters. It adds real meaning for axis, edge, offset, and coordinates (axis-dependent x/y interpretation and offset sign), but says nothing about unit (m/cm/mm), scale (default 50), or overall (default true). Roughly half the parameters remain semantically unexplained, which is insufficient at 0% 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 first sentence, 'A chain of consecutive dimensions plus the overall dimension on a second line,' states a specific construct with a clear resource (a dimension chain with an overall dimension) and an implied verb (create/draw). This distinguishes it from the many single-dimension siblings (dimension_linear, dimension_horizontal, etc.) by the 'chain' concept, though it does not name them explicitly.

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

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

No guidance is given on when to use this tool versus the ~7 sibling dimension tools (dimension_vertical, dimension_linear, dimension_aligned, dimension_angle, dimension_exterior, dimension_room, dimension_horizontal). There are no exclusions, prerequisites, or alternative-routing statements — the axis explanation is geometry, not usage context.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains the automatic behavior, the affected layer, the elements included, and that it returns stops per side. However, it does not disclose side effects such as whether existing dimensions are replaced, where the dimensions are placed, or any unit/scale implications.

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 filler. It front-loads the core purpose, then adds prerequisites and return value compactly. Minor loss for packing behavior details densely, but overall well-structured.

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

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

Given the large sibling set of dimension tools, the complete lack of parameter guidance, and no annotations, the description is not fully actionable. The prerequisite and return value are helpful, but an agent still lacks enough information to choose this tool confidently or set parameters 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 description coverage is 0%, so the description must compensate for the three parameters (unit, scale, offset). It does not mention any of them or explain how they influence the dimensioning. The schema only provides names, defaults, and an enum, leaving the agent without meaningful parameter semantics.

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

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

The description states a specific action and resource: automatic exterior dimensioning on all 4 wall sides for layer 'murs'. It specifies what the dimension chain includes (corners, door/window openings, partitions, overall dimension), making it clearly distinct from sibling dimension tools like dimension_chain or dimension_horizontal.

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

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

It gives a clear prerequisite ('Draw walls, partitions, doors and windows first'), which is useful usage guidance. However, it does not explain when to choose this tool over the many sibling dimension tools, nor does it provide exclusion criteria or alternative routing.

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

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

With no annotations, the description carries the full behavioral burden. It explains the offset parameter's direction and default value, and mentions the output block on layer 'cotations'. However, it does not disclose coordinate system assumptions, side effects, or prerequisites, and the offset default expression ('600 at 1:50, i.e. 12 mm on paper') is somewhat cryptic.

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, front-loads the purpose, and packs useful information into two sentences. However, the offset default phrasing is unclear and could be simplified without losing meaning.

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

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

Given no annotations and 0% schema descriptions, this description is incomplete. It lacks usage guidance against the many dimension siblings, leaves unit and scale unexplained, and the offset default is confusing. The presence of an output schema mitigates the need to describe return values, but the overall gap is still significant for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains offset semantics in some detail but does not explain p1/p2 beyond calling them [x,y] points, nor does it explain the unit or scale parameters. With 5 parameters, this leaves a major gap for an agent trying to invoke the tool correctly.

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 'Horizontal dimension between two [x, y] points (mm).' This identifies a specific verb and resource, and distinguishes it from vertical, aligned, and other dimension siblings. The added detail about a 'Cote' block on layer 'cotations' further clarifies the expected output.

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 name and description imply usage for horizontal dimensions, but no explicit guidance is given on when to prefer this tool over the many sibling dimension tools (dimension_vertical, dimension_aligned, dimension_linear, etc.). No exclusions or alternative conditions are provided, leaving the agent to infer from 'Horizontal' alone.

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

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

With no annotations, the description carries the full burden. It discloses the direction derivation behavior (from points or explicit direction), but does not mention that this creates a dimension entity, any prerequisites, coordinate expectations, 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 concise and front-loaded with the core concept, but it is under-sized for a tool with six parameters and no annotation support. It avoids waste, yet sacrifices necessary detail.

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

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

Given no annotations, low schema coverage, and several dimension siblings, the description is incomplete. It omits parameter meanings, required setup, and behavior context, though an output schema exists to cover 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?

Schema description coverage is 0%, so the description must explain parameters. It minimally covers p1/p2 as 'points' and direction as 'horizontal'/'vertical', but unit, scale, and offset are completely unexplained, leaving most of the 6 parameters ambiguous.

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 that the tool creates a horizontal or vertical dimension from points or an explicit direction. This distinguishes it from aligned, angle, and other dimension siblings, even though it lacks an explicit verb like 'create'.

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

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

The description gives no guidance on when to use this tool versus dimension_horizontal, dimension_vertical, or dimension_aligned. It implies a direction can be auto-derived or set, but does not name alternatives or exclusion criteria.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does add useful behavioral context: dimensions are drawn inside the room, points must be wall faces rather than axes, and the bounding box is used. It omits important details such as how many points must be supplied, how unit/scale/offset affect the drawing, and what side effects or document changes occur.

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 short, front-loaded with the outcome, and includes no filler. The key qualifiers about wall faces and the bounding box are present in just a few lines. The repeated use of 'clear' creates mild ambiguity but does not make the text bloated.

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

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

This is an adequate but incomplete definition for a tool with no annotations and no parameter descriptions in the schema. It explains what the tool dimensions and where the dimension is placed, and the output schema covers return values. However, the undocumented parameters and lack of guidance about points count/order and tool selection leave noticeable gaps for an agent trying to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameters. It only explains 'points' as the room's clear corners on wall faces, which is genuinely helpful. Unit, scale, and offset are not described at all, and the structure, ordering, and expected count of the points array are left to inference from names and schema defaults.

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 identifies a specific function: generating the clear interior width and depth dimensions of a room, drawn inside it along the bottom and left sides. The extra details about wall faces vs. axes and using the bounding box help differentiate it from generic sibling tools like dimension_horizontal, dimension_vertical, and dimension_exterior. Some ambiguity remains in the word 'clear,' which could be read as clearance or as a verb.

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 room-level width and depth dimensions and states where the dimensions are drawn. However, it never explicitly explains when to prefer this tool over dimension_aligned, dimension_chain, or dimension_exterior, and it gives no exclusion conditions. An agent must infer usage primarily from the tool name and the word 'room.'

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the offset direction ('offset > 0 puts the line to the right, < 0 to the left') but does not disclose what the tool returns, whether it mutates the document, how it handles invalid points, or how the vertical dimension is positioned relative to the points. The offset behavior is useful but incomplete.

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

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

The description is a single concise sentence that front-loads the core purpose and then adds the offset rule. Every word earns its place, though it could be slightly more structured by separating the offset behavior into its own sentence.

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 5 parameters, no annotations, and an output schema, the description is too thin. It does not explain the coordinate format for p1/p2, the meaning of scale, the default unit behavior, or what the output schema contains. An agent would need to inspect the schema and guess at conventions, which is risky for a drawing tool.

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

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

Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter documentation. It only explains the offset parameter's sign convention; p1, p2, unit, and scale are left entirely to the schema's bare type/enum definitions. The description adds minimal value beyond the schema for most 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 states a specific verb and resource: it creates a vertical dimension between two points. It distinguishes itself from siblings like dimension_horizontal and dimension_aligned by the 'vertical' qualifier, though it doesn't explicitly name alternatives. The offset direction rule adds useful specificity.

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 defining the tool's function and the offset sign convention, but it does not explicitly state when to choose this over dimension_aligned, dimension_linear, or dimension_horizontal. No exclusions or alternative conditions are given, leaving the agent to infer from the name and sibling list.

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

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

With no annotations, the description carries the behavioral burden and does substantial work: it discloses output scale, units, layer inclusion, editable text, and the no-sheet-needed behavior of model mode. It also mentions overwrite and path rules, though the exact semantics are deferred to export_schedule rather than spelled out.

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

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

The description is compact and front-loaded, with each mode explained in a separate clause and the cross-reference to export_schedule kept to one sentence. The parenthetical layer list adds useful domain detail without bloating the text.

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 core export behavior and the two modes are well covered, and an output schema exists so return-value details are not required. The main gaps are the semantics of the page parameter and the exact path/overwrite defaults, both of which rely on external knowledge of export_schedule rather than being self-contained.

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 mode parameter is well explained, including its default and the meaning of both enum values. However, the page parameter is only implied by the sheet-mode explanation, and path/overwrite behavior relies on a reference to export_schedule rather than being described here, which is thin given 0% schema description 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 opening sentence names the exact operation and artifact ('Export a DXF'), and the two modes specify what is produced: a 1:1 mm CAD plan with layers and editable text vs. the scaled TechDraw sheet. This clearly distinguishes it from sibling export tools like export_svg, export_pdf, and export_ifc without requiring schema inspection.

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

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

The description gives concrete use context for each mode: model mode is 'to work in a CAD program' and sheet mode exports 'the TechDraw page as drawn on paper (scaled)'. It also signals consistency with export_schedule for path/overwrite behavior, but it does not explicitly state when to prefer export_dxf over the other export siblings.

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

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

With no annotations provided, the description carries the burden of explaining behavior. It discloses the output content, optional roof behavior, default file path, and overwrite/path behavior via reference to export_schedule. However, it does not explain failure conditions, required document state, or what happens when overwrite is false or true beyond that reference.

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 efficiently front-loaded: the first sentence states the core purpose and scope, the second gives the default path, and the third points to shared rules. Every clause adds relevant information 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?

For a 9-parameter export tool with no annotations and no parameter descriptions in the schema, the description is moderately complete. It explains the main output, contents, default path, and reuse of export_schedule's rules, but it leaves several parameters and their units/effects underspecified, and relies on an external sibling definition for overwrite behavior.

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

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

Schema description coverage is 0%, so the description must compensate, but it only partially explains roof, path, and overwrite behavior. Parameters such as overhang, roof_pitch, wall_height, slab_thickness, author, and project_name are left to their schema titles and defaults, with no units or clarifying semantics.

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

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

The description clearly states a specific action and resource: 'Export the building to an IFC4 file (BIM)'. It adds a detailed, meaningful list of what is included, which distinguishes it from other export tools in the sibling set like export_svg, export_pdf, and export_schedule.

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 IFC4/BIM framing makes the intended use unmistakable, and the reference to 'path rules and overwrite as export_schedule' connects it to a sibling export tool's conventions. It does not explicitly state when to avoid this tool or prefer a different export tool, but the format and content make the use case 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the default path behavior, vector/print-size output, and that overwrite rules follow export_schedule. However, it doesn't mention whether the operation is destructive, what happens on failure, or whether it requires an active document/sheet, which would be useful for a file-exporting tool.

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 states the core action, format, and size in the first sentence, then covers path defaults and return value in two more sentences. Every sentence earns its place with no 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?

The tool has 3 optional parameters, no annotations, and an output schema (which presumably documents the return value). The description covers the path default and overwrite convention, but the 'page' parameter is unexplained, and there's no mention of prerequisites (e.g., an active sheet) or failure behavior. It's adequate for a simple export but has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'path' parameter's default behavior and mentions 'overwrite' rules via export_schedule, but it doesn't explain the 'page' parameter at all. The description adds some meaning beyond the bare schema but leaves one parameter undocumented.

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 exports a sheet to PDF, specifies vector format and print size, and mentions the default path behavior. It distinguishes itself from export_schedule and export_svg by referencing export_schedule for path rules, though it doesn't explicitly name the sibling alternatives.

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 context on when to use this tool (exporting a sheet to PDF) and references export_schedule for path rules, implying a shared convention. It doesn't explicitly state when not to use it or name alternatives like export_svg or export_dxf, but the PDF-specific purpose is clear enough for an agent to select it appropriately.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly states the file format, default output location, path allowlist, and the overwrite=true requirement for replacing existing files. It does not describe error behavior when path constraints are violated, but the main safety-relevant behavior is covered.

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 dense sentences with the core purpose front-loaded and operational constraints following. There is no filler, tautology, or restatement of schema fields; every clause adds information an agent needs.

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 4-parameter export tool with no annotations, the description covers path and overwrite behavior well. Yet it omits explanation of the required 'kind' argument and optional 'level' argument, and it does not address when to choose this tool over sibling export tools. These gaps make the definition functional but not fully self-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 description coverage is 0%, so the description must compensate for parameter meaning. It adds useful semantics for path (default and allowed locations) and overwrite (replacement only when true). However, it does not explain the required 'kind' parameter or the optional 'level' filter beyond the raw enum values in the schema, leaving a meaningful semantic gap.

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 'Save a schedule as a CSV file', giving a specific verb, resource, and output format. The parenthetical '(semicolon-separated, opens in Excel/LibreOffice)' makes the deliverable concrete. It does not explicitly differentiate from sibling export tools such as export_pdf or export_dxf, though the CSV format makes the distinction largely inferable.

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 useful operational context: default path next to the FreeCAD document, restricted allowed directories, and the overwrite=true requirement. However, it never explicitly states when to prefer this tool over get_schedule or the other export_* siblings, so selection guidance is only implied by the CSV format and tool name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions a 'default path as export_pdf' but does not explain what that path resolves to, what happens when overwrite is false, or whether the operation modifies the document or only creates a file.

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 with no filler. The core purpose is front-loaded, though 'Default path as export_pdf' is terse and relies on knowledge of another tool.

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

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

For an export tool with three parameters and no annotations, the description is incomplete. Key operational details such as overwrite behavior, which page is exported, and the actual default path are missing or only vaguely referenced.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameters. The only parameter-related hint is 'Default path as export_pdf,' which partially addresses 'path' but leaves 'page' and 'overwrite' entirely unexplained.

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

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

The description clearly states a specific action ('Export'), a resource ('the sheet'), and an output format ('SVG file'). It distinguishes itself from sibling tools like export_pdf, export_dxf, and export_ifc by naming SVG as the target format.

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 usage context is implied by the format name: use this tool when an SVG export is needed. However, it does not explicitly say when to prefer this over export_pdf/export_dxf/export_ifc, nor does it describe any exclusions or prerequisites.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It mentions the straight-line restriction and the general result, but it does not state whether the target is mutated in place, what happens when no intersection exists, or whether the operation is destructive or reversible. For a geometry modification tool this is a meaningful 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 one sentence with no filler, and the core verb and object are front-loaded. The parenthetical is compact but slightly awkward, mixing a parameter name with an enum value and reducing immediate clarity.

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 three-parameter geometry mutation with no annotations, this description leaves important gaps: parameter semantics, mutation behavior, edge cases, and usage context. An output schema may document return values, but that does not help an agent know how to construct a valid `target` and `boundary` or what to expect when the extension is impossible.

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

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

Schema description coverage is 0%, so the description must compensate for the missing parameter docs. It partially does by implying `target` is a straight line and `boundary` is the thing to meet, and it connects `end` to the enum values. However, it never explicitly defines `target`, does not explain what "nearest" means relative to the line's endpoints, and provides no detail on how the entities are referenced.

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 an operation (extend), a resource (a straight line), and a termination condition (until it meets `boundary`). However, the parenthetical "end = "start", "end" or "nearest"" is ambiguous because "end" is both the parameter name and one of the enum values, and it does not explicitly distinguish target from boundary. Still, an agent can tell this apart from trimming or offsetting.

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

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

There is no guidance about when to use `extend` rather than sibling tools like `trim`, `offset`, or the line-creation tools. No prerequisites or selection context are provided, so the agent must infer the intended use case entirely from the one-line 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?

With no annotations provided, the description correctly carries the full behavioral burden. It discloses several non-obvious traits: openings remain empty while outlines are rebuilt around cuts, the style enum semantics (solid = poché with tone black/grey, hatch = diagonal at angle), and that a call replaces the fill/hatch drawn by a prior fill_walls call for the same layers. This is meaningful behavioral context beyond the schema, so a 4; it falls short of a 5 only because it leaves scale's effect and any output-schema specifics undisclosed.

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

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

The description is two focused sentences, front-loaded with the primary purpose before diving into style semantics and replacement behavior. Every clause carries information — no filler or repetition of the tool name. It is slightly denser than strictly necessary, but well-organized and efficient, so a 4.

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 moderately complex (5 optional parameters, two enum-driven, output schema present). The description covers the purpose, both style modes, the replacement semantics, and the layer scoping, which is most of what an agent needs to call it correctly. The presence of an output schema relieves the description of documenting return values. The main completeness gap is the unexplained 'scale' parameter and the lack of explicit sibling differentiation, so a 4.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for four of five parameters: it explains 'layers' (selects from 'murs'/'cloisons'), 'style' (solid vs hatch), 'angle' (hatch angle), and 'tone' (black/grey poché). However, 'scale' is entirely unexplained, which is a real gap given nothing else documents the schema. Covering most but not all parameters at 0% coverage earns a 3, not higher.

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 verb and resource: 'Fill (or hatch) the walls of the active level in one call', and details the core behavior — rebuilding wall outlines around doors and windows while keeping openings empty. It explains both styles (solid poché, diagonal hatch). It doesn't explicitly distinguish itself from the closely-related siblings create_hatch and create_fill, but the 'active level' + layers scoping makes the purpose materially clear, so a 4 is warranted.

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 usage context — filling walls of the active level in one call for layers 'murs'/'cloisons' — but provides no explicit when-to-use versus alternatives guidance, nor any exclusions. Given siblings like create_hatch, create_fill, and merge_walls exist in the same family, naming when this should be preferred would help. The guidance is effective but left to inference, so a 3.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It states the visible_only behavior (ignores hidden layers and objects), the optional layer scoping, and the output units in mm. This is solid coverage for a read-only bounding-box query, though it does not describe edge cases like an empty 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?

Two tight sentences front-load the key output fields and units, then add the parameter behavior. Every clause earns its place with no filler or redundancy.

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

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

For a simple getter with an output schema present, the description covers the main calling details: scope, visibility filter, and units. It is slightly terse on default layer behavior, but overall an agent has enough to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It does explain visible_only explicitly and gives context for layer via 'whole drawing (or one layer)', but it does not specify the expected layer-name format or the exact meaning of null. This is useful but not exhaustive.

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

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

The description clearly identifies the tool's output: a bounding box for either the whole drawing or a single layer, with x/y min/max, width, and height in mm. It is specific about the resource type and scope, though it does not explicitly compare itself to sibling tools like get_object_geometry.

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

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

The description implies usage through the layer and visible_only parameters, but it provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions or prerequisites. An agent must infer the appropriate context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully states that the tool reports on the active document and enumerates the returned fields, but it does not explicitly state read-only behavior, error conditions, or what happens when no active document exists.

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

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

The description is a single concise sentence with no filler words. It front-loads the key concept 'Active document' and then efficiently lists the output 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?

For a zero-parameter getter with an output schema, the description is largely complete: it identifies the active-document context and enumerates the main returned data. It doesn't explain how the active document is determined or error behavior, but that is a minor gap 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?

The tool has zero parameters, and the schema confirms this with 100% coverage. The baseline for a zero-parameter tool is 4, and the description adds helpful context about what the tool returns even though no parameter semantics are needed.

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

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

The description clearly identifies the tool as returning information about the active document and lists the specific contents: name, file, unit, object count, layers, and bounds. It lacks an explicit verb like 'returns' and doesn't differentiate itself from sibling getters such as get_layers or get_bounds, but the resource and purpose are 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?

No guidance is provided about when to call get_document versus sibling tools like get_layers, get_bounds, or get_objects. There are no usage conditions, exclusions, or references to alternatives, so an agent is left to infer when this tool is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reads as a list of returned fields rather than a statement of behavior; it does not explicitly say the operation is read-only, whether it can fail, or whether any filtering/scope semantics apply. The 'get_layers' name implies retrieval, but the description itself adds no behavioral transparency.

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

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

The description is a single, lean phrase with no filler words, and it front-loads the key attributes. It is appropriately sized for a simple getter, though it would be slightly clearer as a full sentence like 'Get all layers with...'

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 getter with an output schema present, the description is nearly sufficient for invocation. However, it is missing an explicit scope statement (all layers vs. active layer) and any usage context, so an agent may not know exactly when this tool is the right choice.

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 zero parameters, so there is nothing for the description to explain beyond what the empty schema already shows. The description correctly omits parameter details; the baseline for a zero-parameter tool 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 identifies the resource (layers) and the attributes returned (object count, visibility, line width, colour, style). The verb is only implied by the tool name 'get_layers', and it does not explicitly distinguish itself from siblings, but the resource is specific and clear enough for an agent to understand what it 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 gives no guidance on when to use this tool versus alternatives like get_levels, get_objects, or get_wall_types. It does not state whether this returns all layers, the active layer, or layers in the current view, nor does it mention any exclusions or prerequisites.

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

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

With no annotations, the description carries the burden of explaining behavior. It indicates a retrieval operation and what data is returned, but it does not explicitly state that the tool is read-only or side-effect free, nor does it mention any permissions or limitations. This is a moderate gap for a getter with no annotation coverage.

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, compact phrase with no filler or redundancy. It front-loads the key information about what levels contain and which one is active, earning its place fully.

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 getter with an output schema present, the description is largely complete: it identifies the core return fields and the active-level state. It could be strengthened with usage context or an explicit read-only statement, but the low complexity means nothing critical is missing for invoking it correctly.

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

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

The tool has zero parameters and the schema is empty with 100% coverage, so the baseline is 4. The description adds no parameter syntax, which is correct since there are none to document; it appropriately focuses on the result content.

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 names the resource ('levels') and the specific fields returned ('name, elevation, height'), plus the active level. It is specific and easy to understand, though it lacks an explicit verb and does not directly contrast with sibling tools like create_level or set_active_level.

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

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

There is no guidance about when to use this tool versus alternatives such as get_schedule, get_wall_types, or set_active_level. The intended use is only implied by the tool name and output description, not stated explicitly.

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