timeline_edit_shell

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: it discloses that all supplied keys apply atomically, that any error-state feature reverts everything and raises FUSION_API_ERROR with details.reverted unless allow_errors=true, and that inapplicable keys return INVALID_PARAMS with details.available_keys.

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?

Purpose is front-loaded in the first sentence, followed by an example, then return shape and failure semantics — every block earns its place. Slightly dense with error-code detail, but nothing is wasted.

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 mutation tool with no annotations and no output schema, the description supplies exactly what the structured data lacks: the return payload shape, unit conventions, and the full revert/error contract. An agent can call this correctly without further context.

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 meaning of units, feature, allow_errors and both thickness params is already documented. The description's '(mm or units)' and the example add marginal reinforcement but no new syntax or constraints beyond 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: changing inside/outside wall thickness of an existing shell, with a concrete example call. It is clearly distinguishable from sibling timeline_edit_extrude/revolve/fillet/chamfer tools by naming the exact edited parameters.

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 example plus the note that 'no key at all fails with nothing to change' makes clear at least one of inside_thickness/outside_thickness must be supplied. It gives clear context but does not explicitly route the agent to alternatives (e.g. feature_shell for creating a shell) or state exclusions.

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