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

With no annotations, the description carries the behavioral disclosure burden. It reveals key side effects such as 'a new internal line on the base marks each sewn edge', explains the optional reverse patch shares the same stitch line, and provides practical layer placement guidance. It does not discuss permissions, idempotency, or failure modes, but the additive behavior is well characterized.

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 opens with a clear purpose sentence and then provides a compact, well-organized Args block. Every parameter explanation earns its place, and the extra examples clarify tricky cases like reverse_layer and sewn_lines without padding.

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 output schema and no annotations, the description is nearly complete: it covers defaults, edge cases, and relationships between parameters. The main omissions are the return value/shape and possible error conditions, but the invocation semantics are thoroughly specified.

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 compensates fully by explaining all nine parameters, including defaults, coordinate meaning, edge indexing for sewn_lines, layer semantics, and the relationship between reverse and reverse_layer. This goes well beyond the schema's bare type information.

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

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

The description uses a specific verb and resource: 'Add an appliqué patch on a piece' and explains the patch is sewn in place. It also adds distinguishing detail about optional front/reverse patches, so an agent can infer the tool's role, though it does not explicitly differentiate from sibling tools like add_topstitch or add_internal_shape.

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 is implied by the first sentence: use this when adding an appliqué patch to a piece. However, there is no explicit guidance about when not to use it or how it compares to sibling tools such as add_internal_shape, add_hem, or add_topstitch.

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 disclosure burden. It does explain the key behavior—cloth collision—and the replace_avatar side effect, but it does not mention persistence, return behavior, or whether adding a box has any other scene-level consequences.

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

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

The description is concise and well-structured. The main behavior is front-loaded, and the Args section is compact with every line adding 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?

For a simple additive tool with only three parameters and no output schema, the description covers the required invocation details. It could be more complete by stating what happens after adding the box (e.g., whether it returns an ID and whether multiple boxes are allowed), but the core calling context is present.

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

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

Schema description coverage is 0%, but the description fully compensates by documenting all three parameters: center coordinates in mm, size dimensions in mm, and replace_avatar's boolean effect. The array shapes are clearly specified, which is essential for correct invocation.

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: 'Add a box that cloth collides with.' The examples (table, shelf, bed, window sill) clarify its intended purpose, and the box-vs-rod distinction separates it from sibling tools like add_rod.

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 for when this tool is appropriate by listing example box-like furniture objects. It does not explicitly contrast with add_rod or import_collision_object, but the usage context is sufficiently 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?

No annotations exist, so the description carries the full disclosure burden. It conveys that a new fabric is created from a file but does not mention side effects such as whether the project must be saved, whether duplicates are allowed, or what happens on file load failure.

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, front-loaded with the primary action and followed by a terse parameter explanation. There is no filler or redundant elaboration.

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

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

For a simple one-parameter tool this is usable, but it omits common prerequisites (e.g., an open project, file accessibility) and any behavioral context such as duplicate handling. It is adequate but not complete, especially with no annotations or output schema to fill the 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 schema only provides a title 'File Path'; the description adds the crucial requirements that the path must be absolute and must point to a .zfab or .jfab file. This is meaningful semantic information for the single required parameter.

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

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

States the action ('Add a new fabric') with the exact resource and input format (.zfab/.jfab). It is clear what the tool does, though it does not explicitly name sibling tools such as replace_fabric or apply_fabric_json to differentiate usage.

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

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

No when-to-use guidance or alternative tool recommendations are provided. It does not explain when to choose this over replace_fabric, apply_fabric_json, or import_file, leaving the choice 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?

With no annotations, the description carries the full behavioral burden and does most of it well: it discloses that geometry is added on the reverse side, that the cloth cannot be folded (only ~20 degrees), and that overlapping strips on the same layer crumple. It does not state permissions, undo/persistence behavior, or whether the operation is reversible, which keeps it short of a 5.

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

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

Purpose is front-loaded and the Args block is ordered, so it is easy to scan. It is slightly bloated by parenthetical digressions (the fold-angle aside) that delay the argument list, but nearly every sentence carries usable 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 six-parameter mutation tool with no annotations and no output schema, the description covers what is produced ('the doubled fabric at the edge') and how placement works, which is sufficient to call it correctly. It stops short of covering failure modes or undo/persistence, a minor gap given the richness elsewhere.

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 fully compensate, and it does: it documents all six parameters, including units for width (mm), the source of line_index (get_pattern_geometry / view_patterns), the default for fabric_index, and the default meaning of place_flat. The layer parameter is explained in unusual depth, including -1/1 axis meaning and the -2 convention for crossing hems.

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+resource ('Hem a straight edge') and then explains the mechanism: a turned-back strip sewn along the edge and a new hem line, producing doubled fabric at the edge. This is specific enough to separate it from neighboring construction tools like add_applique or make_rod_pocket without opening any schema.

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

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

The description implies the use case (hemming a straight outline line) and gives a conditional rule for place_flat ('set False and place it yourself for pieces on an avatar'), but it never names an alternative tool or states explicitly when this should be chosen over them. Usage context is present but 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?

With no annotations, the description carries the behavioral burden and handles it well: it specifies pattern coordinates in mm, point type semantics (0, 2, 3), closed behavior, and even notes that CLO accepts points outside the piece. It does not discuss reversibility or validation errors, but the draw action and coordinate rules are clearly 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 action, and uses an Args list that maps cleanly to the schema. No redundant or filler sentences.

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 create-style operation with no output schema and no annotations, the description covers the needed coordinate source, accepted point shapes, closure, and outside-piece behavior. An agent has enough to invoke the tool correctly without additional research.

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 does: it explains the points array format including optional type codes, coordinate units, point type meanings, and the closed parameter's behavior. Pattern_index is also given a one-line role.

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, 'Draw an internal line or shape on a pattern', and gives concrete examples that clarify scope (fold lines, darts, pocket placement). This is distinguishable by 'internal' from other adding tools like topstitch or hem.

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 examples provide clear context for when the tool is appropriate, and the reference to get_pattern_geometry gives actionable guidance for obtaining coordinates. It does not explicitly name exclusions or alternatives such as add_topstitch, but the internal-shape framing makes selection fairly unambiguous.

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. It discloses that the note is a side-effecting write, that it appears on printed sheets only when annotations are shown, and that supplying annotation_index replaces an existing note instead of adding another. It does not cover error cases or return values, but this is adequate for a simple annotation 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?

Two sentences deliver the core action, coordinate system, visibility condition, and replacement behavior without waste. The most important verb and object are front-loaded.

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

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

For a low-complexity write tool with no output schema, the description covers the essential context: what the note is, where it is placed, when it becomes visible, and how to replace rather than append. The main gaps are parameter semantics details already penalized in that dimension.

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 x/y as 2D coordinates in piece space, text as free-form note content, and annotation_index as the replacement flag. However, pattern_index is never explicitly tied to a pattern piece, and units/origin for x/y are not given.

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 ('Write a note') and names the resource ('a piece') plus the domain (2D pattern coordinates). It also distinguishes itself from the read-oriented sibling get_pattern_annotations by making clear this is a write/replace operation.

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 the tool is used: to add a note to a pattern piece and optionally replace an existing note. It gives no explicit comparison with alternatives such as get_pattern_annotations, and does not state when to use this vs. other pattern-editing tools.

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

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

With no annotations, the description carries the full disclosure burden, and it does so thoroughly: it explains that all rods and boxes form one collision object/avatar, that placement is exact, that thin rods can be penetrated unless mesh is finer, and that particle_distance should be about one-third of the diameter with >= 30 mm. This goes far beyond a simple operation summary.

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 longer than average, but every segment earns its place: a one-sentence purpose, a concise behavioral note about collision objects, a practical mesh/particle_distance tip, and a cleanly formatted Args list. It is front-loaded with the core action and then layers supporting 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 tool with no annotations and no output schema, the description covers the full call context: what the tool does, how collision behaves, how coordinates are interpreted, how to choose parameters, when to prefer a sibling, and a concrete rendering pitfall. Nothing essential for calling it correctly is missing.

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

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

Schema description coverage is 0%, so the Args block must carry all parameter meaning, and it does: center is defined with units and a reference to get_cloth_bounds, axis is explained with directional examples, and length/diameter/replace_avatar all get operational meaning beyond their titles.

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 cylinder (curtain rod, rail, hanger bar...) that cloth collides with.' It also differentiates itself from the sibling make_rod_pocket by noting that for curtains, make_rod_pocket does the whole job, so an agent can tell which tool fits the task.

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 an explicit when-not-to-use condition: 'For curtains, make_rod_pocket does the whole job.' It also references get_cloth_bounds as a coordinate source, which guides correct preparation. It does not explicitly contrast add_rod with add_box or hang_on_rod, but the alternative that matters most is named.

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 fully disclose behavioral traits. It only states the action and parameter semantics, without mentioning side effects, reversibility, prerequisites (e.g., pattern must be loaded), or potential error conditions. It also does not clarify what happens if both seam_index and pattern_index are provided. This is a significant 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?

