pro_sheet_bend

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds real behavioral context: constant thickness, circular bends, conserved developed length, native solid volume verification, and the important 'No save' caveat that bounds how destructive the operation actually is. It does not explain what gets overwritten when updating an existing configuration, which keeps it from a 5.

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

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

Roughly three short sentences/fragments, front-loaded with the action and followed by the key constraints and the 'No save' qualifier. Little waste, though the telegraphed phrase 'native solid volume is verified' is slightly opaque without follow-up on what happens if verification fails.

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?

An 11-parameter mutation tool with no output schema, no annotations explaining semantics, and zero schema descriptions needs far more from the description than it provides; the meaning of suppress_features, document_path expectations, and the identity/update semantics of configuration vs feature_name are all left to the agent to guess.

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

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

Schema description coverage is 0% across 11 parameters, so the description carries the full burden. It only obliquely gestures at a few of them ('constant thickness', 'circular bends', 'conserved developed length') while the two other required parameters, document_path and suppress_features, are entirely unexplained, as are feature_name, configuration, and the offset/dimension fields.

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 and resource: 'Create or update an owned geometric sheet-bending configuration in an exact saved part copy.' The clause 'This is geometric animation, not forming simulation' carves out the tool's nature. It does not, however, explicitly contrast with siblings such as add_swept_pipe or pro_variant_study, so the differentiation is only partial.

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

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

The description implies when to use it (geometric bend visualization on a saved copy, explicitly not a forming simulation) and notes 'No save.' There is no explicit when-not guidance, no mention of prerequisites for the document_path, and no routing to an alternative tool when the agent wants a real forming analysis or a saved result.

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