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

With no annotations provided, the description carries the full burden. It discloses the state image order, a useful behavioral detail, but omits key aspects such as whether the tool modifies the active document, requires an open package, or has side effects like opening the created button. Minimal transparency for a creation tool.

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?

The description is a single, concise sentence that immediately communicates the core purpose and a key detail. There is no wasted wording, and it is appropriately front-loaded.

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?

Despite having an output schema, the tool is complex (16 parameters, no parameter descriptions, no annotations). The one-sentence description is far from complete—it does not explain typical usage scenarios, parameter interactions, or potential pitfalls. It is minimally viable but with significant gaps for an agent to invoke the tool correctly.

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%, and the description provides no explanation of any of the 16 parameters. While some parameter names are self-explanatory, many (e.g., as_list_item, create_relations, open_after_create) are ambiguous without further context. The description completely fails to compensate for the lack of schema descriptions.

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 clearly states the tool creates a standard FairyGUI Button component with a specific verb-resource pair. The mention of state image order also distinguishes it from generic component creation or other sibling tools like fgui_create_component.

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 implies when to use this tool (to create a standard button), but it does not explicitly discuss alternatives or when not to use it. No exclusions or references to sibling tools are provided, so guidance is limited to what is already obvious from the name and description.

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

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

With no annotations provided, the description carries the transparency burden. It discloses key default behaviors: '默认打开但不保存' (opens by default but does not save) and '重名时默认拒绝' (duplicate names are rejected by default), which go beyond what the schema reveals. However, it omits other side effects such as whether the component is added to the active document or requires prior project setup.

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?

The entire description is one concise sentence that front-loads the primary action and uses semicolons to add default behaviors. Every clause adds meaningful information without redundancy, making it highly efficient for the agent to parse.

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?

Despite having an output schema, the tool has 10 parameters and no annotation support, and the description only explains a subset of behaviors. It does not cover packaging, folder structure, exported flags, or extension relationships, making it incomplete for fully autonomous invocation. The complexity of the tool demands a richer description.

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?

There is zero schema description coverage, so the description must compensate for the 10 parameters. It only indirectly references package_name ('在指定包中'), open_after_create ('默认打开'), and auto_rename/naming conflict ('重名时默认拒绝'). Parameters like width, height, exported, folder_path, extension_id, and create_folders are entirely unaddressed, leaving significant ambiguity.

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 clearly states the tool creates a new component document in a specified package. The verb '新建' (create) plus resource '组件文档' (component document) and scope '在指定包中' (in specified package) makes the purpose unambiguous and distinguishes it from sibling tools like fgui_create_button or fgui_insert_object.

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 implies this tool is for creating components but does not explicitly contrast it with alternatives such as fgui_create_button or fgui_open_document. There is no when-not-to-use guidance or mention of prerequisites, leaving users to infer the appropriate context from the tool name and siblings.

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

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

No annotations are provided, so the description carries the full burden. It transparently states the destructive nature (discarding all unsaved modifications) and the reload action. It does not explicitly warn about irreversibility, but 'discard' strongly implies it.

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?

The description is a single, well-structured sentence that immediately states the verb and object, with no unnecessary words or repetition.

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?

Given the simplicity of the operation (discard and reload), the description fully conveys the behavior. Since an output schema exists, no return-value details are needed, and the one-sentence explanation is sufficient.

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?

The tool has zero parameters, so the described action is complete as-is. With an empty schema, no additional parameter meaning is needed, and the baseline for 0-parameter tools is 4.

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 uses a specific verb ('discard') and clearly identifies the resource ('all unsaved modifications of the current document') and the action ('reload the disk version'). This distinguishes it from siblings like fgui_save_document and fgui_undo.

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 context is clear: use this tool when you want to discard all unsaved changes and reload the saved version. It does not explicitly mention alternatives or when not to use it, but the intent is understandable from the description alone.

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

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

With no annotations, the description carries the transparency burden. It clearly uses '读取' (read), indicating a non-destructive operation, which is a key behavioral trait. However, it does not disclose what happens if no document is active, whether any side effects occur, or error behavior. This is adequate for a simple getter but not rich.

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?