The description opens with a clear one-sentence purpose, then provides a well-organized, front-loaded argument list. Every sentence earns its place; there is no fluff 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?

Given the complexity of two modes and six parameters, the description is reasonably complete but misses important context: it does not state that seam_index and pattern_index are mutually exclusive, does not mention any prerequisites (e.g., pattern geometry must exist), and does not describe the result or return value. These gaps could lead to incorrect invocations.

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

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

With 0% schema description coverage, the description carries full responsibility for explaining parameters. It does so thoroughly: style_index references list_topstitch_styles, seam_index references get_pattern_geometry, start_ratio/end_ratio define ranges, and pattern_index/line_index describe the alternative mode. This adds substantial meaning beyond the schema's type/default information, though it does not cover edge cases like mutual exclusivity.

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

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

The description clearly states the action (Add topstitching) and the two possible targets (along a seam or along one pattern line). It is specific and distinguishable from sibling tools like list_topstitch_styles or create_topstitch_style, which deal with styles rather than adding topstitch to 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 when to use this tool (when you want to add topstitching) and references where to obtain required indices (list_topstitch_styles and get_pattern_geometry). It does not explicitly state exclusions or alternative tools, but the context makes the usage clear. A slightly higher score would require explicit 'use X instead' guidance, which is absent.

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 well: it discloses that a stopped command may continue inside CLO and that its result is returned here. It also warns that decisions losing work are up to the user, which is important for an interaction 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?

Three sentences, each carrying distinct value: the action, the side effect on stopped commands, and the user-responsibility warning. It is front-loaded and contains no filler.

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

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

Given no output schema and no annotations, the description provides enough context to call the tool safely: it points to get_clo_dialog for dialog context, states that results are returned, and warns about work-losing decisions. The missing button enumeration is mitigated by that reference, though not fully spelled out.

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% for the single required 'button' parameter. The description adds only that the button is on the open dialog and gives one example ('No'), but it does not enumerate valid button values or explain how an agent should determine them beyond referring to get_clo_dialog.

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: clicking a button on a dialog open in CLO. It explicitly references the sibling get_clo_dialog for discovering the dialog, making the distinction between reading the dialog and acting on it clear.

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 usage context: use after a dialog is open via get_clo_dialog, and note that stopped commands may resume. It does not spell out when not to use this tool or name explicit alternatives, but the prerequisite is obvious enough.

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

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

With no annotations, the description carries the full disclosure burden, and it does so well. It explicitly explains that top-level omitted keys keep their values, that mapPhysical replaces the entire physical set, that missing physical keys reset to defaults, and that a missing qsFabricName clears the name. This is unusually transparent about potentially destructive 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 front-loaded with the main action and then packs important behavioral details into the second sentence. It is not overly long, and nearly every sentence adds value. The final sentence about set_fabric_physics is somewhat ambiguous but not wasteful.

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 merge/reset semantics are well covered, which is the most important part for avoiding incorrect calls. However, there is no output schema, no mention of return values, error behavior, prerequisites, or how fabric_index should be obtained. An agent still has to infer some operational details before invoking the tool safely.

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

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

Schema description coverage is 0%, and the description never actually names file_path or fabric_index. It implies that the file is the .jfab and the fabric is the target, but it does not explain whether fabric_index is zero-based, what path format is expected, or how the target fabric is identified. The description does too little to compensate for the bare 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 first sentence clearly states a specific action and resource: apply a .jfab file to a fabric. It also references the CLO SDK spec, which adds precision. However, it does not explicitly contrast itself with siblings like set_fabric_physics or set_fabric_information, and the closing reference to set_fabric_physics is slightly ambiguous.

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 helpful context about applying a .jfab file and mentions set_fabric_physics handles part of the process. But it does not explicitly state when to prefer this tool over alternatives, when not to use it, or what prerequisites exist. Usage guidance is implied rather than direct.

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 meaningful behavior: twill causes crossing colours to mix along diagonals instead of averaging, and back_color's separation order changes the result (a version-specific quirk). It stops short of stating whether the fabric's existing texture is overwritten or whether the operation is reversible.

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

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

Front-loaded one-sentence purpose followed by a structured Args block; every line carries information. Slightly long but no wasted sentences, and the structured layout aids scanning.

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-param, no-annotation, no-output-schema mutation tool, the description is nearly self-sufficient on inputs and behaviour. It omits only the effect on any pre-existing fabric texture and the return/confirmation behaviour.

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: all five params are explained, including a concrete worked example of a 'sett' repeat, the rule that the repeat equals the sum of the widths, and the double-faced meaning of back_color. This adds substantial meaning beyond the bare schema types.

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

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

States a specific verb+resource: generating a plaid/tartan texture from a stripe sequence and applying it to a fabric. It is clearly distinguishable from generic siblings like set_fabric_texture, set_fabric_color, and apply_fabric_json because it names the specific plaid construction (crossing stripes mixed in a twill).

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 never says when to choose this over alternatives such as set_fabric_texture or apply_fabric_json, nor does it state prerequisites (e.g., a fabric must already exist). Usage is only implied by the verb 'put it on a fabric'.

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 explain the three assignment modes, which is useful context beyond the tool name. However, it does not state whether assignment overwrites an existing fabric assignment, whether the operation is reversible, or what 'linked' vs 'unlinked' concretely means.

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: one clear purpose sentence followed by a tight Args block. Every sentence earns its place, and there is no filler or repetition of schema details.

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 tool with no output schema, the description covers the essential invocation details: required indices, the optional assign_option, and what each option means. It is slightly incomplete because it does not define the linked/unlinked behavior or mention error/precondition cases, but the core call is usable.

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 0% description coverage, but the description fully compensates by documenting all three parameters: zero-based fabric_index, zero-based pattern_index, and the assign_option 1/2/3 meanings. It adds meaningful semantics that the bare schema types and default alone do not provide.

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 operation — 'Assign a fabric to a pattern piece' — with a clear verb and resource. It is not a tautology and is understandable on its own. However, it does not explicitly distinguish itself from sibling tools such as get_fabric_for_pattern or set_fabric_color.

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

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

The description provides no explicit when-to-use or when-not-to-use guidance, and does not name alternatives. It also omits prerequisites such as the fabric and pattern piece needing to exist before assignment. The assign_option explanations are parameter semantics, not usage selection guidance.

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

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

With no annotations provided, the description must carry the full burden. It discloses that the tool moves CLO's 3D camera and can change the fit map display. However, it does not specify whether the camera position is restored after capture, whether the capture creates a file or returns data, or any side effects like requiring an open 3D window. These gaps leave the agent uncertain about the tool's full impact.

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 efficiently structured with a purpose statement, a usage hint, and a clean 'Args' section. Every sentence adds value; the fit_map explanation is concise but complete. It is front-loaded with the primary purpose and usage, making it easy to scan.

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

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

Given the tool's moderate complexity and the absence of an output schema, the description covers the essentials: when to use, what it does, and all parameters. However, it omits what the tool returns (e.g., whether it saves an image, returns a path, or is just a UI action) and whether the camera move persists. These are relevant for an agent deciding how to use the result. The lack of an output schema makes this gap more noticeable.

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 fully compensates. It enumerates all valid views (front, back, left, right, three_quarter_left, three_quarter_right, top, bottom, zoom_all, current) and explains fit_map semantics with 'strain'/'stress'/'off' and the default behavior. This is comprehensive and goes beyond the bare 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 verb 'capture' and the resource 'CLO's 3D window', and it explicitly names the camera views it can capture. It distinguishes itself from sibling tools like export_thumbnail and export_snapshot by focusing on the live 3D window rather than file exports, and it gives concrete use cases (checking twisted seams, misplaced pieces, fabric through avatar).

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

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

The description provides explicit when-to-use guidance: 'Use after simulating or editing to check the result'. It also explains that it moves the camera and toggles fit map display. However, it does not explicitly state when not to use it or name alternative tools (e.g., export_snapshot) for saving images, so it lacks 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?

With no annotations, the description carries the full burden, and it does disclose important behavior: it uses Windows UI Automation, it cannot change CLO's mode menu, and it returns the marker it produced. It does not describe failure behavior if CLO is not in the required mode, but the core action, prerequisite, and output are clearly stated.

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 names the exact action first, then gives the use case, prerequisite, and return value. Every sentence adds necessary context 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 zero-parameter, no-output-schema tool, the description covers the use case, mode prerequisite, and return value. It is slightly incomplete because it does not state what happens if CLO is not in Printing Layout mode or if the print layout is not empty, but overall an agent has enough to select and call 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 accepts zero parameters, and the schema's empty properties object fully captures that. There is no parameter detail for the description to add, so the baseline score applies.

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

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

The description states a concrete UI automation action ('Click Nest All Fabrics'), the target editor (Print Layout Editor), and the specific purpose (enabling API nesting to work). This clearly differentiates it from sibling nesting tools like nest_patterns by describing the UI fallback mechanism.

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

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

