Skip to main content
Glama
hellstein-dev

fusion-mcp

timeline_edit_extrude

Change an existing extrude feature's distance, two-sided distance, or taper angle in Fusion 360, with automatic revert if the edit causes an error.

Instructions

Change an existing extrude: distance (only distance extents, not to-object/ through-all), distance_two (two-sided extrudes) and taper_angle (degrees).

Example: timeline_edit_extrude(feature=, distance=30).

Returns {"feature": item, "changed": [{"key", "parameter", "old_expression", "new_expression", "value", "value_unit"}]} (values in mm / deg). All given keys are applied together; if the feature (or any other) falls into the error state everything is reverted and the call fails with FUSION_API_ERROR, details.reverted = true — unless allow_errors=true. A key that does not apply to this feature fails with INVALID_PARAMS and details.available_keys; no key at all fails with 'nothing to change'.

Input Schema

NameRequiredDescriptionDefault
unitsNoUnit of plain length numbersmm
featureYesFeature ref from timeline_list (or 'timeline:<name>')
distanceNoNumber in mm (or `units`), or a Fusion expression ('30 mm', 'width / 2')
taper_angleNoNumber in degrees, or a Fusion expression ('15 deg', 'a / 2')
allow_errorsNoKeep the change even if a feature falls into the error state (default: revert and fail)
distance_twoNoSecond side of a two-sided extrude: mm (or `units`) or expression

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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 discloses atomic application of all keys, automatic revert into FUSION_API_ERROR with details.reverted, the allow_errors override, INVALID_PARAMS with details.available_keys for non-applicable keys, and the 'nothing to change' failure. That is unusually thorough mutation-safety disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and editable fields, then the example, then the return shape, then the failure semantics. Nothing is redundant — even the dense error paragraph earns its place by explaining revert behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 covers the editable surface, units handling, return shape, and every failure mode an agent would hit. Nothing material is left for the agent to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine meaning the schema lacks: distance is restricted to distance extents, distance_two to two-sided extrudes, taper_angle is in degrees, and returned values are in mm/deg. The example call also clarifies the feature reference style.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (change) and resource (an existing extrude) and enumerates exactly which parameters are editable. The 'extrude' qualifier cleanly separates it from sibling editors like timeline_edit_revolve, timeline_edit_fillet, and timeline_edit_hole.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly scopes applicability — distance only for distance extents (not to-object/through-all) and distance_two only for two-sided extrudes — which tells the agent when a key will work. It does not, however, explicitly name where to go for the excluded extent types (e.g. timeline_feature_parameters), so alternatives are only implied.

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

Deploy Server

Other Tools