Skip to main content
Glama

inspect_many

Inspects component parameters across multiple objects at once with filters for component types, fields, and key presets; reads scene files without opening the editor and saves results as JSON.

Instructions

一次查看多个对象的组件参数(逐个调用官方 inspect;只看一个对象的完整原始数据时直接用 inspect),值里的 {type, data} 包装直接展开成值,超长数组只给长度和前几项;绑定的资源写成 {resource, type, file},引用的对象写成 {object, name}。component_types 只留某些组件(如 ["Transform"]),fields 只留属性名包含这些片段的属性(不分大小写,如 ["intensity", "position"])。preset="key" 自动留下通常决定效果的参数:位置/缩放/旋转、显隐与启用、强度/不透明度/权重/颜色类属性、文字内容(str)与 2D 尺寸(sizeDelta)、绑定的资源,以及场景文件里脚本组件的全部参数(这份清单是按已做过的妆容、形变、贴纸、文字效果拍的,缺的用 fields 补,可与 fields 同时用)。传 project_dir 时不开窗口、直接读场景文件(含编辑器面板里的参数,如妆容的贴图和强度),guids 用 scene_tree 给出的 #序号;内置资源写成 {builtin: id},组件运行时生成、工程里没有文件的资源写成 {path}。单个对象失败只在该项写明原因。save_to 是目录的绝对路径,结果另存为其中的 inspect_many.json,长期保留。

Input Schema

NameRequiredDescriptionDefault
guidsYes对象或组件的 guid(scene_tree / get_scene 返回的;project_dir 时是 #序号)。
fieldsNo只保留属性名包含这些片段的属性。
presetNokey:只留关键参数,见工具说明。
save_toNo另存到这个目录(绝对路径,不存在会创建),长期保留。
instance_idNo官方 list_instances 返回的 instance_id,与 project_path 二选一。
project_dirNo不开窗口、直接读这个工程目录的场景文件;给了它就不看 project_path / instance_id。
project_pathNo目标工程的绝对路径。与 instance_id 二选一;只开了一个工程窗口时都可省略。
component_typesNo只保留这些类型的组件。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/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 substantial work: it discloses output shaping ({type, data} unwrapping, long arrays truncated to length plus leading items), reference encodings for resources and objects, per-item partial failure reporting, and that save_to persists results long-term as inspect_many.json. It does not mention the cost implication of internally invoking inspect once per guid or any practical ceiling beyond the schema's maxItems of 40, which is the main behavioral gap.

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 purpose and the alternative-tool routing are front-loaded, and most sentences carry operational facts. It is dense with nested parentheses, and the aside explaining how the preset list was originally derived is lower-value than the rest, slightly diluting an otherwise tight definition.

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?

With 8 parameters, no annotations, and no output schema, the description covers filters, mode selection, output shape, per-item failure, and persistence — enough to call it correctly. It stops short of describing the envelope of the returned result (per-object keys, ordering relative to the input guids) and the performance characteristics of sequential per-object inspection.

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

Parameters5/5

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

Although schema coverage is already 100%, the description adds genuinely new meaning: fields matches case-insensitively on property-name substrings with concrete examples, component_types is exemplified with ["Transform"], preset='key' is fully enumerated (transform, visibility/enabled, intensity/opacity/weight/color, str text, sizeDelta, bound resources, all script-component params) rather than left to the schema's circular '见工具说明', and guids switches to #序号 form in project_dir mode. This is above the baseline-3 expectation for a fully documented 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?

The opening clause gives a specific verb (查看), a specific resource (多个对象的组件参数), and a batch scope, then immediately contrasts with the single-object sibling 'inspect'. An agent can distinguish inspect_many from inspect without opening either schema.

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?

It states explicitly when to use the sibling instead ('只看一个对象的完整原始数据时直接用 inspect'), explains the two execution modes (project_dir for offline/no-window reads vs instance_id/project_path for a live editor), and says preset and fields can be combined. It even admits preset is a heuristic list derived from prior makeup/warp/sticker/text work and directs the agent to fields for gaps.

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