Skip to main content
Glama
Wilson520403

fgui-agent-bridge

by Wilson520403

fgui_remove_transition

Remove a Transition from the current FairyGUI component, with optional save and verification. Undoable via fgui_undo.

Instructions

删除当前组件中的一个 Transition;可由 fgui_undo 恢复。

save=True 保存后默认确认磁盘 XML 不再包含该 Transition;external_reload=True(需 save=True)关闭重开后确认仍不存在,响应 strength 为 reload / disk / none。

Input Schema

NameRequiredDescriptionDefault
nameYes
saveNo
verifyNo
external_reloadNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.6

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 it does add real behavioral context: the removal is recoverable via fgui_undo, save=True persists to disk, and external_reload requires save=True. It stops short of disclosing failure behavior for a non-existent name or any permission prerequisites.

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?

Front-loaded with the core action and recoverability, then a second short paragraph on save/verify semantics. Dense but each sentence adds operational information; no filler.

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 destructive tool with no annotations, it covers recoverability, persistence, and verification strength (reload/disk/none). An output schema exists so return shape need not be explained, though missing error/prerequisite cases keep it from being fully complete.

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 0%, so the description must compensate. It explains save and external_reload (including the save=True dependency) and implies verify via '默认确认', but does not clarify what verify=False does or what 'name' refers to (transition name vs. component). Roughly half the parameters are meaningfully covered.

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 (删除/remove) and resource (Transition) with an explicit scope ('当前组件中的一个'). It is clearly distinguishable from siblings like fgui_remove_transition_item, fgui_upsert_transition, and fgui_get_transition.

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?

Usage is implied by the verb and the description names fgui_undo as the recovery path, which is a useful routing hint. However, it never states when to choose this tool over fgui_remove_transition_item or fgui_upsert_transition, nor any preconditions such as an active/selected component.

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