It explicitly identifies the situation where this tool should be used ('for when the print layout is empty') and explains why it is necessary before API nesting can work. It also states the prerequisite that CLO must be in Printing Layout mode and notes that the mode menu cannot be driven through UI automation.

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 disclosure burden. It reveals that the tool converts between internal and base line representations, but it does not say whether the operation mutates the existing shape, returns a new shape, requires specific permissions, or has any side effects. This is a meaningful gap for what is likely a modifying operation.

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

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

The description is very short and the one sentence directly states the operation, which is front-loaded. However, it is so terse that it omits essential parameter and behavioral context, so the brevity is more under-specification than effective conciseness.

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

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

For a tool with no annotations, no output schema, and three completely undocumented parameters, the description is not complete enough for an agent to call it correctly with confidence. The agent still cannot tell what pattern_index refers to, what values 'to' accepts beyond the two quoted examples, or what the result of the conversion is.

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 the three parameters. It gives partial meaning to 'to' by naming 'base' and 'internal', and it clarifies that 'internal_shape' is the internal shape to convert, but it leaves 'pattern_index' completely unexplained and does not give precise accepted values or constraints.

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 and resource: converting an internal shape to a base line or back. It also distinguishes the two directions ('base' and 'internal'), which makes the tool's core function understandable. However, 'base line' is not fully defined and the description does not clearly differentiate this from sibling shape-editing tools like add_internal_shape or offset_internal_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?

No explicit guidance is provided about when to choose this tool versus alternatives such as add_internal_shape, offset_internal_line, or mirror_pattern. The phrase 'or back' implies bidirectional conversion, but there is no context about prerequisites, typical workflows, or when conversion would be 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, the description must disclose behavior. It states the core operation (duplicate at an offset in mm) but does not mention whether the original is unchanged, if a new pattern piece is created, or any error conditions. The description is accurate and not misleading, but lacks depth beyond the obvious.

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: a single sentence for purpose followed by a compact argument list. It is well-structured and front-loaded, with no unnecessary content. Slightly more detail could be added, but it is efficient and clear.

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

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

For a simple tool with three parameters and no output schema, the description covers purpose and parameters. However, it does not mention return behavior or prerequisites (e.g., pattern_index validity). Given low complexity, it is adequate but could be more complete regarding side effects or success indicators.

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 no descriptions (coverage 0%), so the description is the sole source for parameter meaning. It clearly explains pattern_index as zero-based and x/y as offsets in mm, adding critical semantics beyond the schema's type and default values.

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

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

The description clearly states the action 'Duplicate' on the resource 'pattern piece' and includes positional offsets. This distinguishes it from siblings like delete_pattern, flip_pattern, and move_pattern_2d, as duplication is semantically unique.

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

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

The description does not explicitly mention when to use this tool versus alternatives such as move_pattern_2d or mirror_pattern. The purpose is implied through the name and description, but no exclusions or alternative conditions are stated. This is adequate for a simple operation but not 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 of behavioral disclosure. It goes beyond the verb by stating that it returns the pattern_index and outline lines for immediate sewing, hemming, or topstitching. It does not describe side effects like project mutation or failure behavior, but the key call behavior is adequately exposed.

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 tightly organized: one purpose sentence, a clean args block, and a useful return note. Every sentence contributes either to parameter semantics or to why the return value matters, with no redundant 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?

Even without an output schema, the description tells the agent what input to provide and exactly what will be returned, including line_index, start, end, and length. For a single-parameter creation tool, the information needed to invoke it correctly is present and actionable.

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 fully compensates: it explains points as [x, y] or [x, y, type], defines each type code (0=straight, 2=spline, 3=bezier), specifies mm units, and provides a concrete example. This is exactly the semantic detail an agent needs beyond the bare array schema.

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

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

The description opens with 'Create a new pattern piece from vertex points', giving a specific verb and resource. It clearly distinguishes this from siblings like copy_pattern, delete_pattern, and get_pattern_info because it is the constructive action that builds geometry from coordinates.

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 stated: an agent can infer this is for creating a pattern from raw vertex coordinates. However, the description does not explicitly say when to prefer this over alternatives such as import_file or copy_pattern, and it provides no 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 so well: it discloses the underlying implementation (copies a saved style file with values changed and imports it), the required template workflow, and the return value (style_index). It stops short of stating permissions, error behavior, or what happens if a template name is reused or an existing style is overwritten.

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

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

Front-loads purpose and the return value, then the template explanation, then per-arg docs. The template paragraph is somewhat long but earns its place because the workaround is non-obvious. Minor formatting noise (line breaks, trailing blank) keeps it from a 5.

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

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

No output schema and no annotations exist, so the description must stand alone; it covers the purpose, the non-obvious file-copy mechanism, the template prerequisite, and the returned style_index. For a 6-parameter tool this is complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate fully and does: it documents all six parameters, including the Tex conversion for thread_thickness_mm, the offset meaning relative to the stitched line, defaults inherited from the template, and the first-time-only nature of template_path. This adds substantial meaning beyond the bare schema titles.

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

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

States a specific verb+resource ('Create a topstitch style') and enumerates the three defining attributes (stitch length, thread thickness, offset). It also ties itself into the workflow by explaining it returns a style_index for add_topstitch, distinguishing it from get_topstitch_style/list_topstitch_styles/set_topstitch_style 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?

