Skip to main content
Glama
hellstein-dev

fusion-mcp

feature_offset_faces

Press-pull faces of a body by moving them along their normals a signed distance: positive offsets grow the body outward, negative pull faces inward.

Instructions

Press-pull faces of a body: move them along their normals by a signed distance (positive grows the body outward, negative pulls the faces in).

Press-pull of a sketch profile = feature_extrude; press-pull of a fillet edge (change a rounding) = feature_fillet. Units: distance in units (default mm) or a Fusion expression. Faces from inspect_query on the latest body. The bodies are listed in modified_bodies.

Errors: distance 0, a non-face ref -> INVALID_PARAMS (nothing changed); an offset Fusion cannot compute -> FUSION_API_ERROR, rolled back.

Returns {"feature", "health", "created_bodies", "modified_bodies", "removed_bodies"}.

Example: feature_offset_faces(faces=[], distance=2)

Input Schema

NameRequiredDescriptionDefault
chainNoAlso take tangent-connected faces
facesYesFace refs (inspect_query); re-query after later features
unitsNoUnit of plain-number lengthsmm
distanceYesSigned offset: positive = outward, negative = inward

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/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 well: it discloses that distance 0 and non-face refs yield INVALID_PARAMS (nothing changed) and uncomputable offsets yield FUSION_API_ERROR with rollback. It also enumerates the return keys. It stops short of stating whether this modifies the body's parametric history vs. a direct edit, which would complete the mutation picture.

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

Conciseness4/5

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

Purpose and sign semantics are front-loaded, followed by sibling disambiguation, errors, return shape, and a concrete example. Dense and mostly waste-free, though the multi-line error/return block is slightly heavier than needed.

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?

No output schema exists, yet the description enumerates the returned keys and fully documents error behaviors and rollback. Combined with unambiguous face sourcing, an agent has everything needed to invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, including the signed-distance semantics and units default, so baseline is 3. The description reinforces the sign convention and units and clarifies the faces source, but it never mentions the `chain` parameter (tangent-connected faces), leaving that to the schema.

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+resource (press-pull offset of faces) and immediately clarifies the signed-distance semantics. It also explicitly separates itself from feature_extrude (sketch-profile press-pull) and feature_fillet (edge press-pull), so an agent can pick it apart from siblings without opening schemas.

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

Usage Guidelines5/5

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

Names the alternatives and the exact conditions that select them: press-pull of a sketch profile routes to feature_extrude, press-pull of a fillet edge routes to feature_fillet. It also tells the agent where faces come from (inspect_query on the latest body) and to re-query after later features.

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