Skip to main content
Glama
fgui-agent-bridge

fgui-agent-bridge

by Wilson520403

fgui_move_package_item

Moves a FairyGUI package item into another in-package folder, creating missing folders by default and flagging stale fileName references.

Instructions

把包资源移动到包内另一个目录;磁盘文件同步移动,不可撤销。

folder_path 是包内目录(如 "/ui/")。编辑器原生 MoveItem 要求目标目录已存在, 否则会抛原生异常;本工具默认按 create_folders=True 先建目录再移动,并在响应里回报是否新建了目录。 移动不会更新引用方文档的 fileName 属性(id 不变,运行时按 id 解析不受影响),响应里的 staleFileNameSlots 会列出这些位置。

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": {
      "folder_path": "<folder_path>"
    },
    "name": "fgui_move_package_item"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNo
saveNo
verifyNo
item_nameNo
item_pathNo
folder_pathYes
package_nameNo
create_foldersNo
close_open_documentsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.25

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 handles the most important risks: the operation is irreversible, files move on disk, folders may be auto-created, and referrer documents keep stale fileName values resolved by id at runtime. It does not explain the effects of save, verify, or close_open_documents, which are behavioral switches an agent should understand before calling.

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 most important facts, the move and its irreversibility, are front-loaded, and the caveats about folder creation and stale file names follow in logical order without filler. It is dense but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The existence of an output schema means the mention of staleFileNameSlots and the folder-created flag is sufficient for return-value expectations. However, for a destructive 9-parameter mutation with no annotations, the missing guidance on how to specify the target item is a meaningful completeness gap.

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

Parameters2/5

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

Schema coverage is 0% across 9 parameters, and the description only clarifies folder_path and create_folders. It leaves the item-identification family (url, item_name, item_path, package_name) entirely unexplained, so an agent gets no guidance on which of these identifies the resource to move or whether they are alternatives, and save/verify/close_open_documents are undocumented as well.

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 opens with a precise verb + resource + destination: moving a package resource to another directory inside the package, with the disk file moved in sync. It also flags irreversibility, which immediately separates it from sibling rename/duplicate/delete item tools.

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?

It gives clear applicability context, including the constraint that the editor's native MoveItem requires an existing target folder and that this tool pre-creates it via create_folders=True. It stops short of explicitly contrasting with fgui_rename_package_item or fgui_duplicate_package_item, so there is no stated when-not-to-use.

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