clo3d-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
Most tools have clear resource/action separation (pattern_, snapshot_, avatar_, scene_, checkpoint_), but several overlapping pairs exist: clo_run_python vs clo_api_search vs clo_api_doc (all about understanding/executing CLO API), clo_status/launch/stop_bridge are distinct but 'garment_plan_preview/build/re_build' have empty descriptions, and garment_rebuild's purpose overlaps conceptually with pattern_edit_points/pattern_ops for modifying garments.
Naming Consistency3/5Mostly consistent 'verb_noun' snake_case (pattern_create, scene_open, avatar_list), but there are deviations: some use bare nouns (arrangement_points, scene_info, snapshot), some prefix with 'clo_' while others don't, and 'garment_plan_preview'/'garment_build' sit awkwardly next to 'clo_run_python' and 'sew'.
Tool Count2/548 tools is heavy for an MCP server. While the domain (3D garment simulation) is broadath, the count approaches 50, which burdens agent tool-selection. Several tool families (clo_api_*, checkpoint_*, fabric_*, garment_*) could be consolidated or trimmed.
Completeness3/5Core lifecycle is covered: scene management, pattern creation/editing, simulation, checkpoints, garment rebuilds, and avatar handling. However, notable gaps exist: no tool to delete a seam or unsew pieces, no fabric creation/management beyond listing and assignment, no animation/pose control for avatars, and garment_plan_preview/build appear to exist but have empty descriptions, leaving their capabilities unclear.
Average 3.5/5 across 48 of 48 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the core action but, with no annotations, leaves the full burden on itself. It does not disclose whether existing placements are replaced, whether an avatar must be loaded, or what errors/side effects may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tight sentence with concrete point examples. No filler words; it earns its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter placement tool, the examples are useful, but the description omits the meaning of the 'pattern' parameter, how to discover valid arrangement points, and behavioral details such as whether existing placements are replaced. It is minimally viable but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It gives valid examples for 'point' but never explains what 'pattern' refers to, what format it expects, or where valid values come from.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Place') with a clear resource ('avatar arrangement point') and concrete examples of valid point names (Body_Front_Center_3, Leg_Skirt_Back). It is reasonably distinct from sibling tools like arrangement_points, though it does not explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, when to call arrangement_points first, or what prerequisites must be met. The action is clear, but the decision context is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'save to a path' with no mention of side effects (e.g., overwriting, creating directories), prerequisites (e.g., a loaded scene), or return behavior. This is insufficient 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence with no superfluous words. The verb and subject are front-loaded, making it easy to scan. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the thumbnail parameter, file path conventions, error handling, or any side effects. An agent cannot confidently call this tool without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It implicitly explains 'path' as the destination, but the 'thumbnail' parameter is completely unmentioned. The description adds minimal meaning beyond the schema and fails to cover one of two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (save) and the resources (project .zprj or garment .zpac) and destination (a path). It distinguishes from checkpoint_save by implying file-based output rather than internal state. However, it does not explicitly differentiate from scene_export, which might also save to a file, so it's not fully specific to sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like checkpoint_save, snapshot, or scene_export. It neither states typical scenarios nor contrasts with other save/export tools. An agent would have no clues about which tool to pick for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavioral side effects. It only says 'load an avatar' and gives accepted identifiers; it does not mention whether the avatar replaces the current one (which the 'replace' parameter implies), what happens on failure, or how the loaded avatar becomes active (scene vs in-memory). 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that starts with the action, then specifies types of accepted inputs. No filler, no unnecessary details; it is appropriately sized for a low-complexity tool with only two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a 0% schema description coverage, the description is too sparse to be fully usable. The missing meaning of `replace` and unspecified consequence of loading leave an agent guessing. For a simple tool, a short paragraph with these details would be advisable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the tool description must compensate. It effectively documents `name_or_path` by enumerating valid aliases and confirming file name/path usage, but the `replace` parameter is entirely left unexplained. The partial contribution raises this from an inherent baseline, yet it falls short of full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('load') and the resource ('avatar'), and it gives a concrete list of accepted aliases plus files/paths. This distinguishes it from sibling tools like avatar_list or avatar_measurements by the verb, but it does not explicitly contrast itself with those tools, so a small clarity window remains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance about when to use this tool versus alternatives is provided. It implies its purpose through naming, but there is no 'use this when...' or 'instead, use...' statement, leaving an agent to infer context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It states 'Add a fabric' implying a mutation, but does not disclose what happens to existing fabrics, whether the operation overwrites or merges, what 'pieces' refers to (since no such parameter exists), or any prerequisites such as needing a fabric library loaded. It also doesn't mention errors, reversibility, or return behavior. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the primary action and then adds the optional parameters. There is no fluff or repetition, and it manages to convey the accepted input forms for fabric. It loses a point because the density makes the missing 'patterns' parameter and the ambiguous 'pieces' reference more glaring, but the structure itself is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema description coverage, the description is expected to fully explain all parameters and usage context. It covers fabric, color, and texture_image, but completely omits the 'patterns' parameter, which appears in the schema but is unexplained. It also introduces 'pieces' without a schema property, leaving the agent to guess how to specify target pieces. No prerequisites, side effects, or return details are provided, making this inadequate for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's lack of documentation. It provides useful examples for 'fabric' (keyword, library file, .zfab), 'color' (#hex or name), and 'texture_image' (base texture), but says nothing about 'patterns' (an array of strings), which is a required explanation. It also mentions 'pieces' as an assignment target without any corresponding schema parameter, creating confusion. The description is incomplete for the full parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'Add a fabric... and assign it to the given pieces.' It specifies the types of fabric inputs (keyword, library file, .zfab path) and notes the default behavior (assign to all pieces). While it doesn't explicitly contrast with sibling tools like fabric_set_color or fabric_set_texture, the action of adding and assigning a fabric is distinct and unambiguous. It could be a 5 with explicit differentiation, but it's already quite clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'assign it to the given pieces (default: all)', which tells the agent when this tool is appropriate (when applying a fabric to pieces). However, it gives no explicit guidance on when to use this tool versus alternatives such as fabric_library, fabric_list, fabric_set_color, or fabric_set_texture. There are no exclusions or conditional instructions, so the agent must infer that this is the primary fabric-assignment tool. That is sufficient but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 states the tool returns fabrics in the object browser, but it does not disclose whether this is a read-only operation, whether it returns full fabric data or just names, or whether it reflects unsaved changes. The behavior is minimally described but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. It is front-loaded with the resource name. However, it could be slightly more informative by adding a verb or a hint about the return format, but for a zero-parameter list tool, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is mostly complete: it tells the agent what it returns and the scope. However, it does not mention whether the result is a list of names or full fabric objects, and it does not clarify the difference from fabric_library. Given the sibling context, a bit more detail would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description adds context by scoping the result to the project's object browser, which is useful. With no parameters, the baseline is 4, and the description does not need to explain parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fabrics currently in the project's object browser.' states a clear resource (fabrics) and a scoping context (project's object browser), but it does not use a verb like 'list' or 'get'. It is distinguishable from fabric_library (which likely lists library fabrics) and fabric_apply, but the lack of an explicit action verb makes it slightly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like fabric_library or fabric_apply. The description implies it is for viewing fabrics in the current project, but it does not explicitly state when to prefer it over fabric_library or other fabric tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 it applies an image as a texture, but does not disclose whether this is a mutation (likely yes), whether it modifies the fabric permanently, whether it requires a running CLO instance or specific permissions, or whether it replaces existing textures. The description is minimal and does not disclose potential side effects (e.g., overwriting the base texture without undo).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the main purpose without fluff. It is well-structured, though the placement of the map types in parentheses is slightly parenthetical but acceptable. It earns a 4 because it is efficient but slightly ambiguous about the primary use case (base colour vs. other maps).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 0% schema description coverage, this description is inadequate. It does not explain how 'map' affects the operation, what happens if the image path is invalid, whether the fabric must be loaded first, or what success looks like (e.g., no return value). It mentions multiple map types but does not detail their differences, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description mentions the 'map' parameter (base colour, normal, roughness, opacity) but does not explain the semantic meaning of 'fabric_index' (which fabric) or 'image_path' (what formats are supported, absolute vs relative). It adds some value for 'map' but leaves the other two parameters underspecified, which is insufficient given zero coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (apply an image) and the target resource (fabric's base colour texture or other maps), which distinguishes it from siblings like fabric_set_color (which sets a color) and fabric_apply (which probably applies a fabric to a garment). However, it doesn't explicitly mention that it modifies an existing fabric's texture, which could be inferred but not stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to set a texture on a fabric), but does not explicitly state when to use this over alternatives like fabric_set_color (for colors) or fabric_apply (for applying a fabric). It also doesn't mention prerequisites like the fabric needing to exist or the image path being valid. The context provided by the 'map' parameter suggests usage for different map types, but no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 reveals that deletion can happen by name or index, but it does not state whether deletion is permanent, how invalid or duplicate patterns are handled, or whether indexes are zero-based or one-based. This is a meaningful gap for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the core action and selection mechanism are front-loaded. It is appropriately brief for a simple one-parameter tool, though slightly too terse for a destructive operation to earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema, so the structural burden is low. But because it is destructive and has no annotations, the description should provide more context about reversibility, error behavior, and how indices are expressed. As written, an agent cannot confidently invoke it without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the schema only says patterns is an array of strings. The description adds the key semantic that each string may be a piece name or an index. However, it leaves the index format unspecified and does not explain how the tool distinguishes names from indices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('delete'), a resource ('pieces'), and a selection mechanism ('by name or index'), which clearly separates it from sibling tools like pattern_create or pattern_list. It stops short of 5 because it does not explicitly differentiate from pattern_ops or clarify whether 'pieces' means pattern pieces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings such as pattern_edit_points or pattern_ops, and no stated prerequisites such as listing available patterns first. The only usage signal is the delete verb itself, which is weak for a destructive operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It names the two categories of returned data (scene avatars and library .avt files), which is useful, but it does not describe the return format, whether the list is read-only, ordering, or any caveats. For a listing affordance this is a thin disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the tool's purpose and covers both data sources without waste. It is appropriately sized for a zero-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description bears responsibility for explaining what the agent will receive back. It does not describe the return format (e.g., array of names, object structure), which is a notable gap for a list tool whose entire purpose is to return data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, so there is nothing for the description to explain. The baseline of 4 for a zero-parameter tool applies; the description correctly needs no parameter elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states what the tool lists: avatars in the scene and .avt files in the CLO asset library. It uses an implied verb (list) that matches the name, and the two data sources (scene + library) are clearly specified. It implicitly differentiates from siblings like avatar_load (loading) and avatar_measurements (measuring), though it doesn't name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 avatar_load, avatar_measurements, or other scene-info tools. No conditions for use, no exclusions, and no alternatives are mentioned. An agent must infer from the name that this is an inventory/lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations existфайл; the description carries the full burden. It lists operation names and arguments but never states side effects, whether operations mutate the piece, return values, or prerequisites. For a mutating operation set this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Terse and front-loaded; the operation list is a compact reference. Slightly dense, but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There are no annotations and no output schema; side effects, prerequisites, value ranges, and result behavior for the many operations are unexplained. Ambiguous arguments like 'flip{horizontal,each}' and move_2d coordinate semantics leave the agent guessing, so important invocation context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, so the inline op signatures add real meaning (accepted op names and their arguments), which is essential. However several argument meanings remain ambiguous (e.g., 'flip{horizontal,each}', 'move_2d{x,y|dx,dy}' distinctions, 'strengthen{on}'), and the 'pattern' parameter is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear resource ('Piece') and enumerates specific operation verbs (rename, move_2d, flip, copy, etc.). It doesn't explicitly contrast with pattern_edit_points, but the operation list makes the tool's scope reasonably recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of pattern_edit_points, pattern_create, or other siblings. The operation list implies coverage, but no prerequisites, exclusions, or selection hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation ('Read') but does not disclose potential side effects, failure modes, rate limits, or authentication requirements. It doesn't mention what happens if the function name is invalid or not found. The description is too sparse to be behaviorally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose is front-loaded in the first sentence, and the input hint in the second. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, likely returns documentation text) and has an output schema, so the description doesn't need to explain return values. However, it lacks guidance on how to discover function names (e.g., use clo_api_search) and what to do on errors. This is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 value by recommending a qualified name format with an example ('pattern_api.GetPatternCount'), which gives the agent a concrete pattern. However, it doesn't fully define acceptable formats or what happens with unqualified names, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('live documentation for a CLO function'). It is distinct from siblings like clo_api_search (which searches) and clo_api_call (which executes), though it doesn't explicitly name alternatives. The example of a qualified name adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like clo_api_search or clo_api_describe. The only hint is the input example, which is about formatting the function_name, not about usage context. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool exports the garment and lists formats, but it does not disclose side effects (e.g., whether files are written to disk, whether it overwrites existing files, whether it requires a path to a directory or file, or whether it blocks until export completes). For a tool that writes files, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, then lists formats. It is concise and scannable, though the format list is a bit dense and could be structured (e.g., grouped by type). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file-export tool with no annotations and no output schema, the description is thin. It does not explain the return value (e.g., success status, exported file paths), error conditions, or parameter semantics. An agent would need to guess whether 'path' is a directory or a full file path, and what the boolean flags do. The format list is helpful but not sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 not explain the 'path' parameter (file path vs. directory), 'colorways' (whether to export all colorways), or 'include_avatar' (whether the avatar mesh is included). The format list hints at what the export produces but does not map formats to parameters. Baseline 3 is appropriate because the description adds some context but leaves parameter meaning largely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Export') and resource ('the garment'), and enumerates the supported file formats. It distinguishes itself from siblings like scene_save (which saves a scene) and snapshot (which captures a view), though it doesn't explicitly name an alternative. The format list adds specificity that helps an agent understand the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need to export the current garment to a file format. It does not explicitly state when to use this vs. alternatives like scene_save or snapshot, nor does it mention prerequisites (e.g., a garment must be loaded). The format list gives some context but no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Capture' implies an action but does not disclose what the tool does precisely (e.g., returns an image, saves a file, or just copies to clipboard), nor any side effects or requirements. The description is too terse to adequately inform the agent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is appropriately front-loaded. It conveys the core action and context without any fluff. Perfectly efficient for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description still fails to explain the result of the snapshot (e.g., where it is stored, what format, or how to retrieve it). Additionally, it does not clarify how this differs from the sibling 'snapshot' tool, leaving a potential gap in tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already covers all parameter semantics trivially. The description adds no parameter-specific information, but none is needed. Baseline 4 applies per the rubric for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Capture') and resource ('the 2D pattern window') and adds context ('pattern pieces layout'). It is clear and matches the tool name, but it does not explicitly differentiate from the sibling 'snapshot' tool, which may have a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or contrasts with other capture tools like 'snapshot' or 'clo_ui_screenshot'. The agent is left to 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the permission requirement (Accessibility), that no bridge is needed, and that it returns a snapshot token. However it doesn't describe the output structure beyond the token, nor performance implications of max_depth/max_nodes — gaps 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences with no filler; the purpose, workflow, and requirements each earn their place. The only minor issue is a slightly jumbled ordering (requirements come last rather than being front-loaded with the purpose), but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two optional parameters (both defaulted) and no output schema, the description covers purpose, usage workflow, and prerequisites reasonably well. What's missing is parameter documentation and a clearer picture of the returned snapshot structure, though the tool's low complexity keeps these gaps moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the two parameters, but it mentions neither max_depth nor max_nodes. The parameter names with defaults are somewhat self-explanatory, but the description adds zero value on how they affect the snapshot. This is a clear gap given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Inspect') and a specific resource ('CLO accessibility hierarchy, menus, dialogs, values and supported actions'). It distinguishes from the closest sibling clo_ui_action by describing inspection rather than action, and the mention of returning a snapshot token differentiates it from clo_ui_screenshot. Clear purpose, though it doesn't name the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides workflow context: 'Returns a snapshot token; use it for the next UI action' implies this should be called before invoking the action tool. It also states prerequisites ('No bridge needed', 'Requires macos extra and Accessibility permission'). However, it never names alternatives or gives explicit when-to-use / when-not-to-use exclusions, leaving much to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior itself. It indicates the tool is a read operation (returns a summary) but does not state side effects, error conditions (e.g., what happens if no garment was built), or that it is non-destructive. For a retrieval tool, this is minimal behavioral coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that directly states the tool's output. There is no fluff or redundancy, making it maximally concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a general idea of the return value (spec and plan summary) but lacks specifics such as the format, exact content, or behavior when no garment has been built. With no output schema, the description is the only source of return info, so this gap is notable but acceptable for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 no parameter-specific information because none exist. This score reflects that no semantic gaps are present beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: 'the normalized spec and plan summary of the last garment built in this session.' This is specific and distinguishes it from sibling tools like pattern_info or fabric_list. Though it lacks an explicit verb, the name and phrasing imply retrieval, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or prerequisites. It only states what the tool returns, leaving the agent to infer its purpose from the name. Without mention of alternatives like garment_build or pattern_info, the agent gets no clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose a key behavior: it replaces existing pieces and re-simulates. However, it does not mention whether this overwrites state irreversibly, whether snapshots mitigate that, or what conditions are required before calling it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences: the first states the action with concrete examples, the second states the side effect. No filler, no repetition of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and low schema coverage, the description must carry more weight. It explains what the tool does and the primary parameter, but omits the meaning of snapshots and simulate_steps, prerequisites (an existing last built garment), and what success/errors look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It gives useful examples for the changes object but leaves snapshots and simulate_steps entirely unexplained, and it does not specify the accepted value format beyond examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Re-draft') with a clear target ('the last built garment') and explains the effect: replacing pieces in CLO and re-simulating. It is distinguishable from garment_build because it operates on the most recently built garment, though it does not explicitly compare to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'last built garment' implies this is for modifying an existing garment rather than creating a new one, which provides implicit context relative to garment_build. However, it gives no explicit guidance on when to choose this over alternatives, what prerequisites exist (e.g., a garment must already exist), or when to prefer other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states 'List saved checkpoints', implying a read-only operation, but does not disclose any side effects, permissions, or whether it has any impact on state. There is minimal behavioral detail, such as whether it returns a snapshot or live data, which is a gap given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It directly states the action and resource, and is front-loaded with the key information. There is zero waste, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is adequate. It tells the agent what it does. Given the sibling names like checkpoint_save and checkpoint_restore, the notion of checkpoints is likely understood. However, it does not clarify what a checkpoint is or provide any details about the returned list, but this is not strictly necessary for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The schema is empty and coverage is 100% by definition. Since there are no parameters, the baseline of 4 applies, and the description does not need to add anything beyond what the schema provides. It correctly omits any parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'saved checkpoints', which identifies the action and object. It distinguishes from siblings like checkpoint_save and checkpoint_restore by being the listing operation, though it does not elaborate on the contents or format of the list. This is clear enough for an agent to understand the basic function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that this is the only way to list checkpoints, when to prefer it, or any exclusions. Siblings like checkpoint_save and checkpoint_restore are not referenced, leaving the agent to infer the appropriate context 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's content area but does not state whether it returns info, is read-only, performs any verification actions, or has side effects—leaving the agent uncertain about the tool's behavior beyond its name and vague 'routing guide' label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the tool's central purpose. It includes only the necessary caveat about scope ('absent from the API') and content highlights (desktop prerequisites, verification). The phrase 'routing guide' is a bit vague but does not add filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter guide tool with no output schema, the description gives key context about why the guide exists and what topics it addresses. It does not elaborate on what 'verification' means or what format the guide takes, but for a simple informational tool this is roughly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially complete at 100% coverage. With no parameters, the baseline is 4, and the description does not need to compensate for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'routing guide for CLO functions absent from the API, including desktop prerequisites and verification,' which identifies a specific verb and resource. It also differentiates from API-related siblings (e.g., clo_api_search, clo_api_doc) by targeting functions unavailable in the API, though 'routing guide' is not as precise as a plain verb like 'lists' or 'explains'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when a CLO function is not available in the API and when desktop prerequisites or verification are relevant. However, it does not explicitly name alternatives or conditions for choosing it over similar guides, leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It makes the mutating nature of the operation clear and documents accepted color formats, which is useful. It does not, however, disclose downstream consequences (e.g., whether already-applied garments update), behavior on invalid color input, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single 17-word sentence with no filler. The operation and target are front-loaded, and the parenthetical value-format note earns its place as it directly informs how to fill the `color` parameter. Nothing could be trimmed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter setter with no output schema and no annotations, the description covers purpose and color format adequately. Remaining gaps include the unexplained fabric_index provenance, lack of sibling differentiation, and no error/edge-case behavior. It's sufficient for an agent to make an educated guess, but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It fully documents `color` by specifying '#hex' or colour name formats, but gives no guidance on `fabric_index` — where to obtain it, what it points at, or its zero-based vs one-based nature — beyond the weak hint 'already in the project'. Compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Set') and resource ('base colour of a fabric already in the project'), and adds precision by specifying accepted value formats ('#hex' or colour name). The scope qualifier 'already in the project' meaningfully narrows the operation. However, it doesn't explicitly contrast with siblings like fabric_set_texture or fabric_apply, leaving differentiation implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'already in the project' implies a prerequisite — the fabric must exist before calling — which offers some contextual guidance. But there is no explicit when-to-use guidance, no mention of alternatives (e.g., fabric_library for adding fabrics, fabric_set_texture for texture), and no indication that fabric_index likely comes from fabric_list. Usage context is implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 explains the point type semantics and line ordering, which is helpful for input, but it does not disclose side effects (e.g., does it replace an existing pattern, become active?), permissions, or what the return value is. For a mutation tool, this is a significant gap; the agent is left uncertain about state changes and required context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two-sentence block that front-loads the core purpose and then packs essential input details (point types and line numbering) efficiently. It does not waste words, though it could be slightly better organized with a bulleted list for the type codes. Overall it is well-structured and appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates complex pattern geometry, the description covers the input format thoroughly, including point types and line ordering, and touches on placement via arrangement. However, it does not mention what happens after creation (e.g., whether the new pattern becomes active, how to reference it later), nor does it state any prerequisites like an open scene. Given no output schema and no annotations, the agent lacks guidance on post-conditions and broader workflow integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 substantial meaning to the 'points' parameter by detailing the array format, type codes, and line numbering, and it indirectly explains 'arrangement' by referencing arrangement_points. However, the 'name' parameter is completely ignored; the schema only gives a default of ''. Since the description covers two of three parameters meaningfully but omits one, it earns a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'Create a pattern piece from outline points', and specifies the exact input format (points array with types) and the coordinate system (mm, Y up). It differentiates from siblings like pattern_edit_points (modify existing) and pattern_list (list) by focusing on creation. The line-numbering rule is an additional specific detail that makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies creation for new pattern pieces but does not explicitly state when to use this tool versus alternatives like pattern_edit_points or pattern_ops. It does mention 'Optionally place it on an arrangement point (see arrangement_points)' which provides a hint for arrangement usage, but it lacks explicit exclusions or conditions. An agent would have to infer the when-not from the verb 'create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The name and 'Current...' phrasing imply a read-only snapshot, but the description never explicitly states that it does not modify the scene or what happens if no scene is loaded. With no annotations, this lack of explicit side-effect disclosure is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One terse, front-loaded sentence that lists the important scene categories without extra prose. The parenthetical clarifies that pattern pieces include arrangement point and fabric data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify the shape or granularity of the returned data; the category list helps but leaves open whether it returns IDs, names, full objects, or counts. The presence of many sibling introspection tools also creates a need to mention what makes scene_info the right broad-scope call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parametersbool Result. The description compensates well by enumerating the scene's subcomponents (project, avatars, pattern pieces, fabrics, colorways, seams), giving the agent a concrete sense of what information will be available. Baseline for zero-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('Current CLO scene') and enumerates the main content categories: project, avatars, pattern pieces, fabrics, colorways, and seams. It communicates the purpose of returning an overview of the scene, though it lacks an explicit verb like 'returns' or 'lists.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use scene_info versus sibling tools like scene_open, pattern_list, fabric_list, seams, or avatar_list. The description does not mention prerequisites, such as needing an open scene, nor when this broad scene view should be preferred over targeted sub-resource getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that passing -python clo_bridge.py is attempted but may not work, and advises a manual workaround. This is transparent about limitations and required follow-up. However, it does not mention potential side effects or failure modes beyond the bridge.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the primary action first, then adds a caveat. No wasted words; the structure is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the launch action and bridge quirk but omits parameter semantics and usage differentiation. It does not mention prerequisites, expected output, or how it integrates with the broader tool set. Given the parameter is undocumented, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 mentions the bridge attempt, which likely relates to the with_bridge parameter, but does not explicitly define what true/false does. The parameter's role is only implied, leaving ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Launch CLO') and clarifies the platform (macOS). It distinguishes from siblings like clo_status or clo_stop_bridge by focusing on the launch itself. The mention of the bridge attempt adds context without confusing the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies a sequence (launch then start bridge) but does not name any sibling tool or conditions for selection. An agent cannot infer when to prefer clo_launch over other CLO tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the behavioral burden. It usefully discloses pre-imported modules, stdout capture, coordinate conventions, and return-value semantics. However, it omits significant safety context: running arbitrary Python can mutate the CLO document, create/delete objects, or perform destructive actions, which is critical for an agent to understand before invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise, information-dense sentences with no filler. The most important facts are front-loaded, and the example concretely anchors the usage. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a powerful code-execution tool with no output schema and no annotations, the description covers core mechanics well: modules, return conventions, stdout, and units. But it lacks explicit warnings about side effects on the current scene, persistent state changes, or error behavior, which are important for safe and correct use in an autonomous agent context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 `code` by explaining expression vs. assignment semantics, stdout capture, and the example pattern. `timeout_seconds` is not addressed, though its name and default make it mostly self-explanatory. The compensation is partial but adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Run Python inside CLO with the CLO API modules pre-imported.' The list of modules and the concrete example make the resource unambiguous. Among sibling tools, it is clearly distinct as the generic Python execution entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to write code (expression vs. assignment to `result`) but gives no guidance on when to prefer this tool over siblings like clo_api_call, clo_api_search, or clo_status. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. 'List' implies a non-destructive read operation, which is helpful, but it does not disclose output format, ordering, or any other behavioral details. For a zero-parameter read tool this is acceptable, though 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. It front-loads the action and the target resource without redundant phrasing, making every word meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool, the description conveys the essential operation and output subject. It could add more context about what a sewing group is or how the pieces are represented, but nothing critical is missing for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema offers no additional meaning to add. The description does not need to explain parameter behavior because there are none. This aligns with the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and names a concrete resource ('sewing groups and the pieces involved'), so an agent can tell this is a read-only listing tool. It does not explicitly contrast with sibling list tools like pattern_list or fabric_list, but the seam-specific domain is clear enough to distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. While 'List sewing groups' implies a natural use case, the description does not state exclusions, prerequisites, or which sibling tools handle related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 basic action and the default views; it does not mention return format (e.g., image paths vs. binary data), potential side effects (e.g., whether the scene is modified), or any prerequisites like having the 3D window open. This is a material gap for a tool 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating the core function, followed by a list of view options and the default. Every word earns its place, and key information (default views) is front-loaded. There is no redundant verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers the main parameter (views) and purpose. However, with no annotations and no output schema, it does not explain the return structure or the 'label' parameter, and it omits any prerequisites (e.g., needing a scene open). An agent might call it correctly, but there are gaps that could cause misinterpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does explain the allowed values for the 'views' parameter and gives a default, which adds real value. However, it completely ignores the 'label' parameter, leaving its purpose undefined. Thus the description covers one parameter well but not the other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Capture'), a concrete resource ('the 3D window'), and the output ('return the images'). It also lists valid views, which makes the function's scope unambiguous. The phrase '3D window' differentiates it from the sibling snapshot_2d, so an agent can infer the correct tool 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when a 3D snapshot is needed) and provides default views, but it does not explicitly contrast with snapshot_2d or state any exclusions. There is no 'use this instead of X' guidance, so the usage context is inferred rather than made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 tool lists names for body placement, which implies a read-only operation, but doesn't state return format (e.g., array of strings) or whether it errors if no avatar is loaded. This is adequate for a simple query but leaves some behavioral specifics unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb 'List' and resource 'arrangement points', followed by a parenthetical clarification. Every word earns its place with no redundancy. Ideal length for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 is fairly complete. However, it doesn't specify the exact return type or structure (e.g., whether it's a simple array of names or a mapped object), and it doesn't note potential prerequisites like an active avatar. Given the simplicity, this is a minor gap, so a 3 is fair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects that with an empty properties object. The description adds meaning by explaining what the arrangement points are for ('names used to place pattern pieces on the body'), which is valuable context beyond the schema's emptiness. Since there are no parameters to document, a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'arrangement points', and adds context that these are names used to place pattern pieces on the body. It distinguishes itself from pattern_set_arrangement by focusing on reading vs. setting. However, it does not explicitly name a sibling alternative (like pattern_info) that could overlap, so it's slightly below a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for retrieving arrangement points but gives no explicit guidance on when to use it versus alternatives like pattern_info or pattern_set_arrangement. For a simple list tool, this is acceptable but minimal; it doesn't say 'use this to view, not modify' or mention any preconditions (e.g., avatar loaded).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'no API functions are executed', which is a crucial safety trait, and mentions paging via next_offset. This gives the agent confidence that it is a read-only operation. It does not discuss side effects or error handling, but for a catalog tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and includes key behavioral notes (paging, no execution) without fluff. Every sentence earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a discovery tool with no output schema and four optional parameters, the description covers the core usage: what it does, how to paginate, and that it is safe. It does not explain the return format, but that is less critical for a catalog tool. The absence of annotations is compensated by the explicit no-execution statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 indirectly covers parameters: 'Search names and docstrings' implies the query parameter, 'Modules include rest_api and ApiTypes' explains module, and 'Paged' plus 'next_offset' hints at limit and offset. However, it does not explicitly map each parameter to its purpose, leaving some inference needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers functions, types, and constants in the running CLO version, with a specific verb and resource. It does not explicitly distinguish from the sibling clo_api_search, but the mention of 'no API functions are executed' and paging hints at its read-only catalog role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given, nor are alternatives like clo_api_search mentioned. The description implies it is for exploring the API catalog, but does not contrast it with similar tools. The instruction to follow next_offset is a usage detail, but not about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains that measurements can come from CLO's measurement API, a cache, or an approximation from the mesh, and mentions the prerequisite of opening the Avatar Editor. It does not explain the effect of the 'refresh' parameter, which is a notable gap, but the disclosed sourcing behavior is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core purpose and then adds the source and prerequisite. Every clause contributes meaning, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, units, source, and a prerequisite, which is a solid baseline. However, the behavior of the 'refresh' parameter is unexplained, and since there is no output schema, the return shape is also unspecified. For a one-parameter tool this is not severely incomplete, but meaningful gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'refresh' is not mentioned in the description, and schema description coverage is 0%. The schema's title and default provide only minimal meaning, and the description does not clarify when refresh should be true or what happens when it is set. Given the low coverage, the description should have compensated but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('body measurements of the avatar in the scene'), the unit (mm), and the purpose ('used for drafting'). It lacks an explicit imperative verb like 'get' or 'returns', and does not explicitly differentiate from siblings, but the resource and scope are specific enough that an agent can infer the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: the measurements are used for drafting and may require the Avatar Editor to have been opened once per session. It does not explicitly name alternatives or exclusions, but the use case is stated well enough to guide selection among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 it returns live docstring/overloads/class fields and reflects the running version, implying a read-only query, but it doesn't explicitly state side-effect safety, error conditions, or any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that packs in the purpose, the kinds of information returned, and a version context note, all with representative examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with one parameter and no output schema, the description adequately covers purpose, input format, and version context. Minor gaps (explicit error behavior, return format breakdown) are acceptable given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'name' is clarified through concrete examples ('pattern_api.GetPatternCount or ApiTypes.ImportExportOption'), which establish the expected format of a qualified name. This adds meaning beyond the bare schema (type: string, no description).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('describe') and resource (qualified API names), with concrete examples like 'pattern_api.GetPatternCount'. However, it doesn't explicitly distinguish from sibling tools such as clo_api_doc or clo_api_search, which likely have overlapping documentation purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied through examples (querying a qualified name for its docs), but there is no explicit guidance on when to use this tool versus alternatives like clo_api_search or clo_api_doc. The agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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. The description implies a read-only operation (listing) but does not explicitly state that it has no side effects, nor does it describe the return format or any potential errors. For a simple list tool, this is acceptable but not exhaustive. The agent must infer that this operation is safe and non-mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action and includes the optional parameter behavior. There is zero redundancy or filler. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description covers the essential aspects: what it lists, the scope, and the filter. It does not describe the output format or error conditions, but for a list operation, an agent can reasonably expect a list of fabric identifiers or paths. The absence of an output schema means the description doesn't need to explain return values, but it could have mentioned the structure of the list. Overall, it is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the 'filter' parameter (coverage 0%), so the description must compensate. The description explicitly states 'optionally filtered by substring', which explains the parameter's purpose and behavior. This adds meaning beyond the schema, which only provides a title and default. It could specify case sensitivity or exact matching, but the substring semantics are clearly conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List'), a specific resource ('.zfab fabrics'), and a clear scope ('in the CLO asset library'). It also mentions the optional filter. While it doesn't explicitly name a sibling like fabric_list, the 'asset library' qualifier differentiates it from scene-based fabric tools, making the purpose clear and distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the phrase 'asset library', but it does not explicitly state when to use this tool over alternatives like fabric_list, nor does it mention exclusions or prerequisites. An agent would need to infer that this is for library items, not scene items. There is no explicit 'when to use' or 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose that detail=True adds outline line data and that line indices are what sew() uses, which is useful cross-tool context. However, it does not mention whether this is a read-only operation, performance implications of detail=True, or what the default response shape looks like beyond the field list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core listing behavior, then a compact explanation of the optional detail flag. Every clause earns its place, and the cross-reference to sew() is high-value context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional boolean parameter, the description covers the main behavior and the parameter's effect. It lacks an explicit return format description, but the field list is given and no output schema exists, so the description is reasonably complete. Minor gap: no mention of whether the list is ordered or filtered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does: it explains the single parameter detail and exactly what detail=True adds (outline lines with length/location, seam groups). This is meaningful semantic value beyond the bare boolean schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('pattern pieces') and enumerates the fields returned (index, name, arrangement, fabric, bbox). It distinguishes itself from pattern_info by focusing on listing pieces rather than a single piece's details, though it doesn't explicitly name the sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call it to list pattern pieces, and use detail=True when you need outline lines and seam groups. It does not explicitly state when to prefer pattern_info or seams_list, nor does it give exclusions, so 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a state-changing operation ('Reset') and clarifies the targeted state, but does not disclose side effects, reversibility, or impact on other garment data (e.g., whether modifications are lost). This is a minimal disclosure for a mutation tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It states the action and a clarifying parenthesis, earning its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, no output schema, no annotations), the description is largely complete. It does not mention return values, but for a reset operation this is not critical. The only minor gap is the lack of explicit linkage to related arrangement-setting tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivial and the baseline is 4. The description does not need to explain parameter details; it correctly focuses on the action itself. No additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Reset' and the resource 'garment' to 'arrangement positions', and the parenthetical 'undo the simulation drape' distinguishes it from simulation-related tools. However, it does not explicitly link to a specific sibling like arrange_points or pattern_set_arrangement, leaving slight ambiguity about which arrangement is meant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'undo the simulation drape' implies it should be used after performing a simulation, providing context. But there is no explicit guidance on when not to use it or how it differs from reset-like siblings such as checkpoint_restore, so usage is only implied rather than clearly prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It adds useful behavioral context like 'about 30 steps per simulated second', quality tradeoff labels, and particle_distance effect on speed and fineness. But it does not disclose state mutation, reset requirements, or what the tool returns after running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. Every sentence provides concrete semantic or behavioral value, explaining parameters and performance without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Parameter semantics are well covered, but the tool has no output schema and no annotations, so the description should also mention expected result, side effects, or prerequisites. It is adequate for choosing the tool, but incomplete for fully predicting behavior after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates. Steps, quality, and particle_distance are each given meaningful values and tradeoffs, including numerical scales and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Run the cloth simulation for N steps.' It directly distinguishes this from siblings like simulation_reset or clo_stop_bridge by specifying the action and object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given, and no alternatives are named. It does not tell the agent whether simulation should follow garment construction or when to prefer simulation_reset or scene_export instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the key side effect—'replaces the scene'—which signals that the current scene will be overwritten. However, it does not mention potential data loss, prerequisites (an existing checkpoint), or how failure is handled if the name is invalid. Some important behavioral detail is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the core action ('Reload a checkpoint') and attaches a clarifying outcome ('replaces the scene') in parentheses. Every word contributes to the agent's understanding, making this an exemplary concise definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, no output schema, no annotations), but the description leaves gaps: it doesn't explain what 'name' refers to or how to discover valid checkpoint names. Given that the pointer to checkpoint_save is present and the destructive nature is hinted at, the picture is not wholly inadequate, but it's not complete enough to ensure correct invocation without further investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description for the 'name' parameter, so the description must compensate. It implies that the name identifies a previously saved checkpoint but does not explicitly state that 'name' is the checkpoint identifier or where to obtain valid names (e.g., checkpoint_list). Some semantic value is added, but not enough to fully cover the missing schema context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Reload'), the resource ('a checkpoint saved with checkpoint_save'), and the on-scene effect ('replaces the scene'). It explicitly references the sibling checkpoint_save, and the contrast with scene_open/scene_clear is implicit but sufficient for an agent to understand its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names checkpoint_save as the companion tool, giving context on how checkpoints are produced. It clearly implies this tool is for restoring a previously captured state rather than opening scene files or clearing the scene. It does not explicitly list exclusions (e.g., checkpoint_list for browsing checkpoints), but the intended use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It clearly explains the side effect (saving a named .zprj checkpoint to a path) and the purpose, but does not mention overwrite behavior, name default, limits, or what happens if save fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, and compactly adds the file path, audience, and undo use-case. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one optional-parameter tool, the description provides enough to invoke it for the intended purpose: save a named checkpoint to a known path, then restore later. But it omits behavior for the default empty name, possible return value, or error cases; still, low complexity limits the impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has only an optional 'name' with default '' and 0% schema description coverage. The description adds that the checkpoint is 'named', so `name` identifies the checkpoint, but it does not explain what happens when name is omitted or any naming constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a clear action: save the current project as a named checkpoint. It also gives the exact location (.zprj under ~/.clo3d-mcp/checkpoints) and explicitly ties the tool to undo via checkpoint_restore, which distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: before an edit or seam operation that might fail徒 so it can be undone later. It names the companion tool (checkpoint_restore), though it does not explicitly list exclusions or alternative cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose a meaningful trait—handles expire when CLO restarts—which helps the agent understand handle validity. However, it does not state what happens after release (e.g., whether handles become invalid immediately, whether double-release errors, or whether this is safe to call multiple times).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, the target resource, the timing, and a key lifecycle fact without wasting any words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter release operation, the description gives the essential information: what it releases, when to call it, and how handle lifetime behaves across restarts. It omits return-value details and error semantics, but the operation's simplicity keeps this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must supply meaning for the single 'handles' parameter. It does identify these values as 'native API object handles', which adds semantic context beyond the raw schema. However, it does not explain where the handles come from, their expected format, or what qualifies as a valid handle.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Release') and a clear resource ('native API object handles'), making the tool's purpose immediately recognizable. This distinguishes it from sibling tools like clo_api_search and clo_api_doc, which fetch or describe handles rather than releasing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'when finished' gives explicit temporal guidance for when to call the tool. It does not name alternatives or state when not to use it, but the lifecycle framing ('handles expire when CLO restarts') implies that this is the cleanup counterpart to handle acquisition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the disclosure burden. It adds the bridge prerequisite and the 'running API' scope, but doesn't mention read-only behavior, no-result behavior, or other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, purposeful sentences; verb and target front-loaded, then dependency, then routing to the alternative. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and only two simple parameters, this covers the essential context: scope, prerequisite, and where pagination lives. Minor gap: no detail on what happens when nothing matches.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. It clarifies the query context (search over names and docstrings) and routes pagination elsewhere, but does not explicitly explain the query or limit parameters' formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search'), a precise target ('names and docstrings in the running CLO API'), and distinguishes itself from clo_api_catalog by naming it as the pagination-oriented alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says the bridge is required and points to clo_api_catalog for pagination. It does not fully specify when to prefer one over the other, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It does disclose the read-only nature and that it returns instructions on failure, but it does not clarify what 'instructions' contain, whether any side effects are possible, or any timeout/availability behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. It efficiently states the check, the object, and the failure behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool, this is nearly complete: what is checked, what is returned on failure. It lacks only a bit of detail on the success response or any prerequisites, but these are not critical for a health-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and schema coverage is 100%. The description adds context about what the status check determinesebbende, which is meaningful even without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Check whether CLO is running and the in-CLO bridge is reachable') with a clear subject and scope, and it is immediately distinguishable from sibling tools like clo_launch or clo_stop_bridge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a preflight use case by checking reachability)Skip, but it does not explicitly tell the agent when to call it or when to prefer a sibling (e.g., 'call this before launching' or 'if unreachable, use clo_launch'). The context is clear but no exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the contents of the returned information (lines, points, arrangement, fabric, seams), which is useful. However, it does not explicitly state that the tool is read-only or has no side effects, nor does it mention any failure modes. The nature of 'info' implies a retrieval, but a clearer statement about safe usage would be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the purpose and then lists the specific data categories. It avoids redundancy and every phrase adds value. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description covers the essential information an agent needs: what the tool does, what input it takes (name or index), and the type of output (lines, points, arrangement, fabric, seams). It even specifies points are in 2D mm, which adds detail. It does not mention error handling or the exact output structure, but for a read-only info tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'pattern' with no description, so schema coverage is 0%. The description adds meaning by specifying that the parameter can be a name or index, which clarifies what the user must provide. This is valuable but does not go into format details, so it does not fully compensate for the schema gap, making a 4 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'full information about one piece (by name or index)' and lists the exact data types (lines, points, arrangement, fabric, seams). This distinguishes it from sibling tools like pattern_list (which likely lists multiple patterns) and pattern_create (which creates patterns). The phrase 'one piece' makes the scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific pattern piece needs detail, but it does not explicitly mention alternatives or exclusions. It states the input can be a name or index, but provides no guidance on when not to use this tool or how it relates to other pattern tools. The usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the snapshot token is consumed (one-shot behavior), enumerates supported actions, and includes a safety warning. It does not mention what the tool returns or error behavior, but for a UI input tool the core side effects and constraints are stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and information-packed, starting with a one-line summary and then mapping actions/constraints compactly. It loses a point because the dense run-together style makes some relationships (e.g., which parameters pair with which actions) require inference rather than explicit structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the critical workflow requirement (fresh snapshot token), the action set, coordinate/element usage, modifiers, and keycodes. It doesn't explain parameter pairing (e.g., drag requires end coordinates) or return behavior, but the essential usage pattern for a UI action tool is mostly present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), but the description provides some parameter meaning: scroll uses y, ax_action requires an exposed value, key uses keycode, modifiers are listed. However, several parameters remain ambiguous: end_x/end_y (likely drag target), the difference between `value` for set_value vs text, and when element vs coordinates should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool performs a UI action (one CLO-only UI action) and immediately provides the complete action vocabulary (press, set_value, ax_action, click, right_click, double_click, drag, key, text, scroll), which distinguishes it from sibling tools like snapshot or clo_status that capture or report state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies the prerequisite ('Requires current snapshot token'), explains that 'state is consumed by an action', and warns against guessing coordinates or performing blind action sequences. It does not explicitly name alternative tools for other tasks, but the constraints are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the requirement for Screen Recording permission and warns about coordinate mapping (screen points vs image pixels) in clo_ui_state. However, with no annotations at all, the description carries the full burden of explaining what happens when invoked; it does not state what the capture returns or where the image is stored, so the behavior is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the main action first, then key clarifications about the scope and a permission/coordinate reference. Every sentence earns its place with no redundant padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the missing point is the output: there is no output schema and the description only says the tool captures an image, without whether the image is returned as a file path, base64 string, or MCP resource. The permission and coordinate context help, but this return-value gap leaves an agent uncertain about how to consume the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with full schema coverage, so the baseline is 4. The description contributes a coordinate-related note about the linked clo_ui_state that is meaningful for mapping state coordinates to the screenshot, which goes slightly beyond the basic baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is headed by a specific verb+resource statement ('Capture CLO's window as an image') and clarifies scope ('including UI-only tools and dialogs') and differentiates from API snapshots, which are covered by the sibling snapshot tools. This makes 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes when this tool is useful: for capturing UI-only tools and dialogs that API snapshots don't provide. It helps the agent select it appropriately, but it stops short of explicitly naming alternatives or stating clear 'when not to use' conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and it does disclose the key state-changing modes ('replace' or 'append'). It also limits loading to concrete file categories, which helps an agent predict side effects. It stops short of explicitly warning that replace discards the current scene, but the mode name conveys it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the core action and accepted file types front-loaded and mode values at the end. No filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity open command with only two parameters, the description covers file types, mode choices, and the basic action. It omits prerequisites such as whether CLO must be running and what the call returns, but those are not essential for calling this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds the allowed values for mode ('replace' or 'append') and characterizes path by listing valid extension families. It does not define path format or mode semantics in full detail, hence not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and a clear resource ('a file in CLO'), then enumerates the accepted formats (.zprj, .zpac, .avt, .dxf, pattern .json, .obj/.fbx). This makes it easy to distinguish from sibling scene_* tools such as scene_clear, scene_save, and scene_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for loading existing supported files into CLO and offers a replace/append mode, but it never names an alternative or states when not to use it. An agent must infer that tools like avatar_load or pattern_create may be more targeted for subset operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden — and it delivers: it discloses the JSON serialization format, that non-JSON returns get session handles, that 'a false result is NOT success,' and that timed-out mutations should not be blindly retried. These are exactly the non-obvious behaviors an agent needs for a generic dispatcher, none of which any schema could convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and every sentence carries real value — the safety and retry warnings earn their place for a generic dispatcher. It is slightly dense (six distinct pieces of guidance in a single paragraph), but that density is justified given the complexity and the absence of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic dispatcher with no output schema and no annotations, the description covers purpose, arg construction, handle behavior, and safety. The main gap is error semantics — it warns that false ≠ success but never states what an error looks like (exception vs error object) — though the 'read live documentation first' directive mitigates this since each function's behavior is documented elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the JSON argument syntax ({$type...}, {$enum...}, {$handle...}), which is the hardest part of constructing args. However, it does not explicitly document the 'name' parameter (only implied via 'discovered in clo_api_catalog') or the 'kwargs' parameter, leaving those to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Call any public function discovered in clo_api_catalog, or read a constant') with a clear verb and resource. It distinguishes itself from the discovery/documentation siblings (clo_api_search, clo_api_doc, clo_api_describe) by being the execution tool — an agent can tell it apart without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Read its live documentation first' implies checking docs before calling, and 'Use checkpoint_save before risky scene edits' gives a concrete when-to precedent. However, it never explicitly names the alternative tools (clo_api_doc, clo_api_search) or gives a when-not-to-use exclusion, so differentiation is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It reveals a key behavioral trait — irreversibility: 'there is no API to remove a seam, so save a checkpoint first' — and tells the agent how to verify effects using simulate and snapshot. This goes well beyond a bare mutation statement, though it does not cover failure behavior for invalid pattern references or the return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three purposeful sentences ordered by importance: the operation itself, the tricky direction rule with example, then the irreversibility warning and checkpoint workflow. There is no filler, no repetition of the schema, and each sentence earns its place in helping the agent call the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 output schema and no annotations, the description covers the critical context: direction orientation, verification via simulate plus snapshot, and the checkpoint-first recommendation. Smaller gaps remain (no stated return shape or failure semantics for missing resources), but the core call contract is sufficiently complete for an agent to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does for the hardest parameters. It narratively maps pattern_a/line_a and pattern_b/line_b, and explains dir_b with a concrete example ('front right side <-> back left side') and an explicit condition (opposite directions). dir_a is left somewhat implicit, but its behavior follows from the stated 'each line's point order' rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resources: 'Sew line_a of pattern_a to line_b of pattern_b.' The parenthetical 'segment sewing' scopes the operation as a line-to-line join rather than a whole-pattern operation. Among sibling tools there is only seams_list (a read-only inspection tool), so the purpose is unambiguous and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives actionable when-to-set guidance for direction parameters: 'Directions follow each line's point order; when the two lines run in opposite physical directions set dir_b=False.' It also prescribes a follow-up workflow (check with simulate and snapshot) and a saving checkpoint precondition. It does not state explicit exclusions or name-alternative calls, but since no other tool performs sewing, the guidance is still clear context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 primary side effect (frees the Python editor) and explicitly states what does not happen ('CLO keeps running'), which is helpful. It does not mention idempotency or behavior when no bridge is active, but these are minor for such a tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the action and includes the key side effect in a parenthetical. No wasted words; every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple stop tool, the description provides complete context: what it stops, what it frees, and what remains running. The presence of an output schema (even if not detailed) further reduces the need for description to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema reflects that with an empty properties object. Per the rubric, a baseline of 4 is appropriate since there is nothing to document beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Stop the bridge loop'), identifies the target resource (CLO), and clarifies the effect (frees the Python editor). It clearly distinguishes itself from sibling tools like clo_run_python or clo_launch, which start or run processes, by focusing on stopping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for stopping an active bridge loop, and it notes that CLO keeps running, which sets expectations. It does not explicitly name alternative tools or state when not to use it, but the context is unambiguous for a zero-parameter stop action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and clearly states the destructive outcome (deleting all pattern pieces or starting a fresh project). It does not disclose reversibility or side effects, but for a simple mutating tool with a single parameter, the statement is sufficient to set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler, with the primary action front-loaded. Both branches of behavior are presented compactly without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and straightforward behavior, the description provides everything needed to call the tool correctly. It is self-contained and does not require external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a boolean with a default and 0% description coverage. The description fully explains the semantic difference between true and false, adding critical meaning that the schema lacks entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear verb ('Delete'/'start a fresh project') and resource ('all pattern pieces'/'project'), and distinguishes two distinct behaviors via the parameter. It separates itself from siblings like pattern_delete (which targets individual pieces) and scene_open (which loads a scene) by the scope of the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly links parameter values to usage scenarios (keep_avatar=True vs False), indicating when to use each mode. However, it does not explicitly mention alternatives or when to avoid this tool in favor of pattern_delete or scene_open, leaving slight room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must disclose behavior. It does: explains corner vs curve points, warns about distortion, and suggests simulating afterward. However, it doesn't state side effects like whether changes are reversible or if errors occur for invalid indices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single paragraph that front-loads the action, then details format, prerequisites, caveats, and alternatives. No wasted words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, usage, caveats, and next step (simulate). Lacks return-value info but that's minor for a mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description fully explains moves format (absolute/relative, mm units) and references pattern_info for point indices. It adds essential meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States 'Move outline points of a piece' with specific details on absolute/relative moves. Clearly distinguishes from sibling pattern tools by referencing pattern_info for indices and garment_rebuild for built garments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends garment_rebuild for built garments, reserves this for straight-edged pieces or small tweaks, and instructs to use pattern_info first. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md: