create_named_selection

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the agent knows this mutates model state without destroying geometry. The description adds the genuinely useful note that downstream solvers (Fluent, Mechanical) consume these groups, but says nothing about name collisions, invalid IDs, or what happens to an existing group with the same name.

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?

A single dense sentence with the verb and resource front-loaded and the domain examples parenthesized rather than bloating the text. Nothing is wasted, though one more clause on the selection-parameter rule would have been worth the words.

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 output schema exists, so return values need no explanation, and the domain framing is adequate for a moderately complex 5-parameter mutation. The missing piece is the parameter combination contract — an agent could call it with only 'name' and no geometry and have no textual warning that this is invalid.

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 only 40%, and only 'body' and 'bodies' carry descriptions; face_ids, edge_ids and name are undocumented. The description hints that bodies/faces/edges are alternative things to group, but never states that at least one of bodies/face_ids/edge_ids must be supplied, nor that face_ids/edge_ids require the owning 'body' — the most important invocation constraint is left unstated.

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 ('Group') plus the exact resources (bodies/faces/edges) and the artifact produced (a name), which cleanly separates it from select_faces/select_edges in the sibling list. It stops short of naming those siblings, so the differentiation is inferential rather than explicit.

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 parenthetical use cases (inlet/outlet/wall for CFD, fixed supports for FEA) imply when the tool is appropriate and 'Fluent and Mechanical pick these up' hints at cross-tool consumption. But there is no explicit when-not guidance and no stated alternative for one-off, non-persistent selection.

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