The description is a single, concise sentence in Chinese that is front-loaded with the verb '读取' and states exactly what is read. Every word earns its place with no unnecessary detail.

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 a getter with no parameters and an output schema present, the description fully covers the tool's purpose. The output schema presumably details the return structure, so the description need not repeat it. The description is sufficient for an AI agent to understand what this tool does.

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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the schema correctly shows no properties. The description adds no parameter-related confusion.

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 '读取当前活动文档、修改状态和选择数量' clearly states the tool reads the current active document, its modification status, and selection count. This is a specific verb (read) with a clear resource, and it distinguishes from siblings like fgui_get_tree (gets tree structure) and fgui_get_history (gets history).

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 implies usage when you need the current document's state, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. There is no mention of prerequisites (e.g., an open document) or when not to use it, so guidance is only implicit.

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

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

With no annotations, the description carries the full burden. It states it reads two types of state, implying a read-only operation, but does not explicitly confirm safety, side effects, error conditions, or what the returned data actually contains. More behavioral context would be valuable.

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?

The description is a single concise sentence that leads with the verb. No wasted words, and it is front-loaded with the action.

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 a zero-parameter read tool with an output schema, this is mostly sufficient. However, it doesn't explicitly state that it is non-destructive or explain how it relates to the undo/redo workflow with siblings. Given the lack of annotations, a bit more context would improve completeness.

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?

The tool has zero parameters, so the schema coverage is effectively complete. The baseline of 4 for no parameters applies, and the description doesn't need to add parameter detail.

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 uses the specific verb '读取' (read) and clearly identifies the resources being read: the Agent property transaction stack and FairyGUI native undo state. While it doesn't explicitly contrast with sibling undo/redo tools, the name and resource references make its purpose clear enough.

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?

No guidance is provided on when to use this tool versus fgui_undo/fgui_redo or other siblings. There are no alternatives, exclusions, or contextual triggers mentioned.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'read' which implies non-mutating, but it does not clarify what data is returned, error conditions, or whether any session state is required.

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?

The description is a single concise sentence without fluff. However, it is under-specified for a tool with no parameter details, missing valuable information about what constitutes 'project information'.

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?

Although an output schema exists, the description fails to indicate what fields or sections of project information are returned. For a query tool, this is a significant gap; the agent cannot predict the scope of the response.

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?

The tool has zero parameters, so schema coverage is complete (100%). The description does not need to explain parameter semantics; the baseline of 4 applies.

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 clearly states the action (read) and resource (current FairyGUI project info), but it is vague about what information is included. It does not distinguish this tool from siblings like fgui_status or fgui_get_active_document.

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?

No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, common use cases, or exclusions.

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

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

No annotations are provided, so the description must carry the behavioral burden. It uses '读取' (read), implying a non-destructive operation, which is a mild safety signal. It does not mention side effects, prerequisites, or error handling, leaving some behavioral uncertainty.

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?

The description is two short sentences with no filler. The first sentence front-loads the core purpose, and the second adds the key usage timing. Every word contributes value.

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?

The tool is simple with one optional parameter and an output schema (not shown). The description explains what is read and when to call it, but it does not clarify the parameter's role or behavioral details like return structure or prerequisites. This is adequate but leaves notable gaps for an agent.

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?

The schema has 0% description coverage for the only parameter, package_name. The description mentions '包级覆盖设置' (package-level override settings), which hints that the parameter is related to a package, but it does not explicitly explain how package_name affects the output or that it is optional. This is insufficient to compensate for the missing schema description.

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 it reads project publish directory, format, atlas, code generation, and package-level override settings. The verb '读取' (read) and the specific resource set make the purpose clear. It indirectly distinguishes from the sibling fgui_publish by noting this should be called before publishing, but it does not explicitly name alternative tools.

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 explicitly says '发布前应先调用' (should be called before publishing), providing a clear context for when to use the tool. It does not mention when not to use it or suggest alternatives, but the pre-publish guidance is a useful and specific usage directive.

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

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

