Skip to main content
Glama
hellstein-dev

fusion-mcp

body_scale

Scale 3D bodies uniformly or per axis around a specified base point using unitless factors.

Instructions

Scale bodies about a base point, uniformly (factor) or per axis (factors).

Factors are unitless numbers > 0 (or Fusion expressions) - no unit conversion. Pass either factor or factors. Refs: bodies from inspect_query, points from origin:O, construction_point or vertices.

Errors: a factor <= 0, factor together with factors, a non-point base -> INVALID_PARAMS (nothing changed).

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

Examples: body_scale(bodies=[b], factor=0.5); body_scale(bodies=[b], factors={"x": 1, "y": 2, "z": 0.5})

Input Schema

NameRequiredDescriptionDefault
pointNoBase point: origin:O (default), vertex, sketch/construction pointorigin:O
bodiesYesBody refs (inspect_query / earlier results)
factorNoUniform factor (unitless, > 0)
factorsNoNon-uniform {x, y, z} factors instead of `factor`

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well: it specifies that factors are unitless with no unit conversion, that exactly one of factor or factors should be passed, and that INVALID_PARAMS errors leave nothing changed. It also lists return fields, though it does not discuss permissions, reversibility, or whether bodies are modified in place versus creating new bodies.

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 operation, then compactly covers constraints, references, errors, return shape, and examples. Every sentence adds useful information for correct invocation.

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

Completeness4/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 is quite complete: it covers parameter usage, validation errors, return fields, and examples. Minor missing context includes how the operation affects the timeline or whether it always creates a feature versus modifying bodies in place.

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 is 3. The description adds meaningful semantics beyond the schema: it clarifies that factors are unitless and > 0 or Fusion expressions, that factor and factors are mutually exclusive, and where valid body and point references originate.

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

Purpose4/5

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

The description states a specific verb and resource: scaling bodies about a base point, with uniform and per-axis modes. It is clear what the tool does, though it does not explicitly differentiate itself from other body transformation siblings such as body_move.

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

Usage Guidelines3/5

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

The description explains how to choose between factor and factors and where body and point references come from, which implies usage context. However, it does not state when to use this tool versus alternatives like body_move or when scaling would be inappropriate.

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