Skip to main content
Glama
vino3dx
by vino3dx

poly_detach_faces

Destructive

Detach specific faces from an object into a new named object, or clone them while preserving the original faces. Provide face indices and an object name to separate geometry cleanly.

Instructions

把所选面从原对象分离成一个(或克隆出)新对象。name 为新建对象名。 [English] Detach the selected faces into a new object (or clone them into one). name is the new object's name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes新建对象名。 | Name of the new object.
cloneNo是否克隆(保留原面),默认否。 | Clone instead of moving (keep originals), default false.
facesYes要分离的面索引。 | Face indices to detach.
objectsNo对象名列表;省略则使用当前选择。 | Object names; omit to use the current selection.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, and the description adds useful behavioral context by explaining that faces are detached from the original object into a new one, with cloning as an alternative. This is consistent with the annotations and clarifies the destructive/default behavior.

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?

The description is compact and front-loaded: the first clause states the core operation, with the clone variant and name note after it. The small redundancy with the schema's 'name' parameter description is minor and does not harm clarity.

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?

The schema covers all parameters, annotations provide the destructive hint, and the description conveys the tool's core behavior and clone option. Although there is no output schema or explicit return-value information, the combination of description, schema, and annotations gives sufficient context for correct invocation.

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?

All four parameters are fully described in the input schema, meeting the high-coverage baseline. The description only restates that 'name' is the new object's name, which adds no new meaning beyond the schema.

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 action ('detach') and resource ('selected faces') and clearly describes the result: a new object, with the option to clone. It is unambiguous and easy to understand, though it does not explicitly differentiate itself from related siblings like detach_elements or poly_delete_faces.

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

Usage Guidelines2/5

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

The description does not say when to prefer this tool over alternatives or when not to use it. There is no mention of related tools such as detach_elements or clone_objects, so an agent must infer usage solely from the operation's name and general purpose.

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