Gives clear context for when this is needed (CLO's API cannot set these values on a style, so a template file must be copied and imported) and explains the one-time template setup. However, it never states when NOT to use it or names alternatives such as set_topstitch_style for modifying an existing style or list_topstitch_styles for discovering available ones.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only says 'Delete', which implies mutating and destructive behavior, but it does not disclose whether deletion is irreversible, whether assigned fabrics are affected, or whether undo/checkpoint behavior applies.

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 crisp sentence with no filler words. It is concise and front-loaded, though it is arguably too sparse for a destructive operation, which slightly limits the appropriateness of its size.

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 no annotations and no output schema, the description is incomplete. It omits critical context about the fabric_index meaning, side effects, reversibility, and how this operation interacts with patterns or project state.

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

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

Schema description coverage is 0% and the description adds no meaning to fabric_index. It does not explain where the index comes from, whether it is zero-based, or how it relates to get_fabric_list, so the agent has insufficient 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 verb ('Delete'), a clear resource ('fabric'), and scope ('from the project'). This distinguishes it from sibling operations like delete_pattern, add_fabric, replace_fabric, and export_fabric, so an agent can tell what tool this is without inspecting 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?

No guidance is given for when to use this tool versus alternatives such as replace_fabric or delete_pattern. There are no prerequisites, exclusions, or context about when deletion is appropriate, leaving the agent to infer usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action 'Delete' without mentioning side effects, irreversibility, error conditions, or dependencies. This is a destructive operation and the lack of transparency 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 with no wasted words. It is front-loaded with the action and resource, but it lacks any supporting detail. It is appropriately concise but under-specified.

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 delete operation with two required integer parameters, the description provides no context about how to obtain these indices, what 'line' means, or what the outcome will be. The lack of output schema and parameter details makes it incomplete for reliable 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%, meaning the schema provides no descriptions for pattern_index and line_index. The description also fails to explain what these parameters represent, their format, or any constraints. The agent has no way to correctly construct arguments.

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

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

The description clearly states the verb 'delete' and the resource 'outline line of a pattern', which is specific enough to distinguish it from sibling tools like delete_pattern or delete_point. However, it does not explicitly differentiate from these alternatives or clarify what constitutes an 'outline 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?

No guidance is given on when to use this tool versus alternatives, such as delete_point or delete_pattern. The description only states the action without any context about prerequisites, conditions, 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Delete' without stating that the operation is permanent, irreversible, or how errors are handled. It does not disclose side effects, confirmation behavior, or impact on related patterns.

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 extremely concise: one front-loaded sentence stating the core operation, followed by a minimal args list with no redundant content. Every element 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 simple one-parameter tool, the description provides enough to make the call (resource and param semantics). However, it lacks information about error behavior, irreversibility, and what happens after deletion; with no output schema, these gaps remain unaddressed.

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 only specifies an integer, but the description clarifies that it is a zero-based index and that it refers to a pattern piece. This fully compensates for the 0% schema description coverage on the single parameter and is an essential detail for correct invocation.

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 action ('Delete') and target ('a pattern piece from the project'), identifying the operation and its scope. It distinguishes from other pattern-related siblings by the destructive verb and specific resource, 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?

No guidance is provided on when to use this tool versus alternatives, or on prerequisites such as obtaining a valid pattern_index from get_pattern_list. There is no mention of exclusions or conditions that would make this tool inappropriate.

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. The verb 'Delete' signals destructiveness and the point-line relationship hints at geometric consequences, but the description never states whether deleting a point also affects its associated line, whether the operation is reversible/undoable, or what constraints exist (e.g., minimum point counts or validity rules).

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

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

A single sentence with the core action front-loaded ('Delete an outline point') and a tightly scoped clarifying parenthetical. The cross-reference to get_pattern_geometry earns its place; 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 low-complexity tool (two simple integer params, no output schema), the description is adequate: it states the operation and the indexing convention. However, the point-line relationship introduced in the description raises an obvious unanswered question — what happens to the line when the point is deleted — and no error or undo behavior is mentioned, which matters for a destructive operation.

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

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

Schema description coverage is 0%, so the description must compensate. It does exactly that for point_index by explaining that point n is the start point of line n — genuine meaning the schema cannot convey. pattern_index is left to inference, but the sibling-tool convention and parameter name make its purpose reasonably clear.

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

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

States a specific verb ('Delete') and resource ('outline point'), clearly distinguishing it from sibling deletion tools like delete_line, delete_pattern, and delete_fabric. The parenthetical adds the non-obvious indexing convention ('point n is the start point of line n'), which sharpens what exactly is being targeted.

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 cross-reference to get_pattern_geometry implies the intended workflow — understand the geometry before deleting points — but there is no explicit when-to-use/when-not-to-use guidance. Given that several sibling tools also delete or modify pattern structures, naming an alternative or condition would have been stronger.

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 discloses that the export runs without a dialog and returns pieces read back from the file as a check, which adds useful context. However, it does not mention whether the tool overwrites existing files, handles errors, or has any side effects beyond creating the file. This is a moderate disclosure but not exhaustive.

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 structured with a purpose statement up front followed by a parameter list. Each line in the Args block is necessary and adds value. There is no fluff or repetition. The format is efficient and easy to scan, though it could be slightly more compact.

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 moderate complexity (11 parameters, no output schema, no annotations), the description covers all parameters and the return behavior. It explains the output as a list of piece data (name, size, quantity, outline box in mm), which is helpful. It lacks explicit error handling or file overwrite behavior, but for an export tool this is a relatively complete specification.

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

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

Schema description coverage is 0%, so the description must explain parameters. It does so for every one of the 11 parameters in the Args block, adding meaning beyond the schema's titles and defaults (e.g., file_path must be an absolute path ending in .dxf, format values and their interpretation, metric as mm vs inches). The explanations are concise yet informative, covering all parameters adequately.

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 pattern as a DXF for CAD, plotters, and cutters, with a specific use case. It distinguishes itself from other export tools (obj, fbx, glb, etc.) by naming the DXF format and its target applications. However, it doesn't explicitly contrast with sibling export tools, so a 4 rather than 5.

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

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

The description implies usage via the format options (aama, astm, gerber) and target use cases (CAD, plotters, cutters), but it does not explicitly state when to choose this tool over alternatives or include any exclusions. It's clear enough for an agent to infer, but guidance is not overt.

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 a behavioral constraint (CLO 2025.2 refuses .jfab) and notes the binary nature of the .fab inside, which is useful. However, it does not mention overwrite behavior, error handling, or whether the operation returns anything. For a save operation, these are notable omissions, but the provided nuance adds some 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 two lines, front-loaded with the primary action, and includes a parenthetical detail that is relevant without bloating the text. The argument list is structured and each parameter has a brief, clear definition. No unnecessary words.

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

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

For a simple two-parameter tool with no output schema, the description covers the core action, format, and parameter meanings. It is missing details about overwrite behavior, return values, or potential errors, but given the simplicity, these are gaps rather than critical omissions. The description is adequate for basic invocation but not 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?

The schema provides no descriptions (0% coverage), so the description compensates by explaining both parameters: fabric_index as 'Fabric to export' and file_path as 'Absolute output path ending in .zfab'. This adds clear meaning beyond the bare schema types and titles, giving the agent enough to use them 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 the action ('Save a fabric as a .zfab file') with a specific resource (fabric) and output format. It distinguishes from sibling export tools by format and resource, though it doesn't explicitly name alternatives. The nuance about CLO 2025.2 refusing .jfab adds specificity without confusion.

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

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

The description does not mention when to use this tool versus alternative export tools (e.g., export_obj, export_fbx). It implies the use case (exporting fabric to .zfab) but provides no exclusions or comparisons to siblings. The only guidance is the file path extension requirement, which is more of a constraint than a usage condition.

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

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

With no annotations, the description carries the full burden but only states the core export action. It does not disclose overwrite behavior, whether the destination directory must exist, scope of the exported garment, or any success/failure 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 two brief parts: a front-loaded purpose sentence and a single parameter explanation. There is no filler or repetition, making 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 one-parameter, low-complexity export tool, the description covers the essential invocation detail: what is exported and where to write it. The lack of detail about overwriting or return values is a minor gap given how simple the operation is.

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 by defining file_path as an absolute path and explicitly tying it to the .fbx output. This adds useful meaning beyond the schema's bare 'string' property, though it stops short of providing format or example details.

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 ('Export'), a target ('the garment'), and an explicit format ('FBX'), which clearly sets it apart from sibling export tools such as export_obj and export_glb. Even without reading the schema, an agent knows exactly what this tool produces.

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 about when to choose FBX over the many sibling export tools, nor does it mention alternatives or exclusions. An agent must infer suitability solely from the format name in the first sentence.

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, yet it reveals only the export action itself. It does not disclose overwrite behavior, permission requirements, directory creation, failure modes, or output size. The options field is described only as 'Optional export options,' which is a tautology that adds no behavioral context.

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

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

The description is two sentences plus an Args block with zero filler, and the core purpose is front-loaded. The Args section slightly duplicates the schema, but it is compact and does not waste words.

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

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

With no annotations, no output schema, and 0% schema coverage on both parameters, the description is incomplete for an export operation. It leaves the options object entirely undefined, offers no format-selection rationale versus export_gltf, and provides no behavioral context. An agent cannot know what options are valid or what side effects to expect.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does for file_path, adding the useful 'Absolute path' and destination requirement. But options receives only 'Optional export options,' which merely restates the parameter name and the schema's optionality (default null, not required) — no meaning added for the poorly-understood options object.

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+resource+format: 'Export the garment as a GLB (binary glTF) file.' Naming 'binary glTF' implicitly distinguishes it from OBJ/FBX and from the JSON-based glTF sibling (export_gltf). However, it does not explicitly call out the export_gltf distinction, which is the closest and most confusable sibling.

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

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

No guidance on when to choose GLB over glTF, OBJ, FBX, or any of the ~10 export siblings present. No exclusions, no context, no alternative names mentioned. An agent gets no help selecting this format over its peers.

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 itself conveys the key behavioral trait: the tool writes a glTF file to the supplied absolute path. It does not mention overwrite behavior, whether exported resources/textures are included, or what the call returns, but the core write-to-file behavior is at least explicit.

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

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

The definition is compact and front-loaded: one clear purpose sentence followed by two argument lines. It could earn a 5 with a much smaller addition such as an alternatives sentence, but as written every line serves a purpose without padding.

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 essential purpose and file_path argument, and 'options' is at least identified as optional. It is incomplete in meaningful ways—no options semantics, no return/result indication, no file overwrite note, and no relation to the many sibling export tools—so it is minimally viable rather than complete.

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

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

file_path is given real meaning ('Absolute path for the exported .gltf file'), which is not present in the schema. However, 'options: Optional export options' adds no semantics beyond the schema's optional/nullable declaration, and with 0% schema coverage the description only partially compensates for the opaque options object.

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 ('Export the garment') and names the target format ('glTF file'), so an agent can identify the action. It does not differentiate from the closely related sibling export_glb, which is the same export action with a binary glTF format, so it stops short of a 5.

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

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

The only usage signal is the format name: an agent can infer 'use this when a glTF file is requested.' There is no explicit guidance about when to prefer export_gltf over export_glb/export_fbx/export_obj, nor any exclusion 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 provided, the description carries the full burden of behavioral disclosure. It states the basic operation and lists some option keys, but does not mention side effects such as overwriting an existing file, file-system permission needs, required garment state, or what the tool returns after export.

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 with the core action, followed by a compact Args section. There is no filler or repetition of schema fields, and 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?

For a simple export tool with two parameters this is minimally adequate: the required file_path is defined and the optional options are introduced. But the options object remains under-specified, and with no output schema or annotations, there is no information about return behavior or side effects.

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 usefully defines file_path as an absolute path for the .obj file, and it lists example option keys (bExportGarment, bExportAvatar, bThin, scale). However, it does not explain the types, accepted values, or meaning of those options, so an agent cannot confidently construct a correct options object.

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: 'Export the garment as an OBJ file.' The OBJ format clearly distinguishes it from sibling export tools like export_fbx, export_glb, and export_gltf, so an agent can identify the intended output without inspecting 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 intended use is implied by the format name: use this tool when an OBJ export is needed. However, the description gives no explicit guidance about when not to use it or how it compares to the many other export siblings, so the agent must infer the selection criteria from 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 full burden and does well: it discloses the vector 1:1 scaling, verification in CLO 2025.2, that PDF output stays as a single 1:1 page regardless of paper size (no tiling), and that print_layout depends on a prior CLO layout setup. It does not mention return values or error behavior, but the key behavioral traits are 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?

The description is lengthy but every section earns its place: it front-loads the core behavior, then uses a clean Args block to document eight parameters. The extra notes about 1:1 scaling, paper behavior, and tiling are useful, not 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?

Despite having no annotations and no output schema, the description fully covers the operation, the two source workflows, prerequisites, all parameters, defaults, and paper behavior. An agent has enough to call this tool correctly for both PDF and PNG exports.

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 fully compensate, and it does. It explains file_path requirements, source values, all paper presets plus custom sizing, landscape, width/height, resolution_dpi, and the full show key set with an example object. This is far beyond what the bare input schema provides.

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

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

The description opens with a specific verb and resource: export the 2D pattern as PDF or PNG, and explains the format is chosen by file extension. It also distinguishes the two source modes (print_layout vs pattern), which separates it from related export tools like export_dxf, export_thumbnail, and export_snapshot.

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

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

It gives clear context for when each source mode is appropriate: print_layout exports the marker from CLO's Print Layout Editor and requires one-time layout setup, while pattern exports the pattern window. It does not explicitly state when to choose this tool over sibling export tools, but the format and purpose are obvious enough that the lack is minor.

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. It clearly states that files are written to disk and describes the exact naming convention (<base>_front.png, etc.). It does not mention overwrite behavior or return/success indicators, but the primary behavioral contract is transparent enough for a simple export 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. The first sentence states purpose, the second routes to the relevant sibling, and the Args block is short. No sentence is wasted.

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

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

For a single-parameter, low-complexity tool without an output schema, the description is nearly complete: it covers behavior, naming, and the sibling alternative. It stops short of stating what the tool returns on success/failure, which would make it fully self-contained, but the core usage context is sufficient.

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

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

The schema only says file_path is a string, but the description adds essential meaning: it is a base path, not a literal final file path, and it defines how output filenames are derived. This fully compensates for the 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 description states a specific verb ('Save'), a concrete resource ('front, back, left and right images of the 3D window'), and the output format ('PNG files'). It also explicitly contrasts with capture_3d, which returns images instead, making the tool's role clear among 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 gives explicit usage guidance by naming capture_3d as the alternative when the agent needs to view images directly. It does not compare against other export siblings such as export_thumbnail or export_turntable, but the core decision between saving and returning images is well covered.

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 must disclose behavior itself. It reveals that the tool writes a tech pack to an absolute file path, but does not mention overwrite behavior, whether directories are created, side effects, or return values. This is thin for a file-creation operation.

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

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

The description is short and front-loaded; the first sentence states the operation and output format, and the Args line adds the one necessary parameter detail. It is concise, though slightly under-specified.

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

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

For a one-parameter export tool, the description covers the essential 'what' and 'where.' However, with no annotations or output schema, it omits usage context versus sibling exports and any return/error behavior, making it only minimally complete.

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

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

With 0% schema description coverage, the description compensates by explaining file_path as 'Absolute path for the tech pack output,' adding meaning beyond the schema's bare 'File Path' label. It could specify expected extension or file-vs-directory, but the core semantic is clear.

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

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

States a specific action ('Export') and a distinct resource ('tech pack'), and clarifies content ('JSON metadata and images'). It is distinguishable from sibling export_* tools by the unique 'tech pack' target, though it does not name any sibling.

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

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

No guidance on when to choose this over the many sibling export tools (export_obj, export_pattern_sheet, etc.), nor any prerequisites such as a loaded project. The description simply states what the tool does.

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 states that the tool exports an image with specified width/height, but does not mention side effects, required viewport state, file format, or whether it is read-only. This is minimal but not misleading.

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 primary purpose, followed by a clearly structured Args list. No unnecessary words, though the Args section is largely restating schema fields with added semantic 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?

The description covers the essential mechanics of the tool, but lacks usage context, output/return behavior, and any discussion of file format or overwrite behavior. Given the tool's simplicity, it is adequate 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 adds meaning to all three parameters: file_path is an absolute path for the exported image, width and height are in pixels with defaults. This is more informative than the bare schema.

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

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

The description states a clear verb and resource: 'Export a 3D viewport screenshot/thumbnail.' This distinguishes it from generic export tools, though it does not explicitly differentiate from closely related siblings like export_snapshot or capture_3d.

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 use this tool versus alternatives. The description does not mention export_snapshot, capture_3d, or any conditions that would make export_thumbnail the preferred 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, the description must disclose behavior, but it only states the action without mentioning side effects, file creation, overwrite behavior, or prerequisites. The agent cannot know what happens when it runs.

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 includes a structured Args section. It is not bloated, but it lacks detail that could be added without losing conciseness.

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

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

Given the lack of annotations and output schema, the description is too sparse to fully inform the agent. It omits details about the output format, file naming, required state, and potential side effects, making it insufficient for safe 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?

The description explains file_path as an absolute path that can be a directory or base name, adding meaning beyond the schema's type. However, it doesn't clarify how these two modes differ or what the tool does with the path, leaving ambiguity.

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 360-degree turntable image sequence, which is a specific export type distinct from siblings like export_obj or export_thumbnail. However, it doesn't specify what object the turntable is of, leaving some ambiguity.

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

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

No guidance is given on when to use this tool vs other export tools. The description doesn't mention alternatives or selection criteria, so an agent must infer usage 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 behavioral disclosure burden. It does state that the operation flips a pattern piece and exactly how the boolean maps to horizontal/vertical behavior. However, it does not explicitly say whether the piece is modified in place, whether the flip is reversible, or what the tool returns, leaving some side-effect ambiguity.

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: one clear action sentence followed by a minimal Args block. There is no filler, and every line adds useful semantic 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 simple two-parameter operation, the description is mostly adequate to make a valid call. It is incomplete, though, because it does not clarify side effects or distinguish flip_pattern from the overlapping sibling mirror_pattern, and there is no output schema to clarify the return 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?

The schema has 0% description coverage, but the description fully compensates by explaining that pattern_index is zero-based and that horizontal=true means horizontal flip while horizontal=false means vertical flip. Both parameters receive meaningful semantics beyond their raw names and types.

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 ('flip'), a specific target ('a pattern piece'), and the two supported orientations ('horizontally or vertically'). It is clear and distinguishable from most siblings, but it does not explicitly differentiate itself from the similarly named mirror_pattern sibling.

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 flip_pattern versus alternatives such as mirror_pattern, move_pattern_2d, or copy_pattern. It also provides no exclusions or conditions, so the agent must infer the appropriate 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 provided, the description carries the full behavioral burden. It signals a read-only retrieval ('Get') and scopes the result to arrangement points on the avatar, but it does not state whether there are side effects, how the list is ordered, or what information each point contains. Basic transparency, but not complete.

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 filler; the verb and object are front-loaded and every word contributes. It is appropriately concise for a zero-parameter getter.

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, but there is no output schema and a near-identically named sibling (get_arrangement_points) exists. The description states the return type ('list') and scope ('on the avatar'), which is enough for a basic call, but it lacks disambiguation and any detail about the returned data structure.

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

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

The input schema has zero properties, so there are no parameter semantics to document. The description correctly avoids inventing parameters, and 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 uses a clear verb ('Get') and a specific object ('list of arrangement points on the avatar'), so the basic purpose is unambiguous. However, it does not differentiate the tool from the sibling get_arrangement_points, which appears to describe the same concept, so it falls short of a 5.

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

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

There is no guidance on when to use this tool versus get_arrangement_points or any other sibling. No conditions, prerequisites, or alternatives are mentioned, so the agent is left without selection guidance.

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

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

With no annotations, the description carries the burden. It discloses a prerequisite (avatar presence) and the read-like nature of 'list', but it does not specify what happens if the precondition fails, the exact return format, or any side effects. The prerequisite disclosure is useful, but more behavioral detail would be expected for a tool with zero 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 entire description is a single, front-loaded sentence that conveys the action, a prerequisite, and the intended use case with no filler. Every clause adds value, making it an excellent example of concise writing.

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

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

For a zero-parameter tool with no output schema, the description covers the essential elements: what it does, a key prerequisite, and its purpose. It could mention the return value (a list of points) explicitly, but that is strongly implied by 'list' and the context, so it is adequate for 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 is empty, so the baseline is 4. The description does not need to add parameter semantics, and it correctly avoids inventing any.

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

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

The description clearly states the verb 'list' and the resource 'avatar's arrangement points', with an explicit purpose ('for place_pattern'). It distinguishes from potential siblings like get_arrangement_list by scoping to the avatar and the placement use case, though it doesn't name an alternative directly.

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 a clear precondition ('needs an avatar in the scene') and an implied usage context ('for place_pattern'), but it does not explicitly contrast with alternatives like get_arrangement_list or state when not to use it. The guidance is present but not fully explicit.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It communicates the scope ('in the scene') and the returned data fields, which is useful, but it does not explicitly state that the operation is read-only, non-destructive, or what happens when no avatars exist. For a simple list operation this is minimally adequate.

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 wastes no words. It front-loads the action and resource, then adds the output details, making it easy to parse quickly.

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 low complexity (0 parameters, no output schema, simple list operation), the description is nearly complete. It states the scope and mentions the returned fields, which partially compensates for the missing output schema. It could be slightly more explicit about the shape of the returned list, but this is sufficient for 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 trivially covers 100% of them, so no parameter documentation is needed from the description. The baseline for 0-parameter tools is 4, and the description adds no parameter ambiguity.

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 ('List') with a specific resource ('avatars in the scene') and even states the output fields (names and genders). The scope 'in the scene' clearly distinguishes it from sibling tools like import_avatar or show_avatar, which add or display avatars rather than list them.

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 about when to use this tool versus alternatives such as show_avatar or import_avatar. The description implies a read-only list operation, but it never explicitly states conditions or provides exclusions, leaving the agent to infer usage.

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

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

With no annotations, the description carries the full burden. It usefully discloses that acknowledge-only dialogs are handled automatically and that decision dialogs stop commands with text and buttons, but it does not state this tool's own side effects, safety profile, or behavior when no dialog exists beyond the phrase 'if any'.

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

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

The description is front-loaded with what the tool returns and then adds relevant dialog-handling context. It is reasonably concise, though the second sentence is a dense run-on that mixes behavior of other commands with this tool's context.

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

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

For a zero-parameter getter with no annotations or output schema, the description adequately covers purpose and return content. The main gap is routing guidance: it does not explicitly tell the agent when to use get_clo_dialog versus answer_clo_dialog.

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 input parameters, so the baseline is 4. The description cannot add parameter-level meaning, and that is appropriate for a no-argument getter.

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 resource and return payload: the currently open CLO dialog, if any, including its title, message, and buttons. It does not explicitly name answer_clo_dialog as a sibling alternative, so sibling differentiation is implied rather than explicit.

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: call this to inspect the dialog currently open in CLO. The description explains how commands handle acknowledge-only dialogs and decision dialogs, but it never states when to choose this tool over answer_clo_dialog or other dialog-related tools.

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

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

With no annotations, the description carries the burden of explaining behavior. It discloses that results depend on simulation, that frozen pieces report nothing, and that a flat unpinned piece sits at z=200, plus the axis orientation details. This is rich, useful behavioral context.

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

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

The description is front-loaded with the core result, then adds axis context, behavioral caveats, and structured parameter explanations. Every sentence contributes useful information, 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?

The description covers the return value, units, coordinate system, usage scenarios, simulation prerequisites, behavior edge cases, and parameter semantics. Given the lack of annotations and output schema, it provides everything an agent needs to decide when and how to call it.

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 the parameters itself. It does so by defining region_min and region_max as box corners and pattern_index as a filter for specific pattern vertices. This adds clear meaning beyond the bare schema types and 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 clearly states the tool returns the 3D bounding box of the cloth with units and axis definitions. It is specific about the resource (cloth) and output (min/max x, y, z), though it does not explicitly contrast it with sibling tools like get_pattern_bounding_box.

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 use cases: placing rods and props, and checking where a piece ended up. It does not provide comparisons or exclusions relative to alternative tools, but the intended context is clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses the read-only nature implicitly via 'Get' and specifies the content of the response (names and active flag). It does not explicitly state that no state is modified or mention any errors/edge cases, making this minimally adequate.

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, compact sentence that front-loads the operation and result. Every word adds value, 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 low-complexity, zero-parameter tool with no output schema or annotations, the description adequately explains what is returned (names and active status). It could mention ordering or whether inactive colorways are included, but 'all colorways' already implies inclusion, so it is essentially complete.

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

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

The tool has zero parameters, and the schema coverage is 100% (vacuously). With no parameters, the baseline is 4, and there is nothing the description needs to add about 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 uses a specific verb ('Get') and resource ('all colorways in the current project') and specifies the returned data (names and which is active). This clearly distinguishes it from siblings like set_current_colorway and other get_* list 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 intended use is clear from the context: listing colorways in the current project, which pairs naturally with set_current_colorway among siblings. However, it does not explicitly name alternatives or state when not to use it, 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 full responsibility for behavioral disclosure. It implies a read-only 'get' operation, but does not mention return format, error behavior for invalid indices, or whether any side effects occur. The description is minimal and leaves these behaviors unspecified.

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 extremely concise: one clear declarative sentence followed by a single argument definition. It is front-loaded with the purpose and contains no redundant or extraneous 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?

For a simple getter with one parameter, the description covers purpose and parameter semantics, but it omits the return value format (e.g., fabric ID or name) and any error conditions. Given the absence of annotations and output schema, these gaps leave the tool somewhat incomplete for an agent to use confidently.

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 does so fully by explaining 'pattern_index' as a zero-based index of the pattern piece, adding critical meaning beyond the bare integer type in the schema. This single parameter is clearly and completely defined.

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, specific verb and resource: 'Get which fabric is assigned to a pattern piece.' This distinguishes it from write operations like assign_fabric_to_pattern and list operations like get_fabric_list, though it does not explicitly name 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention conditions, exclusions, or when to prefer get_fabric_info or get_fabric_list. The description simply states what it does without any 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 provided, the description carries the full burden of behavioral disclosure. It mentions the data returned but does not state that it is a read-only operation (implied by 'get'), nor does it describe error behavior, required permissions, or side effects. The description is too terse to fully disclose behavior.

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

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

The description is one concise sentence, front-loading the key details about the returned data. It avoids unnecessary words and is easy to read. It could be slightly clearer in structure but is appropriately sized.

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 one parameter and no output schema, the description offers a minimal specification: it lists the returned fields and mentions the JSON format. However, it lacks details on error handling, the exact JSON structure, and any prerequisites. It is minimally complete but not thorough.

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

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

The input schema has only one parameter, fabric_index, with no description provided (schema coverage 0%). The tool description does not explain the parameter or how it relates to the returned data. The agent must rely on the parameter name alone, which is a gap given the zero coverage.

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

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

The description clearly states what the tool returns: a fabric's name, information fields, and CLO's fabric info JSON. It identifies a specific resource (a single fabric) and distinguishes from siblings like get_fabric_list (which lists fabrics) and set_fabric_information (which mutates). It is not a tautology, though it could be more explicit about retrieving data.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention alternative tools, prerequisites, or contexts. An agent would have to infer usage from the name and siblings, which is insufficient.

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 communicates a read-only intent through 'Get' and states the output shape, but it does not disclose behaviors such as project-state requirements, ordering guarantees, or whether any implicit filtering occurs. This is adequate but not rich.

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 immediately informative, with the action, scope, and output contents all front-loaded. There is no redundant wording or filler.

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

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

For a zero-parameter read-only list tool with no output schema, the description adequately specifies scope and return contents. It could be slightly more explicit about the exact return structure, but an agent can confidently invoke it without missing critical information.

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

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

The tool has zero parameters, so the baseline is 4. The description adds meaningful context by stating the scope ('current project') and the returned data ('indices and names'), which is all an agent needs given no inputs are required.

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 ('Get') and resource ('a list of all fabrics in the current project'), and clarifies the return contents ('indices and names'). This clearly distinguishes it from sibling tools like get_fabric_info, which targets a single fabric, and get_fabric_for_pattern, which is scoped to a pattern.

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

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

No guidance is provided on when to use this tool versus alternatives such as get_fabric_info or get_fabric_for_pattern. The intended use is implied by the name and description, but there are no explicit exclusions or alternative-routing hints.

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 bears full responsibility for disclosing behavior. It says 'export and retrieve' which hints at read-like operation but does not clarify whether any side effects occur (e.g., writing to disk), nor does it mention permissions, rate limits, or reversibility. The term 'metadata' suggests a non-destructive intent but this is not explicit.

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

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

A single, well-structured sentence that front-loads the core action and resource, then details the content. Every word contributes value; there is no redundancy or irrelevant 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?

The description lists the returned content but does not specify the scope of 'garment' — for example, whether it refers to the currently open project, a selected garment, or all garments. Given the absence of parameters and output schema, this ambiguity could confuse an agent. However, the tool is simple, so the description is mostly complete but leaves this key context unclear.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. Per the baseline rule for 0 parameters, this dimension is satisfied. The description adds no parameter-specific meaning because there are none, but it does not need to.

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 ('Export and retrieve') and a distinct resource ('garment metadata') with specific content (pattern details, fabric assignments, measurements). It differentiates from sibling tools like get_pattern_info and get_fabric_info by targeting the garment-level aggregate, making the tool's purpose unambiguous.

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

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

The description implies usage for obtaining overall garment data but does not explicitly state when to prefer this over pattern-specific or fabric-specific tools. No alternative names or exclusion conditions are given, leaving the decision 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that notes and their positions are returned, but does not clarify read-only nature, error conditions, output format, or any side effects. The description adds minimal context beyond the obvious.

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 short sentence, which is concise, but it is under-specified. It is not front-loaded with the most important information (what the tool does). The sentence is not verbose but it does not effectively communicate the core action. It is acceptable in length but poor in content structure.

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 one parameter, no output schema, and no annotations, the description is incomplete. It does not specify the structure of the returned annotations, the meaning of 'positions,' or any prerequisites or error behavior. An agent calling this tool would not know what to expect beyond the name and minimal description.

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

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

Schema description coverage is 0%, so the description must compensate by explaining the pattern_index parameter. It does not. The description mentions 'a piece' but does not explicitly connect it to the pattern_index or explain how the index is used. No additional meaning is added over the schema, which only lists the parameter name and type.

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 'The notes written on a piece, with their positions.' implies the tool retrieves annotations, but it lacks an explicit verb like 'get' or 'retrieve.' The resource is vague ('a piece' vs. the pattern identified by pattern_index). It does not clearly distinguish from sibling add_pattern_annotation, though that tool is obviously for creating. The purpose is discernible but not precise.

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 use this tool versus alternatives. It does not mention that it retrieves annotations for a specific pattern, nor does it contrast with add_pattern_annotation or other get tools. The agent is left to infer usage from the name and 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?

No annotations are provided, so the description carries full burden. It states the tool retrieves bounding box dimensions but does not disclose units, coordinate system, return format, or error behavior for invalid indices. Minimal disclosure for a getter with no annotation support.

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 extremely concise and front-loaded, with a clear one-sentence purpose followed by the parameter explanation. Every word earns its place, no fluff.

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

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

For a simple getter with one parameter and no output schema, the description is mostly complete. However, it lacks return format details (e.g., width/height as floats, units) and error handling, which could confuse an agent. It's adequate but not 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?

The schema only defines pattern_index as an integer with no description. The description adds semantic meaning by specifying 'Zero-based index of the pattern piece,' which is valuable. However, it does not elaborate on valid ranges or edge cases, so it's adequate 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 states the tool gets the bounding box (width/height) of a pattern piece, using a specific verb and resource. It distinguishes itself from siblings like get_pattern_info or get_pattern_geometry by focusing on the bounding box, though it doesn't 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?

No guidance is provided on when to use this tool versus other pattern query tools. The description only states what it does, without context on selection criteria or when it's appropriate 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 carries the full burden. It does convey a read-only operation via the verb 'Get' and states the returned information is a total count. However, it does not disclose whether the count includes only main pieces versus internal/topstitch pieces, or what happens if no project is open — behavioral details an agent might need.

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 12-word sentence with zero waste that front-loads the verb and resource. Every word earns its place, and there is no redundant elaboration.

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 trivial zero-parameter, no-output-schema read tool, the description is mostly complete: it states the purpose and scope. Minor gaps remain — the return type is only implied ('total number' suggests an integer) and error behavior for a missing project is unspecified — but nothing blocks 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?

The tool has zero parameters, so the baseline is 4. The description correctly needs no parameter explanation; the empty schema has 100% coverage trivially, and nothing is left ambiguous about invocation arguments.

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 ('Get'), resource ('total number of pattern pieces'), and scope ('current project'). The word 'count' inherently distinguishes this from siblings like get_pattern_list, get_pattern_info, and get_pattern_geometry, so an agent can tell it apart without opening 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 provides no guidance on when to use this tool versus alternatives such as get_pattern_list or get_pattern_info. There is no mention of when a count is preferred over a full list, no exclusions, and no prerequisites (e.g., requiring an open project), leaving the selection decision entirely 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?

With no annotations provided, the description carries the full burden and does disclose substantial behavior: line lengths, start/end points, seam coverage, sewn_together pairing, twisted-seam handling, and pocket fold-over behavior. It does not explicitly state 'this is read-only/no side effects,' though 'Get' plus the preparatory framing implies it.

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 every sentence earns its place, explaining seam semantics that are essential for correct downstream use. It front-loads the main purpose and usage, then parameter details. It is somewhat long, but the complexity of the returned geometry justifies the length.

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

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

Despite having no output schema and no annotations, the description comprehensively explains what is returned, the meaning of line_index, coordinate units, seam pairing rules, and parameter effects. It gives an agent enough context to correctly call the tool and interpret its output for sewing and editing workflows.

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. It explains pattern_index as filtering to one piece and its touching seams (default all), and include_points as adding every point of every line with a larger-output warning. This meaningfully exceeds the bare schema definitions.

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: 'Get pattern pieces with numbered outline lines, internal shapes and all seams.' It clearly distinguishes the tool from siblings like get_pattern_info and get_pattern_list by framing it as the source of line_index values for line-based editing and sewing 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 explicitly says 'Use this before sewing or editing lines' and explains why, since every line-based tool takes the line_index values returned here. It gives a clear use context but does not explicitly name alternative tools or state when not to use this tool.

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

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

The verb 'Get' strongly implies a read-only operation and the description makes no claim of side effects. However, there are no annotations confirming safety, and the description does not explicitly state that the pattern is unmodified or mention any error/permission conditions. For a simple getter this is acceptable but not rich.

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: one clear purpose sentence and one argument definition with no filler. It is front-loaded and 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 one-parameter getter, the description is minimally sufficient for invocation: the agent knows which argument to provide and that the result is pattern information. But with no output schema, 'detailed information' is vague, and the agent cannot know what fields will be returned until runtime.

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 only says 'pattern_index' is an integer, while the description adds the important semantic that it is a zero-based index of the pattern piece. This fully documents the single required parameter, though it omits bounds or out-of-range behavior.

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

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

The description uses 'Get detailed information about a specific pattern piece,' which clearly names the verb and resource. It distinguishes itself from list-oriented siblings like get_pattern_list and get_pattern_count, though it does not explicitly separate itself from other per-piece getters such as get_pattern_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?

There is no guidance about when to use this tool versus get_pattern_geometry, get_pattern_bounding_box, or get_pattern_state. The description provides no context for choosing it over alternative information-retrieval tools.

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

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

With no annotations, the description carries the full behavioral burden. It communicates a read-only listing operation and specifies the output fields (indices and names). It stops short of stating ordering, pagination, or empty-result behavior, but for a zero-parameter getter this is not a material 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 sentence that front-loads the action and resource, with every word adding information. There is no verbose or redundant content.

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

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

For a zero-parameter list tool with no output schema, the description provides the essential contract: all pattern pieces, indices, and names. Nothing else is required to select or invoke 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?

The tool has zero parameters and the input schema has no properties, so there is nothing for the description to explain about parameter semantics; the baseline score of 4 applies.

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

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

The description uses a precise verb and resource: 'Get a list of all pattern pieces with their indices and names.' It clearly states the scope ('all') and the returned data (indices and names), so an agent can distinguish it from count or single-info tools without opening a schema.

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

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

The wording implies this is the tool to use when enumerating all pattern pieces, but it does not explicitly say when to prefer it over sibling tools such as get_pattern_count or get_pattern_info, nor does it name 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether any side effects occur, or what prerequisites exist (e.g., pattern must exist). While being a 'get' implies non-mutating, this is not explicitly stated, and no additional behavioral context is given.

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 unnecessary words. It lists the key returned attributes concisely and front-loads the main action. This is appropriately sized for a simple getter 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?

Given there is no output schema, the description should clarify what the return value looks like (e.g., a structured object with those fields, or separate values). It also does not explain domain-specific terms like 'solidify state' or '3D arrangement'. For a tool with one parameter and no output schema, the description is too sparse to fully guide correct invocation and interpretation of results.

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 0% coverage for pattern_index, and the description does not explain what pattern_index refers to (e.g., index into the pattern list) or its expected format/range. The parameter name is somewhat self-explanatory, but the description adds no meaning beyond the name, failing to compensate for the lack of schema 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 ('Get') and clearly enumerates the attributes returned (layer, solidify state, grain direction, shrinkage, 3D arrangement). This makes the tool's purpose clear, though it does not explicitly contrast with siblings like get_pattern_info or get_pattern_geometry, which might overlap. The specificity of the listed fields is a strong positive.

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

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

There is no guidance on when to use this tool versus alternatives such as get_pattern_info, get_pattern_geometry, or set_pattern_state. The name implies it is for retrieving state, but the description provides no explicit when-to-use or when-not-to-use conditions, leaving the agent to infer usage.

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

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

With no annotations, the description must carry the behavioral burden itself. 'Current' and the read-only framing make clear this is a query, not a mutation. It also discloses that results are scoped to either the pattern window or print layout. It stops short of describing the response shape or edge cases, but for a simple getter 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 a single sentence with no filler. The resource is front-loaded, the content of the settings is summarized compactly, and the parameter-related detail appears naturally at the end.

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

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

For a one-parameter getter with no output schema and no annotations, the description covers the resource, the parameter values, and the kind of data returned. It does not spell out the exact return structure, 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 input schema provides only a type and default with 0% description coverage, so the description must compensate. The parenthetical values 'pattern' and 'print_layout' give the agent the meaningful options for the source parameter and their purpose. It would be slightly stronger if it explicitly said these are the valid values for `source`, but the mapping is clear.

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 read operation: retrieving current 2D export settings, and it enumerates the content (paper, orientation, resolution, and what is shown). It also distinguishes the two modes, pattern window and print layout, which helps differentiate it from the many export_* sibling 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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternatives. However, the phrase 'Current 2D export settings' implies this is the tool to check settings before exporting, and the two source values provide useful context for when each variant applies.

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. 'Get information' clearly signals a read-only operation, and the description discloses the kind of data returned. However, it does not mention what happens when no project is open, whether all counts are current, or any other operational behavior.

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

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

The description is a single sentence with no wasted words. It front-loads the action and resource, then enumerates the returned information in a clear list-like structure.

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 low-complexity, zero-parameter read-only tool, the description is largely complete. It lists the output fields the agent can expect, which is especially important since no output schema is present. It could be slightly more specific about output shape, but the scope is simple enough that this is a minor gap.

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

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

The tool has zero parameters, so the input schema carries no semantic burden. The description does not need to explain parameter behavior, and the baseline of 4 for a zero-parameter tool is appropriate.

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

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

The description clearly states a specific verb ('Get information'), the target resource ('current CLO3D project'), and the data fields returned (name, path, version, counts). It is distinguishable from project-adjacent siblings like get_pattern_info and get_garment_info because it is explicitly scoped to the project level, though it does not explicitly name any sibling as an alternative.

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

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

The description provides no guidance on when to use this tool versus alternatives such as get_pattern_count, get_fabric_list, or get_colorways. It implies usage through 'current CLO3D project,' but there is no explicit context, prerequisites, 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 behavioral burden. It usefully discloses that the tool reports values exactly as CLO's API provides them and explicitly states that stitch length and thread thickness are not readable through the API. This goes beyond the schema and gives the agent realistic expectations, though it does not mention error behavior.

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

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

The description is a single compact sentence with no filler. The main content is front-loaded, and the parenthetical adds a valuable API limitation 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?

For a simple one-parameter read tool, the description names the returned fields and a key limitation. However, it does not connect style_index to list_topstitch_styles or describe edge cases, and there is no output schema to fill that gap. It is adequate but leaves some context to 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?

The schema has 0% description coverage and the description never explains style_index, such as what it indexes into or how it maps to a topstitch style. The parameter name is fairly self-explanatory, but with no schema description and no compensating detail in the tool description, the agent is left to infer the parameter's meaning.

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 resource (topstitch style) and the specific data returned: name, offset, and per-line values. It does not use an explicit verb like 'retrieves', but the tool name and 'as CLO's API reports them' make the read operation clear. It is distinguishable from list/create/set siblings by focusing on a single style's read-only fields.

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 siblings like list_topstitch_styles, set_topstitch_style, or create_topstitch_style. The parenthetical about unreadable stitch length and thread thickness implies a limitation, but it does not name alternatives or conditions for choosing this tool.

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

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

With no annotations, the description carries the full behavioral burden and meets it: it explains the mechanism (adds a band, sews it, freezes it flat like a pin line, lays a rod along it), the visual outcome (looks like a rod pocket from the other side with rod ends showing), and hints at destructibility by advising a checkpoint first. No safety annotations exist to contradict this.

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 prose is front-loaded with the core purpose, then moves to a concise mechanism sentence and a bulleted Args block. Every sentence carries information—constraint, visual result, checkpoint warning, and each parameter—so the length is justified by 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?

For a 7-parameter tool with no output schema and no annotations, the description supplies everything needed: all parameters with units and constraints, the alternative tool, the visual behavior, the multi-panel requirement, and a checkpoint warning. Nothing required to invoke it correctly is missing.

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

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

Schema description coverage is 0%, so the description must explain every parameter, and it does: pattern_index is defined as a panel or list of panels sharing one rod with equal top-edge heights, band_height has a unit and minimum constraint (rod_diameter + 10), rod_side maps 'front' to +z and 'back' to -z, and defaults are stated for fabric_index. This is strong compensation for an empty 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: 'Hang panels on a rod from a frozen header band,' and explicitly separates itself from make_rod_pocket by noting that the folded pocket approach is unreliable with several panels. It names the sibling and the scope, so an agent can tell the tools apart.

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 states the intended use ('the reliable way to hang curtains, noren and banners'), names the alternative and the condition where it is inferior ('make_rod_pocket's folded pocket is not reliable with several panels'), and gives an operational warning ('Save a checkpoint first'). This gives clear when/why guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without revealing side effects. It does not say whether the avatar replaces an existing one, whether a project must be open, whether the scene is modified, or what the result/return value is. For a mutation-style operation, this is a significant transparency 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, short sentence that front-loads the core action and file formats. It contains no redundant wording, and the optional arrangement mention adds relevant information 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?

For a simple two-parameter import tool, the description provides enough to attempt basic invocation, but it is incomplete in important ways. There is no mention of prerequisites, side effects, or behavior after loading, and no output schema exists to fill that gap. Given the simplicity and the absence of annotations, a few extra details about the operation's consequences would make it more complete.

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

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

The description maps the .avt/.avac files to the avatar file path and the .apf file to the arrangement path, adding clear meaning that the schema (0% coverage) entirely lacks. It implicitly identifies file_path as the avatar and apf_path as the optional arrangement. However, it does not explicitly name the parameters or mention path-format requirements, leaving a small amount to inference.

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 the specific verb 'load' with the resource 'avatar' and names the exact file extensions (.avt, .avac), making the tool's scope immediately clear. It also mentions the optional .apf arrangement file, further distinguishing this from generic import_file or avatar-related siblings like get_avatars and show_avatar.

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 import_file, get_avatars, or show_avatar. The description only states the action, not the conditions under which an agent should select it. No exclusions or prerequisites are given, leaving the decision entirely 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?

With no annotations, the description carries the full behavioral burden and does so well. It discloses the destructive/replacement side effect explicitly and explains unit handling and coordinate behavior, including the keep_position false drop-to-ground effect.

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: purpose, key side effect, units, then an Args block. Every sentence adds necessary information 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 three-parameter tool with no annotations and no output schema, the description is complete enough for correct invocation. It covers all parameters, the required file format, side effects, and units, so an agent can call it without needing additional clarification.

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 fully does. It explains file_path as an absolute path to the .obj file, clarifies what keep_position does in practical terms, and gives meaningful scale guidance with a unit example.

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: importing an OBJ file as an object that cloth collides with. It gives concrete examples (curtain rail, furniture) and clearly distinguishes this from file/avatar imports by explaining the collision-object role.

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

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

The description gives clear context about when to use it: when the user wants to bring in their own OBJ geometry as a collision object. It warns about replacing the current avatar and rods/boxes, which serves as an implicit exclusion, but it does not explicitly name alternative tools such as add_box, add_rod, or import_file.

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 must disclose side effects and behavior. It reveals one useful trait (auto-detects type from extension), but does not say whether importing replaces the current project, merges content, requires an existing project, or what happens on unsupported extensions. This is a significant gap for an import operation.

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

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

The description is two compact sections: a one-sentence purpose and a single argument definition. Every sentence contributes, and the key behavior (auto-detection) is front-loaded.

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

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

For a one-parameter tool, the essential invocation detail (absolute file path) is present, and examples of supported extensions are given. However, the description omits the import's effect on the current CLO3D project and does not differentiate from open_file, so an agent may not know the correct context for calling it.

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 only declares file_path as a string with no description, so the description's 'Absolute path to the file to import' adds the key semantic that the path must be absolute and points to the file. It does not enumerate all supported extensions or constraints, but for a single required parameter this is adequate 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 opens with a clear verb and object ('Import a file into CLO3D') and adds the auto-detection behavior from extension, which helps distinguish it from more targeted imports like import_avatar or import_collision_object. It does not explicitly name sibling tools, but the scope is clear enough.

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 about when to use import_file versus open_file, import_avatar, or import_collision_object. The description only states what the tool does, not the conditions that select it over alternatives.

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

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

With no annotations, the description itself conveys a non-mutating 'List' behavior and the newest-first ordering. It adds useful behavioral context, though it does not mention limits or what checkpoint fields are returned.

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?

Five words state the operation, object, and sort order with no filler. Every word carries meaning and the main action is front-loaded.

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

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

For a parameterless read-only list tool, the description covers action and ordering. Since there is no output schema, a bit more detail on what checkpoint data is returned would be ideal, but it is not required for successful 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?

There are zero parameters, so the schema has no burden and the description does not need to document arguments. The baseline 4 applies because a no-parameter tool cannot gain meaning from parameter 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?

Identifies the exact operation (list), the resource (saved checkpoints), and the result ordering (newest first). This clearly distinguishes it from save_checkpoint and restore_checkpoint and from the various pattern/fabric list 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 for reviewing saved checkpoints, and the sibling set contains save/restore as related alternatives. However, it does not explicitly state when to choose this over restore_checkpoint or when not to use it.

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