fgui_create_button

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

With no annotations, the description carries the full disclosure burden. It adds real behavioral detail (save=True persists package+project and compares package.xml entries; component-class resources don't support external_reload; strength capped at disk), but leaves the mutation surface, permissions, and overwrite/rename behavior undefined.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact paragraphs, front-loaded with the core action, which is good. But the second paragraph is cryptic jargon (external_reload, strength 上限) that spends words without clarifying how to call the tool.

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

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

For an 18-parameter creation tool with no annotations and no parameter descriptions, the definition is far too thin; the output schema excuses return-value documentation, but the invocation surface (mode selection, image input, naming, folder placement) is essentially undocumented.

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

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

Schema description coverage is 0% across 18 parameters, so the description must compensate and does not. It only touches save and the state-image ordering, leaving mode (enum), image_urls, auto_rename, create_icon, create_text, folder_path, as_list_item, extension_id, and the layout flags entirely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and resource: '创建标准 FairyGUI Button 组件' (create a standard FairyGUI Button component), which clearly separates it from fgui_create_component and fgui_create_movieclip siblings. However it never explicitly contrasts itself with fgui_create_component, so the distinction is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives no when-to-use guidance, no prerequisites (e.g. an active project/package via fgui_use_project), and no routing to alternatives such as fgui_create_component. It documents side effects of save=True but not when a caller should choose them.

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