catia_rename_feature

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

Adds real behavioral context beyond the annotations: the rename is done by setting the .Name COM property directly, with no macro/VBA bridge, and it acts on the active Part Body. Annotations only cover safety/idempotency, so this mechanism disclosure is genuinely additive. It stops short of describing failure modes (name collisions, missing old_name) or error behavior.

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

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

Three front-loaded sentences with no filler: what it does, how it works, when to use it. The COM/VBA detail is slightly technical but earns its place by explaining reliability and the absence of a bridge dependency.

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

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

For a tool with no output schema and annotations covering only safety hints, the description supplies scope, mechanism, and workflow placement. It omits error/edge-case behavior (duplicate names, old_name not found, no active document), which keeps it short of fully complete.

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

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

Schema description coverage is 100%, so the schema already documents kind, new_name, and old_name including the 'most recent feature' default behavior. The description adds no format, naming-convention, or constraint detail beyond that baseline.

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

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

States a specific verb (rename) plus the exact resource and scope (a feature or sketch in the active Part Body). This cleanly separates it from the sibling catia_rename_body, which operates on bodies rather than features/sketches.

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

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

Gives a concrete usage context: call it right after creating a feature via catia_pad, catia_pocket, etc., rather than doing it manually in the GUI. It implies the workflow position but never explicitly excludes the related catia_rename_body sibling or states preconditions like an open/active document.

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