timeline_edit_chamfer

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

With no annotations, the description carries the full burden and does so well: it documents atomicity ('all given keys are applied together'), revert-on-error with FUSION_API_ERROR and details.reverted, the allow_errors escape hatch, and two distinguishable failure modes (INVALID_PARAMS with details.available_keys, and 'nothing to change'). It also discloses the return payload and units.

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?

Front-loads the purpose, then an example, then return shape and error behavior — a sensible order. It is dense but nearly every clause carries operational information; minor boilerplate appears in 'all given keys are applied together' and 'details.available_keys', which read like generic edit-template text for a tool that effectively has one editable key.

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?

Despite having no output schema and no annotations, the description covers return structure, units, atomicity, revert semantics, and error codes. An agent has everything needed to call this correctly and to interpret both success and failure.

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 the baseline is 3, but the description adds genuine meaning: distance applies to *all* equal-distance edge sets (not a single edge), and the allow_errors/revert interaction is explained behaviorally rather than just restated. The example pins feature and distance together as the minimal call.

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 ('Set the distance ... of an existing chamfer') and scopes it precisely to 'every equal-distance edge set', which distinguishes it from feature_chamfer (creation) and timeline_edit_fillet. The inline example reinforces the exact intent without needing the schema.

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 word 'existing' implies this is for modifying rather than creating a chamfer, and the error semantics hint at when to use allow_errors. But there is no explicit statement of when to prefer this over feature_chamfer or timeline_feature_parameters, and no prerequisites (e.g. feature must come from timeline_list).

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