sw_generate_wing

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

Annotations already cover the mutation profile (readOnly=false, destructive=false); the description adds real context beyond that: the wing is lofted and mirrored, and the call returns area, aspect ratio, MAC and neutral point. It also fixes the geometric convention (span along +X, flight direction +Z), which is not discoverable from annotations or schema. It does not state document prerequisites explicitly, keeping it just short of top marks.

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 tight sentences: what it builds first, then what it returns, then the orientation convention. Every clause carries information an agent needs and nothing is padded.

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 13-parameter, no-output-schema mutation tool, the description supplies the missing pieces: it enumerates the returned metrics (area, AR, MAC, neutral point) in lieu of an output schema and pins the coordinate conventions. With the schema already documenting per-parameter meaning, nothing essential is absent.

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 coverage is 85%, so the baseline is 3; the description earns an extra point by specifying axis conventions (span on +X, flight on +Z) that no parameter description conveys, and by framing taper/twist/sweep/dihedral as the wing-shaping inputs. It still leaves units and the meaning of sections/incidence to the schema.

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 ('generate a complete wing') plus the exact composition (blended airfoil sections with taper, sweep, dihedral, twist, lofted and mirrored). This clearly separates it from sibling generators like sw_generate_fuselage, sw_generate_propeller and the manual sw_loft/sw_sweep path.

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?

'A complete wing in one call' implies when to prefer this over assembling lofts and mirrors manually, but no sibling is named and there are no explicit exclusions or preconditions (e.g. requires an open document). Usage is inferred rather than stated.

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