codex-creo-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.9.0
Disambiguation3/5
Many tools are clearly distinct by feature type, but the large family of creo_create_safe_*_copy and creo_create_project_* tools creates potential confusion, especially with near-duplicates like creo_get_dimensions vs creo_get_project_dimensions and creo_create_project_sheetmetal_planar_wall vs creo_create_project_sheetmetal_planar_wall_current. Descriptions help, but the boundaries between 'current', 'project', and 'safe copy' variants require careful reading.
Naming Consistency4/5
The naming is predominantly creo_verb_noun with a consistent snake_case style, and most tools follow an action+object pattern. Minor deviations exist, such as creo_set_project_working_directory being a compatibility no-op tool, creo_start_resident_and_get_basic_model mixing concerns, and some verbose names like creo_switch_current_project_component_visibility, but overall the pattern is predictable.
Tool Count1/5
With 60 tools, this is an extreme mismatch for a single MCP server. Even accounting for a complex CAD domain, the tool surface is heavily oversized and contains many near-parallel families for safe copies, sheetmetal walls, skeleton features, and assembly component placement that could be consolidated or made more generic.
Completeness4/5
The server covers a broad workflow: model introspection, safe feature creation, dimension modification, sheetmetal construction, skeleton-driven assemblies, and version cleanup. Minor gaps exist, such as no direct parameter-reading tool and no generic model deletion, but the core lifecycle for the stated safe-Creo-automation purpose is well represented.
Average 4.1/5 across 56 of 60 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.json to 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the description must add context beyond that. It discloses validation of surface extents, verification of volume and +Z envelope, saving, displaying, and recycling older versions—all beyond the annotation. It does not explain failure behavior or what 'recycle older versions' entails, but overall it adds substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense 50-word sentence that front-loads validation and verification before the core action of extrusion creation. It is overstuffed with multiple steps, making it hard to parse. The core purpose is buried mid-sentence, and the structure is not efficient or front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-step operation with 10 parameters and no output schema, the description lacks key context: it does not explain the expected standard skeleton, what 'recycle older versions' means, error handling for validation failure, or return values. Given the complexity, this description is incomplete and would leave an agent guessing about prerequisites and outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 10% (only feature_name has a description). The description loosely implies roles of surface_id, expected_surface_length/width, outset, and depth via the geometry narrative, but it does not explain the exact meaning of expected_assembly, expected_skeleton, orientation_plane, or direction_side. With such low schema coverage, the description should compensate more; it only partially does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: creating a centered additive rectangular extrusion with outward-equal sides on a validated top-face surface, along with validation, verification, save, display, and version recycling. It is clear verb+resource and implicitly distinguishes from the inset sibling by the word 'outward'. It does not explicitly name the sibling, so not 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context ('In the expected standard skeleton') but provides no explicit when-to-use, when-not-to-use, or alternatives. It does not mention that the inset extrusion sibling exists or under what conditions to choose one over the other. Guidance is implied but not 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?
The description adds useful behavioral context beyond the annotations: it modifies only the new copy, refuses to overwrite, succeeds only when the active feature is saved, and requires solid volume to increase. These details give an agent a clearer safety and precondition model than the annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler, and the core purpose is front-loaded before the safety constraints. It is compact and readable, though slightly dense in phrasing like 'solid blind protrusion from a centered rectangular sketch only in the new copy.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with nine parameters, no output schema, and many sibling copy tools, this description is incomplete. It omits parameter semantics, what the tool returns, and how failures beyond overwrite refusal are signaled. The safety preconditions are helpful, but too much essential context is left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, so the description carries the burden of explaining the nine parameters, but it does not. It mentions a centered rectangular sketch and implies width, height, and depth, yet it does not clarify required fields like expected_model, feature_name, or copy_name, nor the optional plane parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—copy the current part and create one solid blind rectangular protrusion only in the copy—so an agent can tell this is an additive extrusion-copy tool rather than a cut, hole, revolve, or parameter copy. It clearly identifies the resource and operation, though it does not explicitly distinguish itself from sibling copy tools by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to choose this tool over alternatives such as creo_create_safe_rectangle_cut_copy or creo_create_safe_thru_hole_copy. It implies usage for adding a rectangular extrusion to a copy, but it never states explicit use cases, exclusions, or alternative selection criteria.
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?
Beyond the annotations, the description discloses meaningful behavioral traits: it copies into the current working directory, refuses overwrite, and verifies the active feature and solid-volume change. There is no contradiction with the annotations, and these additions help an agent anticipate side effects and validation behavior, though error handling on verification failure is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and each clause contributes useful information. It packs scope, supported modes, overwrite behavior, and verification into a compact, readable form without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 12-parameter tool with no output schema, sparse annotations, and many similar sibling tools. The description conveys high-level behavior and safety constraints, but leaves parameter roles, return/error behavior, and selection guidance largely to inference. An agent would need additional context to invoke it correctly in a competitive sibling landscape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description should compensate for the undocumented parameters. It touches on profile ('rectangle or circle'), operation_mode ('additive protrusion and blind cut'), and depth through the extrusion concept, but it does not explain expected_model, copy_name, feature_name, sketch_plane, direction_side, or orientation_plane. This is only partial compensation for a 12-parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific action and resource: copy the current Creo part into the selected live working directory and create a centered rectangle or circle extrusion. It clearly captures the tool's combined copy-and-extrude behavior and its supported modes, though it doesn't explicitly distinguish it from the similarly named 'safe' extrusion/cut siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives such as creo_create_safe_rectangle_extrusion_copy or creo_create_safe_rectangle_cut_copy. The description provides context such as 'current Creo part' and 'live working directory already selected,' but no when-to-use/when-not-to-use framing.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds meaningful detail: it verifies feature status/volume/dimensions, saves and displays the skeleton, saves the assembly, and recycles older versions of model families. This goes beyond the binary annotation flags and explicitly discloses a destructive version-cleanup step, consistent with destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 44-word run-on sentence that front-loads the primary action but chains five distinct behaviors with commas. It is free of filler, but the structure could be improved by separating the creation step from verification, save, display, and version-recycling actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 9-parameter operation with no output schema, the description covers the main workflow—create, verify, save, display, save assembly, recycle versions—but omits prerequisites (e.g., whether expected_assembly/expected_skeleton must already exist), the meaning of direction_side, error/failure behavior when verification fails, and any return value. DestructiveHint and the version-recycle note alert about side effects, but the overall context is not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (~11%, only feature_name documented), so the description must compensate. It refers to 'the requested three envelope dimensions' (length, width, height), 'expected standard skeleton' (expected_skeleton), 'save its assembly' (expected_assembly), and 'a named datum plane' (sketch_plane/orientation_plane). However, direction_side is never explained, and the distinction between sketch_plane and orientation_plane remains ambiguous, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Create one solid rectangular extrusion inside the expected standard skeleton on a named datum plane.' This clearly distinguishes it from generic or copy-based sibling tools by tying it to the standard skeleton workflow. The extra verification, save, and version-recycling clauses describe a multi-step script but do not obscure 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit 'when to use' or 'use instead of' guidance, and it never contrasts with similarly named siblings like creo_create_safe_rectangle_extrusion_copy or creo_resize_project_skeleton_box. The phrase 'expected standard skeleton' implies a particular context, but an agent is left to infer when this tool is preferred over alternatives.
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?
Annotations already indicate a mutating, non-idempotent operation, so the description does not need to restate that. It adds meaningful behavioral context beyond the annotations: 'refuses overwrite' and 'verifies an active shell feature, a feature-count increase, and a decrease in solid volume,' which tells the agent what safety checks and side-effect verification to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the first states the core operation, the second covers the optional parameter, and the third lists safety verification. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow and verification behavior, but it leaves required parameters expected_model and feature_name undefined, and with no output schema it does not describe what the tool returns or how verification results are reported. It is adequate for a high-level understanding but would leave an agent uncertain about two required inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 40% schema description coverage, the description must compensate for undocumented parameters. It clarifies removed_surface_id ('A planar surface ID may be supplied as the opening; otherwise the largest planar surface is selected'), but required parameters copy_name, feature_name, and expected_model remain unexplained in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific compound operation: 'Copy the current Creo part and create one inward shell in the new copy.' This clearly distinguishes it from the many sibling safe-copy tools (parameter copy, dimension copy, etc.) by naming the shell operation and the optional opening-surface behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide when-to-use guidance or route the agent away from alternatives. Given the large set of sibling safe-copy tools, an agent gets no explicit direction on when to choose shell copy over the other copy variants, and no prerequisites or exclusions are mentioned.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar for additional behavioral disclosure is lower. The explicit statement 'The model is not saved or modified' adds concrete side-effect clarity beyond the generic hints and reassures an agent that the operation is safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists the returned data efficiently and ends with a short side-effect note. Every clause adds relevant information, and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly enumerates the expected output data, which is important because there is no output schema. However, it omits the meaning of the required expected_model parameter and gives no guidance on when to prefer this tool over the many sibling query tools, leaving noticeable gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: model_file has a description, but expected_model has only a regex pattern and no semantic explanation. The description provides context for model_file ('part file in the working directory') but never mentions or clarifies expected_model, which is a required parameter and likely crucial for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and a clear resource: one Creo part in the current working directory. It enumerates the exact data returned (edge IDs, lengths, surface IDs, areas, extents), which distinguishes it from sibling tools like creo_get_dimensions, creo_get_features, and creo_get_mass_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool reads geometry from a part file in the working directory, but gives no explicit guidance on when to use this tool versus alternatives such as creo_get_dimensions or creo_get_features. It names no sibling tools and provides no exclusions or conditions, leaving tool selection largely to inference.
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?
Annotations already declare destructiveHint=true, so the bar is lower, and the description adds valuable behavioral context: it verifies name/type, regenerates, saves, displays, and recycles older versions of 'only that assembly family.' This tells an agent what gets modified/cleaned and scopes the destructive effect precisely. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one long sentence but front-loads the core action and packs all behavior into a compact stream. It is somewhat dense, but every clause adds pertinent operational detail; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex CAD operation with no output schema, the description covers prerequisites ('already selected' working directory), units, template source, actions, display, and version cleanup. It does not describe return values or failure modes, but the behavioral detail is enough for an agent to invoke and verify the operation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions 'assembly name' as part of the process and does not explain that assembly_name is the new model's name, its character restrictions, or its interplay with the verify/save steps. The schema's pattern and maxLength carry most of the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a new empty millimeter Creo assembly', and clarifies 'No component is added.' This clearly differentiates it from the sibling creo_create_project_assembly, which presumably covers non-empty assemblies, so an agent can identify this tool's scope 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context: it operates in the currently selected working directory, uses the installed template, and is deliberately empty. However, it never explicitly states when to choose this over creo_create_project_assembly or another sibling; 'No component is added' is an implied selection criterion, not a stated when/when-not rule.
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?
注解已经声明了 readOnlyHint=true、idempotentHint=true、destructiveHint=false，描述也重申了“只读”，两者一致。描述额外补充了返回的尺寸属性字段，但没有解释失败模式、权限要求或关系驱动状态带来的行为影响；在已有注解覆盖安全画像的情况下，描述的价值有限。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述只有一句话，但完整覆盖了只读性质、适用对象、参数来源和输出字段，信息密度高且没有冗余。关键信息“只读”和“当前零件或副本”放在句首，符合前置加载原则。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于只有一个可选参数、无输出 schema 的只读工具，描述已经说明了工具用途、支持的目标模型来源以及返回的字段类别，足以支持调用决策。唯一欠缺的是未描述返回的具体格式或可能的失败情况，但对这个复杂度的工具而言并非关键缺口。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
input schema 对唯一参数 model_file 的说明已经是“可选；安全输出目录中的零件文件名。省略时读取当前模型。”，schema 覆盖率为 100%。描述中的“当前 Creo 零件或安全输出目录中某个零件副本”基本只是复述 schema 内容，没有新增参数语义。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述以“只读列出”这一具体动词确立了操作，并明确资源是 Creo 零件或安全输出目录中的零件副本，还列出了返回的内容（尺寸 ID、符号、数值、类型、关系驱动状态、所属特征）。这一描述足以与 creo_get_project_dimensions 等兄弟工具区分开，因为限定了安全输出目录副本和当前模型两种来源。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述给出了使用场景的部分上下文：省略 model_file 时读取当前模型，指定 model_file 时读取安全输出目录中的副本。但未明确说明何时应使用本工具而非 creo_get_project_dimensions 或 creo_get_features 等替代工具，也没有排除性说明。
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?
Beyond the destructiveHint/readOnlyHint annotations, the description discloses concrete side effects: verification of constraints and X positions, assembly regeneration and save, and recycling of older versions of the assembly family. It does not fully define what 'recycles' entails or failure behavior, but the core destructive behavior is clearly exposed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler; each clause contributes operational detail. The first word 'Read' slightly undersells the destructive write nature of the tool, but overall the structure is efficient and front-loaded for a complex six-parameter operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow but omits return-value behavior, failure conditions, and exact prerequisites for what constitutes the 'current expected assembly'. With no output schema and a destructive mutation, an agent would still have meaningful uncertainty about how to invoke it correctly in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, so the description must compensate. It adds meaning by identifying target_insert_surface_ids as the two cylindrical assembly surfaces and target_x_positions as X positions, and by referring to expected_assembly and component references. However, expected_component and source_component_feature_id are not clearly distinguished, so the parameter mapping remains incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise operation: read one existing ALIGN+INSERT-constrained component instance and add two more while changing only specified cylindrical surfaces and X positions. This clearly distinguishes it from generic component-add siblings like creo_add_project_component_align_insert_three.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it—when repeating an existing component instance in an expected assembly with a specific constraint method—but does not explicitly name alternatives or state when not to use it. The trigger context is present but differentiation is left to inference.
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?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds the lifecycle context of loading from the safe output directory, checking, and unloading from memory — a behavioral detail not present in annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one direct, front-loaded sentence with no filler. Every phrase contributes meaning, from the read-only load to the final unload.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema, so the description must carry more weight. It covers the action and lifecycle but does not describe the verification outcome (e.g., return value or error on mismatch) or define '安全输出目录' precisely. An agent can call it but may not predict the result of a failed check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%: only model_file has a description. The phrase '核对字符串参数' gives a general hint that a string parameter is being checked, but it does not explain the 'parameter' enum values, the meaning of 'CNAME', or the precise role of 'expected_value'. Two parameters remain virtually undocumented, and the description does not compensate enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs (只读载入, 核对, 卸载) and identifies the resource (Creo 零件副本 in 安全输出目录). It clearly differentiates the tool from siblings like creo_get_current_model (which queries the current model) and creo_create_safe_parameter_copy (which creates copies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for verifying a saved copy in the safe output directory, but it does not explicitly state when to use it over alternatives, nor mention exclusions or prerequisites. The intent is inferable, but no explicit guidance is given.
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?
The description goes well beyond the annotations by disclosing that each instance uses a verified planar ALIGN constraint plus cylindrical INSERT constraint with yellow datum sides, that an API readback check occurs, and that the assembly is regenerated, saved, and cleaned to its newest version. It also notes the refusal behavior when an instance already exists. This provides rich behavioral transparency consistent with the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet efficiently structured: the main operation is front-loaded, followed by constraint/verification details and a final refusal condition. Every sentence contributes meaningful information, and there is no filler or redundancy with the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with ten required parameters, no output schema, and no parameter descriptions, the description is not complete enough for an agent to invoke correctly without additional knowledge. It explains the high-level process well, but it omits critical details such as how target_x_positions map to positions, what the surface IDs refer to, and what success or failure return values look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for ten undocumented parameters. It explains the general roles of align and insert surface IDs and target insert surfaces, but it does not explain target_x_positions, component_model_file, expected_assembly, or the numeric ID semantics in enough detail for an agent to call the tool confidently. The description provides high-level behavior but leaves parameter-level meaning largely to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Load one project part and add exactly three instances to cylindrical surfaces of a host component.' It precisely defines the operation, including the exact number of instances and the constraint types, which clearly distinguishes it from sibling tools like the fixed or mate/align component adders. The wording is unambiguous and informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when the tool is applicable by mentioning the current expected assembly and the exact three-instance align/insert workflow, but it does not explicitly state when to prefer it over alternatives such as creo_add_project_component_fixed, creo_add_project_component_mate_align, or creo_repeat_project_component_insert_pair. The precondition that the tool refuses to run if an instance already exists is useful context, yet exclusion guidance is absent.
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?
Annotations already mark the tool as destructive and non-read-only, and the description adds concrete side effects: it recycles older versions of only that part family, keeps the working directory active, saves/displays the part, and verifies the returned subtype. This goes beyond the annotation basics, though it does not explain failure modes if the model name already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence, but every clause adds a distinct behavioral guarantee such as template source, directory state, save/display, and version cleanup. It lacks bullet structure but is front-loaded with the primary create action and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description covers prerequisite, units, template, save/display, subtype verification, and version cleanup. It implies a returned model via 'verify the returned sheet-metal model subtype,' though it does not explicitly state the return value or error behavior if the template or part name conflicts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: model_name has a clear description ('without .prt') plus a pattern and maxLength. The description does not add any parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Create a new empty native millimeter Creo sheet-metal part' and distinguishes itself from sibling tools like creo_create_project_part and the sheet-metal wall creation tools by emphasizing an empty template-based part. It also names the key lifecycle steps (save, display, version cleanup), so an agent cannot mistake it for a feature-adding tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by requiring the live working directory already selected in the current session, which implies the prerequisite of setting a working directory first. However, it never names alternatives like creo_create_project_part or explains when to prefer this tool over them; the usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the annotations: it refuses overwrite, verifies an active chamfer feature, and checks feature-count increase and nonzero solid-volume change. The annotations provide little beyond false hints, so this prose carries the transparency burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The core operation is front-loaded, followed by selection behavior and verification guarantees, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the operation, edge selection, and safety checks, but with no output schema it does not state what the tool returns or how success is reported. It also omits explicit prerequisites beyond the notion of a current Creo part, leaving some gaps for an agent invoking it autonomously.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only edge_id and distance have schema descriptions, and the prose clarifies edge_id's default behavior and the supported straight/circular edge types. However, the required parameters expected_model, copy_name, and feature_name are not explicitly mapped to their roles, leaving some inference needed despite their suggestive names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: copy the current Creo part and create one equal-distance edge chamfer in the new copy. It clearly separates this tool from the many sibling safe-copy tools by naming the chamfer operation and edge-selection behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the action described, but the description does not explicitly state when to choose this tool over alternatives such as round copy, shell copy, or draft copy. It offers no exclusions or alternative routing.
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?
The annotations already convey read-only, idempotent, and non-destructive behavior. The description adds value beyond annotations by explicitly promising that the tool will not modify, save, or display the model, which clarifies an additional behavioral guarantee not present in the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured Chinese sentence that front-loads the action and resource, then appends the key behavioral restrictions. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-less, read-only introspection tool, the description covers the important safety aspects and the target of the read. It is slightly vague about what 'model info' specifically includes, and there is no output schema, but the overall context is sufficient for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema description coverage is trivially 100% and there is no parameter semantics to explain. A baseline of 4 is appropriate because there is no missing parameter information to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the currently running Creo session and the current model information, which is a specific verb and resource. It does not explicitly differentiate itself from sibling read tools like creo_get_dimensions or creo_get_features, so it misses the highest bar for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a safe read-only use case by explicitly stating it will not modify, save, or display the model. However, it does not name alternatives or provide any when-to-use versus when-not-to-use guidance relative to the many sibling tools.
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?
The description discloses additional behaviors beyond the destructiveHint annotation: it 'verifies subtype, feature status, thickness, volume and envelope, saves and displays the part, and recycles older versions of only that part family.' This explains side effects (saving, display, version recycling) that align with destructiveHint=true. It provides useful operational context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The core action is front-loaded in the first sentence, followed by side-effect details and the variant clarification. Every sentence serves a purpose, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and behavioral side effects, and the schema provides parameter constraints. However, without output schema and with 0% parameter description coverage, the description leaves gaps: it does not explain what the verification steps entail, what happens on failure, or the meaning of expected_model and feature_name. Given the tool's complexity and destructive nature, more parameter context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions (0% coverage), and the tool description does not explain the meaning of length, width, thickness, feature_name, or expected_model. While 'thickness' is mentioned as part of verification, the description fails to clarify that length and width define the wall's planar dimensions or what expected_model and feature_name represent. The description does not compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create the first unattached planar wall in the current expected empty native Creo sheet-metal project part on FRONT.' It identifies the verb (create), resource (planar wall), and context (current sheet-metal part, FRONT plane). It also differentiates from siblings by noting 'This variant operates on an existing project sheet-metal part,' which distinguishes it from the non-current variant and other wall tools like flat_wall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when an existing project sheet-metal part is present and you need the first unattached planar wall. It states 'This variant operates on an existing project sheet-metal part,' giving context. However, it does not explicitly name alternatives or state when not to use it (e.g., if you need a flat wall or a new part). The guidance is inferred rather than explicitly contrasted.
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?
Annotations only reveal that the tool mutates and is not idempotent. The description adds substantial behavioral context: reading thread drill diameter from a .hol table, verifying thread metadata, refusing overwrite, requiring an active hole feature, requiring volume decrease, and applying a style-specific maximum-removal guard. None of this contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences deliver the core action, supported styles, thread behavior, and safety constraints without wasted words. The main purpose is front-loaded, and every clause earns its place for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is strong on safety behavior and style coverage, but the tool has 19 parameters and no output schema, and the description leaves required fields like offsets and naming conventions partly unexplained. The schema helps with ranges and style dependencies, yet the overall contract is not fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 42%, so the description needed to compensate for many undocumented parameters. It does little for expected_model, copy_name, hole_name, depth, offset1, and offset2. It adds only indirect thread-related meaning by explaining that threaded drill diameter comes from the installed .hol table.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: copy the current Creo part and create one advanced hole in the copy. It differentiates the tool from siblings by naming the supported hole styles and framing it as an advanced-hole operation rather than a plain hole, dimension, or parameter copy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Supported styles and preconditions like 'requires an active hole feature' give implied usage guidance, but the description never explicitly names alternatives such as creo_create_safe_thru_hole_copy or states when this tool should not be used. Given the many sibling copy tools, more direct routing would be better.
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?
Annotations only mark the operation as non-readonly and non-idempotent; the description adds valuable behavioral detail: it refuses to overwrite existing files, never saves the source model, and regenerates the copy after parameter writes. These behaviors go beyond what annotations reveal and are consistent with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core action, states the batch scope, and lists safety constraints without any filler or repetition. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the main behavior and safety profile for a three-parameter safe-copy tool: what is copied, how many parameters can be updated, regeneration, overwrite refusal, and source-model preservation. It does not reveal the return value or error behavior, but no output schema exists and the core invocation details are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: copy_name and expected_model already have descriptions in the schema. The description adds that updates target 'business whitelist parameters' and that 1-10 are allowed, but it does not explain the meaning of individual whitelisted parameters or how new_value is applied beyond what the schema's enum and maxLength already convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (copy current Creo part to a new file), a specific resource (the current part), and a precise scope (batch-write 1-10 whitelisted business parameters then regenerate). This clearly differentiates it from the numerous sibling copy tools, especially the singular creo_create_safe_parameter_copy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'copy to new file', 'batch write 1-10 parameters', and safety guarantees, but it does not explicitly state when to choose this tool over alternatives or provide exclusion conditions such as 'use the single-parameter variant for one update'. The guidance is clear but inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by disclosing two important behavioral traits: the operation refuses overwrite, and it succeeds only when solid volume remains unchanged. It also states that the datum plane is added only in the new copy, which clarifies the original part is not modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the full behavioral description with zero filler. The core action is front-loaded and the safety constraints are presented succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, sparse annotations, and only 20% schema coverage, the description must carry substantial burden. It provides key safety traits but omits parameter mapping and expected_model/copy_name semantics, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%), and the description adds useful context like 'nonzero offset' and 'named planar datum reference.' However, it does not explain the roles of expected_model, copy_name, plane_name, or reference_plane, leaving the agent to infer which parameter corresponds to the new plane name versus the reference plane.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource: copy the current Creo part and create one datum plane at a nonzero offset. It also distinguishes itself from sibling safe-copy tools by specifying 'one datum plane' and 'named planar datum reference' rather than a generic copy operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly communicates the intended scenario: create a safe copy of the current part while adding exactly one offset datum plane. It does not explicitly list when-not-to-use alternatives, but the narrow scope and safety constraints make the usage context clear.
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?
The description adds meaningful behavioral context beyond the annotations: it explicitly states this changes only the UI display and does not save or modify model data, and it mentions the foregrounding behavior. This complements the idempotentHint=true and destructiveHint=false annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The primary action is front-loaded, followed by key behavioral constraints, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple display action with only two parameters and no output schema, the description covers the core behavior, safety profile, and side effects. It does not detail failure cases or validation mismatches between model_file and expected_model, but these are not necessary for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully documented in the schema with 100% coverage. The description reinforces that model_file lives in the safe output directory but does not add significant new meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: load a Creo part from the safe output directory, display it, refit the view, and bring Creo to the foreground. It clearly identifies the tool's scope and differentiates it from sibling creo_display_project_model by mentioning the safe output directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case—displaying a model from the safe output directory—but does not explicitly state when to choose this tool over alternatives like creo_display_project_model or when not to use it. No explicit 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by stating the operation is read-only and by disclosing exactly which feature fields are returned (ID, name, type, status, visibility, and parent-child relationships). No contradiction with the annotations was found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one front-loaded sentence that states operation, scope, and returned content without repetition or filler. Every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with zero required parameters and no output schema, the description is complete enough: it identifies the two valid input contexts (current part vs safe output copy) and summarizes return content. It does not specify output shape (e.g., array ordering or status value domain), but those are minor for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the schema already states that model_file is optional, names the file in the safe output directory, and explains that omitting it reads the current model. The tool description mirrors this context but does not add meaningful detail beyond the schema, so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('只读列出' / read-only list) and a specific resource (features of the current Creo part or of a saved part copy in the safe output directory), and it enumerates the returned attributes (ID, name, type, status, visibility, dependencies). This makes the tool's purpose clear and distinguishable from sibling list-like tools such as creo_get_dimensions or creo_get_mass_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context for the one optional parameter: omit model_file to read the current model, or provide a file name from the safe output directory. However, it does not state when to prefer this tool over alternatives or call out exclusions (e.g., that it is for feature topology rather than dimensions/mass properties), so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is pre-covered. The description adds 'uses unit density for calculation only' as useful extra context, but 'does not modify the model' merely restates what the annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the resource, scope, calculation caveat, and non-mutating behavior without filler. The key purpose is front-loaded, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read tool with one optional parameter and strong safety annotations, the description covers the main contextual needs: target selection, safe directory, unit-density caveat, and non-modification. It does not describe the return shape, but the absence of an output schema and the simple read semantics make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one optional parameter and the schema description fully documents it: 'Optional part file name in the safe output directory. Omit to read the current model.' The tool description adds little beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read computed mass properties' for either the current Creo part or a part copy in the safe output directory. This distinguishes it from sibling query tools like creo_get_dimensions and creo_get_features, and from the many create_safe_* copy 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the two valid targets — the current model or a saved part copy in the safe output directory — so an agent knows when the tool applies. It does not explicitly name alternatives or when not to use it, but the context is clear enough for this simple read operation.
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?
The description goes well beyond the destructiveHint annotation by explaining what happens: fixed constraint is applied, the assembly is regenerated and saved, and older versions of only that assembly family are recycled. This is exactly the kind of side-effect disclosure that helps an agent understand irreversible behavior, and it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the main purpose and then lists the consequential effects. It is efficient, though slightly long and could benefit from clearer separation between the core action and the side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, mutation-heavy tool with no output schema, the description covers the main operational steps and the key destructive side effect accurately. The main gap is the unclear role of 'expected_component', plus the absence of explicit guidance about when a user would choose this tool over similar add-component tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It clarifies 'translation_x/y/z' as XYZ translation values, 'component_model_file' as an existing project part, and 'expected_assembly' as the current expected assembly. However, 'expected_component' is not explained, and the relationship between it and 'component_model_file' remains ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Add an existing project part'), a specific resource ('current expected Creo assembly'), and a distinctive method ('apply a fixed placement constraint'). This clearly differentiates it from sibling tools like mate_align or align_insert_three by emphasizing the fixed placement constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives operational context: use this tool when adding an existing part at a verified XYZ translation with a fixed placement constraint, followed by regeneration and save. However, it does not explicitly state when NOT to use it or name alternative tools for other constraint types, leaving selection guidance mostly implied.
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?
Annotations already declare destructiveHint=true, so the destructive nature is established, and the description adds meaningful behavioral context by specifying version recycling, default placement, verification, and save/display. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single information-dense sentence with no filler, but the long chain of clauses makes it slightly harder to parse than necessary. All listed steps contribute value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, destructive workflow with no output schema, the description covers the environment, template source, attachment behavior, verification, save/display, and version cleanup. It remains slightly vague about what 'recycle older versions' entails, but the overall process is adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all three parameters thoroughly. The description adds no parameter-level meaning beyond mentioning 'one existing project part', which only loosely maps to component_model_file; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific, multi-step operation: creating a millimeter Creo assembly in the current working directory from the installed template, adding one existing part with default placement, verifying it, saving/displaying, and recycling old versions. This is specific enough to distinguish from siblings such as creo_create_project_empty_assembly and creo_add_project_component_fixed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: the live working directory already selected in the current Creo session, the installed assembly template, and one existing project part. It does not explicitly name alternatives or say when not to use the tool, so it falls short of the 5 bar.
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?
Goes far beyond the annotations (readOnlyHint=false, destructiveHint=true) by disclosing the bend-radius rule (thickness x 0.5), the full verification checklist (edge ID/length, wall type, active feature, radius rule, regeneration, volume increase, saved file), the side effect of moving older model-family versions to the Windows Recycle Bin, and failure cleanup. No statement contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the opening phrase, followed by a dense run of verification and side-effect disclosures. The long second sentence packs many clauses and could be split for easier scanning, but every sentence earns its place and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive 6-parameter tool with no output schema, the description covers the operation flow, verification criteria, pre-save failure cleanup, and post-save version handling. It stops short of stating the return value or success signal, and what happens when a verification fails after save is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the burden and does map to several parameters: wall_height ('requested height'), edge_id/expected_edge_length ('verifies the attachment edge ID and length'), and expected_model ('current expected... project part'). It never mentions feature_name, and the claim of a fixed '90-degree wall' conflicts with the configurable angle parameter (1–179, default 90).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb + resource: 'Create one attached flat wall on one verified straight boundary edge of the current expected native Creo sheet-metal project part.' The qualifiers 'one', 'attached', 'flat', and 'boundary edge' distinguish it from siblings like creo_create_project_sheetmetal_flat_walls_batch and the planar-wall tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through 'current expected native Creo sheet-metal project part' and 'one attached flat wall,' signaling a single-wall operation on the active model. However, no alternative tool is named and no when-not-to-use condition or exclusion is given — the agent must infer that the batch sibling or planar-wall tools are the alternatives.
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?
The description goes well beyond the annotations by disclosing concrete behavioral traits: it refuses overwrite, verifies sheet-metal subtype and several geometric properties, saves/display the part, and moves older versions of only that part family to the Windows Recycle Bin. This is especially valuable because destructiveHint=true but the description explains the precise destructive scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence but front-loads the core purpose clearly. Details about verification and recycle-bin behavior are packed in without bloating the text excessively. A slight restructuring into separate sentences would improve readability, but each clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool without an output schema, the description covers the essential context: working-directory requirement, creation of the part and wall, geometry origin, verification steps, save/display behavior, and destructive cleanup of older versions. It is sufficiently complete for an agent to understand preconditions and side effects, though it does not describe the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, so the description must compensate for undocumented width, length, and thickness parameters. It does imply that length and width define a centered rectangle and that thickness is sheet-metal thickness, and it adds 'millimeter' units. But it does not explicitly map each parameter to its meaning or boundary behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: creating a new native millimeter Creo sheet-metal part and its first unattached planar wall from a centered closed rectangle on FRONT. It clearly names the resource and scope, and the detail 'first unattached planar wall' distinguishes it from generic sheet-metal creation tools and other planar-wall 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when creating a new sheet-metal part in the currently selected working directory and needing its first planar wall. However, it never explicitly contrasts with sibling tools like creo_create_project_sheetmetal_planar_wall_current or creo_create_project_sheetmetal_flat_wall, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations include destructiveHint=true and readOnlyHint=false, the description adds substantial behavioral detail beyond them: verification via ProMdlIsSkeleton and assembly readback, saving both models, and recycling older versions of only those two model families. This clearly conveys the scope and side effects of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the primary creation action followed by the verification, save, and cleanup behaviors. Every clause adds useful information and there is no redundant or filler content, though the sentence is somewhat long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive creation tool with no output schema, the description covers the main workflow: creation, verification, saving, and cleanup of prior versions. Minor gaps remain, such as prerequisites (whether the expected assembly must already be open) and behavior on verification failure, but the description is still notably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It references expected_assembly as the 'current expected project assembly' and skeleton_name implicitly as the new 'standard skeleton model,' but it does not explicitly define the parameters as model names, explain their relationship, or clarify what 'current' means relative to the expected_assembly parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair: 'Create a standard skeleton model' in a particular assembly, and distinguishes it from sibling skeleton tools by specifying 'standard' and 'from the millimeter part template.' It further details verification, saving, and recycling, making the tool's function 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a standard skeleton model must be created in the current expected project assembly. However, it never explicitly contrasts this with sibling tools like creo_create_project_skeleton_box or skeleton_surface tools, and gives no direct 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds meaningful behavioral constraints: it refuses to overwrite, does not modify the input copy or current model, and only resumes features with no children and active parents. These details are not present in the annotations and give the agent important operational expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that efficiently packs the core action, feature constraints, and safety guarantees. It is not redundant, but the long clause structure could be slightly more scannable with clearer separation of the safety guarantees.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five required parameters and no output schema, the description covers the key behavioral constraints an agent needs: source location, feature resumption condition, allowed feature types, overwrite refusal, and non-modification of inputs. It does not describe the return value or failure behavior, but those are not explicitly required given the annotations and schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters, including the expected_type_code enum mapping. The description reinforces the feature-type mapping by naming 圆角、倒角、孔、切除 but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: create a new copy from a suppressed part copy and resume exactly one feature of a specific type (fillet, chamfer, hole, or cut) in the new copy. It also distinguishes itself from related safe-copy tools by emphasizing feature resumption rather than suppression or single-feature creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys the intended scenario: restoring one childless, parent-active feature from a suppressed part copy without modifying the input or current model. However, it does not explicitly name alternative tools such as creo_create_safe_feature_suppression_copy or the specific feature-copy siblings, so the when-not-to-use guidance is only 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with annotations present, the description adds substantial behavioral detail: only the copy is written, the copy is regenerated, existing files are never overwritten, and the source model is not saved. These are meaningful safety guarantees beyond the boolean hints and are exactly what an agent needs to trust invoking a copying 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly packed sentence front-loads the core operation and then states key safety constraints. Every clause contributes information, and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation-style tool with no output schema, the description covers the operation, regeneration behavior, and safety limits well. It does not state success/error behavior or what happens if copy_name already exists, but 'never overwrite' implies a guarded failure path. Minor gap, not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with new_value having no description beyond maxLength and parameter restricted by enum. The description does not compensate by explaining the meaning of new_value, how values are formatted, or the relationship between parameter and new_value. It only vaguely refers to 'allowed parameters,' which already appears in the enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: copy the current Creo part into a new file, write only allowed parameters, and regenerate. It also clearly distinguishes its safety behavior from plain copy tools by stating it never overwrites existing files and never saves the source model. This is enough to differentiate it from the many sibling 'safe copy' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating parameter-modified safer copies of the current part, but it does not explicitly state when to prefer this over the closely related sibling creo_create_safe_multi_parameter_copy or other safe-copy variants. There is clear operational context, but no exclusions or alternative routing.
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?
The description adds substantial behavioral detail beyond the annotations: it 'refuses overwrite,' 'requires an active cut feature,' 'requires solid volume to decrease,' and 'rejects removal greater than the requested rectangular prism.' These are non-obvious constraints that materially affect invocation and expected outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The main action is front-loaded, and the key behavioral constraints are packed into a compact second sentence. Every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity—9 parameters, no output schema, no helpful annotations, and many sibling copy tools—the description stays at a high level. It omits parameter semantics, return/result behavior, and practical guidance about expected_model or copy_name, so an agent would still face significant ambiguity in invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain individual parameters such as expected_model, copy_name, feature_name, sketch_plane, direction_side, or orientation_plane. It only gestures at the rectangular dimensions through 'rectangular prism,' which weakly maps to width, height, and depth, leaving most parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Copy the current Creo part and create one solid blind cut from a centered rectangular sketch only in the new copy.' It clearly identifies the operation (copy + cut), the geometry (centered rectangular blind cut), and the scope (the new copy), which differentiates it from siblings like the rectangle extrusion copy or thru-hole copy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool applies, notably 'requires an active cut feature.' It does not explicitly name alternatives or state when not to use it, but the prerequisites and purpose are clear enough to guide an agent toward this tool over sibling copy tools.
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?
Annotations only declare destructiveHint=true, but the description reveals exactly what is mutated: guarded dimensions are removed, symmetry assumptions are removed, edges are projected, dims are added, the section is regenerated and verified, and the sketch is updated without saving. This is rich behavioral detail beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded with the active-sketch precondition, but it is a single long run-on sentence listing many sequential steps. It could be more readable as a short structured sequence; despite no redundancy, its structure is not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity, 0% schema coverage, no output schema, and only a destructive annotation, the description is impressively complete: it covers prerequisites, the full mutation sequence, verification, and post-conditions. It still leaves some ambiguity around optional paramers and failure behavior, but for a complex CAD tool it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It maps expected_model, model_edge_ids, and inset reasonably well, but it never explicitly explains inner_length, inner_width, feature_id, or feature_name. 'Remove the two guarded overall rectangle dimensions' may allude to inner_length and inner_width, but the connection is too implicit for an agent to confidently bind parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific multi-step operation on a specific resource: while a rectangular sketch is actively being edited, it removes guarded dimensions and symmetry assumptions, projects four specified edges, creates four inset dimensions, and updates the sketch. This is far more precise than the tool name alone and distinguishes it from siblings like creo_constrain_active_rectangle_symmetric_to_axes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the precondition: the expected Creo model must be actively editing a rectangular sketch. It also states the operation's constraints, such as not accepting, exiting, regenerating the solid, or saving. However, it does not explicitly name alternatives or say when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing that existing assembly relations are preserved, conflicting targets are rejected, skeleton dimensions are temporarily modified and restored for verification, models are saved only after verification, the sheet-metal part remains active, and older versions are recycled. This richly characterizes the mutation behavior consistent with destructiveHint=true and idempotentHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded with the core action and prerequisite context. It packs many behavioral details into one long sentence without obvious fluff, though it could be more readable if broken into shorter sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers preconditions, side effects, verification, saving, and version cleanup. However, it does not explain the return/output behavior, and with no output schema and 14 undocumented parameters, an agent still lacks some information needed to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It conceptually mentions length/width symbols, skeleton dimensions, and expected dimensions, but does not explain the specific meanings of feature IDs, expected model names, thickness, or the exact symbol mapping. With 14 required parameters, this leaves many parameters opaque for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise action: creating two assembly relations that drive the planar-wall sketch length and width from skeleton dimensions. It also specifies the required context (verified top-level assembly, sheet-metal component active), making the tool clearly distinguishable from the many sibling modeling and safe-copy 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the required context: a verified top-level assembly with the sheet-metal component active. It does not explicitly name alternatives or when-not-to-use conditions, but the prerequisite and specific scope provide strong usage guidance.
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?
The description goes far beyond the annotations: it discloses dimensional guards, envelope verification with unchanged volume, assembly regeneration, conditional saving only after verification, preservation of assembly-driven dimensions, post-state active part, and version recycling. These are material behavioral traits not available in annotations, and there is no contradiction with destructiveHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one long, dense sentence, but nearly every clause adds meaningful behavior. It is not padded, though readability would improve by splitting into separate sentences for the main action, verification, and side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, complex, 10-parameter tool with no output schema, the description covers the workflow and side effects well. However, the lack of parameter-level guidance and failure-behavior details means an agent cannot fully determine what to supply or what happens on verification failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 10 required parameters, so the description must compensate, but it only refers generically to thickness, length, width, and a 'named top assembly'. It does not explain expected_assembly, expected_sheetmetal, feature_id, symbols, or how the expected_* values are used, leaving agents guessing at critical invocation inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('reverse'), a specific resource ('verified first planar-wall thickness direction of the active native Creo sheet-metal project part'), and an exact target state ('from -Z to +Z'). It clearly distinguishes this from sibling tools like creo_reverse_project_skeleton_box_direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: the part must be the active native Creo sheet-metal project part, the first planar wall must already be verified, and the operation applies on FRONT. It does not explicitly list exclusions or name alternative tools when not to use it, so it misses only the highest bar.
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?
Beyond the destructiveHint annotation, the description discloses concrete side effects: it 'regenerates and saves the skeleton and top assembly, displays the skeleton, and recycles older versions of only those model families.' This gives the agent a clear picture of what will be modified and cleaned up, going well beyond the annotation's generic destructiveness flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler; every clause adds a meaningful detail about the workflow. It could be more readable if split into separate sentences or bullets, but it remains efficient and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, verification steps, and side effects, which is useful for a destructive tool. However, with seven required parameters, no output schema, and minimal parameter-level documentation, it leaves gaps about how the expected dimensions and model names are used and what happens on verification failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, and the description does little to compensate. It references 'requested datum-plane side' and rectangular dimensions, but it never maps the seven required parameters like expected_assembly, expected_skeleton, feature_name, or expected_length/width/height to their roles in the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('Reverse one verified rectangular skeleton extrusion'), a target ('requested datum-plane side'), and the mechanism ('redefining its Pro/TOOLKIT feature element tree'). This clearly distinguishes it from sibling tools such as creo_reverse_project_sheetmetal_planar_wall_to_positive_z.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when a verified rectangular skeleton extrusion must be reversed to a requested side. It does not explicitly name exclusions or compare with alternative creation/resize tools, but the context is specific enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations, explicitly disclosing the destructive version-recycling step, the save/display side effects, the validation behavior, and the verification of volume and +Z envelope increases. This directly complements destructiveHint=true and adds meaningful operational context beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler, and the primary purpose appears early. It packs six actions into one clause chain, which is somewhat harder to scan than a bulleted list, but every listed behavior earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex operation with 8 parameters, no output schema, and sparse schema descriptions, the description covers the main workflow but leaves gaps around direction_side, orientation_plane, prerequisites, failure conditions, and the return value. It is adequate but not fully self-sufficient for an agent deciding how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 13% schema description coverage, the description compensates for several parameters: surface_id as the face to validate, inset as the equal four-side offset, and expected_assembly/expected_skeleton as the models saved afterward. However, direction_side and orientation_plane receive no semantic explanation, and feature_name's behavior is only partially covered by the schema's Unicode note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific multi-step operation: validate a top-face surface by ID and area, create a centered additive rectangular extrusion with equal inset from the XY outline, verify volume and +Z envelope increases, save/display the models, and recycle old versions. This clearly distinguishes the tool from the sibling creo_create_project_skeleton_surface_outset_extrusion through the explicit 'inset' behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'In the expected standard skeleton' provides clear context for when the tool applies, and the centered-inset geometry makes the intended scenario specific. It does not explicitly name alternatives or state when not to use it, but the inset-vs-outset sibling relationship provides enough differentiation.
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 minimal annotations, the description carries the behavioral disclosure burden and does so well: it states that only the new copy is modified, coordinates are limited to -1000..1000, overwriting is refused, and the source model is not saved. This adds a meaningful safety profile beyond the structured annotations, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence front-loads the core operation and then packs in all key constraints and safety behaviors without redundancy. Every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and sparse annotations, the description covers the main operational context: what is created, where it is created, coordinate limits, overwrite policy, and source-model handling. It does not explicitly state whether the new copy is saved or describe success/error returns, but the essential invocation decisions are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes copy_name, point_name, expected_model, and reference_csys, but x/y/z are just numbers with bounds (57% coverage). The description adds the missing meaning: x/y/z are Cartesian offsets relative to the specified coordinate system, in model units, and the refuse-overwrite behavior clarifies copy_name semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and names the exact resource and outcome: copying the current Creo part and creating a Cartesian offset datum point in the new copy relative to a specified coordinate system. It is scoped explicitly ('仅在新副本中') and includes constraints, making it clearly distinct from sibling safe-copy tools such as creo_create_safe_offset_datum_plane_copy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the described operation: an agent can infer this tool is for creating a datum point on a safe copy of the current part. However, there is no explicit when-to-use/when-not-to-use guidance, prerequisites, or routing away from closely related sibling tools.
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?
Beyond the annotations, the description discloses critical safety behaviors: it refuses to overwrite, does not save the source model, validates multiple conditions, and suppresses only one feature in the new copy. This credibly supports destructiveHint=false and adds meaningful side-effect transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense, front-loaded sentence that packs purpose, validation scope, constraints, and side effects without wasted words. Every clause carries decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four required parameters, no output schema, and a safety-critical operation, the description covers purpose, preconditions, validation keys, and non-destructive guarantees. It does not describe the return value or failure behavior, but the operation is well-scoped enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well-documented. The description adds conceptual grouping—model name, feature ID, and type are used for multi-check validation—but does not add format, constraints, or syntax details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise action—create a new copy and suppress one active, visible, childless round, chamfer, hole, or cut feature—while explicitly saying the source model is not touched and overwrites are rejected. This clearly distinguishes it from sibling safe-copy tools like resume or round/chamfer copies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational preconditions: the target feature must be active, visible, and childless, and the expected model/type must match. However, it does not explicitly say when to prefer this tool over alternatives or when not to use it, so the usage guidance is mostly 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?
Annotations already convey readOnly=false and destructive=false, and the description adds concrete behavioral facts beyond that: 'refuses overwrite' and 'succeeds only when the copy volume is reduced.' This gives the agent useful failure/success conditions not present in structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The main action is stated first, followed by placement and safety behavior, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no output schema, the description covers the core workflow, placement method, overwrite refusal, and success condition. It leaves some parameter-level details to the schema, but the essential context an agent needs before calling is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 10%, so the description must compensate. It partially does by explaining placement via 'one named datum plane and two named offset datum planes,' which maps to primary_plane, reference_plane1/2, and offsets. However, it does not explain expected_model, thru_side, or the exact role of each offset, so parameter semantics remain incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Copy the current Creo part and create one regular straight thru-all hole only in the new copy.' It clearly distinguishes this from advanced hole or other copy tools by saying 'regular straight thru-all hole' and 'only in the new copy.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when a simple straight thru-all hole is needed in a safe copy of the current part. It does not explicitly name sibling alternatives or state exclusions, so it misses the top bar, but the 'regular... thru-all' wording implies it is for the basic hole case.
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?
Annotations already indicate this is not read-only, not idempotent, and not destructive, but the description adds valuable behavior beyond that: it explicitly states that same-name outputs are refused/not overwritten. This helps an agent predict failure 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the core action and source location, then adds the important overwrite restriction. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter export tool, the description covers the key operational constraints: source location, what is produced, and the refusal to overwrite. It does not explain the return value or output destination explicitly, but this is a minor gap given the straightforward operation and rich schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters and their formats. The description reinforces the source location for model_file and the no-extension nature of output_name, but does not add substantive semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific operation: exporting a new STEP file from a Creo part copy in the safe output directory. It also adds a distinguishing behavioral constraint, refusing to overwrite same-name output, which makes it easy to separate from the many sibling Creo 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context about the expected input location ('safe output directory' part copy) and the overwrite restriction, so an agent knows when to use it. It does not explicitly name alternatives or exclusions, but no sibling tool appears to be a direct STEP-export alternative.
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?
The description goes well beyond the destructiveHint annotation by detailing the destructive and side effects: failure before save deletes the partially added component, older versions of only that assembly family are recycled, and the assembly is regenerated and saved. It also discloses verification via API readback, duplicate plane rejection, and reporting of packaged/underconstrained state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler, and the core action is front-loaded. It carries a lot of necessary operational detail, though the run-on structure could be split into shorter sentences for easier processing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool this complex, the description covers an impressive amount: constraint types, side meaning, verification, optional full constraint, regeneration, save, version cleanup, and failure rollback. It does not describe return values or clarify the 'expected' naming convention, but neither is likely to block correct invocation given the richness of the rest of the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at only 40%, the description meaningfully compensates by defining mate vs align plane-normal directions, red/yellow datum sides, the one-to-three constraint array, and duplicate plane rejection. The top-level expected_* parameters are left mostly to their names, but the schema already describes component_model_file and require_fully_constrained, so the constraint semantics are the main gap and are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add an existing project part to the current expected Creo assembly,' and immediately scopes the operation to one to three named planar mate/align constraints. The mate/align semantics and side handling clearly distinguish it from sibling tools like creo_add_project_component_fixed or creo_add_project_component_align_insert_three.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear what kind of placement the tool handles, but it never explicitly says when to prefer this tool over alternatives or when not to use it. Usage context is implied rather than stated, leaving the agent to infer that fixed or insert-based placement should go to sibling tools.
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?
Beyond destructiveHint=true, the description discloses specific side effects: creation of construction centerlines when missing, addition of symmetry constraints, API verification, and explicitly no accepting, exiting, regenerating, or saving of the sketch. This gives an agent a precise model of what will change in the active modeling session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence, but it is front-loaded with the key precondition and then lists the operation steps in logical order. It contains no filler; splitting it into shorter sentences would improve readability without adding information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating Creo operation with no output schema and no parameter descriptions, the description covers the essential precondition, the exact operations performed, verification, and the side-effect boundary of not accepting/exiting/regenerating/saving. It still leaves minor gaps around failure handling and precise parameter semantics, but it is substantially complete for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds some meaning by indicating that expected_model refers to the expected part/skeleton and that expected_length and expected_width act as guarded dimensions for identifying rectangle lines. However, it does not explain units, formatting, or how these values map to the sketch's existing dimensions, leaving important ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: constraining an active rectangular sketch symmetrically to sketch axes. It enumerates concrete sub-actions (identifying lines, creating centerlines, adding symmetry constraints, verifying via readback) that clearly separate it from sibling tools like the dimensioning-focused creo_dimension_active_rectangle_four_side_insets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening condition, 'While the expected Creo part or skeleton is actively editing a rectangular sketch,' clearly states the required context for use. However, it does not explicitly name alternatives or describe when not to use this tool, such as when the sketch is not active or the rectangle does not meet the expected dimensions.
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?
Annotations only mark destructiveHint=true, but the description substantially extends that by disclosing duplicate-name rejection, degenerate-geometry rejection, per-entity verification, regeneration, volume-unchanged validation, save behavior, older-version Recycle Bin handling, and partial-sketch deletion on failure. This fully informs the agent of side effects and failure semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the verb and resource, and every sentence contributes material behavioral or input information. The first sentence is long and dense, but it is still economical rather than rambling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no output schema, the description covers expected model, plane requirements, geometry limits, validation, regeneration, save, recycle-bin cleanup, and rollback behavior. It does not describe return payloads or the coordinate semantics of entity properties, but the schema property names and ranges provide reasonable coverage there.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 86% and several parameters already have inline descriptions, so baseline is 3. The description adds useful meaning by linking expected_model to the 'current expected Creo project part,' clarifying sketch_plane and orientation_plane as named datum planes, and defining entities as 1-32 lines/circles/arcs with duplicate-name rejection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Create') and a precise resource ('one independent sketched datum-curve feature'), and bounds the geometry to '1-32 lines, circles, and arcs on a named datum plane with an explicit orientation plane.' This makes it easy to distinguish from the many copy-style sibling tools even though no sibling is named 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong operational context—current expected model, plane requirements, validation, and save behavior—so an agent can infer this is the direct sketch-creation tool. However, it never states when to prefer this over the numerous create_safe_* or create_project_* alternatives, nor does it provide exclusions.
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?
Annotations only carry generic booleans and provide no real safety detail, so the description carries the full burden. It explicitly discloses copy semantics, the default largest-cylindrical-surface selection, refusal to overwrite, and post-condition verification of active draft feature, feature-count increase, and nonzero solid-volume change. This is strong behavioral disclosure beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler. The core action is front-loaded, followed by the optional surface behavior and the verification/refusal details. Every sentence adds value and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow and safety verifications well, and no output schema exists to explain return values. However, the ambiguous direction_side parameter and the absence of any statement about the tool's return/result format leave gaps for an agent trying to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43%, so the description needs to compensate. It does add useful meaning for hinge_plane (used as both hinge and direction reference) and drafted_surface_id (largest cylindrical surface if omitted). However, the required expected_model and the direction_side enum values (1 vs 2) remain unexplained, leaving a real ambiguity for callers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: copy the current Creo part and create one constant-angle draft feature in the new copy. It also distinguishes this tool from the many sibling copy tools by naming the exact feature type (draft) and by detailing the hinge/direction-plane mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when this tool is appropriate: when a constant-angle draft feature needs to be created on a copy of the current part. It gives useful selection guidance for the optional surface ID, but it does not explicitly name alternatives or state when not to use it relative to other safe-copy siblings.
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?
Annotations only declare non-read-only, non-idempotent, non-destructive. The description discloses meaningful behavioral guarantees: the source model is never saved, overwrite is refused, and the success criteria include an active mirror feature, a feature-count increase, and a nonzero solid-geometry change. This is valuable context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense sentence with no filler. The core purpose is front-loaded and the safety/verification clauses each add necessary behavioral information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the four parameters with weak schema descriptions, the description should explain expected_model and success return behavior more explicitly. It does cover verification criteria well, so it is minimally viable but not complete for an agent invoking this tool blind.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only mirror_plane described. The prose partially maps the parameters through 'current part,' 'new copy,' 'mirror feature,' and 'named datum plane,' but expected_model is still ambiguous and no explicit per-parameter explanation is given. This is partial compensation for a low-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: copy the current Creo part and create a whole-part mirror feature about a named datum plane. It distinguishes this from the many sibling safe-copy tools by naming the mirror operation and its safety contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames the operation and its safe usage context: source model is never saved, overwrite is refused, and the result is verified. It does not explicitly name alternatives or say when not to use this tool, but the purpose is specific enough to route an agent reasonably.
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?
The description is exceptionally transparent about what happens: load, verify, activate existing or create a dedicated window, refit, and foreground Creo, while promising no closing, replacing, saving, or modifying of other open model windows. It adds meaningful behavior beyond annotations, and there is no contradiction with readOnlyHint since file-level data is not mutated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded, but it earns its length by packing many distinct behavioral guarantees into a single coherent chain. It is not bloated, though the single long sentence is slightly harder to parse than a structured breakdown would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a display-focused tool, the description covers source directory, model scope, verification behavior, window activation/creation, refit, foregrounding, and non-destructive guarantees. Missing failure behavior and more explicit parameter-value semantics prevent a 5, especially given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden. It does imply that model_file refers to the direct-child Creo file in the working directory and that expected_model is the model name/type to verify. However, it does not define exact filename formats, file-type vocabulary, path-versus-filename expectations, or what happens on mismatch.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific workflow: read the live working directory, load a direct-child part or assembly, verify its expected model name and file type, activate/create a window, refit, and foreground Creo. This is far more specific than the name alone and makes it distinguishable from project-folder-based sibling tools, especially with the explicit 'No configured or caller-supplied project folder is used.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the intended context: the current Creo session's already-selected working directory, targeting only direct-child models, and explicitly excluding configured or caller-supplied project folders. It does not name sibling tools as alternatives, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond the annotations: the result is regenerated, checked by volume and envelope, saved, displayed, and older assembly/skeleton versions are recycled. This complements destructiveHint=true and idempotentHint=false without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action and scope. Every sentence adds value: the first states the operation, the second explains safety guards, and the third covers side effects. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, destructive tool with no output schema, the description provides strong context about postconditions, verification, and version recycling. It does not detail error behavior when expected values mismatch or state the return value, but the operational flow is substantially covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 8%, so the description must compensate, but it only broadly references length/width, expected old values, and dimension symbols. It does not explain expected_assembly, expected_skeleton, feature_name, or new_feature_name, leaving 12 parameters largely under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Change the length and width dimensions of one verified skeleton box feature'. It clearly distinguishes this resize operation from sibling creation and direction tools like creo_create_project_skeleton_box and creo_reverse_project_skeleton_box_direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is clear: use when resizing length and width of a verified skeleton box feature while preserving its height. It does not explicitly name alternatives or say when not to use it, but the stated scope is specific enough to guide selection.
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?
Beyond the annotations already flagging destructiveness and non-read-only behavior, the description discloses atomic modification, uniqueness checks, read-back verification, regeneration, saving, returning the assembly, and moving old versions to the recycle bin. This is exceptionally transparent behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but free of filler, front-loading the core action and then providing necessary operational details. It is a single long sentence rather than structured clauses, but every phrase contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the operation, verification, saving, destructive version cleanup, and return value, which is strong for a complex tool without an output schema. It stops short of describing failure behavior or explicit prerequisites, so a small gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explicitly stating that count and spacing are modified, mapping directly to new_count and new_spacing, and referencing the spacing dimension d229. It does not attach each parameter by name, but the domain meaning is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: modify the 'hinge pattern' in the five-zero assembly skeleton via the current Creo session. It includes unique identifying details such as feature ID 8242, entry ID 8241, and dimension d229, making it clearly distinct from all 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: call this when the current hinge pattern count or spacing must be atomically modified. However, there is no explicit when-not-to-use guidance or mention of alternatives, especially given the many safe-copy sibling tools available.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description substantially enriches this by disclosing the full mutation sequence: pre-read old values, verify feature ownership and relation-driven status, atomic modification, regeneration, save, read-back verification, return the assembly, and moving old versions to the recycle bin. This far exceeds the structured annotation signal and matches the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence but contains no filler; every clause adds a distinct behavioral fact. It is front-loaded with the core purpose before diving into verification and cleanup steps, though the long compound structure slightly reduces scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, state-changing Creo tool with no output schema, the description covers the essential lifecycle: pre-checks, mutation, regeneration, save, verification, return value, and version cleanup. It does not explain what happens when the feature is relation-driven or when verification fails, but the disclosed workflow is strong enough for an agent to anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the meaning of new_length and new_width. It does so by identifying them as the target length and width applied to d2/d3 of the backframe feature. A slight gap remains because it does not explicitly map new_length to d3 and new_width to d2, nor state units, but the parameter meaning is largely recoverable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (the 'rear frame' feature ID 40 in the current skeleton), the exact dimensions to be modified (d3, d2), and the intended result (target length/width). It clearly distinguishes this tool from broader siblings like creo_modify_project_feature_dimensions or creo_resize_project_skeleton_box by fixing the target feature and workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied: use this when you want to resize the backframe of the current assembly's skeleton. However, there is no explicit statement of when not to use it or which sibling tool should be chosen instead under similar conditions, so an agent has to infer selection criteria.
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?
注释已表明 destructiveHint=true，描述进一步披露了原子执行、读回验证、重新生成并保存子装配与总装配、返回总装配，以及将旧版本移入回收站等关键副作用。这些信息显著超出注释本身，帮助代理预判破坏性后果。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述是一个长而密集的句子，但每个分句都承载有效信息，如原子执行、保存、回收站行为。没有冗余，不过可以拆分为更清晰的结构。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
在无输出 schema 且参数无描述的情况下，描述已覆盖操作范围、副作用、验证方式、保存行为和返回值。但仍缺少对 expected_assembly 的明确界定及失败/异常行为，稍有遗漏。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入 schema 覆盖率为 0%，描述承担了参数解释责任。它说明了组件按模型名唯一定位，并区分了“活动组件”和“普通隐含组件”，对应 suppress_component 与 resume_component。但 expected_assembly 的具体含义（总装配还是子装配模型名）仍然模糊，未逐一阐明参数。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明了具体操作：在指定子装配中隐含一个活动组件并恢复另一个隐含组件，且界定了当前总装配范围。与兄弟工具中围绕特征复制/抑制的 create_safe_feature_suppression_copy 等相比，本工具针对组件可见性切换，易区分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述给出了清晰的使用场景：当前项目总装配内、指定子装配中，需要同时抑制和恢复组件时使用。但没有明确说明何时不应使用或列出替代工具，因此未达到最高分。
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?
Beyond the minimal annotations, the description reveals important behavior: it refuses to overwrite existing parts, keeps the folder as the live working directory, saves the model, and displays it. This gives an agent a strong understanding of side effects and persistence behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with the primary creation action front-loaded. Every clause adds operational detail, though the run-on structure is slightly less polished than a more segmented description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter creation tool with no output schema, the description covers the template source, target directory, overwrite refusal, saving, and display. An agent has enough context to invoke it correctly and anticipate its main side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents model_name as the Creo part name without .prt. The description does not add parameter-specific semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: creating a new millimeter solid Creo part from the mmns template. It distinguishes itself from sibling tools by emphasizing 'new,' 'solid,' and template-based creation rather than safe copies or sheetmetal parts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for creating a new solid part in the current live working directory from the installed template. It does not explicitly name sibling alternatives or exclusion conditions, but it implies when this tool is appropriate versus copy or sheetmetal creation tools.
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?
Annotations are all false and carry little positive safety information, so the description carries the behavioral burden. It discloses several non-obvious behaviors: the work happens on a new copy, overwrites are refused, an active feature is required, and a solid-volume change is verified. Failure-behavior details are not described, but the safety-critical traits are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single information-dense sentence with no filler. Every clause adds either purpose, mode support, or a behavioral constraint, and the core purpose appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, no-output-schema tool this is largely complete: it explains what is created, supported modes, key prerequisites, overwrite behavior, and validation. It does not specify the exact return value or failure messages, but the behavior is understandable enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 50%, the description compensates well by relating operation_mode to add/cut, feature_name to the required active feature, the rectangular radial section to axial_width/inner_radius/radial_thickness, and copy semantics to expected_model/copy_name. direction_side remains only an enum in the schema and is not explained in the description, but the full-360 nature makes it less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (copy current part and create a 360-degree solid revolve), a specific section shape (closed rectangular radial section), and the target (new copy). This distinguishes it from sibling safe-copy tools such as rectangle extrusion, cut, and round copies without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to invoke it: it applies when a full 360-degree revolve with a rectangular radial section is desired, in additive or cut mode. It also states a prerequisite (active feature) and a limitation (refuses overwrite), though it does not explicitly name alternative tools for when another feature type is needed.
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?
Beyond the annotations, the description discloses important safety behaviors: 'The tool refuses overwrite and verifies an active round feature, a feature-count increase, and a nonzero solid-volume change.' This adds substantial contextual value about side effects and validation that annotations only partially indicate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three compact sentences, front-loaded with the primary action, then edge-selection logic, then validation behavior. Every sentence contributes essential operational information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is nearly complete for a copy-and-round tool: it explains the action, optional edge selection, overwrite refusal, and post-condition checks. It would be fully complete if it clarified the role of the required expected_model parameter and, to a lesser extent, copy_name/feature_name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description partially compensates by explaining edge_id behavior and constant-radius semantics. However, required parameters copy_name, feature_name, and especially expected_model are not semantically clarified in the description, leaving a meaningful gap for an agent selecting these inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Copy the current Creo part and create one constant-radius edge round in the new copy.' It clearly identifies the tool's distinctive operation (round creation) and differentiates it from sibling copy tools like chamfer, shell, or dimension copies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool is for creating a constant-radius round on a copied part. It also provides an explicit branch for edge_id ('explicit edge ID may be supplied; otherwise the longest supported... is selected'), though it does not explicitly mention alternative tools or exclusions.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond those hints: it targets only 'active' component instances, depends on the 'current expected' assembly, and uses the Pro/TOOLKIT API. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the action, scope, and output contents; the second confirms read-only behavior and API dependency. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only getter with strong annotations and no output schema, the description adequately covers the target assembly and the data returned. It omits error/edge-case behavior and explicit alternatives, but nothing essential for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lone expected_assembly parameter. It does so by tying the parameter to the 'current expected Creo assembly' and clarifying that the tool returns component instances of that assembly. The remaining syntax details are already captured by the schema pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Read' and a clear resource: 'the active component instances of the current expected Creo assembly.' It enumerates the returned data (feature IDs, model names, placement matrices, constraint types/references), making it distinct from sibling getters like creo_get_features or creo_get_dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: reading active component instances from the current expected assembly, and it explicitly flags the operation as read-only. It does not name sibling alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'read-only list' is consistent with those. It adds useful behavioral context by naming the returned data categories and the session-scoped working directory requirement, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense sentence with no wasted words. It front-loads the read-only nature, then the target resource, scope, and returned contents. Every clause earns its place and no information is repeated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema, the description usefully enumerates the returned fields. It covers the input context and read-only behavior. It lacks an explicit pointer to the sibling creo_get_dimensions for the non-project case, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines model_file as a string with length limits; the description adds meaning by indicating the parameter targets a Creo part stored under the current live working directory. It does not explicitly state the expected filename/path format, but for a single simple parameter this is reasonably compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: a 'read-only list of standard dimensions for one Creo part'. It clearly scopes the tool to a part in the live working directory and enumerates exactly what is returned (IDs, symbols, values, relation-driven state, owning features). This differentiates it from the many sibling creation/modification 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: use this when you need standard dimensions for a project part already stored in the current live working directory. It does not explicitly contrast with the sibling creo_get_dimensions, nor state when not to use this tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint and idempotentHint annotations, the description adds valuable behavioral detail: files go to the Recycle Bin, the named keep file is never removed, unrelated files are untouched, and the operation is scoped to the current working directory and .prt/.prt.<version> files. This is exactly the context an agent needs before invoking 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight sentence that front-loads the precondition, then states the action, scope, and exclusions without filler. Every clause earns its place and nothing is repeated from the name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive cleanup tool with one parameter, the description covers what files are affected, the location, the keep-file exception, and the safety behavior. Combined with the annotations and fully documented schema, an agent has enough information to invoke it correctly without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is already fully documented in the schema with the description 'Exact latest Creo part file to keep in the current Creo working directory.' The tool description's mention of the 'explicitly named keep file' reinforces the parameter's role but does not add new semantic information. Baseline 3 is appropriate given 100% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it moves every non-keep .prt or .prt.<version> file in the current Creo working directory to the Windows Recycle Bin. It clearly differentiates itself from the many create/verify siblings by naming the exact cleanup behavior and exclusions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear precondition: use this after a newly generated part has been verified. It does not name alternative tools or explicit when-not-to-use conditions, but no cleanup sibling exists, so the context is sufficient for an agent to recognize the intended workflow.
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?
Beyond the destructiveHint annotation, the description discloses concrete side effects: partial feature deletion on any failure before save, moving older versions of the model family to the Windows Recycle Bin, and detailed verification steps including sheet-thickness removal volume and regeneration. This gives the agent strong awareness of destructive and non-idempotent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not bloated; the main operation is front-loaded and every clause adds operational information. The long verification list would be more scannable as structured bullets, but it remains appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, multi-parameter CAD operation with no output schema, the description covers target model, feature creation, verification checks, failure cleanup, and file-version side effects. It does not clearly describe return values or fully explain optional parameters like orientation_plane, but the essential invocation context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must carry parameter meaning. It does explain core geometric semantics: three equal circles at '-spacing, 0, and +spacing from the requested center', the role of diameter in the total cylindrical cut area, and the expected surface/owner feature verifications. However, parameters such as orientation_plane and center_u/center_v are only implicitly covered, and units are not stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a highly specific action: 'Create one through-all extruded cut containing exactly three equal circles on one guarded planar surface of the current expected native Creo sheet-metal project part.' It names the exact geometry, placement, and target resource, which clearly distinguishes it from the many sibling copy/cut 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear preconditions: the operation applies to the 'current expected native Creo sheet-metal project part' and a 'guarded planar surface', and it verifies surface IDs, layout margins, and active cut features. It does not explicitly name alternative tools or state when not to use it, but the specialized phrasing makes the intended use distinct and inferable.
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?
Beyond the annotations, the description discloses important behavioral guarantees: it refuses to overwrite, does not save the source model, validates against both symbol and expected old value, restricts new values to 0.5–2x the old value, and only works on non-relation-driven dimensions. This gives an agent a clear picture of side effects and safety boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense, information-rich sentences. It front-loads the most decision-relevant constraints—validation, single-dimension modification, copy-only behavior, no overwriting, and no source save—without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five fully documented required parameters and no output schema, the description covers the essential invocation context and safety behavior. It clearly states what is modified, where it is modified, and what is not touched, so an agent can correctly select and call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already well documented. The description reinforces the relationship between expected_value and new_value and mentions the 0.5–2x limit, but it does not add significant parameter-level semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: double-validate the current Creo part, modify exactly one non-relation-driven positive dimension in a new copy, and regenerate. It names a specific verb, resource, and scope, and the mention of 'non-relation-driven' and 'one dimension' helps distinguish it from sibling safe-copy tools such as parameter and multi-parameter copies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need to safely modify a single dimension in a new copy without overwriting or saving the source. However, it does not explicitly name alternatives like create_safe_parameter_copy or create_safe_multi_parameter_copy, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses the full behavioral lifecycle: guarded changes, regeneration, read-back verification, active-feature verification, model save, older-version move to Recycle Bin, and rollback on any failure before save. This is far more transparent than the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: the first states purpose and scope, the second describes the full execution/side-effect sequence, and the third states the rollback guarantee. There is no filler and the most important selection information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is thorough about behavior and side effects, which is crucial for a destructive mutation tool. However, there is no output schema and the description never states what the tool returns to the agent, leaving that aspect to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents expected_model, feature_name, expected_value, and new_value, with 67% coverage. The description adds useful meaning by explaining that changes are guarded by dimension symbol, expected old value, feature ownership, and relation status, and that one to eight modifications map to the schema's min/max constraints. It does not deeply define dimension_symbol, but the added context still elevates it above the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Modify one to eight driving dimensions of one named feature in the current expected Creo project part.' It also specifies the concrete workflow and distinguishes itself from the many sibling creation/copy/suppression tools by focusing on guarded modification of an existing feature's dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: when a named feature's driving dimensions need to be changed in the current project part, with safety guards and save behavior. It does not explicitly name alternatives or say when not to use it, but the context is strong enough for selection among siblings.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false; the description adds useful context beyond those by explaining it is a compatibility tool, operates on the 'live' session directory, and 'never creates, selects, or changes a folder.' This is consistent with and reinforces the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one tightly structured sentence that front-loads the primary purpose and packs in the key clarifications: no side effects, no argument, and current-session scope. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent compatibility tool, this description is complete enough for an agent to invoke it correctly. The annotations cover safety, and the description covers behavior, scope, and the absence of any directory argument, leaving no critical invocation detail missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema description coverage is 100%, so the schema already conveys all parameter meaning. The description still adds value by explicitly confirming it 'accepts no directory argument,' which is important given the tool's misleading setter-style name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('reads and verifies') and resource ('live working directory already selected in the current Creo session'), and directly corrects the misleading name by clarifying it 'never creates, selects, or changes a folder.' This allows an agent to understand the true scope despite the 'set' in the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it is a compatibility tool for reading/verifying an already-selected directory. It also states a clear exclusion — it never changes the folder and accepts no directory argument — which tells the agent not to use it for setting a directory, though it does not name alternative tools explicitly.
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?
Annotations only mark the tool as destructive, but the description discloses a full behavioral profile: directory switching, edge ID and length verification, feature-type checks, radius rule, regeneration and volume checks, a single save, limited version recycling, and deletion of the whole batch feature on failure. This far exceeds the annotation hints and gives an agent a clear picture of the operation's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries operationally useful information. The core action and constraint are front-loaded, followed by a compact list of validations and side effects with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites, verification steps, atomicity, save behavior, version cleanup, and failure handling, which is substantial for a destructive batch tool with no output schema. It does not describe the success return value, but that is not essential for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema-described parameters, the description compensates by explaining shared angle and height, edge IDs and expected lengths for verification, and the bend-radius rule. However, expected_model and feature_name are not explicitly explained, though their property names and constraints make their likely roles reasonably clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: creating 'one native Creo sheet-metal flat-wall feature' on 'exactly two verified straight boundary edges' in one connection and transaction. It clearly differs from the many sibling create-copy and sheet-metal tools because it scopes to exactly two edges in a batch operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description effectively states the preconditions and scope: exactly two verified straight boundary edges, a single connection/transaction, and shared angle and height. It implies when the batch tool is appropriate, but it does not explicitly name the singular flat-wall sibling or state when an agent should prefer an alternative.
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?
The annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral context: it starts or reuses a resident bridge, is bound to the current Creo session, exits automatically when Creo closes, and avoids traversal work. These are meaningful behavioral details beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the critical directive ('first command in every new session') and then states scope, exclusions, and lifecycle in order of importance. Every clause adds necessary information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter handshake tool with no output schema, the description is complete: it explains when to call it, what it returns, what it avoids, and how the bridge lifecycle works. An agent has enough context to invoke it correctly in a new session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to document; this is the baseline-4 case. The description reinforces that no user input is needed beyond calling the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (start or reuse the resident bridge) and resource (current Creo session), and precisely lists the data it retrieves: working directory, current model name, type, and outer dimensions. It clearly distinguishes itself from siblings by stating it is the first command in a new session and that it does not traverse features, dimensions, parameters, or assembly components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this should be the first command in every new Creo session, which is strong when-to-use guidance. It also states what the tool deliberately does not do, providing clear when-not guidance relative to other inspection tools like creo_get_features or creo_get_dimensions.
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:

[![codex-creo-mcp MCP server](https://glama.ai/mcp/servers/520-YM/codex-creo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/520-YM/codex-creo-mcp)

Score Badge

Copy to your README.md:

[![codex-creo-mcp MCP server](https://glama.ai/mcp/servers/520-YM/codex-creo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/520-YM/codex-creo-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/520-YM/codex-creo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server