cocos-mcp

by chenShengBiao

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
The tool set has significant overlap and ambiguity, with many tools performing similar functions or having unclear boundaries. For example, there are multiple tools for adding components (cocos_add_component, cocos_add_rigidbody2d, cocos_add_box_collider2d, etc.) and many specialized tools that could be confused with more general ones (e.g., cocos_add_button_with_label vs cocos_add_button plus cocos_add_label). The descriptions help, but the sheer number of overlapping tools makes disambiguation difficult.
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with a clear 'cocos_' prefix and descriptive verb_noun structure throughout. Examples include cocos_add_script, cocos_create_scene, cocos_set_property, and cocos_scaffold_game_loop. There are no deviations in naming conventions, making the set predictable and readable.
Tool Count1/5
With 184 tools, the count is extremely high for any server's purpose, indicating severe bloat and lack of focus. This many tools will overwhelm agents and make selection challenging, as many tools could be consolidated or removed without losing functionality. The scope appears to cover every possible Cocos Creator operation, but such comprehensiveness comes at the cost of usability.
Completeness5/5
The tool set provides exhaustive coverage of the Cocos Creator domain, including asset management, scene editing, physics, UI, animation, build processes, and testing. There are no obvious gaps; tools support full CRUD operations, lifecycle management, and integration with external systems like AI generation and preview interaction. The surface is complete for game development workflows.
Average 3.6/5 across 184 of 184 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to describe any behavioral traits: it does not state whether this is a mutation (likely yes, given 'add'), what permissions are needed, if it modifies the scene permanently, or what the output schema contains. The description is too minimal to inform the agent about the tool's behavior beyond the basic action implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase 'Attach cc.CylinderCollider', which is overly concise to the point of under-specification. While it avoids verbosity, it fails to provide necessary context or structure, making it inefficient for guiding tool selection. Every word should earn its place, but here the minimalism sacrifices clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, but an output schema exists), the description is incomplete. It does not explain the tool's purpose beyond the name, lacks usage guidelines, omits behavioral context, and provides no parameter semantics. Although an output schema exists, the description fails to cover basic aspects needed for effective tool use, such as when and how to apply it in a Cocos Creator context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameter titles (e.g., 'Scene Path', 'Node Id') are the only documentation. The description adds no semantic information about parameters, such as explaining what 'direction' (an integer) controls, what units 'radius' and 'height' use, or how 'center_x', 'center_y', 'center_z' relate to the node. With 9 parameters, this lack of detail is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach cc.CylinderCollider' restates the tool name 'cocos_add_cylinder_collider_3d' without adding specificity. It uses a vague verb 'Attach' instead of clarifying what 'add' means in this context (e.g., creating and configuring a collider component). No differentiation from sibling tools like 'cocos_add_box_collider_3d' is provided, making it a tautological restatement of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. It does not mention prerequisites (e.g., requiring a 3D node), context (e.g., for physics simulations), or exclusions (e.g., not for 2D scenes). With many sibling tools for adding colliders and components, the lack of any usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to describe any behavioral traits: it doesn't indicate whether this is a mutation (likely yes, as it 'Attaches'), what permissions or scene state are required, if it has side effects, or the response format. The description is minimal and adds no behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Attach cc.ConeCollider.', which is front-loaded and wastes no words. While under-specified, it earns a high score for brevity and clarity within its limited scope, as every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, 0% schema coverage) and the presence of an output schema (which might help but isn't described), the description is severely incomplete. It fails to explain the tool's purpose in context, parameter meanings, usage scenarios, or behavioral aspects, making it inadequate for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 9 parameters are documented in the schema. The description provides no information about parameters—it doesn't explain what 'scene_path', 'node_id', or the geometric properties (radius, height, etc.) mean, their units, or how they affect the collider. This leaves critical input semantics undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach cc.ConeCollider' states a verb ('Attach') and resource ('cc.ConeCollider'), but is vague about what it actually does—it doesn't specify that this adds a 3D cone-shaped collision component to a node in a Cocos Creator scene. While it distinguishes from siblings by naming 'ConeCollider', it lacks the specificity needed for clear understanding, making it borderline tautological with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. The description does not mention prerequisites (e.g., needing a valid scene and node), exclusions, or comparisons to sibling tools like other collider types (e.g., box_collider_3d, sphere_collider_3d). This leaves the agent without context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions attaching a toggle and a parameter source, without explaining what the tool does behaviorally (e.g., whether it creates, modifies, or configures a toggle, what the effects are, permissions needed, or error handling). This leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short phrases, but it's under-specified rather than efficiently structured. It front-loads the main action ('Attach cc.Toggle') but lacks necessary details, making it feel incomplete rather than optimally brief. Some waste exists due to missing context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema (which might help with return values), the description is incomplete. It doesn't cover parameter meanings, behavioral context, or usage scenarios adequately. For a tool with this complexity and lack of structured data, the description falls short of providing enough context.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It only adds meaning for 'check_events' by referencing 'cocos_make_event_handler()', but the other 4 parameters (scene_path, node_id, is_checked, transition) are not explained in the description, leaving most semantics unclear. This partial coverage is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach cc.Toggle. check_events: list from cocos_make_event_handler().' states a verb ('Attach') and resource ('cc.Toggle'), but it's vague about what 'attach' means in this context (e.g., to a node, scene, or component) and doesn't clearly differentiate from siblings like 'cocos_add_button' or 'cocos_add_slider'. It partially explains the purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'check_events: list from cocos_make_event_handler()', which implies a prerequisite or source for one parameter, but it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., other UI components in the sibling list) or any exclusions. No clear context for usage is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but offers minimal behavioral insight. It doesn't disclose if this is a read or write operation, what effects it has (e.g., modifies scene, requires permissions), or any constraints like rate limits. The description is too sparse to inform the agent about the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two brief phrases, front-loading the main action. There is no wasted verbiage, making it efficient to parse, though this conciseness comes at the cost of clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is incomplete. It doesn't explain the tool's purpose in detail, parameter meanings, behavioral traits, or usage context. The output schema might help with return values, but the description fails to provide essential information for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description only mentions 'slide_events' and references another tool, but doesn't explain the semantics of any parameters (e.g., what 'scene_path' or 'direction' mean). It fails to compensate for the lack of schema documentation, leaving most parameters unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Attach') and resource ('cc.Slider'), but it's vague about what 'attach' means in this context (e.g., adding a UI component to a node). It doesn't differentiate from sibling tools like 'cocos_add_button' or 'cocos_add_progress_bar', which also attach UI components, leaving the specific purpose unclear beyond the general category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The mention of 'slide_events: list from cocos_make_event_handler()' implies a prerequisite but doesn't clarify scenarios or exclusions. Without context on use cases or comparisons to siblings, the agent lacks direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'Attach cc.Animation', implying a mutation (adding/attaching a component), but doesn't disclose behavioral traits such as whether this requires specific permissions, if it modifies existing animations, error handling, or what the output looks like. The mention of clip_uuids adds minimal context, but overall, it lacks critical details for a mutation tool.
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 concise with two short sentences, front-loading the main action ('Attach cc.Animation.') and adding a detail about clip_uuids. There's no unnecessary fluff, but it might be overly terse given the tool's complexity. Every sentence serves a purpose, though more structure could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, mutation operation, no annotations, but has output schema), the description is incomplete. It lacks details on behavior, parameter meanings beyond clip_uuids, and usage context. The output schema exists, so return values needn't be explained, but the description doesn't provide enough guidance for effective tool selection and invocation.
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 description coverage is 0%, so the description must compensate. It only mentions 'clip_uuids is a list of AnimationClip asset UUIDs', which covers one of five parameters. It doesn't explain scene_path, node_id, default_clip_uuid, or play_on_load, leaving most parameters undocumented. This adds minimal value beyond the schema, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach cc.Animation. clip_uuids is a list of AnimationClip asset UUIDs.' states the action (attach) and resource (cc.Animation), but is vague about the full scope. It mentions clip_uuids but doesn't explain what 'attach' entails or how it relates to other parameters like scene_path and node_id. It doesn't clearly distinguish from siblings like 'cocos_add_component' or 'cocos_create_animation_clip', which might handle similar animation-related tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites (e.g., needing an existing node or scene), exclusions, or compare to siblings like 'cocos_add_component' for general components or 'cocos_create_animation_clip' for creating clips. Usage is implied only through parameter names, but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides minimal behavioral information. With no annotations, it doesn't disclose whether this is a read or write operation (though 'Attach' implies mutation), what permissions are needed, whether it modifies existing components, or what the output contains. It lacks details on side effects, error conditions, or performance characteristics that would help the agent use it correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan. Every word earns its place by specifying the component type and dimensionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, 0% schema coverage) and the presence of an output schema, the description is insufficient. It doesn't compensate for the lack of parameter documentation or behavioral context. While the output schema may describe return values, the description fails to explain how to use the tool effectively, leaving the agent poorly equipped to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameter titles provide no semantic context. The description doesn't explain any parameters, their relationships, or what values are appropriate. For 9 parameters (2 required), this leaves critical gaps—for example, what 'scene_path' and 'node_id' refer to, or how size/center coordinates are interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and resource ('cc.BoxCollider (3D AABB shape)'), making the purpose specific and understandable. It distinguishes from 2D siblings like 'cocos_add_box_collider2d' by specifying '3D', but doesn't differentiate from other 3D collider tools (e.g., sphere, capsule) beyond the shape type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention prerequisites, when to choose this over other collider types, or what context it's appropriate for. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'Attach cc.Mask' but doesn't disclose behavioral traits like whether this modifies an existing node, requires specific permissions, has side effects, or how it interacts with other components. The mask_type values add some context, but critical details like error handling or performance impacts are missing.
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 brief and front-loaded with the main action, but it could be more structured. The single sentence efficiently states the tool's function and mask_type details, with no wasted words. However, it lacks separation of purpose from parameter info, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage, no annotations, and an output schema (which isn't described), the description is incomplete. It doesn't explain the tool's role in the Cocos ecosystem, expected inputs beyond mask_type, or what the output might be. For a tool that likely modifies scene nodes, this leaves significant gaps for an AI agent.
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 description coverage is 0%, so the description must compensate. It only explains 'mask_type' with numeric codes (0-3), leaving 'scene_path', 'node_id', 'inverted', and 'segments' undocumented. The description adds minimal value beyond the schema, failing to clarify parameter meanings or usage, such as what 'segments' does for ellipse masks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Attach cc.Mask') and resource (mask), but is vague about the context—it doesn't specify what is being masked (e.g., a node in a scene) or how this differs from sibling tools like 'cocos_add_graphics' or 'cocos_add_sprite'. It provides mask_type values, but lacks a clear overall purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description lists mask_type options but doesn't explain their use cases or prerequisites. With many sibling tools for adding components, there's no indication of when masking is appropriate, such as for UI effects or visual clipping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions attaching a scroll view but fails to explain whether this is a mutation operation, what permissions are needed, how it affects existing nodes, or any side effects like performance impacts. This leaves significant gaps in understanding the tool's behavior.
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 a single, efficient sentence that gets straight to the point without unnecessary words. It is front-loaded with the main action, though it could be slightly more informative given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, but with an output schema), the description is inadequate. It fails to explain the tool's purpose in depth, parameter usage, or behavioral context, making it incomplete for effective agent use despite the presence of an output schema.
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?
The description only mentions content_id, ignoring the other 8 parameters (e.g., scene_path, node_id, horizontal, vertical, inertia). With 0% schema description coverage, the description does not compensate by explaining parameter meanings, purposes, or interactions, leaving most parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool attaches a cc.ScrollView component and mentions content_id points to the scrollable content node, which clarifies the verb and resource. However, it does not differentiate from sibling tools like cocos_add_page_view or cocos_add_scroll_bar, which also handle scrolling UI elements, making the purpose somewhat vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as cocos_add_page_view or cocos_add_scroll_bar. The description lacks context about prerequisites, typical use cases, or exclusions, leaving the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('Attach cc.SliderJoint2D') without mentioning critical behaviors such as whether this is a mutation (likely yes, as it adds a component), permission requirements, side effects, error conditions, or how it interacts with the physics engine. This leaves the agent with insufficient information to understand the tool's operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose and provides an example. There is no wasted text, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (15 parameters, 0% schema coverage, no annotations) and the presence of an output schema (which might cover return values), the description is incomplete. It fails to address the tool's behavioral aspects, parameter meanings, or usage context, making it inadequate for an AI agent to reliably invoke this tool without additional guesswork or external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 15 parameters with 0% description coverage, meaning none are explained in the schema. The description adds no information about any parameters, failing to compensate for the lack of schema documentation. It does not clarify the purpose of key parameters like 'scene_path', 'node_id', or the various anchor and motor settings, leaving them entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.SliderJoint2D'), and provides a specific example of its use ('translates along an axis (elevators, pistons)'). However, it does not explicitly differentiate from sibling tools like 'cocos_add_distance_joint2d' or 'cocos_add_hinge_joint2d', which likely serve different physics joint purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a general context ('translates along an axis') and examples ('elevators, pistons'), but lacks explicit guidance on when to use this tool versus alternatives (e.g., other joint types in the sibling list), prerequisites, or any 'when-not-to-use' scenarios. It implies usage for linear motion but offers no further direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the tool attaches a spring joint, with no information on side effects (e.g., whether it modifies existing nodes, requires specific permissions, or has rate limits), error conditions, or what the output schema returns. This is inadequate for a tool with 12 parameters and no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that packs the action, component, functional note, and examples without any fluff. It is front-loaded with the core purpose ('Attach cc.SpringJoint2D'), making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (12 parameters, 0% schema coverage, no annotations) and the presence of an output schema (which the description doesn't leverage), the description is severely incomplete. It fails to explain parameter meanings, behavioral traits, or usage nuances, leaving the agent with insufficient context to use the tool effectively beyond a vague purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 12 parameters have descriptions in the schema. The tool description does not mention any parameters, their purposes, or how they interact (e.g., explaining 'anchor_x' vs 'connected_anchor_x' or the effect of 'frequency' and 'damping_ratio'). This leaves all parameters undocumented beyond their titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and the specific component ('cc.SpringJoint2D'), with a brief functional note ('soft springy distance') and example use cases ('suspensions, ropes'). It distinguishes from sibling tools like 'cocos_add_distance_joint2d' by specifying the spring type, but doesn't explicitly contrast with other joint tools like 'cocos_add_fixed_joint_2d' or 'cocos_add_wheel_joint2d'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage context through the examples ('suspensions, ropes'), which implies scenarios involving flexible connections. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other joint types), prerequisites (e.g., requiring physics bodies), or any 'when-not' conditions. No alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'align_flags is a bitmask', which adds some context about parameter behavior, but fails to describe critical traits such as whether this operation modifies the scene (mutative), requires specific permissions, has side effects, or how it interacts with existing widgets. This leaves significant gaps for a tool that likely alters UI layout.
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 brief and front-loaded with the main action, consisting of two concise sentences. There is no wasted text, but it could be more structured by explicitly listing key parameters or use cases. Overall, it is efficient but slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It lacks details on parameter meanings, behavioral implications, and usage context, making it inadequate for an agent to understand how to invoke this tool effectively in a complex Cocos environment.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It only explains 'align_flags' as a bitmask, ignoring 'scene_path', 'node_id', and 'target_id'. This adds minimal value beyond the schema, failing to clarify the purpose or format of the other three parameters, which are essential for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Attach') and resource ('cc.Widget for screen-anchor layout'), which clarifies the tool's basic purpose. However, it lacks specificity about what 'attach' entails in this context (e.g., to a node or scene) and does not differentiate from sibling tools like 'cocos_add_uitransform' or 'cocos_add_component', which might handle similar UI/layout tasks, making it vague in comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description mentions 'screen-anchor layout', but it does not specify prerequisites, exclusions, or recommend other tools for different layout needs, leaving the agent without context for selection among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 that the tool attaches a collider and specifies direction mapping, but fails to describe key behavioral traits: whether this is a mutation (likely yes, but not stated), what happens if a collider already exists (replacement or error), permissions needed, or side effects. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the action and provides key parameter info. It's front-loaded with the main purpose and wastes no words, making it easy to parse quickly. Every part earns its place by delivering essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, but has an output schema), the description is incomplete. It lacks context on when to use the tool, behavioral details, and semantics for most parameters. While the output schema may cover return values, the description doesn't address mutation risks, prerequisites, or integration with sibling tools, leaving significant gaps for an agent to operate effectively.
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 description coverage is 0%, so the description must compensate. It only explains the 'direction' parameter (mapping 0,1,2 to X,Y,Z), leaving 8 other parameters undocumented. While it adds meaning for one parameter, it fails to cover the majority, including critical ones like 'scene_path' and 'node_id'. This insufficiently compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach cc.CapsuleCollider' clearly states the verb ('Attach') and resource ('cc.CapsuleCollider'), but it's vague about the exact action—it doesn't specify if this creates a new collider or attaches an existing one. It distinguishes from siblings like 'cocos_add_box_collider_3d' by specifying 'Capsule', but lacks detail on the broader purpose (e.g., for physics simulation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description mentions direction mapping (0=X, 1=Y, 2=Z), which hints at orientation but doesn't explain when to choose this over other collider types (e.g., box or sphere) or prerequisites like scene/node setup. Without usage context, the agent must infer from parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'attach' which implies a mutation operation, but fails to detail critical aspects like required permissions, whether it modifies existing colliders, error conditions, or the impact on the scene. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, direct sentence: 'Attach cc.SphereCollider (3D sphere shape).' It is front-loaded and wastes no words, making it efficient and easy to parse, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 7-parameter mutation tool with no annotations and 0% schema description coverage, the description is inadequate. It does not explain the tool's effects, parameter meanings, or usage context. While an output schema exists (which might cover return values), the description fails to provide the necessary completeness for safe and effective use.
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?
The schema description coverage is 0%, meaning none of the 7 parameters are documented in the schema. The description does not add any semantic information about parameters like 'scene_path', 'node_id', 'radius', or 'is_trigger', failing to compensate for the lack of schema documentation and leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach cc.SphereCollider (3D sphere shape)' states the action (attach) and resource (SphereCollider) with a clarifying note about its 3D sphere shape, which is clear but basic. However, it does not differentiate from sibling tools like 'cocos_add_box_collider_3d' or 'cocos_add_capsule_collider_3d', which serve similar purposes for different collider types, leaving the purpose somewhat vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other collider types (e.g., box, capsule) or related tools like 'cocos_add_physics_body2d'. The description lacks any context about prerequisites, typical scenarios, or exclusions, offering no help in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions copying and writing meta, implying a write operation, and notes the return format, but fails to detail permissions, error handling, or side effects like file overwriting. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
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 brief and front-loaded, with three sentences that efficiently convey core functionality and return values without unnecessary elaboration. Each sentence adds value, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, no output schema), the description is incomplete. It covers basic purpose and return format but misses parameter explanations, usage context, and behavioral details like error conditions or dependencies, leaving the agent with insufficient information for reliable use.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It does not explain any of the 4 parameters (project_path, src_path, rel_path, uuid), such as their purposes, formats, or relationships. This lack of semantic detail hinders effective tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Copy an audio file into assets/resources/ + write meta') and resource ('audio file (mp3/wav/ogg)'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'cocos_add_audio_source' or 'cocos_add_resource_file', which might handle similar resources or operations, leaving some ambiguity about uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, mentioning that the file is placed under resources/ for runtime loading via resources.load(), but it lacks explicit when-to-use instructions, prerequisites, or alternatives compared to siblings. No exclusions or clear context for choosing this tool over others are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a creation/mutation action ('Attach') but doesn't disclose side effects (e.g., modifies scene state), permissions, error conditions, or response format. The presence of an output schema helps, but the description itself lacks critical behavioral context for a 12-parameter mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes directly to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, mutation tool, no annotations) and the presence of an output schema, the description is incomplete. It lacks parameter explanations, usage context, behavioral details, and doesn't leverage the output schema to clarify returns. For a physics joint tool with many parameters, this minimal description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 but adds no parameter information. It doesn't explain what parameters like 'scene_path', 'node_id', or 'distance' mean, their units, constraints, or relationships. With 12 parameters entirely undocumented in both schema and description, this is a severe gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and the specific resource ('cc.DistanceJoint2D'), with a brief functional explanation ('keeps two bodies a fixed distance apart'). It distinguishes from sibling tools by specifying the exact joint type, but doesn't explicitly contrast with other joint tools like 'cocos_add_fixed_joint_2d' or 'cocos_add_spring_joint2d'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention prerequisites (e.g., requiring physics bodies), context (e.g., for 2D physics simulations), or exclusions. It's a standalone statement 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return structure ({dragon_asset_uuid, dragon_atlas_uuid, textures, dir}), which is helpful, but doesn't disclose critical behavioral traits: whether this is a read or write operation (likely a write/mutation), what permissions are needed, whether it overwrites existing assets, error conditions, or side effects. For an import tool with zero annotation coverage, this leaves significant gaps.
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 appropriately concise with two sentences: one stating the purpose and one detailing the return structure. It's front-loaded with the core action. However, the second sentence could be integrated more smoothly, and there's room to add brief usage context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It lacks explanations of parameter semantics, behavioral details like mutation effects or error handling, and doesn't clarify how this tool fits within the broader Cocos workflow. The return structure hint is helpful but insufficient for full understanding.
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 description coverage is 0%, so the description must compensate for all 5 parameters. It only implicitly references parameters through the asset types mentioned (_ske.json, _tex.json, _tex.png), but doesn't explain what each parameter does, their relationships, or provide examples. The description adds minimal value beyond what the schema titles already indicate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import DragonBones assets') and specifies the resource types (_ske.json + _tex.json + _tex.png). It distinguishes from siblings like 'cocos_add_dragonbones' by focusing on data import rather than general DragonBones addition. However, it doesn't explicitly contrast with 'cocos_add_spine_data' which serves a similar purpose for different asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention prerequisites, when not to use it, or how it relates to similar tools like 'cocos_add_spine_data' for Spine assets. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the joint creates 'breakable structures' (implying some durability characteristic) and provides historical context about Box2D naming and deprecated tools. However, it doesn't describe what happens when the joint is attached (e.g., whether it modifies existing nodes, requires specific physics bodies, has performance implications, or what the output contains). For a physics tool with 11 parameters, this is insufficient behavioral context.
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 appropriately concise with three sentences that each add value: the core functionality, the Box2D naming context, and the historical replacement note. There's no wasted verbiage, and the information is front-loaded with the primary purpose. It could be slightly improved with clearer structure, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (physics joint tool with 11 parameters), no annotations, and an output schema (which means return values are documented elsewhere), the description is incomplete. It explains what the tool does at a high level but provides no guidance on usage, no parameter semantics, and minimal behavioral context. For a tool that presumably modifies scene physics, this leaves significant gaps in understanding how to use it effectively.
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 description coverage is 0%, meaning none of the 11 parameters have descriptions in the schema. The tool description provides no information about any parameters—it doesn't explain what 'scene_path', 'node_id', 'anchor_x', 'frequency', or any other parameters mean or how they affect the joint creation. With 11 parameters (9 with defaults) and zero coverage, the description fails to compensate for the schema's deficiencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Attach cc.FixedJoint2D — rigidly fuses two bodies (breakable structures).' It provides a specific verb ('Attach') and resource ('cc.FixedJoint2D'), and explains the effect ('rigidly fuses two bodies'). However, it doesn't explicitly distinguish this joint type from other joint tools in the sibling list (e.g., distance_joint2d, hinge_joint2d, mouse_joint2d), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions that it 'replaces the prior cocos_add_weld_joint2d', but this is historical context rather than practical usage advice. There's no indication of prerequisites, when this joint type is appropriate, or how it differs from other joint tools available in the system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool attaches a layout but doesn't describe what that entails—whether it modifies existing nodes, requires specific permissions, has side effects, or how it interacts with the scene. For a mutation tool with 12 parameters, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that directly states the tool's purpose and provides key enum values for layout_type. It's front-loaded with the main action and avoids unnecessary words, though it could be slightly more structured (e.g., separating the enum explanation).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, mutation tool, no annotations, schema coverage 0%), the description is inadequate. It lacks details on parameter meanings, behavioral traits, output (though an output schema exists, the description doesn't hint at it), and usage context. For a tool with many parameters and no annotation support, more comprehensive guidance is needed.
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 description coverage is 0%, so the schema provides no parameter details. The description only explains 'layout_type' with enum values (0=NONE, etc.), adding minimal semantics for 1 of 12 parameters. It doesn't clarify the purpose of other parameters like spacing, padding, resize_mode, or directions, leaving most undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and resource ('cc.Layout'), specifying it attaches a layout component. It distinguishes from siblings by focusing on layout attachment rather than other component types like scripts or animations. However, it doesn't explicitly differentiate from other layout-related tools (none appear in the sibling list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention prerequisites, context, or comparisons with other layout or UI tools. It only defines the tool's function without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'attach' and 'drag-to-target constraint,' implying a mutation operation that likely modifies scene physics, but does not detail permissions, side effects, error conditions, or response behavior. For a tool with 7 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Attach cc.MouseJoint2D — drag-to-target constraint, used to pick up bodies with the mouse.' It is front-loaded with the core action and purpose, with no wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, but has an output schema), the description is incomplete. It lacks parameter explanations, usage context, and behavioral details. While the output schema may cover return values, the description fails to provide essential context for safe and correct invocation, especially for a mutation tool in a physics system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about any of the 7 parameters. With 0% schema description coverage, the schema only lists parameter names and types without explanations. The description does not compensate by explaining what parameters like 'scene_path', 'node_id', 'max_force', etc., mean or how they affect the joint attachment, leaving parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Attach cc.MouseJoint2D — drag-to-target constraint, used to pick up bodies with the mouse.' It specifies the verb ('attach'), resource ('cc.MouseJoint2D'), and provides a functional explanation ('drag-to-target constraint, used to pick up bodies with the mouse'). However, it does not explicitly differentiate from sibling tools like 'cocos_add_distance_joint2d' or 'cocos_add_spring_joint2d', which are also joint-related tools, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions the tool's function but does not specify prerequisites, context (e.g., when in a game development workflow), or compare it to other joint tools in the sibling list. This lack of explicit usage instructions limits its effectiveness for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions configurable aspects but fails to describe key traits: whether this is a mutation (likely yes, as it 'attaches'), what permissions or prerequisites are needed, if it has side effects (e.g., modifying scene state), or the response format. For a tool with 26 parameters and no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and key configurable areas. There is no wasted verbiage or redundancy, making it easy to parse quickly. However, this conciseness comes at the cost of completeness, as noted in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (26 parameters, no annotations, schema coverage 0%) and the presence of an output schema (which might cover return values), the description is insufficient. It lacks usage context, behavioral details, and parameter explanations, making it inadequate for effective tool invocation. The output schema may help with returns, but the description doesn't guide the agent on how or when to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 26 parameters have descriptions in the schema. The tool description only vaguely references 'configurable emission, color, physics' without explaining any specific parameters (e.g., what 'emission_rate' or 'gravity_x' do). This fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and the resource ('cc.ParticleSystem2D'), specifying its configurable aspects (emission, color, physics). It effectively distinguishes this tool from siblings like 'cocos_add_animation' or 'cocos_add_sprite' by focusing on particle systems, though it doesn't explicitly contrast with similar tools (e.g., if there were a 'cocos_add_particle_system_3d').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description lacks context about prerequisites (e.g., needing a valid scene or node), typical use cases (e.g., visual effects), or exclusions (e.g., not for 3D scenes). With many sibling tools, this omission leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a mutation ('Attach'), implying changes to the scene, but does not describe permissions, side effects, error handling, or response format. This leaves significant gaps for a tool that modifies game objects.
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 very concise with two short sentences, front-loading the main action and providing a key parameter detail. There is no wasted text, but it could benefit from slightly more structure to separate purpose from parameter notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, mutation operation) and lack of annotations, the description is insufficient. It does not explain the tool's role in the physics system, interaction with other components, or output behavior, despite having an output schema. More context is needed for effective use.
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 description coverage is 0%, so the schema provides no parameter descriptions. The description only explains 'points' as a vertex list, adding minimal semantics for 1 of 8 parameters. It does not clarify the purpose or usage of other parameters like 'scene_path', 'node_id', or physics properties, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and the resource ('cc.PolygonCollider2D'), making the purpose specific and understandable. However, it does not explicitly differentiate this tool from sibling tools like 'cocos_add_box_collider2d' or 'cocos_add_circle_collider2d', which likely attach different collider types, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other collider types or related tools like 'cocos_add_physics_body2d'. It mentions the 'points' parameter but does not specify prerequisites, context, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the 'body_type' parameter with enum values, which hints at behavior (static, kinematic, dynamic), but fails to disclose critical traits like whether this is a destructive operation, permission requirements, side effects, or error handling. This leaves significant gaps for a tool that likely modifies scene state.
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 very concise with a single sentence, front-loading the core action and providing key parameter info. It avoids unnecessary words, though it could be slightly more structured (e.g., separating purpose from parameter details).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, but has an output schema), the description is incomplete. It lacks behavioral context, usage guidelines, and details for most parameters. While the output schema may cover return values, the description does not adequately prepare an agent for correct invocation in a physics system context.
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 description coverage is 0%, so the description must compensate. It only explains the 'body_type' parameter with enum values, ignoring the other 8 parameters (e.g., 'scene_path', 'node_id', 'gravity_scale'). This minimal coverage fails to add meaningful semantics beyond the schema, leaving most parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and the resource ('cc.RigidBody2D'), specifying what the tool does. It distinguishes from some siblings like 'cocos_add_physics_body2d' by focusing on a specific 2D physics component, but does not explicitly differentiate from all similar tools (e.g., 'cocos_add_rigidbody_3d'), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other physics-related tools in the sibling list (e.g., 'cocos_add_rigidbody_3d' for 3D). It lacks context about prerequisites, scenarios, or exclusions, offering only basic functional information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions attaching a collider, implying a mutation, but lacks details on permissions, side effects, error conditions, or what the output schema might contain. This leaves significant behavioral gaps for a tool with 7 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, front-loading the core action. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters with 0% schema coverage, no annotations, and an output schema (though its content is unknown), the description is incomplete. It does not compensate for the lack of parameter documentation or provide sufficient behavioral context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions the 'terrain_uuid' parameter. It fails to explain the purpose of other parameters like 'scene_path', 'node_id', 'center_x', 'center_y', 'center_z', and 'is_trigger', leaving most semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.TerrainCollider'), specifying it requires a cc.Terrain asset UUID. It distinguishes from siblings like 'cocos_add_box_collider_3d' by focusing on terrain, but does not explicitly contrast with other collider types beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., other collider types in the sibling list), prerequisites, or contextual constraints. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the behavioral trait of mutual exclusivity ('Children are mutually exclusive'), which is valuable. However, it lacks critical details: whether this is a creation or modification operation, permission requirements, side effects on existing nodes, error conditions, or interaction with the scene graph. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core action. Every word earns its place: 'Attach' defines the action, 'cc.ToggleContainer' specifies the resource, and the parenthetical adds crucial behavioral context. There is zero redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage, no annotations, and an output schema (which relieves the description from explaining returns), the description is incomplete. It covers the core purpose but misses parameter semantics, usage context, and behavioral details like error handling or scene integration. For a Cocos Creator scene manipulation tool, this leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no information about the three parameters (scene_path, node_id, allow_switch_off). It doesn't explain what a 'scene_path' or 'node_id' refers to, or the effect of 'allow_switch_off'. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.ToggleContainer') with additional functional context ('radio group', 'Children are mutually exclusive'). It distinguishes from siblings like 'cocos_add_toggle' by specifying a container/group behavior rather than a single toggle. However, it doesn't explicitly contrast with all sibling tools beyond the general 'add' pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for creating mutually exclusive toggle groups, but doesn't specify prerequisites, dependencies, or when to choose this over other UI components like 'cocos_add_button' or 'cocos_add_slider'. The agent must infer usage from the functional description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Set' implies a mutation operation, the description doesn't clarify what 'design resolution' affects, whether changes are reversible, what permissions are needed, or what happens to existing settings. The fit mode explanation adds some context but doesn't cover important behavioral aspects like side effects or error conditions.
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 brief and front-loaded with the main purpose. The second sentence efficiently explains the fit mode combinations. There's no wasted text, though the fit mode explanation could be slightly clearer. The structure is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It explains the basic purpose and fit modes but doesn't cover parameter meanings, behavioral implications, error handling, or what the tool returns. Given the complexity and lack of structured documentation, the description should provide much more context.
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?
With 0% schema description coverage and 5 parameters (1 required), the description provides minimal parameter information. It mentions fit_width and fit_height with their interaction modes, but doesn't explain project_path, width, height, or the practical meaning of these parameters. The description doesn't compensate for the schema's lack of descriptions, leaving most parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set design resolution for multi-screen adaptation.' It specifies the verb ('Set') and resource ('design resolution') with a clear context ('multi-screen adaptation'). However, it doesn't explicitly distinguish this tool from its many siblings, which all appear to be Cocos-related operations but have different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions fit modes (SHOW_ALL, FIT_WIDTH, FIT_HEIGHT) but doesn't explain when to choose one over another or reference any sibling tools as alternatives. There's no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the tool modifies a project configuration file ('project.json'), implying a mutation, but doesn't disclose critical behavioral traits: whether this requires specific permissions, if changes are reversible, potential side effects (e.g., breaking existing builds), or error handling. The description adds minimal context beyond the basic action.
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 appropriately sized with two concise sentences. The first sentence states the action and target, while the second explains the runtime impact. It's front-loaded with the core purpose, and every sentence adds value without redundancy. However, it could be slightly more structured with bullet points for parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover parameter details, error cases, return values, or behavioral nuances. For a configuration tool that modifies project settings, more context is needed to ensure safe and correct usage.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It adds no information about the two required parameters ('project_path' and 'scene_uuid'), such as their formats, examples, or constraints (e.g., UUID format, valid project paths). The description fails to provide meaningful semantics beyond what the bare schema titles imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set the project's start scene') and the target resource ('in settings/v2/packages/project.json'), with a specific purpose ('The engine loads this scene first at runtime'). It distinguishes from sibling tools by focusing on project configuration rather than scene/content creation or modification. However, it doesn't explicitly differentiate from similar configuration tools like 'cocos_set_design_resolution' or 'cocos_set_physics_2d_config'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites (e.g., needing an existing scene UUID), exclusions (e.g., not for runtime changes), or related tools (e.g., 'cocos_create_scene' to create scenes first). The context is implied through the file path, but explicit usage instructions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions what the tool does (attaching an audio source) and one parameter detail, but doesn't describe what happens when invoked (e.g., whether it modifies scene state, requires specific permissions, has side effects, or what the output contains). For a tool with 6 parameters and no annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that gets straight to the point with no wasted words. It's appropriately sized for what it does cover, though it could benefit from additional context given the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and complex sibling relationships (multiple audio-related tools), the description is insufficient. While an output schema exists, the description doesn't provide enough context about the tool's purpose, usage scenarios, parameter meanings, or behavioral characteristics to guide an AI agent effectively.
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 description coverage is 0%, so the description must compensate. It only provides semantic context for one parameter (clip_uuid), leaving the other 5 parameters (scene_path, node_id, play_on_awake, loop, volume) completely unexplained. The description doesn't clarify what these parameters mean or how they affect the audio source behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and the resource ('cc.AudioSource'), and provides specific technical detail about the clip_uuid parameter referencing an audio-clip asset. However, it doesn't explicitly differentiate from sibling tools like 'cocos_add_audio_file' or explain what makes this audio source component unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'cocos_add_audio_file' or other audio-related tools. The description doesn't mention prerequisites, typical use cases, or any context for selecting this specific audio component over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool attaches a component and describes its functional effect (blocking input), but lacks critical behavioral details such as whether this is a mutation (likely yes), permission requirements, error conditions, or how it interacts with existing components. The description is minimal and doesn't compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that directly state the action and effect. It is front-loaded and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 0% schema coverage, no annotations, and an output schema (which might help but isn't described), the description is incomplete. It covers the basic purpose but misses parameter semantics, usage context, and behavioral transparency needed for a mutation tool in a complex environment like Cocos.
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 description coverage is 0%, so the schema provides no parameter details. The description adds no information about the two required parameters (scene_path and node_id), failing to explain what they represent, their format, or how they identify the target node. This leaves parameters completely undocumented beyond their names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.BlockInputEvents'), with a specific effect ('Blocks touch/mouse from passing through this node'). It distinguishes from siblings by focusing on input blocking rather than adding components like animations or scripts, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description mentions the functional effect but doesn't specify prerequisites, context (e.g., for UI elements), or when not to use it, leaving the agent to infer usage from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions attaching a collider with physics material, implying a mutation operation, but does not cover critical aspects like whether it modifies existing colliders, requires specific permissions, has side effects (e.g., affecting gameplay), or error conditions. This leaves significant gaps for a tool that likely alters scene state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the key action and components, making it easy to scan and understand the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, mutation tool), lack of annotations, and 0% schema coverage, the description is inadequate. It does not explain parameter meanings, behavioral traits, or usage context. While an output schema exists, the description fails to provide necessary context for safe and effective use, especially for a tool that likely modifies physics properties.
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 description coverage is 0%, so the description must compensate. It mentions 'radius and physics material', hinting at parameters like radius, density, friction, and restitution, but does not explain the 10 parameters (e.g., scene_path, node_id, offset_x/y, is_sensor, tag) or their purposes. This adds minimal value beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.CircleCollider2D'), specifying the component type and key parameters (radius, physics material). It distinguishes from siblings like 'cocos_add_box_collider2d' by indicating a circle shape, but does not explicitly differentiate from other collider types beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., other collider types like box or polygon), prerequisites (e.g., needing a node with a physics body), or exclusions. The description only states what it does, not when or why to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Attach' which implies a mutation operation, but doesn't disclose critical behavioral traits like whether this requires specific permissions, if it's destructive to existing components, error conditions, or what the output contains. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core action. Every word earns its place by specifying the component type and providing illustrative examples without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, physics joint creation), absence of annotations, and 0% schema coverage, the description is inadequate. While an output schema exists (which helps with return values), the description doesn't address the numerous parameters, behavioral implications, or usage context needed for effective tool invocation.
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?
With 0% schema description coverage and 14 parameters (only 2 required), the description provides no information about any parameters. It doesn't explain what 'scene_path', 'node_id', or any other parameters mean, their units, or how they interact. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.HingeJoint2D'), and provides concrete examples of use cases ('door, wheel, pendulum'). It distinguishes itself from sibling tools by specifying a particular joint type (HingeJoint2D), though it doesn't explicitly contrast with other joint tools like 'cocos_add_distance_joint2d' or 'cocos_add_wheel_joint2d'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or constraints. While the examples imply typical applications, there's no explicit mention of when this joint type is appropriate compared to other joint types available in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'Attach', implying a mutation that adds an effect to a node, but fails to disclose critical behavioral traits such as permissions needed, whether the effect is reversible, performance impact, or how it interacts with existing components. The example hints at visual behavior but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just one sentence with an example—and front-loaded with the core action. Every word earns its place by stating the tool's purpose and providing illustrative context without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, mutation tool), lack of annotations, and 0% schema coverage, the description is incomplete. It doesn't explain parameters, behavioral implications, or output (though an output schema exists, reducing some burden). For a tool that likely modifies scene state, more detail on effects and usage is needed.
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 description coverage is 0%, meaning none of the 8 parameters are documented in the schema. The description adds no information about parameters like 'scene_path', 'node_id', or the color/fade settings, leaving their purposes and formats completely unexplained. This fails to compensate for the schema gap, resulting in poor parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and the specific resource ('cc.MotionStreak'), with an illustrative example ('trail effect. For sword trails, shooting stars.') that helps visualize its use. However, it doesn't explicitly differentiate from sibling tools like 'cocos_add_animation' or 'cocos_add_particle_system_2d', which might also create visual effects, leaving some ambiguity in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a general context ('trail effect') and examples ('sword trails, shooting stars'), which implies usage for dynamic visual trails. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other visual effect tools in the sibling list), prerequisites, or any 'when-not-to-use' scenarios, resulting in minimal actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the tool attaches a PageView component but doesn't disclose behavioral traits like whether it modifies existing nodes, requires specific permissions, handles errors, or what the output contains. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that directly state the tool's function and clarify one parameter. There is no wasted text, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It fails to explain most parameters, lacks behavioral context, and provides no usage guidelines, making it inadequate for effective tool selection and invocation.
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 description coverage is 0%, so the description must compensate. It only explains the 'direction' parameter (0=H, 1=V), leaving the other 5 parameters (scene_path, node_id, content_id, scroll_threshold, page_turning_speed) undocumented. This partial coverage is insufficient for a tool with 6 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Attach cc.PageView') and resource ('swipeable pages'), making the purpose clear. It distinguishes from siblings by specifying a unique UI component (PageView), though it doesn't explicitly contrast with similar tools like 'cocos_add_scroll_view'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as 'cocos_add_scroll_view' or 'cocos_add_page_view_indicator'. The description lacks context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions the sprite's visual behavior ('Stretches center, keeps corners'), but lacks critical details: whether this is a creation/mutation operation, what permissions are needed, if it modifies existing nodes, error conditions, or the output format (though an output schema exists). For a tool with 7 parameters and no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences with zero wasted words. It's front-loaded with the core action and type, followed by a clarifying detail. Every sentence earns its place by adding essential information about the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations) and the presence of an output schema, the description is incomplete. It covers the basic purpose but fails to address parameter meanings, usage context, or behavioral details beyond a high-level visual effect. For a tool that likely creates or modifies game objects, more guidance is needed.
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 description coverage is 0%, so the description must compensate. It adds no information about any parameters—doesn't explain what 'scene_path' or 'node_id' refer to, what 'sprite_frame_uuid' is for, or the purpose of the color parameters. This leaves all 7 parameters undocumented beyond their titles in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach cc.Sprite') and specifies the sprite type ('type=SLICED (9-slice)'), with a brief explanation of its behavior ('Stretches center, keeps corners'). It distinguishes from sibling 'cocos_add_sprite' by specifying the sliced type, but doesn't explicitly differentiate from other sprite-related tools like 'cocos_add_filled_sprite' or 'cocos_add_tiled_sprite'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention prerequisites (e.g., needing a valid scene and node), compare to other sprite types, or indicate typical use cases (e.g., UI elements that need to scale without distorting corners).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a mutation ('Attach') but doesn't specify whether this requires specific permissions, what happens if the attachment fails, or if it modifies existing lights. It lacks details on error handling, side effects, or the output format (though an output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action ('Attach cc.SpotLight') and adds clarifying context ('cone-shaped light (torch, stage spot)') without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (16 parameters, mutation tool), lack of annotations, and 0% schema coverage, the description is inadequate. It doesn't explain parameter meanings, usage context, or behavioral traits. While an output schema exists, the description fails to provide necessary context for safe and correct invocation.
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 description coverage is 0%, so the description must compensate for 16 undocumented parameters. It only mentions 'cone-shaped light' and analogies, which loosely relate to parameters like 'spot_angle' or 'light_range', but provides no explicit mapping, default behaviors, or units. This is insufficient for a tool with many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.SpotLight'), and provides a specific analogy ('cone-shaped light (torch, stage spot)') that distinguishes it from other light types like 'cocos_add_directional_light' or 'cocos_add_sphere_light' in the sibling list. However, it doesn't explicitly differentiate from all siblings beyond the analogy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., other light types or attachment methods), nor does it mention prerequisites like requiring an existing scene or node. It only states what the tool does, not when or why to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Attach' which implies a mutation operation, but doesn't disclose whether this requires specific permissions, what happens if the layer already exists, whether it's reversible, or any rate limits. The mention of 'usually auto-created by TiledMap' adds some context but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple tool and front-loads the essential action ('Attach cc.TiledLayer'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 3 parameters (0% schema coverage), no annotations, but with an output schema, the description is incomplete. It explains what the tool does at a high level but lacks parameter explanations, behavioral details, and usage context. The output schema existence means return values are covered, but other gaps remain significant.
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 description coverage is 0%, so the description must compensate for three undocumented parameters. It provides no information about what 'scene_path', 'node_id', or 'layer_name' represent, their expected formats, or how they relate to attaching a TiledLayer. The description adds no parameter semantics beyond what's in the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.TiledLayer'), and provides context about its typical creation source ('usually auto-created by TiledMap'). It distinguishes from sibling tools like 'cocos_add_tiled_map' by focusing on layer attachment rather than map creation. However, it doesn't explicitly differentiate from other 'add' tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions TiledMap as the typical source but doesn't specify prerequisites, constraints, or when other tools (like 'cocos_add_tiled_map' or general 'cocos_add_component') would be more appropriate. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'Attach' which implies a mutation operation, but does not disclose behavioral traits such as permissions needed, whether it modifies existing components, error conditions, or the effect on the scene. The description adds minimal context beyond the basic action, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and key detail ('type=TILED'). It has zero wasted words and is appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to explain returns), the description is incomplete. It lacks essential details about parameter usage, behavioral context for a mutation tool, and differentiation from siblings, making it inadequate for effective agent use despite the concise structure.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It does not explain any parameters (e.g., what 'scene_path' or 'node_id' refer to, or how 'sprite_frame_uuid' and color values are used). The mention of 'type=TILED' hints at the sprite type but does not map to specific parameters, failing to add meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and resource ('cc.Sprite') with a specific type ('type=TILED'), indicating it adds a tiled sprite component. It distinguishes from generic sprite tools by specifying the tiled pattern fill, but does not explicitly differentiate from sibling tools like 'cocos_add_sprite' or 'cocos_add_filled_sprite' beyond the type hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., 'cocos_add_sprite' for non-tiled sprites or 'cocos_add_filled_sprite' for solid fills). The description implies usage for tiled sprites but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Attach' which implies a mutation operation, but doesn't disclose whether this requires specific permissions, what happens if the webview already exists, whether changes are reversible, or any rate limits. The mention of 'ToS / activity pages' adds minimal context but leaves critical behavioral traits undocumented.
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 a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for the tool's apparent complexity, though it could benefit from more detail given the lack of annotations and schema descriptions.
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?
Given that there's an output schema (which means return values are documented elsewhere) but zero schema description coverage and no annotations, the description is incomplete. It covers the basic purpose but misses parameter explanations, behavioral context, and usage guidelines that would help an agent understand this mutation tool fully.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It provides no information about the three parameters (scene_path, node_id, url) beyond what the schema's titles indicate. The default URL 'https://cocos.com' is only visible in the schema, not mentioned in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.WebView'), specifying it's an embedded browser pane for ToS/activity pages. It distinguishes from siblings by focusing on webview attachment rather than other UI components like buttons or labels, but doesn't explicitly contrast with similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description mentions 'embedded browser pane for ToS / activity pages' which hints at a use case, but doesn't specify prerequisites, constraints, or when other web-related tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it 'attaches' a joint without detailing behavioral traits like whether it modifies existing nodes, requires specific permissions, or has side effects. It mentions the joint's combined functions but not operational specifics like performance impact or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, front-loading the core action and providing brief functional context. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (14 parameters, no annotations, 0% schema coverage) and an output schema present, the description is incomplete. It lacks parameter semantics, behavioral details, and doesn't leverage the output schema to explain return values, making it inadequate for effective tool use.
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 description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what parameters like 'scene_path' or 'anchor_x' mean, their units, or how they interact, leaving 14 parameters undocumented beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.WheelJoint2D'), with additional context about its function ('wheel + axle (slide along axis + spring + motor combined; vehicles)'). It distinguishes from siblings like 'cocos_add_distance_joint2d' by specifying the joint type, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., other joint types in the sibling list) is provided. The description implies usage for vehicle-like physics but lacks context on prerequisites, constraints, or when to choose other joints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a file, implying a write operation, but doesn't cover critical aspects like permissions needed, whether it overwrites existing files, error conditions, or what happens if the path is invalid. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and key details (location and root node). There is no wasted text, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a write operation with 3 parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't compensate for the missing structured data, failing to explain parameter meanings, behavioral traits, or expected outcomes, leaving the agent poorly informed.
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 description coverage is 0%, meaning none of the three parameters (project_path, prefab_name, root_name) have descriptions in the schema. The tool description mentions 'prefab' and 'root node', hinting at prefab_name and root_name, but doesn't explain their semantics, formats, or the purpose of project_path. It adds minimal value beyond the schema's lack of coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create an empty .prefab') and the resource/location ('in assets/prefabs/ with a single root node'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'cocos_save_subtree_as_prefab' or 'cocos_create_node', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites, when-not-to-use scenarios, or compare with sibling tools such as 'cocos_save_subtree_as_prefab' for saving existing nodes as prefabs, leaving the agent without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a read-only operation ('List'), but does not disclose behavioral traits like potential errors (e.g., invalid project path), output format, or whether it requires specific permissions. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core action and resource, making it efficient and easy to parse, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It does not compensate for these gaps by explaining parameters, return values, or behavioral context, making it inadequate for a tool with one required parameter.
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?
The schema description coverage is 0%, and the description does not mention the 'project_path' parameter at all. It fails to add any meaning beyond the schema, such as explaining what the project path should be (e.g., a file path or directory) or its significance, leaving the parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('engine modules and their enabled/disabled status'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'cocos_get_project_info' or 'cocos_list_assets', which might also retrieve project-related information, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, such as needing a valid project path, or compare it to other listing tools in the sibling set, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a read-only operation by using 'Return', but doesn't disclose behavioral traits like whether it requires specific permissions, how it handles errors, or if it's safe for concurrent use. The description is minimal and misses key operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core action. It is appropriately sized for a simple listing tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain the parameter, return format, or behavioral context, leaving significant gaps for an agent to understand and use the tool effectively.
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 description coverage is 0%, so the schema provides no parameter details. The description mentions no parameters at all, failing to explain the required 'project_path' input. This leaves the parameter undocumented and adds no semantic value beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Return') and resource ('all registered post-build patches with their indices'), making the purpose specific and understandable. It distinguishes itself from sibling tools like 'cocos_register_post_build_patch' and 'cocos_remove_post_build_patches' by focusing on listing rather than modifying, though it doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other listing tools like 'cocos_list_assets' or 'cocos_list_scene_nodes', or how it relates to patch-related siblings. It lacks context on prerequisites or typical scenarios for listing post-build patches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action ('Set') but doesn't clarify if this is a destructive mutation, requires specific permissions, has side effects, or details the response format. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, making it highly efficient and front-loaded. Every word contributes to the core purpose, achieving optimal conciseness for such a simple statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which helps), but with 5 parameters at 0% schema coverage and no annotations, the description is inadequate. It doesn't explain parameter meanings, behavioral traits, or usage context, leaving too much undefined for a mutation tool with multiple inputs.
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 description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'node's local scale' but doesn't explain parameters like scene_path, node_id, sx, sy, or sz (e.g., that sx, sy, sz are scale factors, sz defaults to 1). It adds minimal value beyond the tool name, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set a node's local scale' clearly states the action (set) and target resource (node's local scale), making the purpose immediately understandable. It distinguishes from siblings like 'cocos_set_node_position' or 'cocos_set_node_rotation' by specifying scale, though it doesn't explicitly differentiate beyond the obvious parameter differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or context. It lacks any mention of related tools (e.g., other node transformation tools) or scenarios where setting scale is appropriate, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 indicates a mutation operation ('Set'), implying changes to resources, but fails to detail critical aspects like required permissions, whether the operation is reversible, potential side effects, or error handling. This leaves significant gaps in understanding the tool's behavior and safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence that directly states the tool's purpose with no wasted words. It is front-loaded and efficiently communicates the core action, though this brevity comes at the cost of missing additional helpful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with 4 undocumented parameters, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It fails to explain parameter meanings, usage context, behavioral traits, or output implications, making it inadequate for safe and effective tool invocation by an agent.
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?
The schema description coverage is 0%, meaning none of the 4 parameters are documented in the schema. The description only mentions 'property' and '__uuid__ resource ref', which loosely maps to 'prop_name' and 'uuid', but provides no details on 'scene_path' or 'object_id', their formats, or how they interact. This insufficiently compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and resource ('property to a __uuid__ resource ref'), with examples like 'SpriteFrame, AudioClip, etc.' that help clarify the type of resources involved. However, it doesn't explicitly distinguish this tool from similar sibling tools like 'cocos_set_property' or 'cocos_link_property', which might also handle property assignments, leaving some ambiguity in differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as sibling tools like 'cocos_set_property' or 'cocos_link_property'. It lacks context about prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage based solely on the tool name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states a write operation ('Write appid'), implying mutation, but fails to mention permissions, effects on existing data, error handling, or response format. This leaves significant gaps in understanding the tool's behavior and risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It does not address mutation effects, parameter details, or return values, making it inadequate for a tool that modifies configuration files.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'appid' but not 'project_path', and adds no details on format, constraints, or examples. This insufficiently clarifies the two required parameters beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write appid') and target resource ('builder.json for the wechatgame platform'), making the purpose specific and understandable. However, it does not differentiate from sibling tools like 'cocos_set_wechat_subpackages' or other configuration tools, which slightly reduces its clarity in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other configuration tools in the sibling list. It lacks context about prerequisites, typical scenarios, or exclusions, leaving usage unclear beyond the basic action stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'Attach', implying a mutation operation, but fails to disclose critical behavioral traits such as whether this requires specific permissions, if it overwrites existing colliders, error conditions, or side effects. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, front-loading the core action and key attributes. It is appropriately sized for the tool's complexity, making it easy to parse quickly.
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?
Given the tool has an output schema (which handles return values), no annotations, and 11 parameters with 0% schema coverage, the description is incomplete. It covers the basic purpose but lacks usage guidelines, detailed parameter semantics, and behavioral transparency, making it minimally adequate but with significant gaps for a mutation tool in a complex environment.
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 description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'size, offset, and physics material', which loosely maps to some parameters (e.g., width/height for size, offset_x/offset_y for offset, density/friction/restitution for physics material), but it does not explain the semantics of the 11 parameters, such as 'scene_path', 'node_id', 'is_sensor', or 'tag', leaving most undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.BoxCollider2D') with specific attributes ('given size, offset, and physics material'), making the purpose explicit. However, it does not differentiate from sibling tools like 'cocos_add_circle_collider2d' or 'cocos_add_box_collider_3d', which are similar collider-adding tools, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other collider types (e.g., circle, polygon) or 3D variants. It also omits prerequisites, like needing a valid scene and node, leaving the agent to infer usage from the required parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions input_mode values and max_length behavior, but doesn't disclose critical behavioral traits like whether this is a read/write operation, permission requirements, side effects, or error handling. For a tool that likely modifies a scene, this is insufficient.
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 a single, efficient sentence that front-loads the core action. Every part earns its place by explaining key parameters. It could be slightly more structured but avoids waste.
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?
Given 6 parameters with 0% schema coverage and no annotations, the description partially compensates by explaining two parameters. An output schema exists, so return values needn't be explained. However, for a tool that likely modifies a Cocos scene, more context on behavior and usage is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 input_mode values (0=ANY, 6=SINGLE_LINE) and max_length (-1=unlimited), adding meaningful semantics beyond the schema's titles. However, it doesn't cover other parameters like scene_path, node_id, placeholder, or return_type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool attaches a cc.EditBox component, which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like cocos_add_button or cocos_add_label, which also attach UI components. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention prerequisites, context, or comparisons with other UI component tools in the sibling list. Usage is implied only through parameter explanations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is for 'runtime vector drawing' which hints at a dynamic, non-destructive operation, but doesn't disclose permissions needed, side effects, error conditions, or what the output schema might contain. This is inadequate for a tool with mutation implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes a clarifying parenthetical. Every word earns its place with no redundancy or fluff.
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?
Given the tool has an output schema (which reduces need to describe returns) but zero annotation coverage and low schema description coverage, the description is minimally adequate. It covers the basic purpose but lacks details on parameters, behavioral traits, and usage context that would be needed for full understanding.
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 description coverage is 0%, so the description must compensate. It mentions 'node' and 'cc.Graphics' but doesn't explain what 'scene_path' or 'node_id' mean, their formats, or how they relate to the attachment process. The description adds minimal value beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and resource ('a cc.Graphics to a node'), with additional context about its use ('for runtime vector drawing'). It distinguishes from siblings by specifying the graphics component, but doesn't explicitly differentiate from similar attachment tools like 'cocos_add_component'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description mentions 'runtime vector drawing' which implies a context, but doesn't specify prerequisites, alternatives, or exclusions compared to the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool 'Attach[es]' a component, implying a mutation, but doesn't disclose behavioral traits like required permissions, whether it modifies existing colliders, error conditions, or response format. The mention of 'infinite plane' adds some context, but overall, it lacks critical behavioral details for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: two sentences with zero waste. The first sentence states the purpose and typical use, and the second explains default values. Every sentence earns its place, making it efficient and well-structured.
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?
Given the complexity (10 parameters, mutation tool) and no annotations, the description is incomplete. It covers the tool's purpose and some parameter defaults but lacks behavioral transparency, usage guidelines, and details for most parameters. The presence of an output schema (context signals indicate 'Has output schema: true') reduces the need to explain return values, but overall, it's minimally adequate with clear gaps.
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 description coverage is 0%, so the description must compensate. It explains the default normal (0,1,0) and constant 0, clarifying the XZ plane at y=0, which adds meaning for 'normal_x', 'normal_y', 'normal_z', and 'constant'. However, it doesn't address the other 6 parameters (scene_path, node_id, center_x/y/z, is_trigger), leaving most semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Attach cc.PlaneCollider — infinite plane, typically used for the ground.' It specifies the verb ('Attach'), resource ('cc.PlaneCollider'), and typical use case ('ground'). However, it doesn't explicitly differentiate from sibling tools like 'cocos_add_box_collider_3d' or 'cocos_add_sphere_collider_3d', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: 'typically used for the ground.' It doesn't specify when to use this tool versus alternative colliders (e.g., box, sphere, mesh), mention prerequisites, or outline exclusions. Without explicit alternatives or context, it offers little usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes the joint's effect ('keeps relative position+angle') and mentions it replaces an old motor joint, but doesn't disclose critical behavioral traits like whether this is a destructive operation, what permissions are needed, rate limits, error conditions, or what happens when parameters are invalid. The description adds some context but leaves significant gaps.
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 appropriately concise with two sentences that each serve a purpose: the first explains what the tool does, and the second provides historical context about replacing an old tool. There's no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, physics/joint functionality), no annotations, and 0% schema description coverage, the description is insufficiently complete. While an output schema exists, the description doesn't explain the joint's behavior in enough detail for an agent to use it effectively, especially given the many parameters with technical meanings that aren't explained.
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?
With 11 parameters and 0% schema description coverage, the description provides no parameter semantics whatsoever. It doesn't explain what any of the parameters mean, how they affect the joint behavior, or provide usage examples. The schema has descriptive titles but the description adds zero value beyond what's already in the structured schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Attach cc.RelativeJoint2D' with the specific behavior of 'keeps relative position+angle ('attach to' effect)'. It distinguishes from sibling tools by mentioning the deprecated 'cocos_add_motor_joint2d' and explaining that cc.MotorJoint2D doesn't exist in Cocos 3.8, though it doesn't explicitly differentiate from other joint tools in the sibling list.
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?
The description provides implied usage guidance by mentioning it 'covers the follow-target use case that the old cocos_add_motor_joint2d tried to solve', suggesting when this tool might be appropriate. However, it doesn't explicitly state when to use this versus other joint tools (like cocos_add_distance_joint2d or cocos_add_fixed_joint_2d) or provide clear when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions copying files and writing metadata, which implies a write operation, but doesn't disclose critical behavioral traits like whether it overwrites existing files, requires specific permissions, handles errors, or has side effects. The return format is noted, but other operational details are missing.
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 concise with three short sentences that are front-loaded: the first states the core action, the second provides usage context, and the third specifies the return value. There's minimal waste, though it could be slightly more structured for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (file copying with metadata writing), 4 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on parameters, behavioral constraints, error handling, and doesn't fully compensate for the missing structured data, leaving significant gaps for an AI agent.
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 description coverage is 0%, so the schema provides no parameter details. The description doesn't explain any of the 4 parameters (project_path, src_path, rel_path, uuid), such as what they represent, their formats, or how they interact. It mentions 'rel_path' and 'uuid' in the return value but not as inputs, adding confusion rather than clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Copy any file into assets/resources/ + write a minimal meta.' This specifies the verb ('copy'), resource ('file'), and destination ('assets/resources/'), and mentions writing metadata. However, it doesn't explicitly differentiate from sibling tools like 'cocos_add_audio_file' or 'cocos_add_image', which might also add files to resources.
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?
The description provides some usage context: 'Suitable for JSON data, text assets, or custom resources.' This implies when to use it (for those file types) but doesn't explicitly state when not to use it or name alternatives among the many sibling tools. It offers basic guidance but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions HTML tag support and size_preset behavior, but doesn't disclose whether this is a creation or modification operation, what permissions are needed, if it's destructive, or what the output looks like. For a tool with 8 parameters and no annotations, this is insufficient.
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 appropriately sized with two focused sentences. The first sentence states the core purpose with tag examples, and the second explains size_preset behavior. No wasted words, though it could be slightly more structured.
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?
Given 8 parameters with 0% schema coverage and no annotations, the description is incomplete. It explains size_preset well but ignores other parameters and behavioral context. The presence of an output schema helps, but the description doesn't leverage it to explain return values or overall completeness.
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 size_preset values and their effect on font_size and line_height, adding meaningful context beyond the schema. However, it doesn't address other parameters like scene_path, node_id, or horizontal_align, leaving most parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool attaches a cc.RichText component with specific HTML tag support, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'cocos_add_label' or 'cocos_add_styled_text_block' that might handle text differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'cocos_add_label' or 'cocos_add_styled_text_block' from the sibling list. It mentions size_preset overriding font_size, but this is parameter semantics rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool attaches a component and auto-fits nodes, but doesn't disclose critical behavioral traits: whether this is a mutation (likely yes), what permissions are needed, if it's destructive to existing layouts, error conditions, or rate limits. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core action. Every word earns its place: 'Attach' specifies the action, 'cc.SafeArea' identifies the component, and 'Auto-fits node to device safe area (notch/cutout)' clarifies the purpose without redundancy.
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?
Given the tool has an output schema (which likely handles return values), the description's minimalism is partially excused. However, with no annotations, 0% schema coverage, and two required parameters, the description is incomplete for safe usage. It covers the 'what' but misses the 'how' and operational context, making it barely adequate.
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 description coverage is 0%, so parameters 'scene_path' and 'node_id' are undocumented in the schema. The description adds no meaning about these parameters—it doesn't explain what a scene path is, how node IDs are obtained, or their formats. With two required parameters and zero coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.SafeArea') with specific functionality ('Auto-fits node to device safe area (notch/cutout)'). It distinguishes from siblings by focusing on safe area attachment rather than adding components like scripts or animations. However, it doesn't explicitly contrast with similar UI adjustment tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention prerequisites (e.g., needing an existing node), exclusions, or compare it to other layout/adjustment tools in the extensive sibling list. Usage is implied through the action described but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the return values ({skeleton_data_uuid, atlas_uuid, textures, dir}), which adds some behavioral context. However, it doesn't disclose critical traits like whether this is a read/write operation, potential side effects (e.g., file modifications), error conditions, or performance implications. For a tool with 5 parameters and no annotations, this is a significant gap.
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 brief and front-loaded with the main purpose in the first sentence. The second sentence adds useful return value and usage information. There's no wasted text, but it could be slightly more structured (e.g., separating purpose from usage notes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It covers the purpose and return values but lacks parameter explanations, behavioral details, and error handling. For a tool that likely involves file operations and integration with another tool ('cocos_add_spine'), more context is needed to ensure safe and correct usage.
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 description coverage is 0%, so the description must compensate. It doesn't explain any of the 5 parameters (project_path, spine_json_path, atlas_path, texture_paths, rel_dir) beyond what the schema titles provide. The description mentions file types (.json, .atlas, textures) but doesn't clarify parameter roles or relationships, failing to add meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Import Spine skeleton assets (.json + .atlas + textures).' It specifies the verb ('Import') and resources (Spine skeleton assets with file types), making it distinct from most sibling tools that handle different asset types or operations. However, it doesn't explicitly differentiate from 'cocos_add_spine' (a sibling tool), though it mentions using the output with that tool.
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?
The description implies usage by stating 'Use skeleton_data_uuid with cocos_add_spine()', which suggests this tool prepares data for another tool. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other asset import tools) or any prerequisites. The context is somewhat clear but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool attaches a component and is required for UI rendering, but it does not disclose critical behavioral traits such as whether this is a mutation operation, what permissions are needed, if it has side effects, or how it interacts with existing components. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that are front-loaded and waste no words. Every sentence adds value: the first states the core action, and the second provides essential context about its necessity in UI rendering.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 6 parameters, no annotations, and 0% schema coverage), the description is incomplete. It lacks details on parameters, behavioral traits, and usage context. While an output schema exists (which might cover return values), the description does not adequately address the gaps in input and behavioral understanding, making it insufficient for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 6 parameters are documented in the schema. The description does not mention any parameters, their meanings, or how they affect the attachment of cc.UITransform. This fails to compensate for the lack of schema documentation, leaving parameters entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and resource ('a cc.UITransform to a node'), making the purpose specific. It also adds important context about it being 'Required for any UI rendering,' which helps distinguish its role from other sibling tools that add different components or perform different operations, though it doesn't explicitly name alternatives.
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?
The description implies usage by stating it's 'Required for any UI rendering,' suggesting it should be used when UI elements need to be rendered. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., other UI-related tools like cocos_add_button or cocos_add_label), nor does it mention prerequisites or exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'Read' implying a read-only operation, which is helpful, but lacks details on permissions, rate limits, output format, or error handling. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action and resources, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (reading multiple project aspects), no annotations, no output schema, and low schema coverage, the description is incomplete. It does not explain what information is returned, how assets/scenes/scripts are listed, or any constraints, leaving the agent with insufficient context for effective use.
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 does not mention the 'project_path' parameter at all, failing to add meaning beyond the schema. However, with only one parameter, the baseline is 4, but the lack of any parameter context reduces it to 3, as the description does not clarify what the path represents or its format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read') and resources ('package.json + list assets / scenes / scripts'), making the purpose specific and understandable. It distinguishes itself from sibling tools like 'cocos_list_assets' or 'cocos_list_scene_nodes' by combining multiple read operations into one tool, though it could be more explicit about this differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools focused on specific operations (e.g., 'cocos_list_assets'), the description does not clarify if this is a comprehensive overview tool or when it might be preferred over more targeted tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a sub-uuid, implying a read-only operation, but does not specify any behavioral traits such as error handling, performance considerations, or dependencies. The description is minimal and lacks context on what 'sprite-frame sub-uuid' means or how it's used, leaving gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is front-loaded with the core purpose and efficiently conveys the action and output. Every part of the sentence serves a clear function, making it highly concise and well-structured.
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?
Given the tool has 1 parameter, no annotations, and an output schema exists (which should cover return values), the description is minimally adequate. However, it lacks context on the tool's role within the sibling set (e.g., how it relates to other 'get' or asset management tools) and does not fully explain the parameter or output meaning. It meets a basic threshold but has clear gaps in completeness for effective agent use.
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?
The input schema has 1 parameter with 0% description coverage (no schema descriptions). The description mentions 'PNG meta' but does not explain what 'meta_path' is, its format, or examples. It adds minimal semantic value beyond the schema's title ('Meta Path'), failing to compensate for the low schema coverage. A baseline of 3 is not met due to insufficient parameter clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return the `<uuid>@f9941` sprite-frame sub-uuid for a PNG meta.' It specifies the verb ('Return'), resource ('sprite-frame sub-uuid'), and input ('PNG meta'). However, it does not explicitly differentiate from sibling tools, which are all 'cocos_' prefixed but serve various purposes (e.g., adding components, building, managing nodes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions a 'PNG meta' but does not clarify what that is, when this operation is needed, or what other tools might be relevant (e.g., sibling tools like 'cocos_get_object' or 'cocos_list_assets'). There is no explicit when/when-not or alternative usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'sibling_index=-1 appends as last child,' which adds some context about default behavior, but fails to describe other critical aspects like whether this is a destructive operation, what permissions are needed, error conditions, or the impact on existing node hierarchies. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that are front-loaded and waste no words. Every sentence provides essential information, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 4 parameters), no annotations, and 0% schema description coverage, the description is incomplete. It lacks details on behavioral traits, full parameter semantics, and usage context. Although an output schema exists, the description doesn't provide enough information for an agent to use the tool effectively without additional assumptions.
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 for undocumented parameters. It explains 'sibling_index=-1 appends as last child,' adding meaning beyond the schema for one parameter. However, it doesn't clarify the semantics of 'scene_path,' 'node_id,' or 'new_parent_id,' leaving three parameters with no additional context. This partial compensation results in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Re-parent a node' clearly states the verb ('Re-parent') and resource ('a node'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'cocos_duplicate_node' or 'cocos_delete_node' which also manipulate nodes, so it's not fully distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as when to re-parent versus creating a new node or using other node manipulation tools. It lacks context about prerequisites or scenarios where this operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It explains what the toggle does (changes visibility/ticking state) but doesn't mention important behavioral aspects like whether this requires specific permissions, if changes are reversible, what happens to child nodes, or error conditions. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with all necessary information in one efficient sentence. Every word earns its place, with no wasted text or redundancy. The structure moves directly from action to parameter meaning to value interpretation.
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?
Given this is a mutation tool with 3 parameters, 0% schema coverage, no annotations, but with an output schema (which reduces need to describe return values), the description is minimally adequate. It explains the core operation but leaves significant gaps in parameter documentation, behavioral context, and usage guidance that would help an agent use it correctly.
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?
With 0% schema description coverage for all 3 parameters, the description provides no parameter information beyond what's implied by the tool name. It mentions 'node' and '_active flag' which relate to parameters, but doesn't explain what scene_path or node_id represent, their formats, or constraints. The description doesn't compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Toggle a node's _active flag' with specific explanation of what True/False values mean (visible/ticking vs disabled). It uses a specific verb ('toggle') and identifies the resource ('node's _active flag'), though it doesn't explicitly differentiate from sibling tools beyond the name suggesting node manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While sibling tools show many node manipulation options (set_position, set_rotation, etc.), there's no mention of when this specific toggle operation is appropriate versus other node modifications or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Stop') which implies a destructive/mutative operation, but doesn't describe what happens when stopping fails (e.g., if no server is running on that port), whether it's idempotent, or any side effects. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and efficient. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and minimal parameter documentation, the description is inadequate. It doesn't cover behavioral aspects like error handling, idempotency, or side effects. Given the tool's likely role in a preview workflow (with 'cocos_start_preview' as a sibling), more context about dependencies and typical usage would be needed for completeness.
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?
The description mentions 'on the given port' which aligns with the single 'port' parameter in the schema. However, with 0% schema description coverage, the schema provides no documentation about the parameter. The description adds minimal context but doesn't explain the port's purpose, valid ranges, or default behavior (though the schema shows a default of 8080). This partially compensates but remains basic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and target resource ('preview HTTP server on the given port'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'cocos_start_preview' beyond the obvious verb difference, missing an opportunity to clarify their complementary relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While 'cocos_start_preview' is clearly the complementary sibling, the description doesn't mention it or explain prerequisites (e.g., that a preview server must be running). There's no context about error conditions or typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the projection types (ORTHO/PERSPECTIVE) and a use case, but fails to describe critical behaviors such as whether this is a read or write operation, permission requirements, side effects (e.g., if it modifies existing nodes), or error handling. For a tool with 11 parameters and no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly convey key information: the tool's action and a parameter explanation with a use-case hint. Every word serves a purpose, and it is front-loaded with the main function, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no annotations, but with an output schema), the description is incomplete. It lacks details on behavioral traits, most parameter semantics, and overall context needed for effective use. While the output schema may cover return values, the description does not provide sufficient guidance for a tool of this scope, especially with zero schema description coverage.
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 description coverage is 0%, so the description must compensate for all parameters. It only explains the 'projection' parameter (0=ORTHO, 1=PERSPECTIVE) and hints at usage, leaving the other 10 parameters (e.g., scene_path, node_id, priority, ortho_height) undocumented. This adds minimal value beyond the schema, failing to adequately clarify parameter meanings or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and resource ('cc.Camera'), making the purpose specific and understandable. It distinguishes this tool from siblings by focusing on camera attachment rather than other components like scripts, animations, or colliders, though it doesn't explicitly compare to alternatives.
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?
The description provides implied usage context with 'For minimap/split-screen,' suggesting when this tool might be applicable. However, it lacks explicit guidance on when to use it versus alternatives, prerequisites, or any 'when-not' scenarios, leaving the agent to infer from the limited hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool returns a raw JSON dict, which is useful, but does not disclose critical behavioral traits like whether this is a read-only operation, potential performance impacts, error handling, or data format details. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes a contextual note. Every word earns its place, with no wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on parameter usage, return values, error conditions, and operational constraints, making it insufficient for effective tool invocation in a complex environment like Cocos.
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?
The schema description coverage is 0%, so the description must compensate for the undocumented parameters. It does not add any meaning beyond the schema, failing to explain what 'scene_path' and 'object_id' represent, their formats, or examples. This results in inadequate parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Return') and resource ('raw JSON dict of a scene object'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'cocos_get_object_count' or 'cocos_list_scene_nodes', which also retrieve scene information, so it lacks sibling distinction.
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?
The description includes the context 'for debugging/inspection', which implies when to use this tool—for internal inspection rather than production operations. However, it does not provide explicit alternatives or exclusions, such as when to use other getter tools, leaving usage guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a mutation ('Attach') but doesn't disclose behavioral traits such as permissions required, whether it modifies existing components, error conditions, or what the output schema contains. The prerequisite hint is useful but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that are front-loaded and waste no words. Every part ('Attach dragonBones.ArmatureDisplay' and the prerequisite note) earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, mutation tool), lack of annotations, 0% schema coverage, and presence of an output schema, the description is incomplete. It doesn't explain parameter meanings, behavioral implications, or what the output contains, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 8 parameters have descriptions in the schema. The tool description adds no information about what parameters like 'scene_path', 'node_id', or 'dragon_asset_uuid' mean or how to use them, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach') and the resource ('dragonBones.ArmatureDisplay'), providing a specific purpose. It distinguishes from sibling 'cocos_add_dragonbones_data' by referencing it as a prerequisite, though it doesn't explicitly differentiate from other 'add' tools in the list.
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?
The description provides explicit guidance to 'use cocos_add_dragonbones_data first', indicating a prerequisite and sequence. However, it doesn't specify when to use this tool versus alternatives like 'cocos_add_spine' or other animation-related siblings, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 describes the tool's function but lacks critical behavioral details: it doesn't mention if this is a read-only or destructive operation, what permissions are needed, how errors are handled, or what the output looks like. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the purpose, and subsequent lines provide essential parameter details. Every sentence earns its place with no wasted words, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no annotations, schema coverage 0%), the description is incomplete. It explains only 2 parameters and lacks behavioral context, prerequisites, or error handling. While an output schema exists, the description doesn't address the tool's overall role or integration, leaving significant gaps for an AI agent to infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 two parameters ('fill_type' and 'fill_range') with clear semantics and examples, covering 2 out of 12 parameters. This adds meaningful value beyond the schema, though it leaves most parameters undocumented. The baseline would be lower without this, so it scores above average for effort.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach cc.Sprite with type=FILLED') and the resource (a sprite component), with specific examples of use cases ('cooldown timer, radial progress'). It distinguishes itself from generic sprite tools by specifying the FILLED type, though it doesn't explicitly differentiate from sibling tools like 'cocos_add_sprite' or 'cocos_add_progress_bar'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions example use cases but does not specify prerequisites, dependencies, or when to choose this over other sprite or UI tools in the sibling list, such as 'cocos_add_progress_bar' or 'cocos_add_sprite'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a mutation ('Attach'), suggesting this modifies a scene node, but doesn't disclose behavioral traits like whether it requires specific permissions, if it's idempotent, what happens on failure, or the output format. The mention of default values for shadow_casting and shadow_receiving adds some context, but overall behavioral disclosure is minimal.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by parameter details. There's minimal waste, though the parameter explanations could be slightly more structured (e.g., bullet points). Every sentence adds value, making it efficient for an agent to parse.
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?
Given 8 parameters with 0% schema coverage and no annotations, the description partially compensates by detailing 4 parameters. An output schema exists, so return values needn't be explained. However, as a mutation tool with many parameters, the description should ideally cover all parameters or at least the required ones (scene_path, node_id), and provide more behavioral context. It's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 provides meaningful semantics for 4 parameters (material_uuids, shadow_casting, shadow_receiving, reflection_probe_type), explaining their purposes, formats, and default values. However, it omits details for the other 4 parameters (scene_path, node_id, mesh_uuid, enable_morph), leaving them undocumented. The value added for the covered parameters is significant, but incomplete coverage prevents a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Attach cc.MeshRenderer — renders a 3D mesh.' It specifies the verb ('attach'), resource ('cc.MeshRenderer'), and outcome ('renders a 3D mesh'). However, it doesn't explicitly differentiate from sibling tools like 'cocos_add_skinned_mesh_renderer', which appears to serve a similar purpose for skinned meshes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions a workaround for material_uuids ('Pass None to wire later via cocos_set_uuid_property'), but doesn't explain when to choose this tool over other rendering or component-adding tools in the sibling list. No prerequisites, exclusions, or contextual usage hints are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the 'mode' parameter with enum-like values (0=HORIZONTAL, etc.), which adds some context, but fails to describe critical behaviors: whether this is a read or write operation (likely a mutation, but unspecified), what happens to existing components on the node, error conditions, or the output format (though an output schema exists). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that efficiently conveys the core action and key parameter details. It is front-loaded with the main purpose and wastes no words, making it easy for an agent to parse quickly. Every part of the sentence earns its place by adding specific value.
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?
Given the tool's complexity (7 parameters, likely a mutation), lack of annotations, and 0% schema description coverage, the description is incomplete. It explains the 'mode' parameter but omits details on others, behavioral traits, and usage context. The presence of an output schema mitigates the need to describe return values, but overall, the description does not provide enough information for safe and effective use, scoring as minimally adequate with clear gaps.
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 adds meaning for the 'mode' parameter by explaining its enum values (0=HORIZONTAL, 1=VERTICAL, 2=FILLED), which is valuable beyond the schema's generic integer type. However, it ignores the other 6 parameters (e.g., 'scene_path', 'node_id', 'bar_sprite_id'), leaving them undocumented. This partial coverage results in a baseline score of 3, as it provides some but insufficient semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.ProgressBar'), specifying the action of adding a progress bar component to a Cocos Creator scene. It distinguishes from siblings by focusing on progress bars, unlike tools for buttons, labels, or other UI elements. However, it doesn't explicitly differentiate from similar tools like 'cocos_add_hud_bar' or 'cocos_add_slider', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other UI components or sibling tools like 'cocos_add_hud_bar'. It lacks context about prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage based on the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool attaches a light component (implying a mutation/write operation) and explains some parameter meanings, but doesn't cover critical aspects like required permissions, whether this operation is reversible, error conditions, or what the output looks like. For a 12-parameter mutation tool, this is inadequate.
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 appropriately brief with three sentences that each add value: defining the component, providing examples, and explaining two parameters. It's front-loaded with the core purpose and wastes no words, though the formatting with backticks could be cleaner.
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?
Given the tool's complexity (12 parameters, mutation operation, no annotations) and the presence of an output schema, the description is partially complete. It explains the core purpose and some parameters but misses critical behavioral context for a mutation tool. The output schema existence means return values don't need explanation, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation. It successfully explains the semantics of two key parameters (term and light_range) that aren't obvious from their titles alone, providing meaningful context about lighting terminology and behavior. However, it doesn't cover the other 10 parameters, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool attaches a cc.SphereLight component, specifying it's a point-light with physical size and providing examples (bulb, lantern). This is a specific verb+resource combination, though it doesn't explicitly differentiate from sibling lighting tools like cocos_add_directional_light or cocos_add_spot_light.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like other light types or when not to use it. The description mentions technical details but offers no contextual usage advice for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool attaches a component and the opacity range, but it does not cover critical behaviors like whether this is a mutation (likely yes, given 'Attach'), permission requirements, error handling, or side effects. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences that directly state the tool's function and usage context without any wasted words. Every sentence earns its place by providing essential information efficiently.
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?
Given that there is an output schema (which reduces the need to describe return values) but no annotations and low parameter coverage, the description is minimally adequate. It covers the basic purpose and a key usage scenario but lacks details on behavior, parameters, and broader context, making it incomplete for effective tool selection.
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?
The input schema has 0% description coverage, and the description does not explain the parameters beyond implying 'opacity' is involved. It does not clarify what 'scene_path' or 'node_id' mean, their formats, or how they relate to the attachment process. With low schema coverage, the description fails to compensate, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Attach cc.UIOpacity (0=invisible, 255=opaque).' It specifies the verb ('Attach'), resource ('cc.UIOpacity'), and the opacity scale. However, it does not explicitly differentiate from sibling tools like 'cocos_add_component' or other UI-related tools, which prevents a perfect score.
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?
The description provides some usage context by stating 'Required for fade animations,' which implies when to use this tool. However, it does not specify when not to use it or mention alternatives, such as other UI opacity methods or sibling tools for similar effects, leaving the guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that the tool 'Returns the Widget component id,' which is a behavioral detail, but lacks critical information such as whether this operation is destructive (modifies the widget in-place), requires specific permissions, or has side effects. The description is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: the first sentence states the core purpose, followed by a brief explanation of parameters and return value. Every sentence earns its place with no wasted words, making it easy to scan and understand quickly.
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?
Given 4 parameters with 0% schema coverage and no annotations, the description partially compensates by explaining two parameters and mentioning the return value. However, as a mutation tool (implied by 'Attach'), it lacks details on behavioral traits like destructiveness or error handling. The presence of an output schema reduces the need to explain returns, but overall completeness is only adequate with clear gaps.
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 the semantics of 'horizontal' and 'vertical' parameters with an example ('horizontal=False centers only vertically, and vice versa'), adding meaning beyond the schema. However, it doesn't cover 'scene_path' or 'node_id', leaving half of the parameters undocumented. The description adds value but doesn't fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.Widget with centering flags'), specifying the action of applying centering to a widget. It distinguishes from siblings by focusing on centering rather than adding components or other operations, though it doesn't explicitly contrast with specific sibling tools like 'cocos_add_widget' or 'cocos_anchor_to_edge'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it explains the effect of setting horizontal/vertical flags but offers no explicit when-to-use advice, prerequisites, or alternatives. For example, it doesn't clarify if this should be used instead of manual positioning or other layout tools, leaving usage context largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a count, implying a read-only operation, but does not cover aspects like error handling, performance implications, or whether it requires specific permissions. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse quickly.
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?
Given the tool has an output schema (which likely defines the return value), the description does not need to explain return values. However, with no annotations, 0% schema description coverage, and a single parameter, the description is minimal but adequate for a simple counting tool. It could benefit from more context on usage or behavior to be 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?
The description does not mention the 'scene_path' parameter, and schema description coverage is 0%, meaning the parameter is undocumented in both the schema and description. However, with only one parameter, the baseline is 4, but since the description adds no semantic value beyond the schema (which lacks descriptions), it fails to compensate for the coverage gap, warranting a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Return') and resource ('total number of objects in the scene/prefab JSON array'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'cocos_list_scene_nodes' or 'cocos_get_object', which might also involve counting or listing objects, leaving room for ambiguity in sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as 'cocos_list_scene_nodes' for listing objects or other counting methods. It lacks explicit context, prerequisites, or exclusions, offering minimal usage direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool returns, not behavioral traits like whether it's read-only, safe, has side effects, rate limits, or error conditions. 'List' implies a read operation, but this isn't explicitly confirmed, and no additional context (e.g., permissions, performance) is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List every cc.Node in the scene') and details the returned fields. There's no wasted text, making it easy to parse and understand quickly.
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?
Given the tool's complexity (listing nodes in a scene), no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the purpose but lacks usage guidelines, parameter details, and behavioral context, leaving gaps for the agent to navigate.
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?
The description adds no parameter semantics beyond the input schema, which has 0% description coverage. However, with only one parameter ('scene_path'), the baseline is 4, but the description doesn't explain what 'scene_path' means (e.g., format, examples, or constraints), so it doesn't fully compensate for the schema gap, warranting a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('every cc.Node in the scene'), specifying what information is returned (id, name, parent, components, children). It distinguishes from sibling tools by focusing on listing scene nodes rather than adding/modifying them, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'cocos_find_node_by_name' or 'cocos_get_object'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation ('List'), which implies non-destructive behavior, but doesn't disclose any behavioral traits like what information is returned, format, potential errors, or performance characteristics. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple tool and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimal but adequate for basic understanding. However, with no annotations and no output schema, it fails to provide important context about what 'List' returns (e.g., format, structure, or example output), leaving significant gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of parameters. The description doesn't need to add parameter information, and it correctly doesn't mention any parameters, earning a baseline score of 4 for appropriate compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('currently running preview servers'), providing a specific verb+resource combination. It distinguishes itself from most siblings (which are 'add' or 'set' operations), though it doesn't explicitly differentiate from other list operations like 'cocos_list_assets' or 'cocos_list_scene_nodes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites, timing considerations, or relationships with other tools like 'cocos_start_preview' or 'cocos_stop_preview'. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a mutation ('Set'), but does not disclose behavioral traits like whether it requires specific permissions, if changes are reversible, or potential side effects (e.g., affecting child nodes). The z default is useful but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and includes essential parameter context (z default). There is no wasted verbiage, making it highly concise and well-structured.
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?
Given 5 parameters with 0% schema coverage and no annotations, the description is incomplete—it only addresses the z parameter's default. An output schema exists, so return values need not be explained, but for a mutation tool with undocumented parameters, more context is needed for adequate completeness.
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 adds meaning by explaining that z defaults to 0 for 2D scenes, which clarifies one parameter's behavior. However, it does not explain the semantics of other parameters like 'scene_path' or 'node_id', leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and resource 'node's local position' with specific coordinates (x, y, z), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'cocos_move_node' or 'cocos_set_node_rotation', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., 'cocos_move_node' for relative movement or 'cocos_set_node_rotation' for other transformations). It mentions a default for z in 2D scenes, but this is a parameter detail, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool sets rotation, implying a mutation, but does not cover critical aspects like whether this requires specific permissions, if changes are reversible, potential side effects, or response format. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's function without any unnecessary words. It is front-loaded and efficient, making it easy to parse quickly, which is ideal for brevity.
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?
Given the tool has an output schema (which reduces the need to describe return values) but no annotations and low parameter coverage, the description is minimally adequate. It covers the basic action but lacks details on usage, behavior, and parameter context, making it incomplete for a mutation tool in a complex environment like game development.
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?
The description adds minimal semantic context by specifying that 'angle_z' is in degrees, which clarifies the unit beyond the schema's numeric type. However, with 0% schema description coverage and three parameters, it does not explain 'scene_path' or 'node_id', leaving most parameter meanings undocumented. The baseline is adjusted due to the low coverage, but the description provides some value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('2D rotation (euler Z) in degrees'), making the purpose specific and understandable. However, it does not differentiate from sibling tools like 'cocos_set_node_position' or 'cocos_set_node_scale', which are similar transformation operations, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other transformation tools or when rotation might be applied in a game development context. There is no mention of prerequisites, constraints, or typical use cases, leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return value ('Returns the Layout component id'), which is helpful. However, it doesn't disclose whether this creates a new layout or modifies an existing one, what permissions or prerequisites are needed, whether it's destructive or read-only, or any rate limits. The behavioral context is minimal for a tool that likely modifies scene structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. Three brief sentences cover the core functionality, parameter clarification, and return value with zero wasted words. It's appropriately sized for the tool's complexity and front-loads the most important 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?
Given 5 parameters with 0% schema description coverage and no annotations, the description is incomplete. It clarifies one parameter and mentions the return value (though an output schema exists). However, it doesn't explain the tool's behavioral impact (creation vs modification, permissions needed), doesn't cover 4 of 5 parameters, and provides minimal usage context. For a scene manipulation tool, this leaves significant gaps in understanding.
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 provides valuable semantic clarification for the 'align' parameter ('``align`` here is the cross-axis: ``top``/``center``/``bottom``'), which isn't in the schema. However, it doesn't explain the other 4 parameters (scene_path, node_id, spacing, padding) or their expected formats/values. The description adds some value but doesn't fully compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'cc.Layout type=HORIZONTAL — children arrange left-to-right.' This specifies the verb (arrange children horizontally) and resource (Layout component). It distinguishes from its sibling 'cocos_stack_vertically' by specifying horizontal vs vertical arrangement. However, it doesn't explicitly mention that this creates or modifies a layout, which could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While it distinguishes from 'cocos_stack_vertically' by specifying horizontal arrangement, it doesn't mention when to choose horizontal stacking over vertical, nor does it reference other layout-related tools like 'cocos_add_layout'. No prerequisites, exclusions, or contextual usage instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a mutation ('Attach'), but doesn't disclose permissions, side effects, error handling, or what the output schema contains. The auto-wrapping note is useful but insufficient for a mutation tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: first states purpose with example, second explains auto-wrapping, third gives resource ref syntax. It's front-loaded and efficiently structured.
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?
For a mutation tool with 4 parameters, 0% schema coverage, no annotations, but an output schema exists, the description does well on parameters but lacks behavioral context (e.g., side effects, permissions). The output schema means return values needn't be explained, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds significant value: it explains 'type_name' format (full type name with example), clarifies 'props' auto-wrapping behavior (list[3]->Vec3, int->__id__ ref), and specifies resource ref syntax ({"__uuid__": "<uuid>"}). This compensates well for the schema gap, though it doesn't detail 'scene_path' or 'node_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('any cc component'), with a specific example ('cc.RigidBody2D'). It distinguishes from many sibling tools that add specific components (like 'cocos_add_rigidbody2d') by being generic, though it doesn't explicitly contrast with the generic 'cocos_add_script' or 'cocos_add_animation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many specific sibling tools (e.g., 'cocos_add_rigidbody2d' vs. using this with 'cc.RigidBody2D'). It mentions auto-wrapping for 'props', but doesn't clarify prerequisites, error conditions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that 'skinning_root_node_id' is an index from model import, which adds some context about the tool's behavior and data requirements. However, it lacks critical details: whether this is a read or write operation (likely a write since it 'Attaches'), what permissions are needed, if it modifies existing components, error conditions, or output format. For a mutation tool with 8 parameters and no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured. It uses three sentences: the first states the purpose, the second provides usage guidelines, and the third clarifies a key parameter. Each sentence adds value without redundancy, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no annotations, but an output schema exists), the description is incomplete. It covers purpose and one parameter but misses behavioral transparency for a likely mutation tool, does not explain most parameters, and relies on the output schema for return values. For a tool with many parameters and no annotations, more guidance on usage, prerequisites, and error handling is needed to be fully helpful.
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 description coverage is 0%, so the description must compensate. It only explains one parameter ('skinning_root_node_id') in detail, clarifying it's a scene-array index and not a UUID. The other 7 parameters (e.g., 'scene_path', 'node_id', 'mesh_uuid') are not mentioned, leaving their purposes and relationships unclear. With low coverage, the description adds minimal value beyond the schema, failing to adequately document the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Attach cc.SkinnedMeshRenderer — MeshRenderer driven by a skeleton.' It specifies the verb ('Attach'), resource ('cc.SkinnedMeshRenderer'), and provides a technical definition. However, it does not explicitly differentiate from sibling tools like 'cocos_add_mesh_renderer', which might be a similar but non-skinned alternative, leaving room for improvement in sibling distinction.
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?
The description provides clear context on when to use this tool: 'Use this for humanoid/animal characters imported from GLTF/FBX.' This gives specific use cases and file formats. However, it does not mention when not to use it or name alternatives among the many sibling tools, such as 'cocos_add_mesh_renderer' for non-skinned meshes, which could help avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions a prerequisite but does not disclose behavioral traits such as whether this operation is destructive (e.g., overwrites existing components), requires specific permissions, or has side effects like modifying scene state. The description is minimal and lacks critical behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with zero waste. It front-loads the core action and immediately provides essential prerequisite information, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, mutation operation, no annotations) and the presence of an output schema (which may cover return values), the description is incomplete. It lacks parameter explanations, behavioral details, and context about when to use versus siblings, making it inadequate for safe and effective use despite the output schema.
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 description coverage is 0%, so the description must compensate. It does not explain any of the 7 parameters (e.g., what 'scene_path' or 'node_id' refer to, the purpose of 'skeleton_data_uuid', or how 'default_skin' works). The mention of 'sp.Skeleton (Spine)' hints at the resource but adds no parameter-specific semantics beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach sp.Skeleton (Spine)') and resource (a Spine skeleton to a node), distinguishing it from general 'add' tools. However, it does not explicitly differentiate from sibling tools like 'cocos_add_dragonbones' (another animation system) beyond the Spine-specific reference.
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?
The description provides explicit prerequisite guidance ('Use cocos_add_spine_data to import assets first'), which is crucial for correct usage. It does not specify when to use this tool versus alternatives like 'cocos_add_animation' or 'cocos_add_dragonbones', but the prerequisite context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns the Widget component id,' which adds some context about the output. However, it does not describe critical behaviors such as whether this operation is destructive (modifies the node permanently), requires specific permissions, has side effects (e.g., affecting other components), or handles errors (e.g., invalid edge values). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured. It uses a single sentence to state the purpose, followed by bullet-like explanations for parameters and the return value, with zero wasted words. Each part earns its place by providing essential information efficiently.
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?
Given the tool's complexity (a mutation operation with 4 parameters) and the presence of an output schema (which likely covers the return value), the description is partially complete. It explains key parameters but misses details on 'scene_path' and 'node_id', and lacks behavioral context (e.g., safety, errors). With no annotations and incomplete parameter coverage, it is adequate but has clear gaps, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 for the lack of schema details. It effectively explains the 'edge' parameter by listing all possible string values (e.g., 'top', 'bottom-left') and clarifies 'margin' as 'distance from the edge (from both edges for corners).' This adds crucial semantic meaning beyond the schema's basic titles and types. However, it does not cover 'scene_path' or 'node_id', leaving two parameters undocumented, which slightly reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Pin node to an edge / corner of its parent via cc.Widget.' This specifies the action ('pin'), resource ('node'), and mechanism ('via cc.Widget'), making it understandable. However, it does not explicitly distinguish this tool from its many siblings (e.g., 'cocos_center_in_parent', 'cocos_move_node'), which handle related UI positioning tasks, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites (e.g., that the node must have a parent or support cc.Widget), exclusions, or comparisons with sibling tools like 'cocos_center_in_parent' or 'cocos_set_node_position'. This lack of context leaves the agent to infer usage based on the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the tool returns a Layout component id, which is useful, but doesn't disclose critical behavioral traits: whether this creates a new node or modifies an existing one, what permissions or scene state are required, if it's idempotent, or how errors are handled. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: the first sentence states the purpose, followed by bullet-like explanations of parameters. Every sentence adds value with no wasted words, making it easy to scan and understand quickly.
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?
Given the tool has 5 parameters (2 required, 3 optional) with 0% schema coverage and no annotations, but an output schema exists, the description is partially complete. It covers the optional parameters well and mentions the return value, but omits semantics for the required parameters and lacks behavioral context needed for a mutation tool in a UI framework.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 effectively explains three optional parameters (spacing, padding, align) with details on accepted values (design-token names or raw pixels for spacing/padding, alignment options). However, it doesn't cover the two required parameters (scene_path, node_id), leaving their purpose and format undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a vertical layout component ('cc.Layout type=VERTICAL — children arrange top-to-bottom'), which is a specific verb+resource combination. It distinguishes from the sibling 'cocos_stack_horizontally' by specifying vertical arrangement, though it doesn't explicitly mention other layout-related siblings like 'cocos_add_layout'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites (e.g., needing a scene and node), compare with 'cocos_add_layout' or other layout tools, or specify typical use cases for vertical stacking in UI design.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the tool performs navigation, sleeping, and closing actions, but doesn't specify whether this opens/closes browser windows/tabs, what happens on timeout, if it requires specific permissions, or what side effects occur. For a tool with 5 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two brief sentences that efficiently communicate the core functionality and use case. Every word earns its place, and the information is front-loaded with the key actions followed by the specific utility context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It covers the basic purpose and one parameter's role but doesn't explain the other parameters' purposes, what the tool returns, error conditions, or detailed behavioral expectations. The context signals indicate high complexity that the description doesn't adequately address.
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 description coverage is 0%, so the description must compensate for all 5 parameters. It only mentions 'sleep ``ms``' which corresponds to one parameter, leaving the other 4 parameters (url, viewport dimensions, timeout) completely undocumented in both schema and description. The description adds minimal value beyond what's implied by parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs (navigate, sleep, close) and identifies its utility for letting async asset loading finish between build and screenshot operations. It distinguishes itself from sibling tools by focusing on preview waiting rather than asset creation or scene manipulation, though it doesn't explicitly name alternatives.
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?
The description provides clear context for when to use this tool ('useful between a build and a screenshot to let async asset loading finish'), giving a specific scenario. However, it doesn't explicitly state when not to use it or name alternative tools for similar purposes, leaving some guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions attaching a rigid body but doesn't explain if this is a destructive operation, what permissions are needed, how it affects the scene, or error conditions. The focus on parameter semantics leaves behavioral traits largely unaddressed.
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 main purpose, followed by essential parameter details in a compact format. It avoids unnecessary fluff, but the lack of structure (e.g., bullet points or clearer separation) slightly reduces readability, though it remains efficient.
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?
For a tool with 15 parameters, no annotations, and an output schema (which reduces the need to describe return values), the description is moderately complete. It covers critical parameter semantics but misses behavioral context, usage guidelines, and broader integration details, leaving gaps in overall understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage and 15 parameters, the description adds significant value by explaining key parameters like body_type (with enum values and a warning about bitmask vs. contiguous indexing) and linear/angular_factor (with axis-locking behavior). This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.RigidBody (3D)'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'cocos_add_rigidbody2d' or other physics-related tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as the 2D version or other physics components. It lacks context about prerequisites, typical use cases, or exclusions, offering only technical parameter details without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 idempotency, which is a key behavioral trait not obvious from the schema. However, it lacks details on permissions, side effects (e.g., whether it modifies project files), error handling, or response format. This leaves gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a concise behavioral note. Both sentences earn their place by adding value (action and idempotency) with zero waste, making it highly efficient.
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?
Given 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers the basic action and idempotency but misses parameter details, error cases, and output expectations. For a mutation tool in a complex environment (Cocos), this leaves significant gaps for an agent.
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 description coverage is 0%, so the schema provides no parameter details. The description adds minimal semantics: it mentions 'UUID' for 'scene_uuid' and implies 'project_path' relates to 'project settings', but doesn't explain what these parameters represent (e.g., file paths, format, constraints). This insufficiently compensates for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Add') and resource ('scene to the includedScenes list in project settings'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'cocos_set_start_scene' or 'cocos_create_scene', which might involve scene management in different ways.
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?
The description implies usage by mentioning idempotency ('skips if the UUID is already included'), which suggests it's safe for repeated calls. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., vs. 'cocos_set_start_scene' for setting a startup scene), nor does it mention prerequisites like project state or scene existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'Attach', implying a mutation operation, but doesn't disclose behavioral traits like permissions needed, side effects, error conditions, or what the output schema contains. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that are front-loaded and waste no words. Every sentence earns its place by stating the purpose and providing a key usage guideline.
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?
Given the tool has an output schema (which reduces the need to explain return values) but no annotations and 0% schema description coverage, the description is incomplete. It covers the basic purpose and a prerequisite but misses critical details about parameters, behavior, and context, making it only minimally viable.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It adds no meaning beyond the schema, failing to explain what 'scene_path', 'node_id', or 'tmx_asset_uuid' represent or how they should be used. This leaves all three parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('cc.TiledMap component'), making the purpose specific. However, it doesn't explicitly distinguish this tool from its sibling 'cocos_add_tiled_map_asset' beyond mentioning it as a prerequisite, leaving some ambiguity about their distinct roles.
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?
The description provides clear context by specifying a prerequisite ('Use cocos_add_tiled_map_asset to import first'), which helps guide when to use this tool. It doesn't explicitly state when not to use it or compare it to other alternatives, but the prerequisite is a strong usage hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that 'steps' helps if Cocos isn't picking up the drag, which adds some behavioral context. However, it doesn't disclose critical traits like whether this tool simulates a drag in a preview environment, potential side effects (e.g., UI state changes), error conditions, or response behavior, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the core action, and the second provides specific guidance on a key parameter. Every sentence adds value without redundancy, making it easy to parse and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no annotations, no output schema), the description is incomplete. It only addresses one parameter ('steps') in depth and lacks information on the tool's overall behavior, return values, error handling, and most parameter meanings. This is inadequate for a tool with many parameters and no structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 'steps' in detail, including its purpose (intermediate move events), troubleshooting advice, and a typical value (5). However, it doesn't cover other parameters like 'url', 'button', 'wait_ms', etc., leaving 10 out of 11 parameters without semantic clarification beyond their titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Drag the mouse') and specifies the coordinates, making the purpose evident. However, it doesn't explicitly differentiate this tool from sibling tools like 'cocos_click_preview' or 'cocos_move_node', which might involve similar UI interactions in the Cocos context.
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?
The description implies usage for dragging in UI elements like sliders or cards, and suggests adjusting 'steps' if Cocos doesn't pick up the drag. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other interaction tools in the sibling list) or any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the tool sets a reference and allows clearing it, but does not disclose behavioral traits such as permissions needed, whether it's destructive (e.g., overwrites existing properties), error handling, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with two sentences that directly state the tool's purpose and a key usage note. There is no wasted language, and every sentence adds value, making it efficient and easy to parse.
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?
Given the tool has 4 parameters with 0% schema coverage and no annotations, but an output schema exists, the description is incomplete. It explains the core function and one parameter's special case, but lacks details on other parameters, behavioral context, and error handling. The output schema may cover return values, but the description does not compensate for the missing parameter and behavioral information adequately.
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 description coverage is 0%, so the schema provides no parameter descriptions. The description adds some semantics by explaining that 'target_id' can be set to 'None' to clear a reference, which clarifies one parameter's purpose. However, it does not explain the other three parameters ('scene_path', 'component_id', 'prop_name'), leaving them undocumented and unclear in meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set a @property on a component to reference another node/component.' It specifies the verb ('Set'), resource ('@property on a component'), and action ('reference another node/component'), making it easy to understand. However, it does not explicitly differentiate from sibling tools like 'cocos_set_property' or 'cocos_set_uuid_property', which may have overlapping or similar functions, so it misses full distinction.
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?
The description provides clear context on when to use this tool: for setting references between nodes/components, and specifically notes 'Pass `target_id=None` to clear the reference,' which indicates a use case for clearing references. It does not explicitly mention when not to use it or name alternatives among siblings, but the guidance is sufficient for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 behavioral traits such as the meaning of 'env_lighting_type' values and how to clear or leave 'envmap_uuid' unchanged, which adds useful context. However, it does not cover other parameters like 'enabled' or 'use_hdr', and lacks details on permissions, side effects, or response format, leaving gaps in behavioral understanding.
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 appropriately sized and front-loaded, starting with the main purpose and then detailing specific parameters. Each sentence adds value without redundancy, though it could be slightly more structured (e.g., bullet points) for clarity.
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?
Given the complexity (5 parameters, no annotations, no output schema), the description is partially complete. It explains some parameter semantics but omits others like 'enabled' and 'use_hdr', and does not describe the return value or error handling. It meets a minimum viable level but has clear gaps in coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the semantics of 'env_lighting_type' (with enum-like details) and 'envmap_uuid' (clear vs. leave unchanged). It does not cover 'scene_path', 'enabled', or 'use_hdr', but adds significant value for two key parameters, justifying a score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Configure') and target resource ('scene's cc.SkyboxInfo'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'cocos_set_ambient' or 'cocos_set_fog', which also configure scene properties, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied context by explaining the 'env_lighting_type' options and 'envmap_uuid' behavior, but it does not explicitly state when to use this tool versus alternatives (e.g., other skybox-related tools if any) or any prerequisites. There is no guidance on exclusions or specific scenarios for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that this is an animation tool that runs 'at scene start' and returns specific identifiers (clip_uuid, clip_path, anim_component_id), which is useful. However, it lacks details on permissions, error handling, or side effects (e.g., whether it modifies the node permanently). The description adds some behavioral context but is incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured. It uses three sentences: one for the core purpose, two for parameter examples, and one for return values. Each sentence adds essential information without redundancy, making it easy to parse quickly.
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?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description is partially complete. It covers the animation effect and return values but lacks details on parameter usage, error conditions, and behavioral nuances. For a tool that likely modifies scene state, more context on side effects or prerequisites would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 the semantics of `from_scale` with examples (0 and 0.5), which clarifies its role in the animation. However, it doesn't cover other parameters like `scene_path`, `node_id`, `duration`, `delay`, or `rel_dir`. The description adds meaningful value for one parameter but leaves others undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Pop a node in from `from_scale` to 1.0 at scene start.' It specifies the action (pop-in animation), resource (node), and effect (scale transition). However, it doesn't explicitly differentiate from sibling tools like 'cocos_add_fade_in' or 'cocos_add_slide_in', which likely serve similar animation purposes but with different effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It explains the effect of `from_scale` values (0 and 0.5) but doesn't indicate when to use this tool versus other animation tools (e.g., for scale effects vs. fade effects) or mention prerequisites like scene setup. No explicit alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that the tool attaches a scroll bar and provides some behavioral details like parameter usage and the 'link_property' alternative. However, it lacks critical information such as whether this is a read-only or destructive operation, permission requirements, error handling, or rate limits. The description adds some context but is insufficient for a mutation tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the first sentence stating the core purpose. Subsequent sentences efficiently explain key parameters and alternatives without unnecessary details. Every sentence adds value, making it concise and well-structured.
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?
Given the complexity (7 parameters, no annotations, but has output schema), the description is partially complete. It explains the tool's purpose and some parameters but misses details on behavioral traits and several parameters. The presence of an output schema means return values are documented elsewhere, but for a tool with mutation implications and low schema coverage, the description should do more to guide usage and clarify behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 adds meaningful semantics for three parameters: 'direction' (with values 0=HORIZONTAL, 1=VERTICAL), 'scroll_view_id', and 'handle_sprite_id', explaining their purposes and usage. However, it does not cover the other four parameters ('scene_path', 'node_id', 'enable_auto_hide', 'auto_hide_time'), leaving gaps in understanding. The description provides valuable insights but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Attach cc.ScrollBar — companion scroll indicator for a ScrollView.' It specifies the verb ('Attach'), resource ('cc.ScrollBar'), and context ('companion scroll indicator for a ScrollView'). However, it does not explicitly differentiate from sibling tools like 'cocos_add_scroll_view', which might be related but serves a different function.
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?
The description implies usage by mentioning it's a 'companion scroll indicator for a ScrollView', suggesting it should be used with a ScrollView. It also hints at alternatives: 'Pass ``scroll_view_id`` + ``handle_sprite_id`` to wire both references at attach time; otherwise set later via link_property.' This indicates when to use certain parameters but does not explicitly state when to use this tool versus other UI or scroll-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool does (attaching a sprite with specific parameters) but lacks critical behavioral details: it doesn't mention whether this is a mutation (likely yes, but not stated), what permissions are needed, error conditions, or what the output contains. The description adds some context about parameter interactions (e.g., color_preset overrides RGBA), but overall behavioral disclosure is insufficient for a tool with 9 parameters and no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: a clear purpose statement followed by bullet-like explanations of specific parameters. Every sentence adds value, with no wasted words. It's front-loaded with the main action and efficiently addresses complex parameter semantics.
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?
Given the complexity (9 parameters, 0% schema coverage, no annotations) and the presence of an output schema (which reduces need to describe returns), the description is partially complete. It explains some parameter semantics well but misses behavioral context (mutation effects, error handling) and doesn't cover all parameters. For a tool with this many inputs and no annotations, more comprehensive guidance would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 provides meaningful explanations for three key parameters: sprite_frame_uuid (format and sources), size_mode (enum values 0-2 with meanings), and color_preset (purpose and effect). This adds significant value beyond the bare schema, though it doesn't cover all 9 parameters (e.g., scene_path, node_id, color RGBA components remain unexplained in the description).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach a cc.Sprite to a node') and specifies the resource (a sprite). It distinguishes from some siblings like 'cocos_add_filled_sprite' or 'cocos_add_sliced_sprite' by focusing on general sprite attachment, but doesn't explicitly differentiate from all similar tools in the extensive list.
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?
The description implies usage by referencing other tools ('cocos_add_image' or 'cocos_get_sprite_frame_uuid') for obtaining the sprite_frame_uuid, suggesting when to prepare inputs. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'cocos_add_filled_sprite' or other sprite-related tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: the duplication is shallow (no children/components), it returns a new node index, and it's a mutation operation (implied by 'duplicate'). However, it lacks details on permissions, error handling, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core action. Every word earns its place, with no wasted text, making it easy to parse quickly.
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?
Given the tool's moderate complexity (mutation with 3 parameters), no annotations, and an output schema (implied by 'Returns new node index'), the description is minimally adequate. It covers the basic operation and output but lacks details on parameters, error cases, and behavioral nuances.
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 description coverage is 0%, so the description must compensate. It adds no parameter semantics beyond what the schema provides (scene_path, node_id, new_name). No explanation of what these parameters mean or how they affect the duplication is given.
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 clearly states the specific action ('shallow-copy a node'), resource ('node'), and scope ('no children/components'), distinguishing it from sibling tools like 'cocos_create_node' or 'cocos_instantiate_prefab' which likely create new nodes or prefabs with different behaviors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'cocos_create_node' or 'cocos_instantiate_prefab' is provided. The description implies usage for duplicating nodes without children/components, but lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions it 'Builds a cc.EventHandler dict,' implying it creates a data structure, but does not disclose behavioral traits such as whether this is a read-only or mutating operation, any side effects, permissions needed, or error handling. For a tool with 5 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by specific usage examples and a comparison to a sibling tool. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It explains the tool's purpose and usage context but lacks details on parameters, behavioral traits, and return values. For a tool that builds event handlers in a game development context, more information is needed to use it effectively, especially with zero schema coverage.
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 description coverage is 0%, so the schema provides no parameter descriptions. The description does not explain any of the 5 parameters (e.g., what 'scene_path', 'target_node_id', 'component_name', 'handler', or 'custom_data' mean or how to use them). It only mentions the tool's purpose and usage context, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Build a cc.EventHandler dict for component event bindings.' It specifies the verb ('Build'), resource ('cc.EventHandler dict'), and context ('for component event bindings'). However, it does not explicitly differentiate from all siblings, though it mentions 'Same pattern as cocos_make_click_event but for non-Button components,' which helps distinguish from that specific sibling but not others like 'cocos_add_button'.
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?
The description provides explicit usage guidelines: it lists specific tools to use with (e.g., 'cocos_add_scroll_view(scroll_events=[...])') and clarifies when to use it versus alternatives by stating 'Same pattern as cocos_make_click_event but for non-Button components.' This gives clear context on when to use this tool versus the sibling 'cocos_make_click_event' and other event-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 key behavioral traits: it's a soft-delete (not permanent), involves disconnecting from parent and deactivating, and maintains stable indices. However, it lacks details on permissions, reversibility, or error conditions, which are important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences with zero wasted words. It front-loads the core action ('Soft-delete a node') and adds clarifying details efficiently. Every sentence earns its place by providing essential 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?
Given the tool's complexity (a mutation with 2 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is moderately complete. It covers the core behavior but misses parameter explanations and usage context, leaving gaps for an agent to infer.
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 schema provides no parameter details. The description doesn't explain what 'scene_path' or 'node_id' represent, their formats, or constraints. It adds no semantic value beyond the schema's property names, but the baseline is 3 due to only 2 parameters.
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 clearly states the action ('Soft-delete a node') and specifies what that entails ('disconnect from parent, deactivate'), distinguishing it from siblings like 'cocos_remove_post_build_patches' or 'cocos_set_node_active'. It explicitly defines the operation as a soft-delete, not a permanent removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites, such as whether the node must exist or be active, or compare it to other deletion-related tools in the sibling list. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 return structure and some behavioral details (grouping by type, minimum fields, conditional 'sprite_frame_uuid' for images). However, it doesn't mention whether this is a read-only operation, potential performance impacts, or error conditions. The description adds useful context but leaves 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by details about the return structure. There's minimal waste, though the second sentence could be slightly more structured. Overall, it's efficient and clear.
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?
Given the tool's low complexity (single parameter, no annotations, no output schema), the description is reasonably complete. It explains what the tool does and the return format in detail, which compensates for the lack of output schema. However, it misses parameter semantics and some behavioral aspects, keeping it from a perfect score.
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?
The input schema has 1 parameter with 0% description coverage. The tool description doesn't mention the 'project_path' parameter at all, providing no additional semantic meaning beyond what the schema's title suggests. Since schema coverage is low, the description fails to compensate, but with only one parameter, the baseline remains at 3 as the impact is limited.
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 clearly states the tool's purpose: 'List all assets in the project grouped by type, with their UUIDs.' This specifies the verb ('List'), resource ('assets'), and scope ('in the project'), and distinguishes it from sibling tools that are primarily 'add' operations rather than listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites, context for usage, or differentiate from other listing tools like 'cocos_list_scene_nodes' or 'cocos_list_tools' that might serve similar inventory purposes. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a mutation ('Set'), but does not specify whether this requires specific permissions, if changes are reversible, what happens to existing layer settings, or any side effects like performance impacts. The mention of 'Common' layer values adds some context but falls short of explaining the tool's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose followed by helpful examples. Every word serves a clear purpose, with no redundant or unnecessary information, making it easy to parse quickly.
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?
Given the tool's moderate complexity (3 parameters, mutation operation) and the presence of an output schema (which reduces the need to describe return values), the description is partially complete. It covers the core action and provides layer examples, but lacks details on behavioral aspects, usage context, and full parameter semantics, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation. It clarifies the 'layer' parameter by providing common examples (UI_2D=33554432, DEFAULT=1073741824), which adds meaningful semantics beyond the schema's basic type. However, it does not explain 'scene_path' or 'node_id', leaving two of the three parameters without additional context.
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 clearly states the specific action ('Set a node's layer bitmask') and resource ('node'), distinguishing it from sibling tools like 'cocos_set_node_position' or 'cocos_set_node_active' which modify different node properties. It provides concrete examples of layer values (UI_2D=33554432, DEFAULT=1073741824), making the purpose highly specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, such as other node-setting tools or how layer bitmasks interact with other Cocos features. It lacks context about prerequisites, like whether the node must exist or be in a specific state, and does not mention any exclusions or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the tool creates an animation (implied mutation) and returns specific identifiers ({clip_uuid, clip_path, anim_component_id}), which is useful behavioral context. However, it doesn't cover error conditions, side effects (e.g., if it modifies existing animations), or performance implications, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three focused sentences: first states the purpose, second provides tuning guidelines, third specifies return values. Each sentence adds value without redundancy, and it's front-loaded with the core functionality.
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?
Given 6 parameters with 0% schema coverage and no output schema, the description partially compensates by explaining two key parameters and the return format. However, as a mutation tool with no annotations, it lacks details on error handling, side effects, and the semantics of undocumented parameters, making it incomplete for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 adds meaningful semantics for 'overshoot' (tuning range 1.05-1.3, effects of values) and 'duration' (default 0.5s, adjustment for UI vs. games), covering 2 of 6 parameters well. However, it doesn't explain 'scene_path', 'node_id', 'delay', or 'rel_dir', leaving half the parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a 'spring-like overshoot' entrance animation (specific verb+resource), distinguishing it from siblings like 'cocos_add_fade_in' or 'cocos_add_scale_in'. However, it doesn't explicitly contrast with all sibling animation tools, leaving some ambiguity about when to choose bounce over other entrance effects.
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?
The description provides implied usage guidance by suggesting default values (0.5s duration for UI, halve for games) and tuning ranges for 'overshoot', which helps inform when to adjust parameters. However, it lacks explicit when-to-use vs. alternatives (e.g., compared to 'cocos_add_pulse' or other animation siblings) and doesn't mention prerequisites like required scene or node setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes what the tool creates (a HUD bar) and its positioning behavior (pinned to top/bottom), but doesn't disclose important behavioral traits like whether this is a read-only or mutating operation, what permissions are needed, error conditions, or how it interacts with the scene. The mention of default configuration adds some context, but key behavioral aspects remain undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections: purpose statement, items parameter details, default configuration, and side parameter explanation. Every sentence adds value with no wasted words. The technical details are presented in a readable format with appropriate line breaks and code formatting for the items structure.
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?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description provides good coverage of the items parameter but leaves other parameters unexplained. It doesn't describe what the tool returns or how errors are handled. For a tool that presumably creates UI elements in a game engine context, more information about integration with the scene system would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It provides excellent semantic information for the 'items' parameter (detailing the structure of label and spacer objects with their properties) and explains the 'side' parameter options. However, it doesn't explain the purpose of 'scene_path', 'parent_node_id', or 'height' parameters, leaving 3 of 5 parameters without semantic clarification in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a horizontal HUD bar pinned to top or bottom, specifying the resource (HUD bar) and action (build). It distinguishes from siblings by focusing on HUD bar creation rather than other UI elements like buttons or labels. However, it doesn't explicitly contrast with similar layout tools like 'cocos_add_layout' or 'cocos_add_widget'.
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?
The description implies usage for creating HUD bars in games, mentioning 'good for endless-runner style games' as a default configuration. It provides some context about when the default configuration is appropriate but doesn't explicitly state when to use this tool versus alternatives like 'cocos_add_layout' or 'cocos_add_widget' for similar UI positioning tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses critical behavioral traits: the convex parameter requirement based on rigid body dynamics and backend limitations. However, it lacks details on permissions, error conditions, or what happens on attachment (e.g., overwriting existing colliders). The information is useful but incomplete for a mutation tool.
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 core purpose, followed by important usage notes. It uses two concise sentences with no fluff, though the formatting with backticks and dashes could be slightly cleaner. Every sentence adds value, making it efficient.
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?
Given 8 parameters with 0% schema coverage, no annotations, and an output schema (which alleviates need to describe returns), the description is incomplete. It covers the convex parameter well and provides critical physics context, but misses semantics for other parameters and broader behavioral details like error handling or side effects, leaving gaps for a complex tool.
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 description coverage is 0%, so the description must compensate. It only explains the 'convex' parameter's semantics and implications, ignoring the other 7 parameters (scene_path, node_id, mesh_uuid, center_x/y/z, is_trigger). This leaves most parameters undocumented, failing to adequately address the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach cc.MeshCollider') and identifies the specific resource (a mesh collider component). It distinguishes from siblings like 'cocos_add_box_collider_3d' by specifying mesh-based collision. However, it doesn't explicitly contrast with all sibling collider tools, keeping it from a perfect score.
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?
The description provides explicit usage guidance with 'IMPORTANT' notes on when to set convex=True (for DYNAMIC rigid bodies) vs convex=False (for static ground geometry). It directly addresses physics backend constraints (PhysX/Bullet) and differentiates based on body type, offering clear when-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 key behaviors: it writes files (a mutation), returns specific data (path, rel_path, uuid), and notes UUID format details. However, it lacks information on permissions, error handling, or side effects, which are important for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by specific details on parameters and return values. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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?
Given no annotations, no output schema, and 0% schema coverage, the description does a decent job by covering the tool's action, parameter usage, and return data. However, for a mutation tool with three parameters, it lacks details on error cases, validation, or integration with other tools, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds significant meaning for 'rel_path' by explaining its two formats and default behavior, and it implies 'source' as the script content. While 'project_path' is not detailed, the overall clarity on parameters is strong, though not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write a TypeScript script + its meta') and resource ('into the project'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'cocos_add_and_attach_script', which might have overlapping functionality, so it falls short of a perfect score.
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?
The description implies usage by detailing how 'rel_path' works and mentioning a sibling tool ('cocos_compress_uuid') for UUID conversion, but it does not explicitly state when to use this tool versus alternatives like 'cocos_add_and_attach_script' or provide clear exclusions. This leaves some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states the tool returns constants, implying it's a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, or what format the return values take. The description adds some context about the types of constants (e.g., layer bitmasks), but lacks details on output structure or potential side effects. With no annotations, this is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: two sentences that directly state the purpose and benefit. Every sentence earns its place by clarifying the tool's function and utility without any redundant information. It's front-loaded with the main action and efficiently uses examples to illustrate scope.
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?
Given the tool has no parameters, no annotations, and no output schema, the description provides basic completeness by stating what constants are returned and why to use it. However, it lacks details on the return format, potential errors, or how the constants are structured (e.g., as a list, dictionary, or specific data types). For a tool with zero structured data, the description is adequate but leaves gaps in behavioral and output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't mention any parameters, which is appropriate since none are required. It adds value by explaining what constants are returned (e.g., layer bitmasks), but since there are no parameters, the baseline is 4 as it compensates for the lack of parameter documentation with semantic context about the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return commonly used Cocos Creator constants.' It specifies the resource (Cocos Creator constants) and provides examples (layer bitmasks, blend factors, alignment enum values), which helps distinguish it from sibling tools that perform actions like adding components or building projects. However, it doesn't explicitly differentiate from potential sibling tools that might also return constants, though none are listed.
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?
The description implies usage context: 'Saves you from looking up layer bitmasks, blend factors, alignment enum values, etc.' This suggests it should be used when needing these constants to avoid manual lookup. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., if other tools provide similar constants or if there are specific scenarios where it's preferred). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the return behavior ('Returns its array index, or None'), which is helpful, but lacks details on error handling (e.g., what happens if the scene_path is invalid), performance implications, or whether this is a read-only operation. The description does not contradict annotations, but it is insufficient for a mutation-sensitive context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the purpose and outcome. Every word earns its place, and it is front-loaded with the main action. No unnecessary details or fluff are present.
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?
Given that there is an output schema (which should detail the return structure), the description does not need to explain return values. However, for a tool with 2 parameters and no annotations, the description could provide more context on parameter usage and behavioral traits. It is mostly complete but lacks depth in parameter semantics and behavioral transparency.
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?
The schema description coverage is 0%, so the schema provides no parameter descriptions. The description does not add any meaning to the parameters 'scene_path' and 'name' beyond what their titles imply. It mentions 'given name' which hints at the 'name' parameter, but does not explain what 'scene_path' is or the format expected. Baseline is 3 due to 0% coverage, but the description does not compensate adequately.
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 clearly states the specific action ('Find the first node'), target resource ('with the given name'), and outcome ('Returns its array index, or None'). It distinguishes itself from sibling tools like 'cocos_list_scene_nodes' (which lists all nodes) by focusing on finding a specific node by name.
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?
The description implies usage when you need to locate a node by name in a scene, but it does not explicitly state when to use this tool versus alternatives like 'cocos_get_object' or 'cocos_list_scene_nodes'. No exclusions or prerequisites are mentioned, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the tool lazy-creates a cc.FogInfo and links it if missing, which is useful behavioral context. It also mentions atmospheric settings are inter-dependent, hinting at constraints. However, it doesn't cover critical aspects like whether this is a read/write operation, error handling, or side effects beyond creation, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose, followed by context and parameter details. Every sentence adds value—no fluff or repetition. It's efficiently structured for quick understanding.
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?
Given the tool's complexity (14 parameters, mutation operation) and lack of annotations/output schema, the description is partially complete. It explains key parameters and behavioral traits but misses details on return values, error cases, and full parameter semantics. It's adequate for basic use but has clear gaps for advanced scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 adds significant meaning by explaining fog_type values (0=LINEAR, etc.) and their dependencies (e.g., LINEAR ignores density). This clarifies parameter interactions beyond the bare schema. However, it doesn't cover all 14 parameters (e.g., color components, atten, accurate), so it's not fully comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Configure volumetric fog on the scene's cc.FogInfo.' It specifies the verb ('configure') and resource ('volumetric fog'), and distinguishes it from siblings by mentioning it's the 'fourth scene-global alongside ambient/skybox/shadows.' However, it doesn't explicitly differentiate from all sibling tools, just contextualizes within a category.
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?
The description implies usage by stating it's for configuring fog and lazy-creates a cc.FogInfo if missing, which suggests when to use it (when fog needs setup). It mentions atmospheric settings are inter-dependent, hinting at parameter relationships. However, it lacks explicit guidance on when to use this vs. alternatives (e.g., other fog-related tools if any) or prerequisites, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that 'props' sets '@property fields' and describes value handling, but it does not disclose critical behavioral traits such as whether this is a mutation (likely yes), error conditions, permissions needed, or side effects. The description adds some context but is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by focused explanations for key parameters. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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?
Given the tool's complexity (4 parameters, 0% schema coverage, no annotations) and the presence of an output schema (which reduces need to explain return values), the description is partially complete. It covers parameter semantics for two parameters but lacks behavioral transparency and full parameter documentation, leaving gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining 'script_uuid_compressed' (23-char short form from 'cocos_compress_uuid') and 'props' (sets @property fields with specific value types). It adds meaningful semantics beyond the schema, though it does not cover 'scene_path' or 'node_id' parameters, which remain undocumented.
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 clearly states the specific action ('Attach a custom TypeScript script component to a node'), identifies the resource ('node'), and distinguishes it from siblings like 'cocos_add_script' (which likely creates a script) and 'cocos_add_component' (which is more generic). The verb 'attach' is precise and differentiates it from creation or addition operations.
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?
The description implies usage by mentioning 'script_uuid_compressed' and referencing 'cocos_compress_uuid', but it does not explicitly state when to use this tool versus alternatives like 'cocos_add_script' or 'cocos_add_component'. It provides context for parameter preparation but lacks explicit guidance on tool selection or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 describes the transformation behavior (23-char to 36-char dashed), but does not disclose error handling, input validation, performance characteristics, or other behavioral traits like whether it's idempotent or has 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded with the core purpose and includes essential details (input/output lengths and format). Every word earns its place.
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?
Given the tool's low complexity (single parameter, simple transformation) and the presence of an output schema (which likely defines the 36-char dashed UUID output), the description is adequate. However, with no annotations and 0% schema coverage, it lacks details on error cases or edge behaviors that would be helpful for robust use.
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 implies the parameter is a '23-char short' UUID, adding meaning beyond the schema's generic 'string' type. However, it does not detail format constraints, examples, or validation rules for the short UUID.
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 clearly states the tool's function: it reverses cocos_compress_uuid, transforming a 23-character short UUID into a 36-character dashed UUID. This is specific (verb: 'reverse', resource: 'cocos_compress_uuid'), and it distinguishes from sibling tools by referencing the specific sibling 'cocos_compress_uuid'.
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?
The description explicitly states when to use this tool: to reverse cocos_compress_uuid. It implies usage context by referencing the sibling tool, but does not specify when not to use it or alternatives beyond that sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively discloses key behavioral traits: it's a read-only operation (implied by 'return'), always returns a complete theme, handles fallback scenarios ('un-themed projects get the dark_game default'), and explains the 'source' field values ('registry' vs 'fallback'). This covers most essential aspects for a retrieval tool, though it lacks details on error handling or performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: two short sentences that front-load the core purpose and follow with essential behavioral details. Every sentence adds value without any wasted words, making it easy for an AI agent to parse quickly.
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?
Given the tool's moderate complexity (retrieval with fallback logic), no annotations, no output schema, and 0% schema description coverage, the description is adequate but has gaps. It explains what's returned and fallback behavior but doesn't describe the output format, error conditions, or the single parameter. This meets minimum viability but isn't fully comprehensive.
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?
The input schema has 1 parameter with 0% description coverage. The description doesn't mention the 'project_path' parameter at all, so it adds no semantic meaning beyond what the schema provides. However, since there's only one parameter and its purpose is somewhat inferable from context, this meets the baseline for minimal viability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return the project's active UI theme (fully resolved).' It specifies the verb ('return'), resource ('UI theme'), and scope ('fully resolved'). However, it doesn't explicitly differentiate from sibling tools like 'cocos_set_ui_theme' or 'cocos_list_builtin_themes', which would be needed for a score of 5.
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?
The description implies usage context by stating 'Always returns a complete theme' and explaining fallback behavior for un-themed projects, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'cocos_set_ui_theme' or 'cocos_list_builtin_themes'. The guidelines are implied rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the tool configures physics settings and mentions a default gravity value, which is useful behavioral context. However, it lacks details on permissions needed, whether changes are reversible, or any rate limits, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with two sentences that directly state the tool's purpose and a critical usage guideline. Every sentence earns its place, and there is no wasted verbiage.
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?
Given the complexity (7 parameters, mutation tool) and no annotations or output schema, the description is incomplete. It covers the purpose and a key guideline but lacks details on parameter semantics, behavioral traits, and return values. This is adequate for a basic understanding but has clear gaps for effective tool use.
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 lists the parameters (gravity, timestep, solver iterations) and provides a default gravity value, adding some meaning beyond the schema. However, it does not explain the purpose or typical values for parameters like velocity_iterations or allow_sleep, leaving many parameters inadequately documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Configure 2D physics: gravity, timestep, solver iterations.' It specifies the verb ('configure') and resource ('2D physics'), and lists the key configurable parameters. However, it does not explicitly differentiate from its sibling 'cocos_set_physics_3d_config', which is a notable gap.
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?
The description provides clear usage context: 'Must call this before build if using physics.' This gives a specific prerequisite and timing guidance. However, it does not explicitly state when NOT to use this tool or mention alternatives like the 3D physics config tool, which limits the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool attaches a button component (implying mutation/creation), explains color preset behavior and auto-derivation logic, and shows click event binding. However, it doesn't mention permissions, error conditions, rate limits, or what happens if the node already has a button component.
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 efficiently structured with key information front-loaded: purpose, transition types, color_preset behavior, and click_events usage. The example is helpful and well-placed. Some sentences could be slightly more concise, but overall it's appropriately sized for the tool's complexity.
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?
Given the complex 22-parameter schema with 0% description coverage and no annotations, the description does a good job covering the most important aspects: transition types, color system, and click events. The presence of an output schema reduces the need to explain return values. However, for such a complex tool, more complete parameter coverage would be ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 22 parameters, the description adds significant value beyond the schema. It explains the meaning of 'transition' values (0-3), clarifies color_preset behavior and its relationship to RGBA parameters, and provides usage context for click_events. However, it doesn't cover all 22 parameters - notably missing scene_path and node_id semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Attach cc.Button' with specific details about transition types. It distinguishes from sibling 'cocos_add_button_with_label' by focusing on button attachment without label functionality. However, it doesn't explicitly contrast with other UI component tools like 'cocos_add_toggle' or 'cocos_add_slider'.
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?
The description provides clear context about when to use color_preset versus explicit RGBA values, and includes a concrete example showing how to use click_events with cocos_make_click_event. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'cocos_add_button_with_label' or other UI components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the return value structure ({tmx_uuid, tsx_files, textures, dir}), which adds some behavioral context. However, it lacks details on permissions, side effects (e.g., file modifications), error handling, or rate limits, leaving gaps for a tool that likely modifies project assets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, with two sentences that directly state the purpose and usage. Every sentence adds value without redundancy, making it efficient and easy to parse for an agent.
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?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It covers the purpose and workflow but misses parameter explanations, behavioral details, and output specifics beyond a brief mention. It's minimally adequate for basic understanding but lacks depth for safe and effective use.
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 description coverage is 0%, so the description must compensate for all 5 parameters. It does not explain any parameters (e.g., what 'project_path' or 'rel_dir' mean), their formats, or constraints. The mention of file types (.tmx, .tsx, PNGs) hints at 'tmx_path' and 'texture_paths' but lacks specifics, failing to adequately supplement the schema.
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 clearly states the specific action ('Import TiledMap assets') and resources ('.tmx + .tsx tilesets + tileset PNGs'), distinguishing it from sibling tools like 'cocos_add_tiled_map' which appears to use the imported assets. It explicitly mentions the file types involved, making the purpose distinct and unambiguous.
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?
The description provides explicit usage guidance by stating 'Use tmx_uuid with cocos_add_tiled_map()', indicating when to use this tool (for importing assets) versus its sibling (for adding the map). It clearly defines the workflow, helping the agent understand the sequence of operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 this is a configuration/mutation tool (implied by 'configure'), describes the default values for parameters, and mentions the DirectionalLight prerequisite. However, it doesn't cover important behavioral aspects like whether changes are reversible, what permissions are needed, error conditions, or what happens when shadows are disabled. For a 10-parameter mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured. Four sentences cover purpose, parameter meanings, null behavior, and a prerequisite. Every sentence earns its place with essential information. No wasted words, and the most critical information (what the tool does) appears first.
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?
Given the complexity (10 parameters, mutation tool) and lack of both annotations and output schema, the description is incomplete. While it excels at parameter semantics, it lacks crucial context: no information about return values, error handling, side effects, or what 'configure' actually does to the scene. For a tool that modifies scene state, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate fully. It does this excellently: it explains the meaning of normal (ground plane normal with default), distance (signed offset), and color (shadow color with integer range). It also clarifies the null behavior: 'Pass None on any axis/channel to leave it unchanged.' This adds crucial semantic context beyond the bare parameter names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Configure planar shadows on the scene's cc.ShadowsInfo.' It specifies the verb ('configure') and resource ('planar shadows'), though it doesn't explicitly differentiate from sibling tools (none appear to be shadow-related). The description goes beyond the tool name by explaining what aspect of shadows is configured.
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?
The description provides some implied usage guidance: 'Enabling planar shadows also typically requires at least one DirectionalLight in the scene.' This gives a prerequisite condition. However, it doesn't explicitly state when to use this tool versus alternatives (no shadow-related siblings exist) or provide exclusion criteria. The guidance is helpful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 describes the component's shape and kinematic nature, but lacks critical behavioral details: it doesn't specify if this is a destructive operation (attaching likely modifies the node), what permissions are needed, whether it can be undone, or how it interacts with other components. The height clarification is useful but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: the first sentence states the core purpose, the second provides comparative context, and the third clarifies a critical parameter detail. Every sentence earns its place with no wasted words.
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?
Given the tool's complexity (12 parameters, mutation operation) and the presence of an output schema (which reduces need to describe returns), the description is partially complete. It covers the purpose and one parameter nuance well, but lacks behavioral transparency for a mutation tool and leaves most parameters unexplained. The output schema existence helps but doesn't compensate for the missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 12 parameters, the description adds significant value by clarifying the 'height' parameter semantics ('distance between the two sphere centers' vs 'total capsule height'). However, it doesn't explain the other 11 parameters (like 'scene_path', 'node_id', or physics-related settings), leaving most parameter meanings undocumented.
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 clearly states the specific action ('Attach'), the exact component ('cc.CapsuleCharacterController'), and its nature ('capsule-shaped kinematic character'). It distinguishes from the sibling 'cocos_add_box_character_controller' by noting that capsules are 'more common than box for humanoid characters' and provide 'smoother wall sliding'.
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?
The description provides clear context for when to use this tool by comparing it to the box alternative and explaining its advantages for humanoid characters. However, it does not explicitly state when NOT to use it or mention any prerequisites beyond the required parameters, which are documented in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's effect (attaches Widget component, makes node fill parent) and return value (Widget component id), but doesn't mention potential side effects, permission requirements, or error conditions. The description is adequate but lacks depth about mutation behavior or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first sentence, followed by usage examples and technical context. Every sentence adds value: the second provides concrete use cases, the third gives technical background, and the fourth states the return value. Zero wasted words.
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?
Given the tool's moderate complexity (layout operation), no annotations, 0% schema coverage, but with an output schema, the description does well on purpose and usage but lacks parameter details. The output schema likely covers return values, so the description's mention of returning 'Widget component id' is sufficient but not essential.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It provides no information about what 'scene_path' or 'node_id' represent, their formats, or valid values. The description adds zero parameter semantics beyond what the bare schema provides.
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 clearly states the specific action ('Attach cc.Widget'), the resource ('node'), and the effect ('stretches to fill its parent'). It distinguishes from siblings by focusing on fullscreen layout behavior, unlike other tools that add components or handle events.
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?
The description provides clear context for when to use ('Use for backgrounds, modal backdrops, full-bleed panels') and mentions a technical alternative ('Replaces the ``align_flags=15`` incantation'). However, it doesn't explicitly state when NOT to use this tool or name specific sibling alternatives for different layout needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively explains key behavioral traits: the text is emitted one character at a time via the keyboard API, and IME/input-event handlers fire per character. This clarifies the tool's operational mechanics, though it lacks details on error handling or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by specific use cases and behavioral details. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It covers the core action and behavior well but lacks parameter explanations and details on return values or error conditions. This leaves gaps for an agent to fully understand how to invoke the tool correctly.
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 description coverage is 0%, so the description must compensate for undocumented parameters. However, it only mentions the 'text' parameter implicitly and does not explain the purpose of 'url', 'wait_ms', 'viewport_width', 'viewport_height', or 'timeout_ms'. This leaves most parameters unexplained, failing to add meaningful semantics beyond the schema.
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 clearly states the specific action ('Type a string') and target ('whatever widget currently has focus'), distinguishing it from sibling tools that focus on adding components or managing scenes. It provides concrete examples of use cases (name-entry fields, high-score initials, chat boxes), making the purpose immediately understandable.
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?
The description explicitly states when to use this tool ('Ideal for filling name-entry fields, high-score initials, chat boxes'), providing clear context. However, it does not mention when not to use it or name specific alternatives among the many sibling tools, such as those for clicking or dragging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this creates an animation ('animate the entrance') and returns specific identifiers, but doesn't mention whether this modifies scene state permanently, requires specific permissions, has side effects, or any rate limits. The behavioral disclosure is adequate but lacks depth for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely efficient with three focused sentences: purpose statement, parameter guidance, and return value specification. Every sentence adds essential information with zero wasted words, and key information is front-loaded.
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?
Given 7 parameters with 0% schema coverage, no annotations, and no output schema, the description provides good coverage for the animation behavior and one parameter, but leaves most parameters unexplained. For a tool that likely modifies scene state (animation creation), more behavioral context would be helpful, though the return value specification partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 7 parameters, the description adds significant value by explaining 'from_side' parameter semantics (enum values and purpose) and clarifying the relationship between node position and animation. However, it doesn't cover the other 6 parameters (scene_path, node_id, distance, duration, delay, rel_dir), leaving them undocumented.
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 clearly states the specific action ('Slide a node in from off-screen at scene start') and identifies the resource ('node'). It distinguishes from siblings by specifying this is for slide-in animation, unlike other animation tools like 'cocos_add_fade_in' or 'cocos_add_bounce_in'.
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?
The description provides clear context for when to use it ('at scene start') and includes a crucial prerequisite ('set the final position first, then call this to animate the entrance'). However, it doesn't explicitly state when not to use it or name alternative tools for different animation types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the tool simulates keydown/keyup events via Cocos's 'systemEvent' KeyCode hook, which is useful behavioral context. However, it lacks details on error handling, side effects (e.g., if the preview must be running), or performance implications, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by key details and usage examples in three concise sentences. Every sentence adds value without redundancy, making it efficient and well-structured.
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?
Given 6 parameters with 0% schema coverage and no output schema or annotations, the description is incomplete. It covers the 'key' parameter well and hints at the tool's behavior but omits details on other parameters, error conditions, and return values, which are significant gaps for a tool with multiple inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 the 'key' parameter's semantics (uses Playwright's names and examples like 'Enter', 'a'), adding crucial meaning beyond the schema. However, it does not address other parameters like 'url', 'wait_ms', or viewport settings, leaving them undocumented.
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 clearly states the specific action ('Press a single key') and target context ('in the running preview'), distinguishing it from sibling tools like 'cocos_type_preview' (typing text) or 'cocos_click_preview' (mouse clicks). It provides a verb+resource combination that is precise and unambiguous.
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?
The description explicitly states when to use this tool ('Use this for keyboard-driven input (pause menus, player movement, form submit)'), providing clear context. However, it does not specify when not to use it or mention alternatives like 'cocos_type_preview' for text input, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 excels by disclosing key behavioral traits: it generates a file with specific properties (e.g., target tracking, smoothing logic), mentions performance details ('Zero per-frame allocation'), handles edge cases ('null-checks target each lateUpdate'), and describes the return format. This goes beyond basic functionality to include implementation nuances.
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 well-structured and front-loaded with the main purpose, followed by property details and behavioral notes. It is appropriately sized with no wasted sentences, though it could be slightly more concise by integrating some details more tightly. Every sentence adds value, such as explaining smoothing logic and memory usage.
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?
Given the complexity of generating a camera-follow script with multiple behavioral aspects, no annotations, and no output schema, the description is largely complete: it covers purpose, properties, performance, edge cases, and return values. However, it lacks information on the input parameters, which is a minor gap in an otherwise thorough explanation.
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?
The input schema has 2 parameters with 0% description coverage, and the tool description does not mention or explain these parameters at all. While the description details the generated script's properties (e.g., target, offsetX), it fails to add meaning to the actual input parameters (project_path, rel_path), leaving them undocumented and unclear in context.
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 clearly states the tool's purpose: 'Generate CameraFollow.ts — attach to the Camera node to track a target with deadzone + frame-rate-independent smoothing + optional world bounds.' It specifies the verb ('Generate'), resource ('CameraFollow.ts'), and distinguishes from siblings by focusing on camera-follow functionality, unlike other scaffold tools for audio controllers, enemy AI, etc.
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?
The description provides clear context for when to use this tool: 'attach to the Camera node to track a target.' It implies usage for camera tracking in game development. However, it does not explicitly state when not to use it or name alternatives among siblings, such as other camera-related tools like 'cocos_add_camera'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 behavioral traits like file generation, default paths, and return format ('Returns the usual four keys'), but lacks details on permissions, error handling, or side effects. It adequately describes what the tool does without contradictions, but could be more comprehensive for a code-generation tool.
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 well-structured and front-loaded with the main purpose, followed by bullet-like explanations for each behavior kind and concluding with default paths and return info. It is appropriately sized with no wasted sentences, though the formatting with quotes and backticks could be slightly cleaner for readability.
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?
Given no annotations, 0% schema coverage, and no output schema, the description does a decent job by explaining parameters and behaviors. However, it lacks details on the return value ('the usual four keys' is vague), error conditions, or integration with the project context, leaving some gaps for a tool with 3 parameters and code-generation complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 effectively explains the semantics of the 'kind' parameter by detailing the three options (patrol, chase, shoot) with their properties and behaviors, and clarifies 'rel_path' with default values per kind. This adds significant meaning beyond the bare schema, fully documenting parameter usage.
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 clearly states the tool generates enemy behavior starter files with specific verbs ('Generate Enemy{Kind}.ts — common enemy-behaviour starters') and distinguishes itself from siblings by focusing on AI scaffolding rather than UI components or asset management. It explicitly lists the three behavior types (patrol, chase, shoot) with detailed mechanics, making the purpose highly specific and differentiated.
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?
The description provides clear context for when to use this tool (to create enemy AI behavior starters) and implies usage through the detailed behavior explanations. However, it does not explicitly state when not to use it or name alternatives among siblings, such as other scaffolding tools like 'cocos_scaffold_player_controller', leaving some guidance gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: the generated script exposes a runtime API with specific properties (e.g., moveDir, jumpPressed), follows a singleton pattern with self-destruction for extra instances, and returns a structured object with paths and UUIDs. It covers essential traits like mutation (generation), integration flow, and output format, though it lacks details on error handling or permissions.
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 well-structured and front-loaded with the core purpose, followed by API details, behavioral notes, and a usage example. Each sentence adds value, such as explaining the singleton pattern and return values. It could be slightly more concise by reducing repetition in the API examples, but overall, it avoids unnecessary fluff and is efficiently organized.
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?
Given the complexity of generating a script with runtime behavior, no annotations, and no output schema, the description is largely complete. It covers the tool's purpose, behavioral traits, parameters in context, and integration steps. However, it lacks explicit error handling, performance considerations, or detailed output schema explanation, which would enhance completeness for a scaffolding tool.
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?
The schema description coverage is 0%, but the description compensates by explaining the parameters in context. It mentions 'project' in the typical flow example, implying 'project_path', and 'rel_path' is shown with a default value ('InputManager.ts'). However, it does not fully detail parameter meanings, such as what 'project_path' expects or constraints on 'rel_path', leaving some ambiguity beyond the schema's basic types.
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 clearly states the tool's purpose: 'Generate InputManager.ts + meta - unified keyboard/touch input singleton.' It specifies the verb ('Generate'), resource ('InputManager.ts + meta'), and distinguishes it from siblings by focusing on input abstraction rather than UI components or other scaffolding tools like 'cocos_scaffold_audio_controller' or 'cocos_scaffold_player_controller'.
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?
The description provides clear usage context with a 'Typical flow' section, showing how to integrate the generated script into a scene using sibling tools like 'cocos_add_script'. However, it does not explicitly state when not to use this tool or mention alternatives, such as other input handling methods or sibling tools like 'cocos_add_button' for UI input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does well by detailing behavioral traits: it generates files with specific runtime API, handles persistence via localStorage with key 'cocos-mcp-high-score', swallows write failures to prevent crashes, and returns specific output data. It does not mention rate limits or auth needs, but covers core behavior adequately.
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 appropriately sized and front-loaded, starting with the core purpose. It uses bullet-like sections for runtime API and wiring instructions, but includes some technical details that could be streamlined. Most sentences earn their place by adding necessary context without excessive verbosity.
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?
Given the complexity (scaffolding a score system), no annotations, no output schema, and low schema coverage, the description is fairly complete. It explains what the tool does, behavioral traits, optional features, and return values. However, it could improve by explicitly linking parameters to the project context and providing more usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 does not explicitly mention the parameters (project_path, rel_path), but implies usage in a Cocos project context. The description adds value by explaining the tool's output and functionality, though it could directly reference parameters for better clarity. With 0% coverage, this is above baseline.
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 clearly states the tool generates a GameScore.ts file with meta, specifying it creates a singleton for current/high scores with localStorage persistence and optional Label auto-render. It distinguishes from siblings by focusing on score system scaffolding rather than adding components or managing assets.
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?
The description implies usage for creating a score system in a Cocos project, but does not explicitly state when to use this tool versus alternatives like other scaffolding tools (e.g., cocos_scaffold_player_controller) or general script addition tools. It provides some context about optional features but lacks explicit guidance on prerequisites or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explains that colors are floats 0..1 (not 0..255), that None values leave parameters unchanged, and provides the default sky_illum value (~20000 lux). However, it doesn't mention whether this is a read or write operation, what permissions are needed, or what happens if the scene doesn't have AmbientInfo. The description adds useful context but doesn't fully cover behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with four sentences that each add value: stating the purpose, explaining color format, describing parameter behavior with None, providing default illumination, and stating the prerequisite. There's no wasted text, and key information is front-loaded.
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?
Given the complexity (10 parameters, no annotations, no output schema), the description provides good basic context about parameter formats and prerequisites but lacks information about return values, error conditions, or what constitutes valid scene_path values. For a configuration tool with many parameters, more complete documentation would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 10 parameters, the description must compensate significantly. It explains the meaning of color parameters (floats 0..1, normalized like material PBR inputs), clarifies that sky_illum is in lux with a default value, and notes that passing None leaves parameters unchanged. However, it doesn't explain the scene_path parameter or differentiate between sky_color and ground color parameters beyond naming them.
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 clearly states the specific action ('Configure ambient lighting'), target resource ('scene's cc.AmbientInfo'), and scope (lighting parameters). It distinguishes from sibling tools by focusing on ambient lighting configuration rather than scene creation, node manipulation, or other lighting types like directional or spot lights.
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?
The description provides clear context for when to use this tool: when configuring ambient lighting on a scene that has been created via 'cocos_create_scene' (which auto-attaches AmbientInfo). It doesn't explicitly state when not to use it or name specific alternatives, but the prerequisite is clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the tool modifies configuration files ('Configure... in builder.json') and that fields are optional with None preserving existing values, which is useful behavioral context. However, it doesn't mention whether this requires specific permissions, if changes are reversible, or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first sentence states the core purpose, followed by bullet-like explanations of each parameter group, ending with the important optionality rule. Every sentence adds essential information with zero waste, making it easy to scan and understand.
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 complex configuration tool with 15 parameters, no annotations, and no output schema, the description does remarkably well by explaining parameter semantics thoroughly and clarifying the optional/merge behavior. The main gap is lack of information about return values or error conditions, but given the parameter-heavy nature, it's mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 15 parameters, the description compensates excellently by explaining the meaning and format of nearly all parameters: platform values ('ios' or 'android'), orientation options, path requirements, iOS team ID format, Android API level examples, keystore usage logic, and app bundle purpose. It adds significant value beyond the bare schema.
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 clearly states the specific action ('Configure'), target resource ('iOS or Android native build settings in builder.json'), and scope (all optional fields). It distinguishes itself from sibling tools by focusing on native build configuration rather than scene/node manipulation or other build-related tasks like 'cocos_set_bundle_config' or 'cocos_build'.
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?
The description implies usage when configuring native build settings for iOS or Android platforms, but provides no explicit guidance on when to use this tool versus alternatives like 'cocos_set_bundle_config' or 'cocos_build'. It mentions platform-specific parameters but doesn't clarify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates this is a mutation operation ('Set'), but doesn't disclose behavioral aspects like permissions needed, whether changes are reversible, error conditions, or rate limits. The description adds some context about property types but lacks comprehensive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both of which add clear value. The first sentence states the core purpose, and the second provides specific usage guidance with sibling differentiation. No wasted words or redundant 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?
For a mutation tool with 4 parameters (0% schema coverage) and no annotations, the description provides good purpose and usage guidance but lacks behavioral context and complete parameter semantics. The existence of an output schema helps, but the description should do more to compensate for the missing structured information about this write operation.
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 schema provides no parameter descriptions. The description mentions 'literal property' and gives examples of property names, which adds some semantic context for 'prop_name' and implies 'value' accepts various data types. However, it doesn't explain 'scene_path' or 'object_id' parameters, leaving significant gaps in parameter understanding.
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 clearly states the verb ('Set') and resource ('literal property on any scene object'), with specific examples (_string, _fontSize, _color). It explicitly distinguishes from its sibling tool 'cocos_link_property' by specifying this is for non-reference properties only.
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?
The description provides explicit guidance on when to use this tool ('for literal properties like _string, _fontSize, _color') and when to use an alternative ('For node/component references, use cocos_link_property instead'). This gives clear context for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: the controller handles 'ground snapping, slope limits, step-up automatically' which reveals automation capabilities. However, it doesn't mention permission requirements, error conditions, or mutation effects (e.g., whether this modifies existing components).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first sentence, followed by usage guidance and key capabilities. Every sentence earns its place with no wasted words, making it highly efficient for an agent to parse.
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?
Given 13 parameters with 0% schema coverage and no annotations, the description is incomplete despite having an output schema. It explains the 'what' and 'when' well but leaves the 'how' (parameter usage) entirely undocumented. For a complex tool with many numeric parameters, more guidance on parameter relationships would be helpful.
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 description coverage is 0% (13 parameters with no descriptions in schema). The description adds no parameter information beyond what's implied by the tool name. It doesn't explain what parameters like 'scene_path', 'node_id', or the various dimension/extent parameters actually mean or how they relate to the character controller.
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 clearly states the specific action ('Attach cc.BoxCharacterController') and resource ('AABB-shaped kinematic character'), distinguishing it from sibling tools like 'cocos_add_capsule_character_controller' by specifying the shape type. It provides a precise technical purpose beyond just the tool name.
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?
The description explicitly states when to use this tool ('Use this INSTEAD of RigidBody + Collider for player movement') and provides a clear alternative scenario to avoid. This gives the agent specific guidance on tool selection versus other physics components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by describing key behaviors: whole card acts as button, automatic text color contrast based on variant, extras wrap to new rows, and return structure. It doesn't mention permissions, rate limits, or mutation effects, but covers core UI behavior adequately.
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 efficiently structured with clear sections: purpose, card structure, behavior, return values, and click wiring. Every sentence adds value, though the technical formatting (:: and # comments) slightly reduces readability.
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 7-parameter tool with no annotations and no output schema, the description provides substantial context: purpose, parameter semantics, behavior, and return structure. It could mention error conditions or performance considerations but covers the essentials well given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 7 parameters, the description compensates excellently by explaining the 'cards' array structure in detail (title, subtitle, icon, variant, click_events) and mentioning layout behavior (wrapping when count > columns). It adds crucial meaning beyond the bare schema property names.
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 clearly states the tool creates a 'Grid of tappable cards' with specific use cases (level select, shop, character picker). It distinguishes from sibling tools by focusing on card grid creation rather than other UI components like buttons, labels, or dialogs listed in the sibling tools.
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?
The description implies usage through example contexts (level select, shop, character picker) but doesn't explicitly state when to use this tool versus alternatives like 'cocos_add_button' or 'cocos_add_main_menu'. No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the tool performs file copying and metadata writing (mutating operations), mentions the return value structure, and specifies the default directory and resource placement behavior. However, it doesn't address permissions, error conditions, or side effects beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: purpose statement, parameter guidance, and return value. Every sentence adds essential information with zero wasted words. It's appropriately sized for the tool's complexity.
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 mutation tool with no annotations and no output schema, the description does well by explaining the operation, parameter effects, and return structure. It covers the key aspects needed to use the tool correctly, though doesn't address potential errors or edge cases. The return value documentation partially compensates for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 4 parameters, the description compensates well by explaining the 'as_resource' parameter's purpose and effect (placement under assets/resources/ for runtime loading). It also implies 'rel_path' usage through the default path mention, though doesn't fully document all parameters like 'project_path' and 'src_png' semantics.
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 clearly states the specific action ('Copy a PNG into the project and write a complete sprite-frame meta'), identifies the resource (PNG file), and distinguishes from siblings by focusing on image/sprite-frame creation rather than scripts, animations, audio, or other asset types. It provides concrete details about the operation.
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?
The description provides clear context about when to use the 'as_resource' parameter (for runtime loading via resources.load()), but doesn't explicitly state when to use this tool versus alternatives like 'cocos_add_sprite' or 'cocos_add_filled_sprite'. It gives practical guidance about the default behavior and the resource placement option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 some behavioral traits: it explains overflow modes (CLAMP truncates, SHRINK auto-shrinks font) and cache modes, and mentions theme dependency. However, it doesn't cover important aspects like whether this is a creation/mutation operation, what permissions might be needed, error conditions, or what the output contains.
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 appropriately sized and front-loaded with the core functionality. The first sentence establishes the purpose, followed by parameter explanations and theme context. While dense with information, every sentence serves a clear purpose in explaining tool behavior and usage.
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?
Given the complexity (19 parameters, 0% schema coverage) and the presence of an output schema (which handles return values), the description does a good job covering key aspects. It explains parameter semantics thoroughly and provides important context about theme dependencies. The main gap is lack of behavioral transparency about the operation's nature (creation vs. modification) and potential side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 19 parameters, the description compensates exceptionally well. It explains the semantics of 'overflow' and 'cache_mode' parameters with their numeric codes and behaviors, and provides detailed information about the three preset parameters (color_preset, size_preset, outline_color_preset) including examples and valid values. This adds substantial meaning beyond the bare schema.
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 starts with a specific verb ('Attach') and resource ('cc.Label'), clearly stating what the tool does. It distinguishes from siblings by focusing specifically on label creation/attachment, unlike other tools that add different UI components (buttons, sprites, etc.) or perform different operations (building, previewing).
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?
The description provides clear context about when to use design-token presets versus explicit arguments, and mentions the prerequisite of setting a theme via 'cocos_set_ui_theme'. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the tool's behavior by detailing the menu structure (full-screen, vertical, with background, title, and buttons) and default button configuration, but lacks information on permissions, error handling, or side effects like scene modification impacts. The example flow adds practical context but does not fully cover behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by specific details and a practical example. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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?
Given the complexity of a UI-building tool with 6 parameters, no annotations, and no output schema, the description is fairly complete: it explains the tool's purpose, provides usage guidelines with an example, and covers parameter semantics partially. However, it lacks details on return values or error conditions, which would enhance completeness for this type of tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 6 parameters, the description compensates by explaining key parameters: it mentions 'title' and 'buttons' in the example, implies 'scene_path' and 'parent_node_id' through the flow, and references button dimensions via 'button_width' and 'button_height' defaults. However, it does not detail all parameters (e.g., exact usage of 'scene_path'), leaving some gaps.
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 clearly states the tool's purpose: 'Build a full-screen vertical main menu: bg + title + stacked buttons.' It specifies the verb ('Build'), resource ('main menu'), and key components, distinguishing it from sibling tools like 'cocos_add_dialog_modal' by referencing it for button shape but focusing on a full-screen menu structure.
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?
The description provides clear context for usage with a 'Typical flow' example, showing how to integrate it into a scene creation process and referencing sibling tools like 'cocos_create_scene' and 'cocos_set_ui_theme'. However, it does not explicitly state when not to use this tool or mention alternatives, such as other UI components from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 key behavioral traits: the tool attaches a component, auto-spawns indicator sprites, and has a default direction. However, it lacks details on permissions, side effects (e.g., if it modifies existing nodes), rate limits, or error handling, which are important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the first sentence stating the core purpose. Each subsequent sentence adds necessary details without waste, making it efficient and easy to parse for an AI agent.
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?
Given the tool's moderate complexity (7 parameters, mutation operation), no annotations, and an output schema present, the description is fairly complete. It covers the tool's purpose, basic usage, and key parameters, but lacks details on behavioral aspects like error conditions or output format, though the output schema may mitigate this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 7 parameters, the description adds significant meaning beyond the schema. It explains 'sprite_frame_uuid' as a template for sprites and 'direction' values (0=HORIZONTAL, 1=VERTICAL), covering 2 of 7 parameters. It does not address 'scene_path', 'node_id', 'cell_width', 'cell_height', or 'spacing', but provides enough context for core functionality.
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 clearly states the tool's purpose with specific verbs ('Attach cc.PageViewIndicator') and resource ('dots row that tracks PageView position'), distinguishing it from siblings like 'cocos_add_page_view' (which creates the PageView itself) and other UI components. It precisely defines what the tool does without being tautological.
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?
The description provides clear context on when to use this tool ('Attach to a child of the PageView node'), implying it should be used after creating a PageView. However, it does not explicitly state when not to use it or name alternatives among siblings, such as other indicator or navigation components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses behavioral traits such as the fade-in/out timing (0.25s each), minimum duration (0.6s), that the toast stays in scene as a zero-opacity node after animation, and the return values (toast_node_id, label_node_id, animation_component_id). This covers key operational details beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by parameter details and return values. Each sentence adds value, with no wasted words, making it efficient and easy to parse.
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?
Given the complexity (8 parameters, no annotations, no output schema), the description is fairly complete. It explains the tool's behavior, key parameters, and return values, but lacks details on some parameters and does not fully address all input semantics, leaving minor gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 'variant' with specific options (info, success, warn, danger) and their visual effects, and 'duration' with timing details (total time, minimum 0.6s). However, it does not cover other parameters like 'scene_path', 'parent_node_id', 'text', 'position', 'width', or 'height', leaving some gaps.
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 starts with 'Transient pill notification — fade in, hold, fade out,' which clearly states the tool's function as creating a temporary notification with specific visual behavior. It distinguishes from siblings by focusing on toast notifications rather than other UI elements like buttons, labels, or dialogs listed in the sibling tools.
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?
The description implies usage for transient notifications but does not explicitly state when to use this tool versus alternatives like 'cocos_add_dialog_modal' or 'cocos_add_label'. It mentions the tool's behavior (fade in/out) and parameters, but lacks explicit guidance on scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the creation of a file and the return format, which is useful. However, it lacks details on permissions, error handling, whether the operation is idempotent, or what happens if the file already exists. The description adds some behavioral context but is incomplete for a mutation tool.
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 core purpose, followed by essential details and an example. It's appropriately sized, but the example track could be slightly more concise. Overall, most sentences earn their place by adding critical information.
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?
Given the complexity (6 parameters, 0% schema coverage, no output schema, no annotations), the description does well by explaining the tracks parameter thoroughly and the return values. However, it doesn't cover other parameters like 'project_path' or 'duration', leaving some gaps in context for a tool with multiple inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 provides detailed semantics for the 'tracks' parameter, including structure, property types, and value formats, with an example. This adds significant meaning beyond the bare schema, effectively documenting the most complex parameter.
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 clearly states the specific action ('Create a .anim AnimationClip file') and resource type, distinguishing it from sibling tools that handle scripts, audio, components, etc. It provides concrete details about the output format and structure, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining the return values and how to use the uuid with 'cocos_add_animation()', which implies a workflow. However, it doesn't explicitly state when to use this tool versus alternatives like 'cocos_create_node' or other creation tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: it creates a new scene with specific components (Canvas, UICamera, etc.), sets the camera's clearColor for a sky-blue background, and returns canonical IDs for use in subsequent tool calls. It covers creation, output format, and usage of IDs, though it could mention potential side effects like file system changes or scene overwriting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with three paragraphs that efficiently cover creation details, visual behavior, and return values. Each sentence adds value: the first defines the tool's purpose, the second explains the background color setup, and the third details the returned IDs and their usage. There is no redundant or wasted information.
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?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is fairly complete. It explains what the tool creates, the visual outcome, and the structure of returned IDs for downstream use. However, it could improve by addressing parameter meanings or potential errors, but it covers core functionality adequately for a creation tool without structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 for undocumented parameters. It does not explicitly describe any of the 7 parameters, but it implies context for 'clear_color' parameters by mentioning the camera's clearColor is set to sky-blue. However, it lacks details on other parameters like 'project_path' or 'scene_name'. The description adds some value but does not fully compensate for the coverage gap, warranting a score above baseline due to implied parameter relevance.
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 clearly states the tool's purpose: 'Create a minimal empty 2D scene + meta in assets/scenes/'. It specifies the verb ('Create'), resource ('2D scene'), and scope ('minimal empty'), distinguishing it from sibling tools like 'cocos_create_node' or 'cocos_create_prefab' which create different resources. The mention of included components (Canvas, UICamera, etc.) further clarifies what constitutes the scene.
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?
The description implies usage context by stating it creates a 'minimal empty 2D scene', suggesting it's for initial scene setup. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'cocos_create_node' for individual nodes or 'cocos_create_prefab' for reusable templates), and does not mention prerequisites like requiring a valid project path. The context is clear but incomplete for sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the output format and typical use cases, but lacks details on behavioral traits such as whether the UUID is globally unique, if there are any rate limits, or if it requires specific permissions. The description does not contradict any annotations, but could provide more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with two sentences that efficiently convey the tool's function and usage. Every sentence adds value without any waste, making it easy for an AI agent to understand quickly.
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?
Given the tool's simplicity (0 parameters, no annotations, but has an output schema), the description is mostly complete. It explains what the tool does and its typical use, but could benefit from mentioning that it returns a UUID string (implied by the output schema) or any constraints. However, it adequately covers the core functionality for a straightforward generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and output without redundant parameter details, earning a high baseline score.
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 clearly states the verb ('Generate') and resource ('fresh standard UUID4'), specifying the exact format ('36-char dashed lowercase hex'). It distinguishes from siblings by indicating its specific use case ('main UUID for new scripts, scenes, prefabs, and images'), unlike other tools that perform various creation or manipulation tasks.
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?
The description provides clear context for when to use this tool ('Used as the main UUID for new scripts, scenes, prefabs, and images'), which helps differentiate it from siblings like 'cocos_compress_uuid' or 'cocos_decompress_uuid'. However, it does not explicitly state when not to use it or name specific alternatives, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses key behavioral traits: it generates code with specific callbacks ('onEnter<PascalCase>' and 'onExit<PascalCase>'), includes runtime API details ('GameLoop.I.current', 'GameLoop.I.go(state)', 'GameLoop.I.reset()'), and describes validation at scaffold time (e.g., 'State-name validation at scaffold time' with rules and error handling via 'ValueError'). It does not mention side effects like file overwriting or permissions, but covers core behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. Each sentence adds value: explaining states, callbacks, runtime API, validation, and return values. There is no wasted text, and it uses bullet-like formatting for clarity without being verbose.
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?
Given the tool's complexity (generating code with validation and runtime API), no annotations, and no output schema, the description does a good job covering purpose, behavior, parameters, and returns ('Returns {path, rel_path, uuid_standard, uuid_compressed}'). It misses some details like error handling beyond validation or file system impacts, but is largely complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 adds meaning for the 'states' parameter by explaining its purpose ('ordered list, default ["menu", "play", "over"]'), format, and validation rules. It also implies 'project_path' is for file generation and 'rel_path' defaults to 'GameLoop.ts', though not explicitly named. However, it doesn't detail all three parameters fully (e.g., exact usage of 'project_path'), leaving some gaps.
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 clearly states the tool's purpose: 'Generate GameLoop.ts — singleton state machine.' It specifies the verb ('Generate'), resource ('GameLoop.ts'), and distinguishes it from sibling tools (e.g., 'cocos_scaffold_audio_controller', 'cocos_scaffold_player_controller') by focusing on a state machine implementation rather than other game components.
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?
The description implies usage context through details like 'singleton state machine' and 'Designers can wire either from the Inspector or from script code,' suggesting it's for game development in Cocos Creator. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other scaffolding tools like 'cocos_scaffold_ui_screen'), no prerequisites, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: the tool generates TypeScript files, details spawning mechanics (jitter, queue management, parenting rules), and mentions callback execution. However, it doesn't cover potential side effects like file overwriting or error conditions, leaving some gaps in behavioral understanding.
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 efficiently structured with clear sections: purpose statement, variant explanations, parenting behavior, and default paths. Every sentence adds value, though the formatting with quotes and backticks could be slightly cleaner. It's appropriately sized for the complexity without unnecessary elaboration.
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 tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description provides strong contextual completeness. It covers purpose, variants, behaviors, parenting rules, and parameter implications. The main gap is lack of explicit error handling or output format details, but given the tool's nature (file generation), this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description compensates by explaining parameter semantics beyond the schema. It clarifies that 'kind' accepts 'time' or 'proximity' with detailed behavior for each, explains 'rel_path' defaults (SpawnerTime.ts/SpawnerProximity.ts), and implies 'project_path' is for file generation location. This adds substantial meaning not present in the bare schema.
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 clearly states the tool's purpose: 'Generate Spawner{Kind}.ts — instantiate @property prefab on a trigger.' It specifies the verb ('generate'), resource ('Spawner{Kind}.ts'), and distinguishes from siblings by focusing on spawner generation rather than adding components or assets. The detailed explanation of 'time' and 'proximity' variants further clarifies its unique functionality.
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?
The description implies usage contexts through the explanation of 'time' and 'proximity' variants, but does not explicitly state when to use this tool versus alternatives. No sibling tools are mentioned for comparison, and there's no guidance on prerequisites or exclusions. The context is clear but lacks explicit usage directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes what gets generated (TypeScript files with specific properties and behaviors), mentions the toggle mechanism (rootNode.active), and specifies the return format. However, it doesn't cover important behavioral aspects like error handling, file overwriting behavior, or permission requirements for writing to project_path.
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 appropriately sized and front-loaded with the core purpose. The bullet-point format for different kinds is efficient, though some sentences could be more concise (e.g., 'whole-subtree toggle beats per-node UIOpacity for full screens' could be simplified). Overall, most content earns its place.
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 3-parameter tool with no annotations and no output schema, the description provides substantial context about behavior, parameters, and integration requirements. It explains the return format and GameLoop dependency. The main gap is lack of error handling information, but otherwise it's quite complete for a scaffolding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters, the description provides excellent semantic context. It explains that 'kind' accepts specific values (menu, settings, pause, game_over) with detailed behavior for each, clarifies that 'rel_path' has default values per kind, and implies 'project_path' is where the files will be generated. This fully compensates for the lack of schema documentation.
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 clearly states the tool generates a full-screen UI controller file tied to GameLoop, specifying the exact file format (<Kind>Screen.ts) and distinguishing it from sibling tools that add components rather than scaffold full controllers. It explicitly lists four specific kinds (menu, settings, pause, game_over) with their distinct purposes.
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?
The description provides clear context about when to use this tool (to generate UI screens for GameLoop integration) and mentions the prerequisite to scaffold GameLoop first so references resolve. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It adequately describes the core behavior (patching .meta files) and mentions runtime loading implications. However, it lacks details about side effects (e.g., whether this overwrites existing configs), error conditions, or permission requirements that would be helpful for a mutation tool.
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 efficiently structured with parameter explanations followed by a runtime usage note. Every sentence adds value, though the compression_type explanation could be slightly more concise. It's appropriately sized for a complex configuration tool with many parameters.
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?
Given the tool's complexity (7 parameters, mutation operation, no annotations, no output schema), the description does well. It covers parameter semantics thoroughly and includes runtime context. The main gap is lack of explicit behavioral warnings or error handling information that would be valuable for a configuration mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 7 parameters, the description provides excellent compensation. It explains all key parameters (folder_rel_path, bundle_name, priority, compression_type, is_remote) with examples, defaults, and platform-specific details. The description adds substantial meaning beyond the bare schema titles.
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 clearly states the specific action ('Mark a folder as an Asset Bundle by patching its .meta sidecar') and identifies the resource (folder with .meta file). It distinguishes from siblings by focusing on bundle configuration rather than asset creation or scene manipulation, making its purpose unambiguous.
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?
The description provides clear context about when to use this tool (configuring asset bundles for runtime loading) and includes a runtime usage example. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, though the context implies it's for bundle setup rather than general asset management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It explains some behavioral aspects like default illuminance values and shadow PCF mapping, but doesn't cover important behavioral traits like whether this operation is destructive/reversible, permission requirements, rate limits, or what the output contains. The description adds value but leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three focused sentences that each earn their place: first states the core purpose, second explains key parameter semantics, third provides usage context. No wasted words, front-loaded with the most important information, and well-structured for quick comprehension.
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?
Given the tool's complexity (13 parameters, no annotations) but presence of an output schema, the description does well by covering purpose, key parameter semantics, and usage context. However, for a mutation tool with many parameters and no annotations, it could benefit from more behavioral context about what the tool actually does (creates/modifies/attaches) and potential side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 13 parameters, the description compensates excellently by explaining the semantics of key parameters: 'illuminance' units (lux) with a real-world reference (65000 ≈ midday sun), and 'shadow_pcf' enumeration mapping (0=HARD, 1=SOFT, etc.). This adds crucial meaning beyond what the bare schema provides for the most important parameters.
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 clearly states the specific action ('Attach cc.DirectionalLight') and resource ('sun/moon parallel light'), distinguishing it from sibling tools like 'cocos_add_sphere_light' or 'cocos_add_spot_light' by specifying it's for directional lighting. It provides concrete technical context about what type of light component is being added.
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?
The description provides clear context about when to use this tool ('A scene typically has exactly one directional light'), which helps the agent understand its appropriate application. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the many sibling tools, preventing a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 effectively describes key traits: the animation loops forever ('Clip loops forever — attach and forget'), which is crucial for understanding its persistent nature. It also mentions the return values ('Returns {clip_uuid, clip_path, anim_component_id}'), aiding in post-invocation handling. However, it lacks details on potential side effects, error conditions, or performance implications, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. Each sentence earns its place: the first states the purpose, the next two explain key parameters with practical advice, and the final two cover behavioral aspects and return values. There is no wasted text, making it efficient and easy to parse.
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 tool with 5 parameters, no annotations, and no output schema, the description does well by covering purpose, key parameter semantics, behavioral traits (looping forever), and return values. It effectively compensates for the lack of structured data. However, it does not explain the three undocumented parameters ('scene_path', 'node_id', 'rel_dir'), which are required or have defaults, leaving some gaps in full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given a schema description coverage of 0%, the description must compensate fully. It provides detailed semantic information for two parameters ('strength' and 'period'), including default values, acceptable ranges, and design guidelines (e.g., 'Keep subtle; above ~0.15 looks anxious'). This adds significant meaning beyond the bare schema, which only lists titles and types without explanations. The description does not cover 'scene_path', 'node_id', or 'rel_dir', but the high value added for the documented parameters justifies a top score.
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 clearly states the tool's purpose: 'Looping subtle scale pulse — attention-grabber for idle UI.' It specifies the verb ('add pulse'), resource (UI element), and distinguishes it from siblings by focusing on a subtle animation effect rather than other UI components or animations listed in the sibling 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?
The description provides clear context for when to use the tool: 'attention-grabber for idle UI.' It implies usage for subtle visual feedback in inactive interfaces. However, it does not explicitly state when not to use it or name alternatives among the many sibling tools, such as other animation tools like 'cocos_add_animation' or 'cocos_add_shake.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively discloses key behavioral traits: it's a read-only operation (implied by 'List'), returns structured data (list of dicts with specific fields), and specifies platform-specific search paths. However, it doesn't mention error handling, permissions needed, or whether it requires Cocos Dashboard to be installed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded and concise. The first sentence states the core purpose, the second describes the return format, and the third specifies search paths. Every sentence adds essential information with zero waste, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple read-only tool with zero parameters and an output schema exists (implied by context signals), the description is complete. It covers purpose, return format, and platform-specific behavior. No annotations are needed for this straightforward operation, and the description provides all necessary context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage 100%), so there are no parameters to document. The description appropriately doesn't discuss parameters, which is correct for a parameterless tool. Baseline for zero parameters is 4, as it avoids unnecessary parameter discussion.
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 clearly states the verb ('List') and resource ('every locally installed Cocos Creator version'), making the purpose specific and unambiguous. It distinguishes itself from sibling tools (which are all about adding components, creating assets, or modifying projects) by focusing on system-level discovery of installed software versions.
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?
The description implies usage when you need to discover installed Cocos Creator versions, but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided about prerequisites, timing, or comparisons to other tools in the sibling list. The context is clear but lacks explicit usage directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses key behavioral traits: it's a headless build operation, applies post-build patches automatically (unless disabled), returns detailed results including exit codes and logs, and notes performance characteristics (first build is slow, subsequent builds faster with `clean_temp=False`). It does not cover error handling or permissions in depth, but provides substantial context.
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 appropriately sized and well-structured, with clear sections for platforms, flags, parameter behavior, and output. It is front-loaded with the core purpose. Some sentences could be slightly tightened (e.g., the note on `None` defaults is verbose), but overall it earns its place with useful information.
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?
Given the complexity (12 parameters, no annotations, no output schema), the description is largely complete. It explains the tool's purpose, parameter semantics, behavioral traits, and output structure. It could benefit from more explicit error handling details or prerequisites, but covers most critical aspects for a build tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 adds significant meaning beyond the schema: explains common platforms, details the purpose of boolean flags (e.g., `source_maps` for stack traces), clarifies that `None` uses defaults, describes how `build_options` works for unspecified flags, and explains the effect of `apply_patches`. This fully compensates for the lack of schema descriptions.
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 clearly states the tool's purpose: 'Headlessly build the project via `CocosCreator --build`.' It specifies the verb ('build') and resource ('project'), and distinguishes itself from sibling tools (which are mostly about adding components, managing scenes, or previewing) by focusing on the build process.
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?
The description provides clear context for when to use this tool (e.g., for building projects to various platforms, with release flags and post-build patches). It mentions an alternative for unspecified flags ('use `build_options`'), but does not explicitly state when NOT to use it or compare it to other build-related siblings (none are listed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly describes the destructive nature of the operation (removing directories) and the performance implication of 'all' level being slow. However, it doesn't mention permissions needed, whether the operation is reversible, or what happens if the tool fails mid-operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely efficient - three sentences with zero waste. The first sentence states the purpose, the second explains the default behavior, and the third explains the 'all' option with its consequence. Every sentence earns its place.
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 and no output schema, the description does well by explaining what gets removed at different levels and the performance trade-off. However, it doesn't mention error conditions, success indicators, or what happens to the project state after cleaning. Given the complexity (destructive operation), it could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well for the 'level' parameter by explaining what 'default' and 'all' mean in practical terms. However, it provides no information about the 'project_path' parameter beyond what the schema title suggests. The description adds significant value for one of the two parameters.
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 clearly states the specific action ('Clean build artifacts') and resource ('build artifacts'), with explicit scope details about different cleaning levels. It distinguishes itself from sibling tools which are all about adding/creating/modifying assets rather than cleaning.
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?
The description provides explicit guidance on when to use different levels: 'default' for basic cleaning, 'all' for comprehensive cleaning with the warning that it's slow due to re-importing assets. This gives clear context for choosing between the two main usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the transformation behavior (36-char to 23-char) and provides an example, which is helpful. However, it doesn't mention error handling (e.g., invalid UUID format), performance implications, or whether the operation is idempotent. The description adds some behavioral context but lacks completeness for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by usage context and a concrete example. Every sentence earns its place by adding essential information without redundancy. It's efficiently structured and appropriately sized for a single-parameter tool.
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?
Given the tool's low complexity (one parameter), no annotations, and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, usage, and parameter semantics effectively. However, it could improve by mentioning error cases or linking to 'cocos_decompress_uuid' for reverse operations, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well. It explains that the 'uuid' parameter is a 36-character UUID and provides an example ('5372d6f5-721e-43f6-b004-d30da1c8a9a0'), clarifying the expected format. This adds meaningful semantics beyond the bare schema, though it doesn't detail validation rules or edge cases.
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 clearly states the specific action ('Compress a 36-char UUID to Cocos Creator's 23-char short form') and distinguishes it from siblings by specifying its unique use case for custom TS script classes in scene/prefab JSON. It provides a concrete example showing the transformation, making the purpose unambiguous and distinct from other tools.
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?
The description explicitly states when to use this tool: 'Required when referencing a custom TS script class as a component `__type__` in a scene/prefab JSON.' This provides clear context for its application, distinguishing it from sibling tools like 'cocos_decompress_uuid' and other UUID-related operations by specifying the exact scenario where compression is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses the return format ({path, rel_path, uuid}), explains how to bind the material to a collider, provides default values that match the engine, and gives practical usage ranges for restitution and friction. It doesn't mention error conditions or performance implications, but covers the essential behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three focused sentences: creation purpose, binding instructions, and parameter guidance. Each sentence adds clear value without redundancy. The code snippet is appropriately brief and directly relevant to tool usage.
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 creation tool with no annotations and no output schema, the description provides good coverage of the tool's purpose, usage, and key parameters. It explains the return format and how to use the created asset. The main gap is incomplete parameter coverage (missing rolling_friction, spinning_friction, rel_dir), but overall it's quite helpful for understanding this tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 7 parameters, the description compensates well. It explains the meaning and typical usage of friction and restitution parameters with specific examples (0.6 default, 0.02 for ice, 0.3-0.9 for bouncy materials). However, it doesn't cover other parameters like rolling_friction, spinning_friction, or rel_dir, leaving some gaps in parameter understanding.
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 clearly states the verb 'Create' and the resource 'cc.PhysicsMaterial (.pmat) asset', specifying it's a physics material asset. It distinguishes from sibling tools by focusing on physics material creation rather than other asset types like animations, scripts, or nodes.
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?
The description provides clear context on when to use this tool: to create physics materials with specific friction and restitution properties. It gives examples like 'for bouncy materials' and 'for ice', but doesn't explicitly state when NOT to use it or name alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns themes 'verbatim' (exact format) and mentions they are 'bundled' (pre-installed). However, it doesn't describe the return structure (e.g., list format, JSON), error conditions, or performance characteristics. The description adds some behavioral context but leaves gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly sized with two sentences. The first sentence states the core purpose, and the second provides practical usage guidance. Every word earns its place with zero waste or redundancy.
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 parameterless tool with no output schema, the description provides good context about what's returned ('five bundled UI themes verbatim') and clear use cases. However, without annotations or output schema, it could benefit from more detail about the return format (e.g., array of theme objects) to be fully complete. The description does well given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. It focuses instead on what the tool returns and its use cases, which is the right approach for a parameterless tool.
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 clearly states the specific action ('Return all five bundled UI themes verbatim'), identifies the resource ('bundled UI themes'), and distinguishes from siblings by focusing on listing built-in themes rather than creating or modifying UI elements like most sibling tools. It provides exact scope ('five') and output format ('verbatim').
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?
The description explicitly provides two concrete use cases: 'previewing the palette before pinning one' and 'as a starting point for a custom= override passed to cocos_set_ui_theme'. It names the specific alternative tool (cocos_set_ui_theme) for when customization is needed, giving clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the tool builds a dict for use in another tool's click_events list, which implies it's a helper function with no direct side effects. However, it lacks details on error handling, validation of inputs, or whether the dict is mutable. This is adequate but leaves gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: it starts with the core purpose, lists key parameters with explanations, describes the return value, and provides a concise example workflow. Every sentence adds value without redundancy, making it efficient and easy to scan.
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?
Given 5 parameters with 0% schema coverage and no output schema or annotations, the description does a good job covering the tool's purpose, usage, and key parameters. However, it misses details on scene_path and custom_data, and lacks output format specifics beyond 'dict'. For a helper tool in a complex ecosystem, this is mostly complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 the semantics of three parameters (target_node_id, component_name, handler) in the Args section and provides an example with values, adding meaning beyond the schema. However, it omits scene_path and custom_data, leaving two parameters undocumented. This partial coverage earns a 4 for significant but incomplete compensation.
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 clearly states the tool's purpose: 'Build a cc.ClickEvent dict for use with cocos_add_button's click_events.' It specifies the verb ('Build'), resource ('cc.ClickEvent dict'), and distinguishes it from siblings by explaining its role in a workflow with cocos_add_button, unlike other tools that add components or manage scenes.
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?
The description provides explicit usage guidance: it states when to use this tool ('for use with cocos_add_button's click_events'), includes an example workflow showing how to integrate it with cocos_add_button, and implies alternatives by referencing a specific sibling tool (cocos_add_button) for the overall button creation process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses that expressions are evaluated against a running preview, that the tool handles JS exceptions gracefully ('a bad expression can't crash the tool'), and describes the return format structure. It could mention performance implications of the wait/timeout parameters or whether this affects the preview state, but covers key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with four focused sentences: purpose statement, prerequisite condition, concrete examples, and return format with error handling. Every sentence adds essential information with zero waste, making it easy to parse while being comprehensive.
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 tool with 6 parameters, no annotations, and no output schema, the description does well by explaining the core functionality, prerequisites, examples, and return format. It could more explicitly connect parameters like 'wait_ms' and 'timeout_ms' to the preview interaction behavior, but covers the essential context needed to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 6 parameters, the description compensates well by explaining the core 'expression' parameter through examples and context. It doesn't explicitly document all parameters (url, wait_ms, viewport dimensions, timeout), but the examples and context provide meaningful guidance for the primary use case. The description adds significant value beyond the bare schema.
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 clearly states the specific action ('Evaluate a JavaScript expression against the running preview and return the value'), identifies the resource ('the running preview'), and distinguishes from siblings by focusing on reading state rather than adding/modifying components like most other tools. It provides concrete examples of what can be read, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('The preview page must expose state on `window` for this to be useful') and gives a specific pattern example. However, it doesn't explicitly state when NOT to use it or name alternative tools for different scenarios, though the sibling list suggests many alternatives for different operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 excels at disclosing behavioral traits. It details idempotency (playBGM('already-playing') is no-op), error handling (unknown clip names silently skipped), persistence (volumes stored to localStorage), implementation details (auto-attaches components, swallowed write failures), and return values. This provides comprehensive behavioral context beyond basic functionality.
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 appropriately sized and front-loaded with the core purpose. Each section (Runtime API, Inspector, Implementation details, Behavioral traits, Returns) adds valuable information without redundancy. While slightly longer than minimal, every sentence earns its place by providing essential context for a complex scaffolding tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (scaffolding a full audio manager), no annotations, 0% schema coverage, and no output schema, the description provides exceptional completeness. It covers purpose, usage patterns, implementation details, behavioral characteristics, error handling, persistence, and return format. This fully compensates for the lack of structured metadata and gives the agent everything needed to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. While it doesn't explicitly mention the two parameters (project_path, rel_path), it implies their purpose through context: generating AudioController.ts in a Cocos project. The default value 'AudioController.ts' for rel_path is mentioned in the description's first sentence, and project_path is logically needed for file generation. However, it doesn't fully document parameter formats or constraints.
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 clearly states the tool generates an AudioController.ts file that serves as a singleton BGM + SFX manager. It specifies the exact resource (TypeScript file) and verb (generate/scaffold), distinguishing it from sibling tools like cocos_add_audio_source or cocos_add_audio_file which add different audio-related components rather than creating a comprehensive controller script.
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?
The description implies usage context through runtime API examples and inspector properties, suggesting this tool is for setting up audio management in Cocos projects. However, it doesn't explicitly state when to use this vs. alternatives like cocos_add_audio_source or cocos_scaffold_ui_screen, nor does it mention prerequisites or exclusions. The guidance is present but not explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses that the tool generates files, specifies dependencies (InputManager singleton), describes what fields appear in Inspector for each kind, mentions physics requirements for some kinds, and indicates the return format. It doesn't cover error conditions or performance aspects, but provides substantial behavioral context.
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 appropriately sized and front-loaded with the core purpose. Every sentence adds value: the first states what it does, the second explains dependencies, the third introduces the kind parameter, and subsequent sections detail each kind. Minor formatting issues with code-like elements slightly affect readability, but no wasted content.
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 3-parameter tool with no annotations and no output schema, the description provides substantial context: purpose, usage prerequisites, parameter semantics, behavioral details about generated files and Inspector properties, and return format. It doesn't explain error handling or edge cases, but covers the essential aspects well given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 3 parameters, the description compensates fully. It explains the 'kind' parameter with detailed descriptions of 4 options (platformer, topdown, flappy, click_only), clarifies that 'rel_path' has defaults per kind, and implies 'project_path' is required for file generation. This adds crucial meaning beyond the bare schema.
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 clearly states the tool generates a game-type-specific player controller script (Player{Kind}.ts) that reads InputManager and drives node motion. It distinguishes from siblings by specifying it's for player controller scaffolding rather than other components like audio, animation, or UI elements listed in the sibling 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?
The description provides clear context for when to use this tool: it specifies that cocos_scaffold_input_abstraction should be run FIRST, and explains which kind to use for different game types (platformer, topdown, flappy, click_only). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a write operation ('Writes settings/v2/packages/physics.json'), mentions performance implications, provides default values, and explains unit differences between 3D and 2D systems. It doesn't cover all potential behavioral aspects like error conditions or permission requirements, but provides substantial context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero wasted sentences. The first sentence establishes core functionality, subsequent sentences provide important contextual details (defaults, units, file location, performance advice), and every statement adds value. It's appropriately sized for a configuration tool with multiple parameters.
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 9-parameter configuration tool with no annotations and no output schema, the description provides substantial context: it explains the write operation, file location, key parameter semantics, performance considerations, and system differences. While it doesn't cover all parameters or potential edge cases, it gives enough information for an agent to use the tool effectively in most common scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 9 parameters, the description compensates well by explaining the meaning and usage of three key parameters (gravity components, timestep, max_sub_steps), including default values, units, and performance guidance. It doesn't cover all 9 parameters, but provides substantial semantic context for the most critical ones, significantly adding value beyond the bare schema.
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 clearly states the specific action ('Configure 3D physics') and resources (gravity, timestep, sub-step cap), distinguishing it from sibling tools like 'cocos_set_physics_2d_config' by explicitly contrasting 3D vs 2D physics systems. It provides concrete details about what gets configured rather than just restating the tool name.
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?
The description provides clear context about when to adjust certain parameters ('Bump max_sub_steps to 3-4 if physics drops frames after hitches') and distinguishes between 3D and 2D physics systems. However, it doesn't explicitly mention when to use this tool versus alternatives or provide exclusion criteria, leaving some guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key traits: the atomic replacement behavior ('Replaces the entire subpackages list'), the critical consequence of upload rejection without subpackages, and the dependency on another tool ('Pair with cocos_set_bundle_config'). It lacks details on error handling or permissions, but covers essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: it starts with the core purpose, provides format details and an example, explains the necessity (WeChat constraints), and ends with implementation notes. Every sentence adds value without redundancy, and it is appropriately sized for the tool's complexity.
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?
Given no annotations, 0% schema coverage, and no output schema, the description does well to cover purpose, usage context, behavioral traits, and parameter details. It misses explicit error cases or return values, but for a configuration tool with clear constraints and dependencies, it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 provides detailed semantics for 'subpackages': specifying the required format with name and root fields, giving an example, and explaining the root path convention ('assets/<dir>'). It does not explain 'project_path', leaving a gap, but the coverage for the complex array parameter is substantial, justifying a score above baseline.
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 clearly states the tool's purpose with specific verbs ('Configure', 'Replaces') and resource ('WeChat mini-game subpackages'). It distinguishes from sibling tools by focusing on subpackage configuration, unlike other tools that handle assets, scripts, or scene elements. The example reinforces the specific functionality.
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?
The description provides clear context for when to use this tool: to avoid WeChat's 4 MB main package limit and prevent upload rejection. It explicitly mentions pairing with 'cocos_set_bundle_config' for complete implementation. However, it does not specify when NOT to use it or list direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key traits: the tool starts a server, returns specific data ({port, url, serving}), is idempotent, and replaces existing servers on the same port. However, it lacks details on error conditions, timeout behavior, or server lifecycle management, which keeps it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by return values and behavioral notes in subsequent sentences. Every sentence adds value without redundancy, making it efficiently structured and appropriately sized.
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?
Given the tool's complexity (starting a server with 3 parameters) and no annotations or output schema, the description does well by covering purpose, prerequisites, idempotency, and return values. However, it lacks details on error handling or server configuration, which are relevant for a mutation tool, preventing a perfect score.
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?
The schema description coverage is 0%, so the description must compensate. It mentions the 'build/<platform>/ directory', which hints at the 'platform' parameter, and 'port' in the idempotency note, but does not explain 'project_path' or provide format details. Since it adds some context but not full parameter semantics, a baseline 3 is appropriate.
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 clearly states the specific action ('Start a local HTTP server') and the resource being served ('the build/<platform>/ directory'), distinguishing it from sibling tools like 'cocos_build' (which prepares the build) or 'cocos_stop_preview' (which stops the server). It provides a precise verb+resource combination that is not tautological.
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?
The description explicitly states when to use this tool ('Run `cocos_build` first') and provides a clear prerequisite. It also distinguishes it from alternatives by noting idempotency and replacement behavior, which helps the agent understand when to invoke it versus other server-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key traits: it's idempotent ('does nothing if the sub already exists'), it modifies metadata ('add the f9941 (sprite-frame) sub'), and it returns a value ('Returns the updated meta dict'). However, it doesn't mention potential errors (e.g., invalid paths) or side effects, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by context, behavioral note, and return value in three concise sentences. Each sentence adds essential information without redundancy, making it efficient and well-structured for quick understanding.
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?
Given 1 parameter, no annotations, and no output schema, the description provides good context: purpose, usage, idempotency, and return value. It covers the tool's role in the Cocos workflow but lacks details on parameter semantics and error handling. For a simple mutation tool, this is mostly complete but could be enhanced with more parameter guidance.
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?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It implies 'meta_path' refers to the path of a PNG meta file needing upgrade, but doesn't specify format (e.g., relative/absolute path) or constraints. This adds minimal semantic value beyond the schema's title 'Meta Path', meeting the baseline for low coverage without fully compensating.
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 clearly states the specific action ('Upgrade a texture-only PNG meta'), the resource ('PNG meta'), and distinguishes it from siblings by explaining it adds a 'sprite-frame sub' for use with 'cc.Sprite', unlike other tools that add components or manage scenes. It explicitly mentions the context of Cocos Creator's CLI auto-generation, making the purpose distinct and well-defined.
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?
The description provides explicit guidance on when to use this tool: when Cocos Creator's CLI generates a 'type: texture' meta for a fresh PNG and you need to reference it from 'cc.Sprite'. It also states when not to use it: if the sub already exists, as the tool is idempotent. This clearly differentiates it from sibling tools that handle other asset types or operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it creates UI elements (implies mutation), returns IDs for later modification, inherits colors from theme, and provides default button behavior. It doesn't mention permissions, error handling, or rate limits, but covers the essential creation and return mechanics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three paragraphs: purpose and efficiency gain, theme inheritance and button details, and return value. Every sentence adds value without redundancy, and key information is front-loaded.
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 complex UI creation tool with 8 parameters, 0% schema coverage, no annotations, and no output schema, the description does well by explaining the tool's purpose, parameter semantics, and return value. It could improve by mentioning error cases or prerequisites, but it covers the essential context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 8 parameters, the description adds significant value beyond the schema. It explains the 'buttons' parameter structure in detail (including variants like 'primary', 'secondary', 'danger', 'ghost'), mentions default values for buttons and body, and clarifies that colors inherit from theme, which helps interpret parameters like scene_path and parent_node_id in context.
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 clearly states the tool builds a centered modal dialog with specific components (backdrop, panel, title, body, buttons) and distinguishes it from siblings by noting it replaces 15+ primitive calls. It provides a specific verb ('Build') and resource ('centered modal dialog').
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?
The description provides clear context for when to use this tool (to create modal dialogs efficiently) and mentions inheritance from UI theme set via another tool, but does not explicitly state when not to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses key behavioral traits: it generates a '.anim' clip in a default directory (with override option), attaches specific components ('cc.UIOpacity' and 'cc.Animation'), sets initial opacity to 0 to prevent flashing, and enables play_on_load. It also explains the effect of the 'delay' parameter. However, it does not cover error handling, permissions, or side effects like file overwrites, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by implementation details and a return value summary. Every sentence adds value—explaining file generation, component attachment, parameter effects, and outputs—with zero waste. It is structured for quick comprehension.
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?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description is largely complete. It explains what the tool does, how it behaves, parameter roles, and return values. However, it lacks explicit error cases, prerequisites (e.g., node existence), or output schema details, which could be helpful for an agent. The return value description is provided, mitigating the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 adds significant meaning: 'rel_dir' overrides the default 'assets/animations/' directory, 'delay' holds at 0 opacity before the ramp for staggering fades, and the tool implicitly uses 'scene_path' and 'node_id' to target a node. It also mentions 'duration' as part of the fade ramp. This clarifies all 5 parameters beyond their schema titles, fully compensating for the lack of schema descriptions.
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 clearly states the tool's purpose: 'Fade a node from transparent → opaque at scene start.' It specifies the verb ('Fade'), resource ('a node'), and scope ('at scene start'), distinguishing it from siblings like 'cocos_add_scale_in' or 'cocos_add_slide_in' by focusing on opacity animation. This is specific and actionable.
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?
The description provides clear context for usage: 'at scene start' and 'useful for staggering sibling fades.' It implies when to use it (for fade-in effects) but does not explicitly state when not to use it or name alternatives among the many sibling tools. The guidance is helpful but not exhaustive regarding alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It effectively describes the tool's behavior: it creates a centered spinner with rotation animation, explains the rotation period meaning, and specifies the return value structure. It doesn't mention side effects, permissions, or rate limits, but provides substantial behavioral context for a UI 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured: first sentence states the core purpose, subsequent sentences explain key parameters, then provides a practical tip, and ends with return values. Every sentence adds value with zero waste, making it easy to scan and understand.
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 6-parameter tool with no annotations and no output schema, the description provides excellent context about parameters, behavior, and return values. The main gap is lack of explicit error conditions or prerequisites, but it covers the essential usage scenario thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 6 parameters, the description compensates excellently. It explains sprite_frame_uuid's purpose (for rotation animation vs None for text-only), clarifies rotation_period meaning (full 360° revolution time), provides default context for text ('Loading...'), and gives practical guidance on generating the sprite asset.
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 clearly states the tool's purpose: it adds a centered rotating icon with optional caption (loading spinner). It distinguishes from siblings by specifying this is specifically for loading indicators, unlike general UI components like buttons or labels in the sibling list.
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?
The description provides clear context on when to use this tool (for loading indicators) and includes a helpful tip on how to generate the required sprite asset. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It effectively discloses key behavioral traits: it's a one-shot animation (not continuous), oscillates around current position, decays linearly, and returns animation identifiers. It clarifies that it animates 'around the node's CURRENT _lpos', which is crucial for understanding its effect. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: it opens with the core purpose, details parameters with examples, adds a critical usage note, and ends with return values. Every sentence adds essential information without redundancy, making it easy to parse.
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?
Given 6 parameters with 0% schema coverage and no output schema, the description does an excellent job explaining most parameters and the tool's behavior. However, it does not cover 'rel_dir' or potential errors, and the return values are listed without explanation. For a mutation tool with no annotations, it's very complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully. It provides detailed semantics for 'axis' (mapping values to specific feedback types), 'intensity' (peak amplitude in logical pixels), and 'duration' (linear decay time). It also implies 'scene_path' and 'node_id' target a node, though 'rel_dir' is not explained. This adds significant value beyond the bare schema.
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 clearly states the tool's purpose as a 'one-shot position wobble' for 'damage / error / impact feedback', specifying the action (add shake), resource (node position), and context (feedback animation). It distinguishes from siblings like 'cocos_add_bounce_in' or 'cocos_add_pulse' by focusing on oscillation decay for impact effects.
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?
The description provides clear context for when to use it ('for damage / error / impact feedback') and includes a procedural note ('position the node first, then attach'), which guides proper sequencing. However, it does not explicitly mention when not to use it or name alternative tools for similar effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: color sourcing from UI theme, text wrapping/overflow behavior, conditional divider rendering (only when body is present and show_divider=True), alignment application, and return value structure with nulls for absent pieces. It doesn't mention error conditions, performance characteristics, or mutation effects on the scene.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero wasted sentences. It opens with the core concept, explains the rationale, details implementation behaviors, and concludes with return values. Every sentence adds essential information about tool behavior, constraints, or outputs.
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 complex UI creation tool with 8 parameters, 0% schema coverage, no annotations, and no output schema, the description provides substantial context about behavior, constraints, and return values. It explains the conditional logic, styling defaults, and output structure. However, it doesn't cover error cases, scene modification effects, or provide examples of typical usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 8 parameters, the description compensates exceptionally well. It explains the semantic meaning of title, subtitle, body, and show_divider parameters, clarifies the conditional relationship between body and divider, describes alignment options, and implies width controls block dimensions. It provides crucial context missing from the bare schema.
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 clearly states the tool's purpose: it creates a styled text block with title, optional subtitle, optional divider, and optional body. It specifies this is a composite UI element that pulls colors from the active theme and handles text wrapping/overflow. The description distinguishes it from sibling tools by explicitly mentioning it replaces composing from 4-6 'add_label' calls.
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?
The description provides clear context for when to use this tool: for the 'most frequently rebuilt pattern in AI UI code' to avoid composing from multiple 'add_label' calls. It mentions an alternative approach (using 'add_label') but doesn't explicitly state when NOT to use this tool or compare it to other text-related sibling tools like 'cocos_add_label' or 'cocos_add_richtext'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining key behaviors: it creates files (marker + meta), automatically packs PNGs at build time, copies PNGs if provided, and returns specific data including a reusable folder path. It mentions build-time integration but could elaborate more on error conditions or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by operational details, parameter explanations, and return values. Every sentence adds value—no wasted words—and it efficiently covers complex functionality in a compact format.
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 complex tool with 12 parameters, no annotations, and no output schema, the description is highly complete: it explains purpose, usage, parameters, and return values. However, it lacks explicit error handling or permission requirements, and the output schema absence means return value details are only partially covered in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage for 12 parameters, the description compensates excellently by explaining the optional nature of 'png_paths', listing all tunable parameters with their defaults and purposes (max_width, padding, algorithm, etc.), and clarifying the role of 'rel_dir' through the default folder example. This adds substantial meaning beyond the bare schema.
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 clearly states the tool creates an AutoAtlas bundle for Cocos 3.8 build-time packing, specifying it generates a marker file and metadata. It distinguishes from sibling tools by focusing on sprite atlas creation rather than general asset addition or scene manipulation, with no tautology present.
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?
The description provides clear context on when to use the tool (for automatic sprite packing at build time) and mentions that PNGs can be added later without re-running the tool. However, it does not explicitly state when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key traits: it's a read-only comparison tool (implied by 'report the change'), explains the threshold parameter's role in handling PNG compression noise, details the return format with specific metrics, and clarifies dependencies (Pillow-based, no playwright/chromium). It doesn't mention error handling or performance limits, but covers core behavior well for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficiently packed. It starts with the core purpose, provides a practical use case example, explains the threshold parameter, details the return format, and ends with implementation notes. Each sentence adds value without redundancy, and the information is front-loaded with the most important details first.
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?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is quite complete. It covers purpose, usage context, parameter semantics, return values, and implementation details. The only minor gap is the lack of explicit error cases or limitations documentation, but for a comparison tool with clear parameters and return format, it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It adds significant meaning beyond the schema: explains that 'before_png_path' and 'after_png_path' are file paths for PNG screenshots, clarifies that 'threshold' is 'a per-channel absolute delta; pixels below are considered identical (8 rejects typical PNG compression noise)' with a default value context, and notes both inputs are required. This provides complete parameter understanding despite the schema's lack of descriptions.
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 clearly states the tool's purpose: 'Compare two PNG files on disk and report the change.' It specifies the resource (PNG files) and verb (compare and report), and distinguishes itself from sibling tools by focusing on image comparison rather than scene manipulation or asset creation. The example use case further clarifies its role in confirming visual changes.
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?
The description provides clear context for when to use the tool: to confirm whether an action had a visible effect by comparing screenshots before and after. It mentions prerequisites ('Both inputs must be file paths; save via cocos_screenshot_preview first') and notes it's 'pure Pillow — it does NOT need playwright / chromium installed,' which helps differentiate it from other screenshot-related tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: it applies patches to a build directory, stops on first error to prevent cascading failures, and returns a structured result object. However, it doesn't mention permissions, rate limits, or whether it's idempotent, leaving some gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero wasted sentences. It front-loads the core purpose, then provides usage guidelines, return format, and behavioral detail—all in four concise sentences that each serve a distinct purpose.
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 mutation tool with no annotations and no output schema, the description does well by explaining the return format and error behavior. However, it doesn't fully cover parameter details or potential side effects, leaving some gaps given the tool's complexity and lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 3 parameters, the description adds significant value beyond the schema. It explains that 'platform' determines which patches are applied and that 'dry_run=True' enables preview mode. However, it doesn't clarify 'project_path' semantics or parameter formats, leaving some ambiguity.
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 clearly states the specific action ('Apply registered patches') to a specific resource ('build/<platform>/') with a clear scope ('for platform'). It distinguishes itself from sibling tools like 'cocos_build' by explaining its specialized role in post-build patching, making the purpose immediately understandable.
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?
The description provides explicit guidance on when to use this tool versus alternatives. It states that 'cocos_build invokes this automatically on success' and specifies two direct-use scenarios: 'dry-run preview' and 're-apply without rebuilding.' This gives clear context for when to call it directly versus relying on the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes the tool's behavior: it walks up from the scene file to find package.json if project_path is not provided, and returns a structured result with fields like 'ok', 'required', 'enabled', 'disabled', and 'actions'. It also explains what happens when ok=False (actions list next steps). However, it doesn't mention error handling, performance implications, or side effects like file system access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: it starts with the core purpose, explains the problem it solves, provides parameter usage notes, and describes the return value—all in a compact format. Every sentence adds value without redundancy, making it easy to parse and understand quickly.
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?
Given the tool's complexity (validating engine modules against scene components) and lack of annotations or output schema, the description does a good job of covering key aspects: purpose, usage, parameters, and return structure. It could be more complete by detailing error cases or performance considerations, but it provides sufficient context for an agent to use the tool effectively in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 2 parameters, the description compensates well. It explains the semantics of 'project_path' (defaults to null, walks up from scene file, use when scene is outside project) and implies 'scene_path' is required for the audit. While it doesn't detail parameter formats or constraints, it adds meaningful context beyond the bare schema.
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 clearly states the tool's purpose: 'Cross-check scene components against the project's engine.json' to catch a specific runtime failure scenario. It explicitly distinguishes this from sibling tools by focusing on module validation rather than scene creation, component addition, or other operations listed in the sibling tools.
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?
The description provides explicit guidance on when to use this tool: for detecting 'build succeeded, game broken at runtime' failures due to disabled engine modules. It also specifies when to pass the project_path parameter (when the scene is outside the project) and mentions an alternative tool ('cocos_set_engine_module') for remediation, giving clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes the tool's behavior: it's a mutation tool (executes operations on scenes), explains the performance optimization (single file read/write cycle), details the return structure ({object_count, ops_executed, results, named_results}), and mentions implementation details like back-references. However, it doesn't cover potential error conditions, permissions needed, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with purpose and usage guidelines, but becomes very lengthy due to exhaustive listing of all supported operations. While this detail is valuable, it makes the description quite long. Some of the operation details (like specific parameter names for each component type) might be better placed in a separate reference rather than in the core description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch mutation operations with many possible operation types), no annotations, no output schema, and 0% schema coverage, the description provides exceptional completeness. It covers purpose, usage guidelines, performance characteristics, parameter semantics, return structure, back-reference system, and exhaustive documentation of all supported operations. The only minor gap is lack of error handling information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the 2 parameters, the description fully compensates by providing extensive semantic information. It explains that 'operations' is an array of dicts with 'op' keys and operation-specific params, documents all supported operation types with their parameter structures, and provides detailed examples of back-reference syntax ('$N', '$name'). The 'scene_path' parameter's purpose is implied through context.
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 clearly states the tool's purpose: 'Execute multiple scene operations in a single file read/write cycle.' It specifies the verb ('execute') and resource ('scene operations'), and distinguishes it from siblings by explicitly naming alternative tools (cocos_add_*, cocos_set_*, etc.) and providing a rule of thumb for when to use this batch tool instead.
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?
The description provides explicit guidance on when to use this tool vs alternatives: 'PREFERRED for ≥3 sequential mutations on the same scene' and 'Rule of thumb: if you would otherwise call... three or more times in a row on the same scene, use this tool instead.' It also mentions performance benefits (~80× faster) and lists specific sibling tools to replace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the operation creates a new entity ('Append a new cc.Node'), returns an array index, and that the node starts without components. It doesn't mention permissions, error conditions, or whether this is a destructive operation, but covers the core behavior adequately 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: first states purpose and output, second explains layer defaults, third provides critical follow-up guidance. Each sentence adds essential information, and the structure is front-loaded with the core functionality.
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?
Given 9 parameters with 0% schema coverage and no annotations, the description does well by explaining layer behavior and component follow-up. However, it doesn't address all parameters or potential error cases. The presence of an output schema means return values are documented elsewhere, so this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 the 'layer' parameter's default (UI_2D) and special value for camera nodes (1073741824), and implies that 'parent_id' determines hierarchy. However, it doesn't clarify other parameters like 'scene_path' or 'name' semantics, leaving some gaps.
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 clearly states the specific action ('Append a new cc.Node'), target resource ('under parent_id'), and output ('return its array index'). It distinguishes from sibling tools like 'cocos_create_scene' (creates scenes) or 'cocos_duplicate_node' (copies existing nodes) by focusing on creating a basic node with positioning and layer defaults.
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 provides explicit when-to-use guidance: 'The new node has no components yet — call cocos_add_uitransform, cocos_add_sprite etc. to attach them.' This tells the agent to use this tool for initial node creation and other tools for adding functionality. It also specifies layer defaults and camera node usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses key behavioral traits: the tool is a generator (not destructive), uses HSL math for color computation, includes fixed colors for success/warn/danger, and returns a dict ready for another tool. However, it doesn't mention error handling, performance, or rate limits.
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 well-structured and front-loaded with the core purpose. It uses bullet points for algorithm details and includes a code example, but could be slightly more concise by reducing some explanatory text (e.g., 'severity readability trumps brand consistency').
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?
Given no annotations, 0% schema coverage, and no output schema, the description does an excellent job covering purpose, usage, parameters, and behavior. It explains the return format and integration with other tools. However, it lacks details on error cases or validation rules for 'seed_hex'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully explains both parameters: 'seed_hex' is described as 'the game's primary/brand color', and 'mode' is explained as 'dark' or 'light' with a default of 'dark'. This adds crucial meaning beyond the bare schema.
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 clearly states the tool's purpose: 'Generate a coherent UI palette from one brand color' with specific details about the algorithm (HSL math) and output format. It distinguishes from siblings like 'cocos_set_ui_theme' by focusing on derivation rather than application.
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?
The description provides explicit usage guidance: it includes a 'Typical use' example with code, explains when to use it (to create a palette from a seed color), and mentions integration with 'cocos_set_ui_theme'. It also implies when not to use it (e.g., for fixed themes or manual color specification).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses the multi-step flow (generate PNG → remove background → write meta), mentions authentication needs (ZHIPU_API_KEY), and notes free providers. However, it doesn't cover rate limits, error handling, or output format details beyond the example's 'sprite_frame_uuid'.
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 well-structured and front-loaded with the core purpose. Every sentence adds value: setup details, flow explanation, example, and style list. It could be slightly more concise by integrating the style list into the example, but overall it's efficient with minimal waste.
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?
Given the tool's complexity (AI generation + import), 9 parameters, no annotations, and no output schema, the description does well: it covers purpose, setup, flow, example, and styles. However, it lacks details on output structure beyond the example's 'sprite_frame_uuid', and doesn't explain all parameters fully (e.g., 'as_resource').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 9 parameters, the description compensates excellently: it explains 'project', 'prompt', 'name', 'style' (with list), 'provider' (with options), and implies 'transparent' via background removal. It doesn't cover 'width', 'height', or 'as_resource', but provides substantial context for most parameters.
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 clearly states the tool's purpose: 'Generate a game asset via AI and import it into the project in one step.' It specifies the verb ('generate'), resource ('game asset'), and distinguishes from siblings by focusing on AI generation and import, unlike other tools that add existing assets or components.
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?
The description provides explicit usage guidance: it explains when to use (for AI-generated assets), mentions built-in providers with setup instructions, and includes an example showing how to integrate the result with sibling tool 'cocos_add_sprite'. It also lists available styles to guide parameter selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses the return format ('Returns {r, g, b, a}') and the tool's purpose as a safe conversion utility (implied non-destructive, read-only). However, it doesn't mention error handling for invalid hex codes or performance considerations, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by return format and usage context. Every sentence adds value: the first defines the conversion, the second specifies output, and the third explains the use case. No wasted words, and it's appropriately sized for a simple utility tool.
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 simple conversion tool with 2 parameters, 0% schema coverage, no output schema, and no annotations, the description is largely complete. It covers purpose, usage, output format, and parameter context. The main gap is lack of explicit error handling details, but given the tool's simplicity, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 the 'hex_color' parameter by listing supported formats ('#rrggbb / #rgb / #rrggbbaa') and hints at 'alpha' by mentioning RGBA output, though it doesn't explicitly describe the 'alpha' parameter's role or default. This adds significant value beyond the bare schema.
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 clearly states the specific action ('Convert') and resource ('#rrggbb / #rgb / #rrggbbaa to RGBA ints'), distinguishing it from sibling tools which are all about adding components, managing scenes, or other operations unrelated to color format conversion. It precisely defines the transformation being performed.
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?
The description explicitly states when to use this tool: 'Lets the caller paste CSS / design-tool hex codes without hand-translating to int quadruples (a common source of off-by-one color bugs).' It provides a clear use case and distinguishes it from manual alternatives, though it doesn't name specific sibling alternatives since none are color-related.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: it copies a template, patches `package.json` with a UUID and version, and creates `assets/` subdirectories. However, it lacks details on error handling, permissions required, or whether the operation is idempotent, which are important for a tool that writes to the filesystem.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by specific actions and a usage guideline. Each sentence adds value: the first states the overall goal, the second details the steps, and the third provides prerequisite advice. There is no wasted text, and the structure is logical and efficient.
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?
Given the complexity of initializing a project with 4 parameters, no annotations, and no output schema, the description does a good job covering the core functionality and usage. It explains what the tool does, key parameters, and a prerequisite step. However, it lacks information on output (e.g., success confirmation or error messages) and does not fully document all parameters, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 the purpose of `dst_path` (where the project is copied), `creator_version` (patched into `package.json`), and `template` (default is 'empty-2d'). It does not mention `project_name`, leaving one parameter undocumented, but provides meaningful context for three out of four parameters, which is substantial given the lack of schema descriptions.
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 clearly states the specific action ('Initialize a new Cocos Creator project from a template') and resource ('Cocos Creator project'), distinguishing it from siblings that focus on adding components, managing assets, or building projects. It explicitly mentions copying a template, patching files, and creating directories, which differentiates it from other initialization or creation tools in the list.
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?
The description provides explicit guidance on when to use this tool: 'Use `cocos_list_creator_installs` first to see available versions.' This indicates a prerequisite step and suggests an alternative tool for checking versions, helping the agent understand the proper sequence and context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses the tool is non-destructive (returns warnings, not errors), specifies the exact return format {ok, scene_path, warnings:[...]}, and explains that warnings are 'non-fatal' with the caller deciding fixes. It doesn't mention performance characteristics or rate limits, but covers core behavioral aspects adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first sentence establishes purpose, bullet points provide concrete examples, final sentences explain return format and warning nature. Every sentence adds value with zero wasted words, and key information is front-loaded.
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 tool with no annotations, no output schema, and 0% schema coverage, the description does remarkably well. It explains purpose, usage, behavior, and return format. The only minor gap is not explicitly mentioning the single input parameter, but the return format implies it. Given the complexity (UX linting tool), this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 1 parameter, so the description must compensate. While it doesn't explicitly mention the 'scene_path' parameter, the return format includes 'scene_path' and the context implies it analyzes a scene. The description provides rich semantic context about what the tool checks (touch targets, label overflow, UI layer), which helps understand what the parameter represents beyond just a path string.
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 clearly states the tool performs a 'Non-structural UI quality check' and specifies it's a 'complement to cocos_validate_scene.' It explicitly distinguishes itself from siblings by focusing on UX issues that build cleanly but produce bad user experience, unlike the many 'add_' and 'create_' sibling tools.
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?
The description provides explicit guidance: 'Flags issues that build + load cleanly but produce bad UX' and positions it as 'complement to cocos_validate_scene.' It gives three concrete examples of when to use it (small touch targets, label overflow, wrong UI layer) and states 'All warnings are non-fatal; the caller decides what to fix,' clarifying its advisory role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: it captures a screenshot (implying a read-only operation), returns the PNG as an MCP Image for inline display, and mentions dependencies and installation requirements. However, it lacks details on error handling, performance implications, or what happens if the preview URL is not accessible, which prevents a perfect score.
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 well-structured and front-loaded with the core purpose, followed by usage context, parameter guidance, and dependency notes. Each sentence adds value, but the inclusion of installation commands, while necessary, slightly reduces conciseness. Overall, it is efficient and avoids redundancy, though it could be slightly tighter.
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 tool with 6 parameters, 0% schema coverage, no annotations, and no output schema, the description does a strong job by covering purpose, usage context, parameter semantics, dependencies, and return format. It misses some behavioral details like error cases or performance limits, but given the complexity and lack of structured data, it is largely complete and actionable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage for 6 parameters, the description compensates excellently by explaining the semantics of key parameters. It details the purpose of 'wait_ms' ('gives the page time to run scripts after `networkidle` fires') with context on default values and when to adjust ('Bump for heavy 3D scenes'), and implies the use of 'url' for the preview target. This adds significant meaning beyond the bare schema.
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 clearly states the specific action ('Capture a PNG screenshot') and target resource ('of a running preview URL via Playwright'), distinguishing it from sibling tools like 'cocos_screenshot_preview_diff' by focusing on direct capture rather than comparison. It explicitly mentions the tool's role in the visual-feedback loop after build and preview steps, making its purpose distinct and well-defined.
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?
The description provides explicit guidance on when to use this tool ('after `cocos_build` + `cocos_start_preview` call this to see what the browser actually rendered') and why ('iterate on UI with sight, not guesswork'). It also mentions an optional dependency and installation steps, which are crucial prerequisites for correct usage, ensuring the agent knows the necessary setup before invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes the tool's behavior: it enables or disables modules, requires post-action cleanup ('clean library+temp and rebuild'), and has dependencies (e.g., enabling modules before using specific components). However, it lacks details on error handling, permissions, or rate limits, which prevents a perfect score.
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 appropriately sized and front-loaded, starting with the core purpose. Every sentence adds value, such as prerequisites and cleanup steps. However, the list of common modules is lengthy but necessary for clarity, slightly reducing conciseness. Overall, it avoids waste and is well-structured.
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?
Given the tool's complexity (module configuration with dependencies), no annotations, and no output schema, the description is largely complete. It covers purpose, usage, parameters, and behavioral steps. A minor gap is the lack of output details (e.g., success/failure response), but this is mitigated by the tool's straightforward nature. It adequately supports agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds significant meaning: 'project_path' is implied by context (Cocos project), 'module_name' is explained with examples like 'physics-2d-box2d' and a list of common modules, and 'enabled' is clarified as 'Enable/disable'. This fully documents the parameters beyond the schema's basic titles.
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 clearly states the verb 'Enable/disable' and the resource 'engine module', with specific examples like 'physics-2d-box2d, spine, dragon-bones, tiled-map, etc.' It distinguishes this tool from siblings by focusing on module configuration rather than adding components or assets, as seen in tools like 'cocos_add_spine' or 'cocos_add_tiled_map'.
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?
The description provides explicit usage guidelines, including when to use (e.g., 'MUST enable 'physics-2d-box2d' before using RigidBody2D/Collider2D') and post-action steps ('After changing modules, clean library+temp and rebuild'). It lists common modules, helping users select appropriate ones without specifying alternatives since this is a unique configuration tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behavioral traits: the operation is idempotent (important for retry safety), has a prerequisite (meta must be sprite-frame type), and specifies the purpose (setting borders for sliced sprites). However, it doesn't mention error conditions, performance implications, or what happens when borders exceed image dimensions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three focused sentences: purpose statement, usage context, and prerequisites. Each sentence adds distinct value without redundancy. The information is front-loaded with the core functionality stated immediately.
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 mutation tool with no annotations and no output schema, the description provides good coverage of purpose, prerequisites, and usage context. It explains the 'why' behind the tool and when to use it. However, it doesn't describe what the tool returns or error conditions, which would be helpful given the lack of structured output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 5 parameters, the description must compensate. It explains that parameters represent border values 'in pixels' and mentions 'top, bottom, left, right' (though not explicitly listing all four). However, it doesn't fully explain the meta_path parameter's format or the meaning of zero values. The description adds meaningful context but doesn't completely document all parameters.
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 clearly states the specific action ('Set 9-slice border'), target resource ('existing sprite-frame meta'), and unit of measurement ('in pixels'). It distinguishes itself from sibling tools by focusing on sprite-frame border configuration rather than creation, attachment, or other operations listed among siblings.
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?
The description provides explicit guidance on when to use this tool ('Required before using a PNG with cc.Sprite type=SLICED'), when not to use it ('The meta must already be sprite-frame type'), and an alternative action to take first if needed ('run `cocos_upgrade_image_meta` first if it's still texture-only'). It also mentions typical use cases ('rounded buttons, UI panels, dialog backgrounds').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes the tool's effect (pinning a theme for subsequent UI element calls), default behavior, fallback logic, and the structure of custom themes. However, it doesn't mention whether this is a persistent configuration, if it affects existing UI elements, or any permission requirements.
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 appropriately sized and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds valuable information (built-in themes, custom dict structure, vocabulary requirements, default behavior). While slightly dense, there's minimal waste - every sentence serves a clear purpose in explaining tool behavior.
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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description provides comprehensive context about what the tool does, when to use it, parameter details, and behavioral characteristics. It explains the relationship with sibling UI element tools and provides complete documentation for both theme options. The main gap is lack of information about persistence or scope of the theme application.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 3 parameters, the description compensates fully by explaining all parameters: 'project_path' is implied through context, 'theme' is detailed with built-in names and fallback behavior, and 'custom' is thoroughly documented with its structure ({color, font_size, spacing, radius}) and vocabulary requirements. The description adds significant meaning beyond the bare schema.
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 clearly states the tool's purpose with specific verbs ('Pin a UI theme') and resources ('every subsequent cocos_add_label/cocos_add_button/cocos_add_sprite call'), distinguishing it from sibling tools that add UI elements rather than configure their styling. It explicitly explains the effect ('produces a visually consistent game') rather than just restating the name.
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?
The description provides explicit guidance on when to use this tool ('so every subsequent...call with color_preset=.../size_preset=... resolves through the same design tokens') and includes clear alternatives (built-in themes vs. custom dict). It also specifies the default behavior ('Calling with no args pins dark_game') and fallback logic ('missing preset names fall through to dark_game defaults').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It effectively discloses behavioral traits: it's a read-only validation tool (implied by 'sanity-check'), returns structured output ({valid: bool, object_count: int, issues: [...]}), and has specific limitations ('structural-only'). However, it doesn't mention error handling or performance aspects like timeouts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by output details and usage guidelines. Every sentence earns its place by adding critical information without redundancy, making it highly efficient and well-structured.
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?
Given the tool's complexity (validation with output details), no annotations, and no output schema, the description does a good job covering purpose, usage, and output structure. However, it lacks details on error cases or input parameter specifics, leaving minor gaps for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It doesn't explicitly mention the 'scene_path' parameter, but the context ('a scene file') and usage note imply it takes a scene path. This adds some meaning beyond the bare schema, though not detailed syntax or format.
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 clearly states the specific verb ('sanity-check') and resource ('a scene file'), with explicit details on what it checks ('ref ranges, type tags, parent linkage'). It distinguishes from sibling tools by contrasting with 'cocos_audit_scene_modules' for a different type of validation.
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 provides explicit guidance on when to use ('Run this after building a scene to catch dangling __id__ references before invoking `cocos_build`') and when not to use ('structural-only'), with a clear alternative named ('cocos_audit_scene_modules') for different checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: it's a write operation (creates/updates files and attaches components), explains idempotent mode ('preserve an existing UUID on overwrite'), mentions potential errors ('silently-broken component'), and details the return structure. However, it doesn't cover permissions, rate limits, or error handling beyond the UUID issue.
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 well-structured and appropriately sized. It front-loads the core purpose, provides context about the problem it solves, details parameters in a clear section, and shows the return format. While comprehensive, every sentence earns its place by adding necessary information. The only minor improvement would be slightly tighter formatting of the parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, no output schema), the description provides complete context. It explains the tool's purpose, when to use it, detailed parameter semantics, behavioral characteristics, and the exact return structure. For a mutation tool with rich functionality and no structured metadata, this description adequately compensates with thorough textual documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 7 parameters, the description fully compensates by providing detailed semantic explanations for all parameters. It explains what each parameter does (e.g., 'rel_path follows cocos_add_script's prefix rules'), provides usage examples ('Use {"__id__": N} for node/component refs'), and clarifies optional behavior ('Omit to let the underlying add_script preserve an existing UUID'). This adds substantial value beyond the bare schema.
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 clearly states the tool's purpose: 'Write a TS script file + attach it as a component in ONE call.' It specifies the exact action (write and attach), the resource (TS script file), and distinguishes it from sibling tools by explaining it replaces the problematic 3-call sequence involving 'cocos_add_script' and 'cocos_compress_uuid'.
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?
The description provides explicit usage guidelines by explaining when to use this tool ('Replaces the 3-call sequence agents ran dozens of times per session') and when not to use alternatives (avoiding the 'two same-named cocos_add_script tools' that cause friction). It names specific sibling tools ('cocos_add_script', 'cocos_compress_uuid') and describes the problems they cause, giving clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: it's a creation/mutation tool (implied by 'attach'), specifies error handling ('Raises ValueError on unknown shape'), explains parameter interaction ('relevant shape knobs are read based on the choice; the others are ignored'), and details the return value. However, it doesn't cover aspects like side effects, performance, or permission requirements, which could be relevant for a physics body tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage context, parameter details, and return value. Every sentence adds value: the first states the purpose, the second provides usage context, the third explains shape parameter, the fourth covers body_type, the fifth adds error behavior, and the sixth specifies the return. There is no wasted text.
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 complex tool with 21 parameters, no annotations, and no output schema, the description does a very good job. It covers purpose, usage, key parameters, error handling, and return value. However, given the high parameter count, it doesn't explain all parameters (e.g., gravity_scale, linear_damping), leaving some semantics undocumented, which is a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given the schema description coverage is 0%, the description must compensate, which it does excellently. It explains the 'shape' parameter with specific values ('box', 'circle', 'polygon') and how they affect other parameters. It details 'body_type' with numeric mappings (0=Static, 1=Kinematic, 2=Dynamic). It also clarifies parameter dependencies and defaults, adding significant meaning beyond the bare schema.
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 clearly states the tool's purpose: 'Attach cc.RigidBody2D + a shape collider in one call.' It specifies the verb ('attach'), the resources (RigidBody2D and collider), and distinguishes it from sibling tools by explicitly contrasting with the 2-call pattern using cocos_add_rigidbody2d and cocos_add_box_collider2d, which are listed as siblings.
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?
The description provides explicit usage guidelines: it states when to use this tool ('Replaces the 2-call pattern every Bird / Pipe / Enemy needed') and names specific alternatives (cocos_add_rigidbody2d and cocos_add_box_collider2d). It also implies when not to use it by suggesting the separate tools for more granular control.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behavioral traits: the tool attaches a VideoPlayer component (implying a mutation/write operation), explains the resource_type parameter's meaning (0=REMOTE, 1=LOCAL), and discloses platform-specific behavior for WeChat mini-game regarding native overlays and layering controls. It doesn't mention error conditions, performance implications, or response format, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. The first sentence states the core purpose. The second explains the critical resource_type parameter. The use cases section provides practical guidance in bullet points. The final sentence covers platform-specific behavior. Every sentence earns its place with valuable information, and the information is front-loaded appropriately.
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?
Given a complex tool with 12 parameters, 0% schema coverage, no annotations, but with an output schema, the description does an excellent job. It explains the tool's purpose, provides usage guidance, clarifies parameter semantics, and discloses platform-specific behavior. The output schema existence means the description doesn't need to explain return values. The only minor gap is lack of explicit mention about error conditions or prerequisites, but overall it's highly complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 12 parameters, the description must compensate significantly. It successfully adds crucial semantic meaning: it explains the resource_type parameter's enum values (0=REMOTE, 1=LOCAL) and their corresponding parameter usage (remote_url vs clip_uuid). It also provides context for loop parameter usage in tutorials and explains the platform-specific meaning of stay_on_bottom and full_screen_on_awake for WeChat mini-game. This adds substantial value beyond the bare schema.
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 clearly states the tool's purpose: 'Attach cc.VideoPlayer — plays mp4 from a local cc.VideoClip or remote URL.' It specifies the exact component being attached (cc.VideoPlayer), the media format (mp4), and the two source types (local clip or remote URL). This distinguishes it from sibling tools like cocos_add_audio_file or cocos_add_animation that handle different media types or components.
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?
The description provides explicit usage guidance with three distinct use cases: 'Cinematic intro / cutscenes (LOCAL with clip_uuid)', 'Rewarded video ads (REMOTE with ad-server URL)', and 'In-game tutorials (LOCAL, loop=True)'. It also includes platform-specific guidance for WeChat mini-game regarding layering behavior. This gives clear context for when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 excels by detailing: the execution model ('Runs EVERY assertion even if earlier ones fail'), error handling ('LookupError surfaces as a failed assertion'), return format ('Returns {ok, scene_path, total, passed_count, failed_count, passed: [...], failed: [...]}'), and operational constraints. This provides comprehensive behavioral context beyond basic parameter documentation.
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 appropriately sized and front-loaded with the core purpose. While dense with technical details, every sentence serves a purpose - explaining parameters, operations, syntax, and behavior. It could be slightly more structured with clearer section breaks, but the information is well-organized and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (testing/validation with detailed assertion logic), no annotations, 0% schema coverage, and no output schema, the description provides complete context. It covers purpose, usage, detailed parameter semantics, behavioral traits, and return format. This is comprehensive enough for an agent to understand and correctly invoke the tool despite the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the 2 parameters, the description fully compensates by explaining both parameters in detail. It documents 'scene_path' contextually and provides extensive documentation for 'assertions' including structure examples, path syntax, operations, and optional root-finder shortcuts. This adds significant semantic meaning beyond the bare schema.
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 clearly states the tool's purpose: 'Declarative expectations against a scene/prefab — regression-test style.' It specifies the verb ('assertions') and resource ('scene/prefab'), and distinguishes it from all sibling tools which are primarily creation/editing tools rather than testing/validation 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?
The description provides clear context for when to use this tool ('regression-test style'), but doesn't explicitly mention when not to use it or name specific alternative tools. It implies usage for testing scene/prefab states, which is helpful but lacks explicit exclusions or comparisons to other validation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: explains post-click waiting behavior ('wait_ms gives post-click animations/scene-changes time to settle'), dependency requirement ('Requires optional playwright dependency'), success/failure outcomes ('Returns {ok: True} on success, raises on navigation/launch failure'), and provides actionable error guidance. Could mention rate limits or concurrency constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly front-loaded with core functionality, then elaborates on parameters and behavior. Every sentence adds value: first states purpose, second gives usage context, third explains coordinate space, fourth details button parameter, fifth explains wait_ms, sixth covers dependency, seventh describes outcomes. Zero wasted words.
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 complex 8-parameter tool with no annotations or output schema, the description provides excellent coverage of purpose, usage, parameters, and behavior. Missing details about exact error types or viewport_width/height usage keep it from perfect, but it's highly complete given the constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate fully. It explains all 8 parameters: x/y (coordinates in PAGE space with top-left origin), button (values 'left'/'right'/'middle'), wait_ms (purpose for animations), url (implied as preview target), and mentions viewport dimensions/timeout through sibling reference. Adds crucial context beyond schema titles.
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 clearly states the specific action ('Click at page coordinates'), target resource ('in a running preview'), and distinguishes it from siblings by focusing on UI interaction rather than scene construction or asset management. It goes beyond the tool name to explain the exact functionality.
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?
Explicitly states when to use ('Use this to drive UI you just built') with concrete examples ('Start button, menu tab, card'), mentions sibling tool dependency ('same as cocos_screenshot_preview'), and provides context about coordinate space ('PAGE space, NOT viewport-relative').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly describes the tool's behavior: generates a TypeScript file that sets a global flag on 'onLoad', needs to be attached to a persistent scene node, and returns specific data fields. However, it doesn't mention potential side effects, error conditions, or performance implications of enabling dynamic atlas.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections: purpose statement, technical context, usage guidance with example flow, parameter explanations, and return value documentation. Every sentence adds value with no redundancy or fluff.
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 4-parameter tool with no annotations and no output schema, the description provides excellent context about what the tool does, how to use it, parameter meanings, and return values. The only minor gap is not explicitly documenting the required 'project_path' parameter in the parameter list, though it's shown in the usage example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all 4 parameters: 'rel_path' (default location), 'max_frame_size' (sprite frame batching threshold with engine default), and 'class_name' (TypeScript class name). It also clarifies that 'project_path' is required by showing it in the typical flow example, though this could be more explicit.
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 clearly states the tool's purpose: 'Generate a boot script that enables Cocos 3.8's runtime dynamic atlas' with specific implementation details. It explicitly distinguishes from sibling tool 'cocos_create_sprite_atlas' by explaining the difference between AutoAtlas (build-time) and DynamicAtlas (runtime).
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?
The description provides explicit usage guidance: it names the complementary tool ('cocos_create_sprite_atlas'), explains when to use both together ('catches small UI frames the AutoAtlas doesn't cover'), and provides a concrete usage example with the typical flow involving another sibling tool ('cocos_add_script').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses key behavioral traits: it's a read-only operation (implied by 'list'), returns structured data with count and tools array, explains the 'summary' field derivation, describes filtering behavior, and states that empty filters return all tools. It doesn't mention rate limits, authentication needs, or pagination, but covers the core behavior well for a listing tool.
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 appropriately sized and well-structured. It starts with the core purpose, addresses the specific problem scenario, describes the return format, explains parameters with examples, and ends with usage guidance. While somewhat detailed, every sentence adds value. It could be slightly more concise but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is complete. It explains the tool's purpose, when to use it, behavioral details, parameter semantics, and return format. The lack of output schema is compensated by describing the return structure. For a listing tool with filtering, this provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must fully compensate. It provides detailed semantics for both parameters: 'name_contains' is explained as 'case-insensitive substring on the tool name' with concrete examples ('joint', 'scaffold'), and 'category' is described as 'coarse bucket inferred from the name prefix' with a complete list of possible values. The description also clarifies that both are optional and that empty filters return every tool.
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 clearly states the tool's purpose: 'List the tools actually registered on this MCP server.' It specifies the exact resource (tools) and verb (list), and distinguishes itself from siblings by addressing stale-catalog scenarios and providing ground truth about server capabilities.
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?
The description provides explicit guidance on when to use this tool: 'Addresses stale-catalog scenarios where a subagent's MCP session can't reliably see tools registered after the session started' and 'Use this whenever you need to double-check whether a capability is already baked in before implementing it manually.' It also explains the alternative (asking the server directly vs. relying on session state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It effectively discloses key behavioral traits: patches auto-apply after successful builds, validation happens at registration time (not build time), and it explains the 'mode' parameter behavior ('append' vs 'replace', including how to clear patches). It doesn't mention error handling or side effects beyond validation, but covers the core mutation behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: first sentence states the core purpose, second provides usage context, then details parameters with clear formatting. Every sentence adds value—no redundancy or fluff. It's appropriately sized for a complex tool with multiple parameter details.
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?
Given the tool's complexity (3 parameters, 0% schema coverage, no output schema, no annotations), the description is largely complete. It explains what the tool does, when to use it, parameter details, and behavioral aspects. The main gap is lack of output information (what happens after registration), but otherwise it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It comprehensively documents all three parameters: 'project_path' is implied through context, 'patches' is detailed with structure (platform, file, kind with subtypes and required fields), and 'mode' is explained with default and options. The description adds significant value beyond the bare schema.
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 clearly states the tool's purpose: 'Register declarative patches that auto-apply after every successful build.' It specifies the verb ('register'), resource ('patches'), and timing ('after every successful build'). It also distinguishes from siblings by explaining when to use it versus other build/customization tools.
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?
The description provides explicit usage guidelines: 'Use when a customization has no Cocos source-config switch and would otherwise get wiped on the next ``cocos_build``.' It gives concrete examples (style.css, project.config.json, index.html) and distinguishes from alternatives by implying this is for post-build patching when other configuration methods are insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes the removal logic (precedence rules, AND filtering, no-op behavior) and references another tool for explicit wipes. However, it doesn't mention potential side effects, error conditions, or what happens to other patches after removal, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. The first sentence states the purpose and two methods, while subsequent sentences explain precedence rules and edge cases. Every sentence earns its place with no wasted words, making it easy to parse quickly.
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?
Given the tool's moderate complexity (4 parameters, mutation operation), no annotations, and no output schema, the description does an excellent job covering purpose, usage rules, and parameter semantics. However, it doesn't describe what the tool returns (success/failure indicators, removed patch details) or error handling, leaving some contextual gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 4 parameters, the description must compensate, which it does excellently. It explains the semantic relationship between parameters: indices take precedence, otherwise platform+file filters combine with AND logic, and all None results in a no-op. This adds crucial meaning beyond the bare schema, fully addressing the coverage gap.
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 clearly states the verb ('Remove') and resource ('patches'), specifying two distinct methods (by index list OR by platform/file filter). It distinguishes itself from sibling tools like 'cocos_register_post_build_patch' and 'cocos_list_post_build_patches' by focusing on removal operations rather than registration or listing.
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?
The description provides explicit usage rules: indices take precedence over filters, calling with all None is a no-op, and an explicit wipe requires a different tool ('cocos_register_post_build_patch' with specific parameters). This gives clear when-to-use and when-not-to-use guidance, including named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes the tool's behavior: it creates a composite UI element, handles design-token presets through the project's UI theme, forwards click events verbatim from 'cocos_make_click_event', and specifies the return structure. However, it lacks details on error handling, permissions, or rate limits, which are minor gaps given the context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose, followed by detailed context, examples, and return values. Every sentence adds value: the first states the core function, the second explains the common use case, the third lists the folded calls, the fourth shows the structure, the fifth covers design tokens, the sixth explains click events, and the seventh specifies returns. No waste, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (16 parameters, no annotations, no output schema), the description is remarkably complete. It covers purpose, usage, behavioral traits, parameter semantics, and return values in detail. The lack of output schema is mitigated by explicitly stating the return structure. For a tool with high parameter count and zero schema coverage, this description provides all necessary context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate fully. It adds significant meaning beyond the schema: it explains that parameters like 'label_color_preset', 'label_size_preset', and 'bg_color_preset' resolve through the project's UI theme, clarifies that 'click_events' are forwarded from 'cocos_make_click_event', and implies default behaviors for optional parameters (e.g., sprite is optional). This provides essential context not in the schema.
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 clearly states the tool creates a button node with a child label in one call, specifying the exact structure produced (Btn with UITransform, optional Sprite, Button, and child Label with UITransform and Label). It distinguishes from siblings like 'cocos_add_button' and 'cocos_add_label' by emphasizing it folds seven separate calls into one, making the purpose specific and differentiated.
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?
The description explicitly states when to use this tool: for the 'most common UI primitive' where menus typically have 2-4 buttons, and it folds seven separate calls into one. It implies alternatives by listing the individual sibling tools (e.g., cocos_create_node, cocos_add_uitransform, cocos_add_button, cocos_add_label) that would otherwise be needed, providing clear context for usage versus those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It does an excellent job describing the internal process (reads JSON, deep-copies node tree, shifts IDs, refreshes fileId, parents under parent_id), the unlinked nature of the instantiation, and the update behavior. However, it doesn't mention error conditions, performance implications, or authentication requirements, keeping it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and front-loaded: the first sentence states the core purpose and return value, followed by implementation details, behavioral constraints, and parameter guidance. Every sentence earns its place with no wasted words, and technical details are presented in a logical flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, mutation operation, no annotations) and the presence of an output schema (which handles return values), the description is remarkably complete. It covers purpose, behavior, parameter semantics, usage constraints, and implementation details. The only minor gap is lack of error handling information, but the output schema likely covers return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must fully compensate, which it does excellently. It explains the purpose of the 3 required parameters (scene_path, parent_id, prefab_path are implied through context), and explicitly documents the 5 optional parameters (name, pos_x, pos_y, pos_z, scale) with clear semantics about overriding root defaults. The description adds significant value beyond the bare schema.
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 clearly states the specific action ('Drop a .prefab file into the scene as a child node') and resource (.prefab file), distinguishing it from sibling tools like 'cocos_create_prefab' (which creates prefabs) or 'cocos_create_node' (which creates individual nodes). The opening sentence provides immediate clarity about the tool's core function.
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?
The description explicitly states when to use this tool ('Treats the prefab as **unlinked** (a one-shot copy)') and when not to use it ('If you later edit the .prefab, instances already dropped into the scene will NOT update — re-instantiate to pick up the changes'). It also provides clear alternatives by implication (re-instantiate for updates rather than expecting automatic updates).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: the tool runs actions sequentially in a shared session, does not abort on single failures (allowing earlier results to be returned), and handles screenshot data encoding (PNG bytes as hex). It lacks details on error handling beyond 'error' field, rate limits, or authentication needs, but covers core operational traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by essential usage context, parameter details, and return value explanation. Every sentence adds value: the first states the purpose, the second provides usage guidance, the third introduces action structure, the list details action kinds, and the remainder covers output behavior and data handling. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 0% schema coverage, no annotations, but with output schema), the description is remarkably complete. It explains the purpose, usage context, parameter semantics (especially the complex 'actions' array), output format, and special data handling (hex encoding for screenshots). The output schema existence means return values need less explanation, and the description provides exactly what's needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It provides detailed semantics for the 'actions' parameter, listing all 7 action kinds with their specific keys and optional fields. It also implies 'url' is for browser navigation and mentions viewport/timeout defaults contextually. This adds substantial meaning beyond the bare schema, fully documenting the complex 'actions' array structure.
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 clearly states the tool's purpose: 'Run a list of actions in a SINGLE browser session.' It specifies the verb ('Run') and resource ('list of actions'), and distinguishes itself from potential siblings by emphasizing the single-session requirement for play-testing, which is unique among the listed sibling tools focused on Cocos engine operations rather than browser interaction.
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?
The description provides explicit guidance on when to use this tool: 'Essential for play-testing: game state resets on every page reload, so a multi-step test plan... MUST share one session.' It clearly defines the context (multi-step browser interactions in testing) and implicitly excludes single-step operations or non-browser tasks, though it doesn't name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It thoroughly explains key behaviors: the self-contained rule for node references (with error handling), how asset UUID refs are handled, that the operation is read-only on the scene ('Effects on ``scene_path``: NONE (read-only)'), and the explicit two-step process for replacing the subtree. It also details the return values, compensating for the lack of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. Each sentence adds value: it explains the use case, technical constraints, effects on the scene, workflow guidance, and return values. There is no wasted text, and the information is organized logically from general to specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the operation (prefab creation with technical constraints), no annotations, 0% schema coverage, and no output schema, the description provides complete context. It covers purpose, usage, behavioral details, parameter implications, and return values, making it fully self-sufficient for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 4 parameters, the description must compensate, which it does effectively. It explains the purpose of 'scene_path' and 'root_node_id' implicitly through context, and clarifies that 'prefab_uuid' can be null (default). The description adds significant meaning beyond the bare schema, making parameter roles clear in the context of the operation.
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 clearly states the tool's purpose: 'Extract a fully-configured scene subtree into a reusable .prefab.' It provides a specific verb ('extract'), resource ('scene subtree'), and output format ('.prefab'), and distinguishes itself from sibling tools by focusing on prefab creation rather than component addition or scene manipulation.
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?
The description explicitly states when to use this tool ('The usual case: build your "Enemy" in a scratch scene... then save-as-prefab to spawn dozens') and when not to use it ('Without this, every copy requires re-running the same ``add_*`` stack'). It also names an alternative tool ('cocos_instantiate_prefab') for the next step after creation, providing clear guidance on workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cocos-mcp MCP server](https://glama.ai/mcp/servers/chenShengBiao/cocos-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chenShengBiao/cocos-mcp)

Score Badge

Copy to your README.md:

[![cocos-mcp MCP server](https://glama.ai/mcp/servers/chenShengBiao/cocos-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chenShengBiao/cocos-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chenShengBiao/cocos-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server