feature_rule_fillet

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

With no annotations, the description carries the full burden and does well: it discloses error conditions (INVALID_PARAMS for mismatched faces2/rules, FUSION_API_ERROR with rollback on failure), identifies that modified bodies are reported, and gives the return object shape. It omits any note about performance or side effects on the timeline, but covers the essential 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?

The description is front-loaded with the core rule logic and units, then covers errors and return values. It is slightly long but every sentence serves a purpose; the example is helpful but could be trimmed without much loss.

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?

Given no output schema and no annotations, the description is nearly complete: it states the return shape, error modes, and rollback behavior. It does not explicitly warn that this creates a timeline feature or mention constraints on radius value, but overall it gives an agent enough to call correctly.

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 100%, so baseline is 3, but the description adds meaning beyond the schema: it clarifies that radius can be a Fusion expression (schema only says string/number) and explains that faces come from inspect_query while features come from earlier feature_* results. This reduces ambiguity for the two most complex parameters.

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 opens with a precise verb+resource: 'Rule-based fillet: round every edge of the given faces/features (all_edges) or only the edges where faces meet faces2 (between_faces), with one radius.' This distinguishes it from the sibling feature_fillet (explicit edges) and clearly states the two rule modes.

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?

It explains when to use all_edges vs between_faces and explicitly says to fall back to feature_fillet with explicit edges if the Fusion API lacks rule fillets. However, it does not state a general preference between this tool and feature_fillet when both are available, leaving a small gap.

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