Skip to main content
Glama
fgui-agent-bridge

fgui-agent-bridge

by Wilson520403

fgui_set_instance_override

Sets extension-level overrides on FairyGUI component instances to give individual instances different titles, icons, colors, or font sizes. Saves changes and can verify persistence after reload.

Instructions

写组件实例的扩展级 override(同一个组件、不同实例不同文案/样式)。

只支持扩展级覆盖,这是编辑器与 FGUI 运行时共同支持的那一层: 源组件是 Button 扩展时可写 title(text 是别名)、icon、selectedTitle、selectedIcon、 titleColor(#RRGGBB 六位,alpha 会被编辑器丢掉)、titleFontSize;Label 扩展可写 title、icon、titleColor、titleFontSize。落盘形态是实例节点里的扩展子节点 <component ...><Button title="..."/></component>,运行时按同一组字段消费。

边界(真机 6.1.4 实测):编辑器不支持逐子对象覆盖——改实例内部子对象只改到内存, 磁盘不落盘;这类需求请改用 insert_text 直接建对象,或把样式固化成组件类型。 源组件没有扩展时也会被拒绝。

external_reload=True 会在保存后关闭并重新打开文档再比对,是唯一能证明「重新载入时值不丢」 的验证;需要 save=True。响应中的 strength 字段标明验证强度:reload / disk / none。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "properties": "<properties>"
    },
    "name": "fgui_set_instance_override"
  }
}

Input Schema

NameRequiredDescriptionDefault
saveNo
verifyNo
object_idNo
propertiesYes
object_nameNo
object_pathNo
external_reloadNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.25

TDQS

A4.3/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 most of that work: it discloses the on-disk serialization shape (`<component><Button title=.../></component>`), the edit-time-vs-runtime boundary validated on editor 6.1.4, the rejection condition, and that external_reload=True requires save=True and is the only way to prove values survive a reload. The remaining gap is that it never says whether the operation is additive or destructive to pre-existing overrides, nor what happens to unlisted fields. That is a meaningful omission for a mutation tool, but the disclosed behavior is far above average.

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 front-loaded with the purpose and then cleanly partitioned into supported fields, boundaries, and verification semantics, which suits a tool with this many constraints. It is dense but nearly every clause carries information an agent needs. The allowed-field enumeration is somewhat list-like and could be tightened, but nothing is redundant.

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 tool has an output schema, and the description still goes beyond it by explaining the `strength` field's reload/disk/none values, which is genuinely useful. Given a seven-parameter mutation tool with 0% schema coverage and a nested free-form `properties` object, the unresolved gap is target addressing (id/name/path) and verify semantics. Aside from that, the definition is complete enough to call correctly.

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 coverage is 0%, so the description must compensate, and it compensates well for the most important parameter: the allowed `properties` keys per extension type, the title/text alias, and the #RRGGBB six-digit format with alpha silently dropped by the editor. It also explains the external_reload/save dependency. However, four of seven parameters — object_id, object_name, object_path and verify — get no explanation at all, leaving ambiguous how the target instance is addressed and what verify toggles relative to external_reload.

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 description names a specific verb and resource: writing an extension-level override onto a component instance, with the concrete effect of giving the same component different text/style per instance. It also implicitly separates itself from the object-level mutation siblings (fgui_set_property) and from fgui_insert_text by stating which layer of override is supported. An agent can tell what this tool does and what it does not do without opening 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 Guidelines5/5

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

It states explicitly when to use it — extension-level fields on Button/Label extensions — and when not to: per-child-object overrides are unsupported because they only mutate memory and never reach disk, and in that case it directs the agent to fgui_insert_text or to baking the style into the component type. It also states the precondition that a source component without an extension will be rejected, so the failure mode is predictable before the call.

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