creo_get_features

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.

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.

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.

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.

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.

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.