With no annotations, the description carries the burden of behavior disclosure. The term 'read' implies a non-destructive operation, and the advice to get stable IDs before modifying adds context. However, it doesn't detail any potential side effects or limitations, so transparency is moderate.

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?

The description is a single sentence with two clauses, providing the core purpose and a usage tip without any wasted words. It is front-loaded and easy to parse.

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?

The tool is simple, with one parameter and an output schema provided. The description covers the what and when, and the output schema handles return values. The only gap is the undocumented max_depth parameter, but the overall context is sufficient for a basic read tool.

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?

The single parameter max_depth has no description in the schema (0% coverage) and the tool description does not mention it, leaving its semantics unexplained beyond the name. The description fails to compensate for the schema gap.

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 clearly states the tool reads the current component object tree, using the specific verb 'read' and a distinct resource. This differentiates it from mutation tools like fgui_insert_object and fgui_remove_object.

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 notes that this should be used before modifications to obtain stable object IDs or paths, providing clear usage context. It doesn't explicitly exclude other tools but indicates the intended timing.

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

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

With no annotations provided, the description carries the full burden. It explicitly states 'this is a disk write operation' and describes the conflict handling modes (reject, auto-rename, replace). This provides useful behavioral context beyond the schema, though it could mention permissions or reversibility.

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?

The description is a single sentence that starts with the core action and adds key context. It is concise, front-loaded, and contains no fluff.

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?

Despite being a tool with 8 parameters and no annotations, the description only covers the source path and conflict policy. It omits other significant parameters like folder_path, create_folders, resource_name, and timeout_seconds. An output schema exists, but the description leaves too much to discover through parameter names alone.

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?

The description adds meaning to two parameters: 'source_path' (absolute local path) and 'conflict_policy' (reject, auto-rename, replace). However, with 8 parameters and 0% schema description coverage, the other six parameters (exported, folder_path, resource_name, create_folders, timeout_seconds) are left unexplained. The description partially compensates but not fully.

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 clearly states the action ('import image'), the resource type ('image'), and the source ('absolute local path'). It also declares a disk write operation, which distinguishes it from read-only sibling tools like fgui_get_tree or fgui_status. This is specific and unambiguous.

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 implies when to use this tool (when importing an image from a local path). It clearly sets the context but does not explicitly state when not to use it or mention alternative tools. Since the context is clear and no exclusions are given, a 4 is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals two key behaviors: the operation is non-persistent (not saved) and is not undoable through the Agent property transaction stack. This is valuable beyond the tool name and schema, although it does not mention return values or other side effects.

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?

The description is a single sentence that packs two essential caveats (no save, no undo via property stack) without excessive verbosity. It is concise, front-loaded, and every word contributes meaningful information.

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?

