Skip to main content
Glama
hellstein-dev

fusion-mcp

timeline_edit_hole

Modify existing hole features by updating diameter, depth, tip angle, counterbore, or countersink parameters, reverting changes automatically if the model enters an error state.

Instructions

Change an existing hole: diameter, depth (distance extents only), tip_angle, counterbore_diameter/depth (counterbore holes), countersink_diameter/angle (countersink holes). Lengths in mm (or units), angles in degrees.

Example: timeline_edit_hole(feature=, diameter=6.6, depth=12).

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
depthNoNumber in mm (or `units`), or a Fusion expression ('30 mm', 'width / 2')
unitsNoUnit of plain length numbersmm
featureYesFeature ref from timeline_list (or 'timeline:<name>')
diameterNoNumber in mm (or `units`), or a Fusion expression ('30 mm', 'width / 2')
tip_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)
counterbore_depthNoNumber in mm (or `units`), or a Fusion expression ('30 mm', 'width / 2')
countersink_angleNoNumber in degrees, or a Fusion expression ('15 deg', 'a / 2')
counterbore_diameterNoNumber in mm (or `units`), or a Fusion expression ('30 mm', 'width / 2')
countersink_diameterNoNumber in mm (or `units`), or a Fusion expression ('30 mm', 'width / 2')

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 provided, the description carries the full behavioral burden and does so thoroughly. It documents the return structure, units, all-keys-applied-together semantics, revert-on-error behavior, FUSION_API_ERROR with details.reverted, INVALID_PARAMS with details.available_keys, and the no-key failure case.

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?

The description is front-loaded with the core action and editable fields, followed by units, an example, return shape, and error semantics. Despite covering many parameters and complex transactional behavior, every sentence carries useful information and there is little waste.

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 10-parameter mutation tool with no annotations and no output schema, the description supplies the missing behavioral and return-value context. It explains parameter applicability, units, success and failure behavior, and the revert semantics, leaving no major gap for correct invocation.

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 schema already documents each parameter, and the description adds cross-parameter meaning: lengths are in mm or units, angles in degrees, depth applies only to distance extents, counterbore fields apply to counterbore holes, and countersink fields to countersink holes. It also clarifies that all supplied keys are applied together, which is not obvious from the schema alone.

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?

The description opens with a specific verb and resource: 'Change an existing hole', then enumerates the editable properties. It clearly distinguishes editing an existing hole from creating one, and the scope is concrete enough that an agent can identify the operation without inspecting the schema.

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?

It states that this tool changes an existing hole and notes applicability constraints such as depth being for distance extents only, counterbore fields for counterbore holes, and countersink fields for countersink holes. It does not explicitly name alternatives such as feature_hole for creation, but the context is clear.

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