Skip to main content
Glama

face_warp_list

Lists all FaceWarpX sculpt-brush components in a scene, including object path, enabled state, brush index, and strength, so you can inspect brush settings before adjusting intensity.

Instructions

列出场景里所有「塑型画笔」组件(FaceWarpX,含猫脸/狗脸),返回 object_path、是否启用、每项画笔的序号与强度。官方 set_component 改不了画笔强度,用 face_warp_set_intensity。

Input Schema

NameRequiredDescriptionDefault
instance_idNo官方 list_instances 返回的 instance_id,与 project_path 二选一。
project_pathNo目标工程的绝对路径。与 instance_id 二选一;只开了一个工程窗口时都可省略。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden, and it does disclose the return shape (object_path, enabled state, brush index and intensity) plus an important behavioral quirk about set_component not being able to change intensity. It does not state whether the call mutates anything, how large scenes are handled, or whether results are paginated, which keeps it short of a 5.

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?

Two compact sentences with the resource and return fields front-loaded, then the alternative routing. The parenthetical about cat/dog faces and the set_component warning both earn their place, though the sentence is dense enough to need a second read.

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?

There is no output schema or annotation coverage, but the description compensates by enumerating the returned fields and flagging the set_component limitation. Nothing critical for calling a read-only two-parameter lister is missing, though scope of the listing (whole scene vs. current instance) is only implied.

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% and both parameters (instance_id, project_path) already document their mutual exclusivity and the single-window fallback. The description adds no parameter-level meaning, so the baseline 3 is appropriate.

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 plus resource: list all FaceWarpX brush components in the scene, including the cat-face/dog-face variants. It also names the exact fields returned (object_path, enabled flag, per-brush index and intensity), so an agent can distinguish it from the sibling face_warp_set_intensity without opening any 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?

Explicitly routes the intensity-changing case to the sibling face_warp_set_intensity and warns that the official set_component cannot change brush intensity. It gives clear context for reading, but offers no exclusion about when this listing is unnecessary (e.g., versus scene_tree or inspect_many for general inspection).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.