The tool has 5 parameters and an output schema, but the description only covers core behavior and key caveats. It omits parameter semantics, where the insertion occurs, and prerequisites (e.g., active document). While the output schema covers return values, the description is not fully complete for a tool with this complexity and 0% schema coverage.

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%, so the description must compensate for parameter meanings. It only hints at the 'url' parameter via 'ui:// resource' and leaves x, y, name, and insert_index unexplained. The description adds little value over the raw schema, resulting in a poor score for parameter semantics.

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 clearly states the tool's function: inserting an existing ui:// resource. It also distinguishes itself from save operations by explicitly noting it does not save, and the tool name and sibling fgui_remove_object make the insert/remove contrast clear.

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 implies when to use the tool (to insert an existing ui:// resource) and provides important constraints: it does not save, so a separate save tool is needed for persistence; and structural operations are not undoable via the Agent property transaction stack, warning against relying on undo. It does not explicitly name alternative tools, but the save and undo caveats offer practical usage guidance.

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

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

With no annotations available, the description carries the full burden of behavioral disclosure. It states the core action (list resources) and the filtering capability, but does not explicitly mention that it is read-only, nor does it describe potential errors (e.g., package not found) or any limitations. The behavior is predictable but not fully transparent.

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?

The description is a single, concise sentence that front-loads the primary action and resource, with the filtering capability added at the end. Every word contributes meaning, and there is no redundant or extraneous information.

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?

The tool is simple with only two parameters and an output schema, but the description lacks context about the broader workflow (e.g., that this is a read-only inspection step before editing) and does not explain the valid values for item_type or the structure of the output. It covers the basics but leaves gaps for an agent to fully understand how and when to invoke it.

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?

The schema descriptions coverage is 0%, so the description must compensate. It does so by indicating that 'package_name' refers to the specified package ('指定包') and that 'item_type' is used for filtering by FairyGUI resource type. This adds semantic meaning beyond the raw property names, though it does not enumerate valid item_type values.

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 clearly states the verb '列出' (list) and the resource '指定包中的资源' (resources in the specified package), distinguishing it from sibling tools like fgui_list_packages which lists packages. It also mentions the optional filtering by resource type, making the purpose specific and unambiguous.

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 provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It neither names sibling tools for comparison nor explains typical use cases, leaving the agent to infer when listing is appropriate.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It states the action 'list' which inherently implies a read-only query, but it does not disclose additional behavioral traits such as side effects, error conditions, or performance implications. The description is minimal but not misleading.

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?

The description is a single concise sentence that immediately states the tool's purpose without any redundant information. It is well-structured and front-loaded.

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 a simple zero-parameter list tool with an output schema, the description is sufficiently complete. It clearly defines the scope (current project) and the result (all packages). The presence of an output schema covers return value details, and there is no additional complexity requiring more context.

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?

The tool has zero parameters, so the baseline of 4 applies. There is nothing to explain beyond the schema, and the description correctly omits parameter details.

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 uses the specific verb '列出' (list) and resource '全部包' (all packages) in the current FairyGUI project. It clearly distinguishes this tool from siblings like fgui_list_items (list items) and fgui_get_project (get project info).

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 implies usage when the agent needs to enumerate available packages in the current project, but it does not explicitly state when to use it versus alternatives or mention any exclusions. There is no explicit guidance on selecting this over related tools.

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

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

With no annotations provided, the description must disclose behavior, but it only states the action. It does not mention side effects like changing the active document, error handling when the document is not found, or whether the operation is safe or destructive.

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?

The description is a single short sentence that is front-loaded and free of filler. It conveys the essential purpose without unnecessary detail, making it highly concise.

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?

The tool requires project context, as seen from sibling tools like fgui_use_project, but the description does not mention prerequisites or whether the project must be active. It also does not explain possible error states, though an output schema exists. The minimal description is insufficient for a smooth agent interaction.

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?

The schema has 0% description coverage, but the description explicitly maps the parameters to 'package name' and 'resource name', providing semantic meaning beyond the bare property titles. However, it lacks details on formats, constraints, or relationships between the parameters.

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 clearly states the function: opening a FairyGUI component document by package name and resource name. It uses a specific verb '打开' (open) and identifies the resource type, distinguishing it from sibling tools like save, publish, or insert operations.

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 guidance on when to use this tool versus alternatives such as fgui_get_active_document or fgui_get_tree. It only states the action without explaining prerequisites or situations where it is appropriate.

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

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

With no annotations, the description carries the full burden. It does disclose a meaningful side effect ('wakes up' the editor) and confirms it verifies protocol and capabilities, implying a non-mutating check. However, it omits details like failure modes, idempotency, or whether the editor must be running.

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?

A single sentence conveys purpose and behavioral nuance without redundancy. It is front-loaded and every word contributes meaning.

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 a simple ping tool with no parameters and an output schema, the description sufficiently covers the operation and verification scope. It could mention that this is intended for initial connection checks, but that is implied by the name and content.

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?

The tool has zero parameters, so the schema is complete. The description adds no parameter-specific detail, but none is required. A baseline of 4 is appropriate for a no-parameter tool.

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 clearly states the tool wakes the FairyGUI Editor and verifies bridge protocol, version, and capabilities. It identifies a specific verb and resource, distinguishing it from general-purpose tools, though it could more explicitly contrast with the sibling 'fgui_status'.

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 guidance on when to use this tool versus alternatives like fgui_status or fgui_get_project. It implies a startup/handshake role but lacks explicit prerequisites, exclusions, or recommended invocation context.

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

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

No annotations are provided, so the description carries the burden. It discloses that it saves before publishing by default and allows selecting scope. However, it does not mention side effects, timeout implications, branch usage, or publish_desc_only behavior, which are relevant for a publish/export operation.

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?

The description is a single, well-structured sentence that front-loads the main purpose and covers key default behaviors and scope options. No unnecessary words or repetition.

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?

Despite having an output schema, the description is too brief for a tool with 6 parameters and no annotations. It omits semantics for several parameters (branch, timeout, publish_desc_only) and lacks details on side effects or error behavior, making it incomplete for an agent to use effectively.

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 has 0% description coverage for parameters. The description clarifies 'scope' and 'save_before_publish' implicitly, but leaves 'branch', 'timeout_seconds', and 'publish_desc_only' unexplained. With six parameters, the description only partially compensates for the missing schema descriptions.

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?

Description clearly states the tool's function: '按工程发布设置导出 FairyGUI 包' (export FairyGUI packages according to project publish settings). It uses a specific verb (导出/export) and resource (FairyGUI包), and distinguishes it from sibling tools like fgui_get_publish_settings (read) and fgui_save_document (save).

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?

Description provides context on default behavior (publishes current document's package and saves first) and scope options (specific package or all packages), but it does not explicitly compare with alternatives like fgui_save_document or fgui_list_packages. No when-not-to-use guidance is given.

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

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

With no annotations, the description carries the full burden. It discloses the key behavioral trait: prioritizing agent property transactions and falling back to native redo when the transaction stack is empty. This adds meaningful context beyond the name, though it does not cover side effects or return behavior, which is acceptable given the output schema.

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?

The description is a single, focused sentence that front-loads the key behavior. Every word earns its place, with no unnecessary elaboration.

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?

Given the tool has no parameters and an output schema, the description sufficiently explains the tool's operation and its unique fallback behavior. However, it assumes prior knowledge of 'Agent property transactions,' which could be clarified for full context.

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?

The input schema has zero parameters, so schema coverage is 100%. The description does not need to explain parameters, and the baseline for 0 params is 4. It adds no param info, but none is needed.

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 clearly states the tool redoes actions, with a specific focus on agent property transactions and a fallback to native FairyGUI redo. This distinguishes it from sibling tools like fgui_undo and specifies the exact operation and behavior.

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 implies usage for redo operations and explains the priority of agent property transactions, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The fallback behavior hints at when native redo is used, but explicit guidance is missing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the deletion is limited to non-root objects and does not persist, and it hints at rollback limitations by recommending fgui_discard_document. However, it omits other mutation-related traits like undo support, permissions, and impact on references.

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?

The description is a single sentence that efficiently conveys the action, scope, save behavior, and an alternative tool – no redundant words.

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?

The description lacks essential context: how to specify the object, what happens if no or multiple identifiers are provided, and behavior for root objects. Although an output schema exists, the operation's parameter semantics are entirely undisclosed, making the tool hard to use correctly.

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?

The description provides zero information about the three parameters (object_id, object_name, object_path). Since schema coverage is 0%, the description must compensate but fails to explain how to identify the target object, leaving agents without guidance.

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 clearly states the action (delete), the target scope (non-root objects), and the persistence behavior (does not save). This distinguishes it from sibling tools like fgui_discard_document, which is explicitly mentioned for rollback scenarios.

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 explicitly advises using fgui_discard_document when reliable rollback is needed, providing a clear alternative and context for when this tool is not the right choice.

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

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

No annotations are provided, so the description carries the full burden. It discloses an important side effect: '清空 Agent 属性事务栈' (clears the Agent property transaction stack), which is valuable behavioral info. However, it does not explain the implications of clearing the stack (e.g., loss of undo history) or any prerequisites/errors.

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?

One compact sentence with clear front-loading: action verb + target resource + side effect. No wasted words.

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?

With 0 parameters, an output schema present, and clear scope, the description is largely complete. The only minor gap is lack of detail about what happens after saving (e.g., return value or failure conditions), but the output schema presumably covers return shape.

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?

The tool has 0 parameters, so baseline is 4. The description correctly omits parameter details, and no additional semantics are needed.

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 uses a specific verb '保存' (save) with an explicit resource scope: '所有 FairyGUI 文档、已打开包和工程' (all documents, open packages, and project). This clearly differentiates it from sibling tool fgui_save_document, which saves a single document.

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 word '显式' (explicitly) and '所有' (all) indicate when this tool is appropriate: when a complete save of all open FairyGUI state is needed. It does not name alternatives explicitly, but the scope is unambiguous enough for an agent to distinguish from single-document save tools.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states that the operation clears the Agent property transaction stack, a key side effect beyond the save itself, which is valuable for the agent's state awareness.

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?

The description is a single, compact sentence that front-loads the action and includes the most important side effect. Every word earns its place with no redundancy.

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?

Given there are no parameters, the description covers the core action and a critical behavioral side effect. An output schema exists for return values, so the description does not need to detail them. This is fully adequate for a simple save tool.

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?

The tool has zero parameters, so there is no parameter semantics to clarify. Baseline for 0 parameters is 4, and the description adds no unnecessary param information.

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 precisely states the action 'save' and the target 'current FairyGUI document', and adds a specific side effect (clearing the agent property transaction stack). This clearly differentiates it from siblings like fgui_save_all and fgui_discard_document.

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 indicates it applies to the 'current' document, giving clear context for when to use it. However, it does not explicitly mention alternatives or state when not to use it, so it lacks explicit exclusionary guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether this operation is non-destructive, how it affects prior selections, what happens if multiple objects match, or error behavior when no object is found. The minimal wording leaves these aspects opaque.

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?

The description is a single concise sentence that front-loads the action and lists the three selection methods. Every word earns its place; there is no redundancy or filler.

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?

Despite having an output schema, the tool has 3 optional parameters with zero schema descriptions and no annotations. A single sentence is insufficient to cover selection semantics (e.g., disambiguation, return behavior, or side effects). The tool is under-specified for reliable autonomous invocation.

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?

The description partially compensates for the 0% schema coverage by clarifying that object_id, object_name, and object_path are alternative means of selection ('or'). However, it does not specify whether they are mutually exclusive, their precedence, or expected format (e.g., full path vs. relative path). This adds some semantic value but leaves key details ambiguous.

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 clearly states the action ('select an object') and the resource (object), with three specific locator methods: ID, path, or unique name. This verb+resource pair is distinct from siblings like fgui_insert_object or fgui_remove_object, making the purpose unambiguous.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an open document), selection context, or why one locator method might be preferred over another. The description is purely functional with no usage context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses two key behaviors: the modification is not saved and the action is tracked in the undo/redo transaction stack, which addresses reversibility and persistence. Missing details include side effects, return values, and error conditions, but the core behavioral traits are covered.

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?

The description is extremely concise, consisting of two short sentences with no filler. It front-loads the action and the key constraint, and every word contributes meaning.

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?

Despite the tool having 5 parameters, 2 required, and 0% schema description coverage, the description provides only minimal guidance. It omits any explanation of the whitelist concept, how to specify the target object among three options, or what values are acceptable. The existence of an output schema does not compensate for these gaps, making the description incomplete for reliable use.

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?

The schema has 0% description coverage, and the description does not compensate. It only implies the existence of property_name and value but provides no explanation of valid property names, value types, or the three object identification parameters (object_id, object_name, object_path). This is a significant gap for correct invocation.

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 clearly states the action (modify whitelisted properties) and a key constraint (does not save), which distinguishes it from sibling tools like fgui_save_document. The mention of undo/redo transaction stack further separates it from save and redo operations. However, the term 'whitelist' is ambiguous and not explained, leaving some purpose clarity gaps.

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 explicitly indicates this is a non-persistent operation that enters the undo/redo stack, implying when to use it: for reversible, in-memory property changes. It also implicitly warns against using it when persistence is required, though it does not name specific alternative tools. The usage context is reasonably clear.

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

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

No annotations are provided, so the description bears the full responsibility. It does disclose a read-only operation ('读取') and the key non-waking behavior ('不主动唤醒编辑器'), which is useful. However, it does not explain what 'bridge heartbeat' entails, how it behaves when the editor is not running, or any other edge cases, leaving gaps in behavioral disclosure.

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?

The description is a single sentence that efficiently conveys the core purpose and key behavioral caveat. There is no fluff, and it is appropriately sized for a simple no-parameter status 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?

Given the tool's simplicity, the presence of an output schema, and the description covering purpose and the critical 'does not wake' behavior, it is fairly complete. However, it could provide a bit more context about what 'bridge heartbeat' represents or how this tool relates to other status checks, preventing a perfect score.

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?

The tool has zero parameters, so the schema description coverage is trivially 100%. The description adds no parameter-specific semantics, but with no parameters to explain, the baseline of 4 is appropriate.

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 clearly states the tool reads ('读取') local FairyGUI project selection and bridge heartbeat, which is a specific verb+resource combination. It also distinguishes itself from siblings by noting it does not actively wake the editor, which sets it apart from tools like fgui_ping or fgui_get_project.

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?

No explicit guidance is provided about when to use this tool versus alternatives. The statement '不主动唤醒编辑器' implies it is a safe non-intrusive status check, but there is no mention of alternatives, exclusions, or specific scenarios. This is insufficient for helping an agent decide between fgui_status and related tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses the priority/fallback behavior, adding value. However, it leaves ambiguous details such as whether undo is single-step, what happens when there is nothing to undo, and the exact definition of 'transaction stack'.

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?

One concise front-loaded sentence with no wasted words, effectively communicating the essential behavior.

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?

While the description covers the core undo behavior and fallback, it does not explain the concepts of 'Agent attribute transactions' or the transaction stack, which could be ambiguous to an AI agent. With an output schema present, return values are covered elsewhere, but the behavioral edge cases are not specified.

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?

The tool has zero parameters, so there is nothing to describe. The description does not need to explain parameter semantics.

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 clearly states the tool performs undo operations, prioritizing agent property transactions and falling back to native FairyGUI undo. This distinguishes it from sibling tools like fgui_redo (opposite action) and fgui_get_history (viewing history).

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 implicitly defines when to use this tool (to undo) and explains the decision logic: it tries agent transactions first, then native undo. However, it does not explicitly mention alternatives or exclusions, though the redo tool is an obvious opposite.

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

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

With no annotations available, the description carries the full burden of behavioral disclosure. It mentions selecting for the session but does not explain side effects (e.g., overriding previous selection), validation behavior, or error handling. This is a state-changing operation, yet the description remains surface-level.

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?

The description is a single concise sentence that front-loads the action and resource. Every word is informative, with no filler or redundancy.

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 a simple one-parameter setter tool, the description is minimal but acceptable. It covers the core purpose and parameter semantics, but lacks usage context (when to call) and behavioral details. The presence of an output schema reduces the need to describe return values, but the lack of guidelines makes it incomplete.

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?

The schema has one parameter (project_path) with no description (0% coverage). The tool description compensates by explaining the accepted path types (.fairy file, project directory, or repository directory), adding meaning beyond the raw schema. However, it does not specify path format (relative vs. absolute) or other constraints.

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 clearly states the tool's function: selecting a .fairy file, FairyGUI project directory, or repository directory for the current MCP session. It uses a specific verb ('select') and distinguishes from siblings like fgui_get_project, which likely retrieves the current selection rather than setting it.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, ordering (e.g., use before other operations), or exclusions. The context implies it is a setup step, but the description never says that explicitly.

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