Skip to main content
Glama
hellstein-dev

fusion-mcp

body_delete_faces

Removes specified faces from a body and lets Fusion heal the gap, effectively stripping features such as fillets or bosses; requires face refs from inspect_query.

Instructions

Delete faces from a body; Fusion heals the gap (e.g. remove a fillet or a boss).

Faces from inspect_query on the latest body. The bodies are listed in modified_bodies.

Errors: a non-face ref -> INVALID_PARAMS (nothing changed); faces Fusion cannot heal -> FUSION_API_ERROR, rolled back.

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

Example: body_delete_faces(faces=[<fillet face 1>, <fillet face 2>])

Input Schema

NameRequiredDescriptionDefault
facesYesFace refs (inspect_query); re-query after later features

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the load and does it well: it discloses automatic gap healing, two distinct error modes with their error codes and whether state is preserved or rolled back, and the shape of the returned payload. The remaining gap is undo/timeline-editability context for a destructive operation.

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-loaded purpose followed by input provenance, error behavior, return keys, and an example — each line performs a distinct job with no filler or repetition of the schema.

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, so documenting the return keys is necessary and done here; combined with error codes, rollback behavior, prerequisite sourcing, and an example, an agent has everything needed to invoke this correctly.

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 baseline is 3; the description adds real value by telling the agent where the refs must come from (inspect_query on the latest body) and warning to re-query after subsequent features. The example also shows multiple faces accepted at once, which the schema does not convey.

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 ('Delete faces from a body') and immediately clarifies the distinctive healing semantics (e.g. remove a fillet or a boss), which separates it from body_remove (whole body) and body_replace_face 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.

Usage Guidelines4/5

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

Gives a concrete prerequisite ('Faces from inspect_query on the latest body') and a worked example call, plus the caveat to re-query after later features. It stops short of naming alternatives such as body_remove or timeline_edit_fillet, so it does not reach the top band.

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