Provides specialized tools for managing and inspecting Spine skeletal animations within the editor, including the ability to list skeletons and atlases, retrieve skeleton-specific metadata such as animations and skins, and access skin images.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Phaser Editor MCP Server List all scenes and available textures in the project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This Model Context Protocol (MCP) server provides the tools to connect an LLM with Phaser Editor v5. It is designed to work seamlessly with Phaser Editor's IDE features, allowing developers to create and manage game scenes efficiently.
This server is available as an NPM package and you can use it in the configuration of MCP hosts like Cursor, Claude Desktop, GitHub Copilot, etc...
This is an example of a configuration file for Cursor:
{
"mcpServers": {
"phaser-editor": {
"command": "npx",
"args": ["@phaserjs/editor-mcp-server"]
}
}
}This servers connects with a running instance of the Phaser Editor v5 desktop application. All changes on the project are made through the Phaser Editor running instance.
Related MCP server: cocos_mcp
All tools provided by this server are specifically tailored to work with Phaser Editor features, such as the Scene Editor, Asset Pack Editor, and others. These tools are not intended for direct modification of your project's source code. However, when used alongside code editors like Cursor, the server enables simultaneous interaction with both Phaser Editor's custom files and the project's source code—creating a powerful, integrated development workflow.
We recommend starting with one of the Phaser Editor project templates, which are preconfigured for seamless integration with Cursor. These templates include all necessary configurations and the rules for the LLMs to understand how to interact with Phaser Editor's custom files and the project's source code.
Large Language Models (LLMs) excel at generating new content when provided with high-quality, contextual examples. This is especially effective for game level generation. To take full advantage of this capability, it's a good practice to create training levels that clearly express the concepts and elements you want the model to replicate.
Training levels serve as concrete examples that define the structure and logic of your game. These examples help the LLM understand the components involved and how they interact, enabling it to generate new levels that align with your design.
For example, if you're working with tilemap-based levels, you can create a TrainingLevel scene that includes the key objects used in your game. To improve clarity and semantic understanding:
Use one layer per object.
Name each layer with a descriptive identifier, such as pipe, cloud, or mountain.
This organization helps the LLM detect patterns and apply them to new content generation tasks.
The MCP server provides tools to inspect texture images and generate scene "screenshots." While these visuals are helpful, they may not always be sufficient for the LLM to fully grasp the game's context and logic.
That's why creating structured and well-labeled training levels is essential. These levels provide a richer, more actionable context that enhances the model's ability to generate accurate and relevant game content.
This project provides a comprehensive set of tools for managing scenes, assets, tilemaps, animations, and more within the Phaser Editor environment. Below is a summary of all available tools, grouped by their main functionalities.
ide-get-all-scenes-in-project: Lists all scenes in the project.
ide-get-active-scene: Gets the currently focused scene in the editor.
ide-open-scene: Opens a scene in the editor.
ide-create-new-scene: Creates a new scene file.
ide-save-scene: Saves the editor state of a scene.
assets-get-available-textures: Lists all available textures in the project.
assets-get-texture-binary: Gets the binary data of a texture.
assets-get-available-bitmapfonts: Lists all available bitmap fonts.
assets-get-bitmapfont-image: Gets the PNG image/texture of a bitmap font.
assets-get-spritesheet-image: Gets the PNG image/texture of a spritesheet.
assets-get-texture-content-bounding-box: Gets the bounding box of a texture's content.
assets-get-available-animations: Lists all available sprite animations.
assets-get-available-spine-skeletons: Lists all Spine skeletons in the project.
assets-get-available-spine-atlases: Lists all Spine atlases in the project.
assets-get-spine-skeleton-info: Gets info (animations and skins) for a Spine skeleton.
assets-get-spine-skin-image: Gets the PNG image of a Spine skin.
assets-get-available-tilemaps: Lists all available Tiled tilemap files.
assets-get-tilemap-data: Gets the data of a Tiled tilemap file.
scene-clear-scene: Clears the current scene.
scene-get-scene-dimension: Gets the dimensions of the current scene.
scene-get-screenshot: Gets a screenshot of the scene.
scene-get-scene-data: Gets all objects in the current scene, including their properties.
scene-move-game-object-in-render-list: Sorts objects in the current scene.
scene-delete-game-objects: Deletes specified game objects from the scene.
scene-move-game-objects-to-parent: Moves objects to a specified parent.
scene-pack-objects-in-container: Groups objects in a container.
scene-delete-plain-objects: Deletes specified plain objects from the scene.
scene-add-game-objects: Adds multiple new game objects to the scene.
scene-update-game-objects: Updates multiple game objects in the scene.
scene-add-plain-objects: Adds multiple new plain objects to the scene.
scene-update-plain-objects: Updates multiple plain objects in the scene.
scene-add-editable-tilemap: Adds a new editable tilemap to the scene. Editable tilemaps are fully modifiable and represented as plain objects.
scene-add-tileset-to-editable-tilemap: Adds a tileset to an editable tilemap and updates tile IDs in all layers.
scene-delete-tileset-from-editable-tilemap: Removes a tileset from an editable tilemap and updates tile IDs in all layers.
scene-add-editable-tilemap-layer: Adds a new layer to an editable tilemap and the scene.
scene-resize-editable-tilemap-layer: Resizes an editable tilemap layer's data.
scene-write-editable-tilemap-layer-data: Updates part of the tile data in a layer for efficient changes.
scene-fill-editable-tilemap-layer-data: Fills a region of a layer with a single tile ID.
scene-get-editable-tilemap-layer-selection-data: Retrieves selected tile data from a layer as a 2D array.
Add a Google Font configuration to the given asset pack. This is required if you want to use the font in a scene text.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The key of the font to use in the scenes. It is recommended to use the same name as the font family plus the variant, but you can use any name. It should be unique in the project. | |
| url | No | The URL of the Google Font ttf file. You can get it with the `assets-get-google-font-info` tool. | |
| family | Yes | The font family to use. The family must be exactly as in Google Fonts. You can use the `assets-get-google-font-families` tool to get the list of available font families. | |
| assetPackFileName | Yes | The relative path of the asset pack file. You can search for available asset packs using the `assets-get-available-asset-packs` tool. If there are multiple choices, you can pick any of them. You are not forced to ask the user. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It describes the action as adding a configuration, implying a write operation, but does not disclose side effects (e.g., overwriting existing fonts, asset pack modification limits, or success signals). The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: the first defines the action and target, the second explains the necessity. No extraneous information, and the structure 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no output schema, 4 parameters fully described in schema), the description is sufficient. It covers the core functionality and prerequisite context via parameter descriptions. Minor omission: it does not mention confirmation or error handling, but overall complete enough for a straightforward task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents each parameter. The tool description does not add additional meaning beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a Google Font configuration') and the resource ('asset pack'), and specifies the necessity for using the font in scene text. It distinguishes itself from sibling font tools like 'assets-get-google-font-families' and 'assets-get-google-font-info' which are for retrieving information, not adding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates when to use the tool: 'required if you want to use the font in a scene text.' It does not mention when not to use or alternatives, but the context of sibling tools provides enough differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available sprite animations in the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states a read-like operation ('Get') but does not explicitly confirm non-destructive behavior, performance implications, or error conditions. Minimal disclosure beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 8 words. No redundancy or fluff. Front-loads the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, description lacks details on return format (e.g., list of IDs, objects, or names). Adequate for a simple query but could improve by clarifying output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so baseline is 4 per rules. Description adds no parameter details, but schema coverage is 100% (empty schema). Description does not detract from clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get', resource 'all available sprite animations', and scope 'in the project'. Distinct from sibling tools which target other asset types (e.g., textures, fonts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. While siblings target different asset types, the description does not state prerequisites or provide context on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available asset packs in the project. An asset pack is a collection of assets, like images, audio files, and other resources that can be used in the game. The asset pack contains information like the key of the assets, the url to the file, and other parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the operation and defines asset packs, but does not disclose behavioral traits like side effects, permissions, or limitations. For a read operation, minimal transparency is offered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and the second sentence provides useful context. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description reasonably covers the tool's purpose and the nature of asset packs. It mentions that asset packs contain key, URL, and other parameters, which is useful. Minor omission: it could explicitly state the return format (e.g., list of objects).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. The description does not need to add parameter information, and the baseline score of 4 applies as per rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get all available asset packs in the project.' It specifies the resource (asset packs) and scope (all in project), distinguishing it from sibling tools like 'assets-get-available-animations' which target different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the many sibling 'get-available-*' tools, explicit usage context or exclusions would be helpful but are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available bitmap fonts in the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description accurately conveys a simple read operation. It doesn't add extra behavioral context but the straightforward nature makes it transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 8 words, perfectly concise and front-loaded with no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no parameters and no output schema, the description is complete. It covers the essential purpose without missing details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% and the description doesn't need to add parameter info. Baseline 4 is appropriate for an input-free tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all available bitmap fonts in the project, using a specific verb and resource. It distinguishes from sibling tools that handle other asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states the functionality without context, exclusions, or usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the all the Spine atlases in the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden. It states the tool 'Get[s]' data, implying a read-only operation. No additional behavioral traits (e.g., side effects, permissions, rate limits) are disclosed. For a parameterless list tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise. However, the redundant phrase 'the all the' slightly reduces clarity. It effectively conveys the purpose without extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward, parameterless list tool, the description provides sufficient context. It states what it returns (Spine atlases) and the scope (the project). No output schema exists, but the name and description convey the return type implicitly. Complete enough for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, and schema description coverage is 100% (trivially). The description adds no parameter info, which is acceptable as there are none. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all Spine atlases in the project. The verb 'Get' and resource 'Spine atlases' are specific, and it differentiates from sibling tools like 'assets-get-available-spine-skeletons'. However, the phrase 'the all the' is grammatically awkward but does not obscure meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives is provided. The usage is implied as a simple list retrieval when spine atlases are needed. No exclusions or context are given, but the tool's simplicity and parameterless nature make this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the all the Spine skeletons in the project. It only returns the key of the skeleton.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation and specifies the output limited to skeleton keys, but with no annotations, it does not disclose error handling, performance characteristics, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, front-loading the core purpose with no redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is adequate but could mention the return format (e.g., an array of skeleton keys) and clarify what 'key' means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so no parameter information is needed from the description. The baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get all Spine skeletons) and specifically notes it returns only the key, differentiating it from siblings like assets-get-spine-skeleton-info that return more details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., assets-get-available-spine-atlases). There is no explicit context, exclusions, or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available textures in the project. It includes the name of the texture and the size.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool returns texture names and sizes, but does not mention if the operation is expensive, cached, or requires any special permissions. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the key action and output details. Every sentence is necessary and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with no output schema, the description adequately covers purpose and output. It could specify the return format (e.g., array of objects) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), so the description need not explain any. Baseline score of 4 is appropriate as the description adds no param-specific meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all available textures in the project and includes their name and size. This distinguishes it from sibling tools like assets-get-texture-size or assets-get-texture-binary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context on when not to use it or how it compares to other asset listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for the available Tiled tilemap files in the asset packs and return the list of tilemap keys. A Tiled tilemap file contains the data of a tilemap. It is used by the scene editor to create the Tilemap and TilemapLayer objects. These maps are created by the third party tool Tiled. Like the other assets in the asset packs, Phaser Editor uses the tilemap key to identify the tilemap.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the tool returns a list of tilemap keys and gives context about Tiled tilemaps, but does not disclose error behavior or side effects. It is adequate for a read-only query but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loaded with the main action, and provides necessary context without excessive detail. It is efficient but could be slightly trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple list-retrieval tool with no parameters and no output schema. It explains tilemap origin and key usage, making it contextually sufficient. Minor gaps exist in clarifying relationship to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the description has no parameter details to add. Baseline of 3 applies as schema alone is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for available Tiled tilemap files in asset packs and returns tilemap keys. The verb 'Search' and resource 'asset packs' are specific, and the tool name with 'tilemaps' distinguishes it from siblings for other asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the name and description: it is used to get tilemap keys. However, no explicit guidance is given on when to use this tool versus alternatives like assets-get-available-textures or scene-add-editable-tilemap, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the PNG image/texture of the given bitmap font.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The key of the bitmap font. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It implies a read-only operation but does not disclose any side effects, permissions, or output format details. For a simple retrieval, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, conveying the essential information without any fluff. It is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is nearly complete. It identifies the resource and action, though an explicit note about returning image binary data would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'key' is fully described in the schema with the same phrasing as in the description. The description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'PNG image/texture of the given bitmap font'. It distinguishes this tool from sibling asset tools like assets-get-spritesheet-image or assets-get-texture-binary by specifying bitmap fonts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like assets-get-available-bitmapfonts or assets-get-texture-binary. The description does not mention prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the Google Fonts list of families. It connects to Google API and get the list. This method doesn't provide the fonts available in the project. To see the fonts in the project, check the fonts in the asset packs.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | A filter string to filter the font families. This is optional to do a quick search and confirm if a font family is available. |
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 transparency. It discloses that the tool connects to the Google API, implying an external network call, but does not discuss potential issues like latency, rate limits, authentication requirements, or whether the operation is read-only. The description adds some value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the core action. It is concise and each sentence adds value: main purpose, external call, and distinction from project fonts. However, the grammar could be slightly improved (e.g., 'get the list' vs 'gets the list').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the essential purpose and a key limitation. However, it does not explain the return format (e.g., array of family names or objects), pagination, or error scenarios. The description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (filter) with 100% coverage, so the schema already documents its meaning. The description does not add any additional semantic information beyond what is in the schema. Thus, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the Google Fonts list of families, specifying it connects to the Google API. It also distinguishes itself from project-specific fonts by noting that it doesn't provide fonts available in the project, which helps differentiate from sibling tools like assets-get-available-asset-packs. However, it does not explicitly contrast with the closely related sibling assets-get-google-font-info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly advises when not to use this tool (not for project fonts) and where to find that information (check asset packs). However, it lacks explicit guidance on when to use this tool vs. alternatives like assets-get-google-font-info, which might be confused for specific font details. There is no mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the Google Fonts info for a given font family.
| Name | Required | Description | Default |
|---|---|---|---|
| family | Yes | The font family to get the info. The family must be exactly as in Google Fonts. You can use the `assets-get-google-font-families` tool to get the list of available font families. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description alone must disclose behavioral traits. It only states 'gets' without explaining side effects, permissions, or rate limits. It does not specify what information is returned, leaving the agent uninformed about the output structure and potential constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It efficiently conveys the action and target, earning high marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is adequate but incomplete. It fails to describe what 'info' includes, leaving the agent guessing about the return format. Given the critical missing output information, a score of 3 reflects the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a detailed parameter description specifying exact matching and referencing the listing tool. The tool description adds no new meaning beyond the schema baseline, so a score of 3 is appropriate as per the guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and the resource 'Google Fonts info' and specifies the input 'for a given font family'. It directly contrasts with siblings like 'assets-add-google-font-to-asset-pack' (mutation) and 'assets-get-google-font-families' (listing), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only implies usage when needing font info for a specific family. It does not explicitly state when to use this tool versus alternatives, nor does it mention criteria like required permissions or prerequisites. The parameter description references the sibling tool for listing families, but the main description lacks this guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the skeleton info (animations and skins) of the given Spine skeleton key. To build the info of a skeleton it requires also the Spine atlas key. The user can select a different atlas key, but it is common that the user also define a 'preview' atlas key for each skeleton. You can use it if it exists or ask for a different atlas key to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| dataKey | Yes | The key of the spine data (skeleton) asset. | |
| atlasKey | Yes | The key of the spine atlas asset. |
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 requirement for an atlas key and the type of info returned (animations, skins). However, it does not mention error behavior, what happens if the key is invalid, or the exact output structure. This is adequate for a simple read operation but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all essential. The purpose is front-loaded, and each sentence adds unique value without redundancy. Perfectly concise for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should clarify the return value. It mentions 'animations and skins' but does not specify the exact data structure or format. For a tool with 2 simple params, this is minimally adequate but leaves the agent guessing about output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable context beyond the schema: it explains the relationship between dataKey and atlasKey, and provides a common usage pattern (preview key). This helps the agent understand the semantics and typical workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves skeleton info (animations and skins) for a given Spine skeleton key. The verb 'Get' and resource 'skeleton info' are specific, and the description distinguishes from sibling tools by focusing on info retrieval rather than listing or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that building the skeleton info requires an atlas key, suggests using a 'preview' atlas key if available, and advises asking the user otherwise. This provides clear context for when and how to use the tool, though it lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the PNG image of the given Spine skin. You can use this tool to get a better understanding of the appearance of a Spine skeleton with a given skin. The image may be scaled or not. You can the skeleton data to get more info about the size of a skeleton.
| Name | Required | Description | Default |
|---|---|---|---|
| dataKey | Yes | The key of the spine data (skeleton) asset. | |
| atlasKey | Yes | The key of the spine atlas asset. | |
| skinName | Yes | The name of the skin to use. A skeleton can have multiple skins. | |
| animationName | Yes | The name of the animation to use. A skeleton can have multiple animations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It mentions that the image may be scaled and suggests using skeleton data for size, but omits crucial details like error conditions, permissions, or the exact return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the first sentence stating the purpose and the second providing usage context. It is concise but could be more front-loaded regarding the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should fully specify the tool's behavior. It lacks information about the image format, size range, error handling, and prerequisites, making it incomplete for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have complete descriptions in the schema (100% coverage). The description adds no additional semantic value beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'PNG image of the given Spine skin'. It conveys the tool's purpose effectively but does not differentiate from sibling tools like 'assets-get-spine-skeleton-info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding appearance but lacks explicit guidance on when not to use this tool or alternatives. It offers no exclusions or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the PNG image/texture of the given spritesheet. You can use this tool to get a better understanding of the position of tiles/frames.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The key of the bitmap font. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states it gets an image, without detailing return format (e.g., URL, base64), size limits, or prerequisites. The hint about tile positions is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The first states the purpose, the second adds context. Minimal but effective structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks critical context: no output schema, no mention of prerequisites (e.g., spritesheet must exist), and no guidance on how the key relates to other tools (e.g., assets-get-available-spritesheets if it existed). Incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the parameter description erroneously calls the key a 'bitmap font' key, contradicting the spritesheet context. This misleads the agent and adds negative value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the PNG image/texture of a spritesheet, which distinguishes it from sibling tools like assets-get-bitmapfont-image. However, the parameter description incorrectly references 'bitmap font' instead of spritesheet, causing slight confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding tile/frame positions but does not explicitly state when to use this tool over alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the size of the texture. If you need to get the real size of the object inside the texture (without the transparent margin), then you can use the assets-get-texture-content-bounding-box tool.
| Name | Required | Description | Default |
|---|---|---|---|
| texture | No | The texture of the game object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should fully disclose behavior. It only claims to get size, which conflicts with the tool name. No mention of return types, side effects, or what the tool actually does (binary data vs size). Extremely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but misleading. Conciseness is only valuable when accurate. It wastes its single sentence on incorrect information rather than being genuinely concise about the actual functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one nested parameter and no output schema, the description is critically incomplete. It does not explain what the tool returns (binary data? size?), how to interpret the result, or any prerequisites. This is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add any additional meaning to the parameters (texture object with key and frame). Baseline score is appropriate as the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get the size of the texture' but the tool name 'assets-get-texture-binary' implies retrieving binary data. This is misleading, and a sibling tool 'assets-get-texture-size' exists for size. The purpose is unclear and likely incorrect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions an alternative (assets-get-texture-content-bounding-box) for a specific sub-case but does not specify when to use this tool vs other texture tools like assets-get-texture-size. No usage context or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the bounding box of the content of the given texture. Many textures has transparent padding but we need the exact offset and size of the content/object of the texture to place them in the right positions in the scene. Like when placing different objects one next to the other, with touching edges. If you need to know the size of the whole image, use the assets-get-texture-size tool.
| Name | Required | Description | Default |
|---|---|---|---|
| texture | No | The texture of the game object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It explains that the tool returns the bounding box of the content, accounting for transparent padding. It does not mention any side effects, authentication, or rate limits, but the operation is read-only and non-destructive, which is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the action, the second adds rationale and alternative. Front-loaded, no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides complete context: what it does, why (transparent padding), and when to use an alternative. No gaps given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'texture' parameter with 'key' and optional 'frame', and schema descriptions cover these. The description does not add additional meaning beyond the schema, and schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the bounding box of the content of the given texture.' It explains the context (transparent padding) and provides a use case (placing objects with touching edges). It also distinguishes from the sibling tool 'assets-get-texture-size' by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool versus the alternative: 'If you need to know the size of the whole image, use the assets-get-texture-size tool.' It provides context about transparent padding, but does not explicitly state when not to use this tool beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the binary data of a texture.
| Name | Required | Description | Default |
|---|---|---|---|
| texture | No | The texture of the game object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action (get binary data) without describing the output format, side effects, or any constraints. The tool name suggests a size return, but the description implies binary data, creating confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is inaccurate relative to the tool name. Conciseness alone does not compensate for misleading content. The description should be clarified to match the tool's actual function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (nested object parameter, likely binary output) and the absence of an output schema and annotations, the description is severely incomplete. It fails to explain what the return value is, how to interpret it, or how this tool differs from similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'texture' and its nested properties 'key' and 'frame.' The description adds no further semantic information beyond the schema, so it meets the baseline for parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get the binary data of a texture,' but the tool name is 'assets-get-texture-size,' which implies retrieving the size (dimensions) of a texture. This mismatch is misleading and fails to clarify the tool's actual purpose. Additionally, a sibling tool 'assets-get-texture-binary' exists, further confusing the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not explain the difference between this tool and the sibling 'assets-get-texture-binary,' nor does it mention any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the data of a Tiled tilemap file. It returns the data of the tilemap, including the layers, tilesets, and objects. The data is used by the scene editor to create the Tilemap and TilemapLayer objects.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The key of the file in the asset pack. The key is used by the scene editor to create Tilemap objects. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that the tool returns data including layers, tilesets, and objects, implying a read-only operation. However, it does not mention performance, side effects, or required permissions beyond the single parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no fluff. Efficiently communicates purpose and content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description explains the purpose and return value. It misses mention of error handling or prerequisites (e.g., asset pack loaded), but is largely complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description already covers the 'key' parameter fully (100% coverage), describing its role. The tool description merely restates this without adding new semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the data of a Tiled tilemap file, specifying what is returned (layers, tilesets, objects) and its use. It distinguishes itself from the sibling 'assets-get-available-tilemaps' which lists available tilemaps, not their data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'assets-get-available-tilemaps'. The description only implies usage through the 'used by the scene editor' comment, but does not mention prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the system instructions. This is fully required for the LLM to know how to build the arguments of this MCP server tools. Tools like scene-add-game-objects, scene-update-game-objects, scene-add-game-object-filters, scene-update-game-object-filters, scene-add-plain-objects, and scene-update-plain-objects requires that the LLM get the system instructions first to know the tool arguments structure.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Get the system instructions' without detailing behavioral aspects like permissions, side effects, or read-only nature. Minimal additional context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. First sentence states purpose, second sentence explains necessity and dependencies. Every word earns its place, fitting for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately explains its role and when to use it. It could specify the return format or content, but the overall completeness is high for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. Per guidelines, the baseline is 4. The description adds no parameter-specific information but is not required to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves system instructions, which is a specific verb+resource. It distinguishes itself from sibling tools by explaining its unique prerequisite role for certain scene operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that the tool is required for the LLM to build arguments for several listed tools, providing clear usage context. It does not include when-not-to-use or alternatives, but the prerequisite nature is well-communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new special scene that is a prefab. A prefab is a scene with a single game object (the prefab object) and its children. You can create a prefab instance and add it to a scene or another prefab. That's the idea of prefabs, create reusable objects. It is very common to create a prefab for every entity of the game, like the player, the different enemies, non-player characters, platforms, collectibles and many more. A prefab scene is compiled as a subclass of a game object, not as a Phaser.Scene. You can think about a prefab as a custom game object class. Even, you can create a prefab that is variant of another prefab. This means, a prefab that inherits another prefab. To create a prefab variant, just use another prefab instance as root of the prefab scene, as prefab object. This tool only creates an empty prefab scene, you must add the prefab object to the scene, immediately. The goal of a prefab is to instantiate and add it to other scenes.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the prefab scene file. It is not a full name, just the name. The extension will be added automatically. |
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 explains that a prefab scene compiles as a game object subclass and that the tool only creates an empty scene, requiring immediate object addition. Minor gaps like error conditions or performance are absent but acceptable for a simple creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and includes extensive prefab background information. While well-structured and front-loaded, some sentences are redundant for a tool definition. Could be more concise while retaining key usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description provides all necessary context: what a prefab is, how to create one, and what actions follow. No additional details are needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats that the name parameter is not a full path and extension is added automatically, but adds no new meaning beyond the schema. The detailed prefab explanation doesn't directly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new special scene that is a prefab.' It defines prefab and distinguishes it from a regular scene, differentiating from sibling tools like 'ide-create-new-scene'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises creating a prefab for reusable game entities and instructs that the created prefab is empty and the user must add a prefab object immediately. It also mentions variant creation via another prefab instance, providing guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new scene file. This tool only creates a new scene. If the user wants to show the scene in the game then the user has to add the scene first to the game instance.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the scene file. It is not a full name, just the name. The extension will be added automatically. |
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 it only creates a scene file and does not display it, but it doesn't mention potential side effects like overwriting existing files or checking for name collisions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the core purpose, followed by a crucial usage note. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and no output schema, the description is complete. It explains what the tool does and a key usage condition. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'name' has a helpful description that clarifies it's just the base name, not a full path, and that the extension is added automatically. Since schema coverage is 100% and the description adds meaning beyond the schema, it scores well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new scene file, distinguishing it from siblings like ide-open-scene or scene-get-scene-data. It uses a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes that creating a scene does not show it in the game, and that adding it to the game instance is a separate step. This provides clear context for when to use this tool vs. other scene-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the scene has the focus in the editorÍ. The active scene is the one the user is working at the moment. It may be happen there isn't an active scene.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds moderate value by noting that there may be no active scene. However, it does not discuss any side effects, required permissions, or other behavioral traits. For a simple read operation, it is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the main purpose. However, the first sentence contains a typo ('editorÍ') and awkward phrasing, which detract slightly from its structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the core functionality and mentions the possibility of no active scene. It does not specify the return format, but overall it provides sufficient context for a basic getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to elaborate on parameter semantics. Baseline score of 4 applies as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the active scene, which is the one currently being edited. However, the wording 'Get the scene has the focus' contains a grammatical error and a stray character, which slightly reduces clarity. It effectively distinguishes from siblings like 'ide-get-all-scenes-in-project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus related tools like 'ide-open-scene' or 'ide-get-all-scenes-in-project'. No usage context or alternatives are mentioned, leaving the agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all prefabs in the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must cover behavioral traits. It only states the function, omitting details like performance impact, permissions, or whether prefabs are returned with nesting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no superfluous words or repetition. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-less tool with no output schema, the description is minimal. It lacks details about return format or what constitutes a prefab, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description adds no further semantics, but none are needed since schema already conveys the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all prefabs in the project'), clearly distinguishing from siblings like ide-get-all-scenes-in-project or ide-get-prefab-inheritance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any context about when not to use it. Siblings exist but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all scenes in the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 a simple read operation but does not disclose any potential side effects, return format, errors (e.g., empty project), or authentication needs. Two sentences could add clarity, e.g., 'Returns a list of scene names; no side effects.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the presence of many sibling tools, the description should provide more context about what 'scenes' means (e.g., names, IDs) or how the result is structured. It is incomplete for an agent to understand the return value without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100% and the description adds nothing extra about params. Baseline for 0 params is 4, and the description does not detract from it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all scenes in the project' clearly states the verb (get) and resource (all scenes in the project), distinguishing it from siblings like 'ide-get-active-scene' which gets a single scene, and creation tools. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Among many sibling scene tools (e.g., ide-get-active-scene, ide-create-new-scene), the description does not clarify context or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an array of all the prefabs that are part of the inheritance of the given prefab. A prefab can inherit another prefab. We call it a prefab variant. If the result is an empty array it means the given prefab is not a variant any other prefab.
| Name | Required | Description | Default |
|---|---|---|---|
| prefabId | Yes | The ID of the prefab scene to get the inheritance from. The `prefabId` is the same of the id of referring prefab scene. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits like read-only nature (implicit but not stated), error cases, or permissions. The description only states the return type and a condition for empty arrays, which adds minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core purpose in the first sentence. The second sentence explains the inheritance concept and the meaning of an empty result, which is helpful but could be more concise. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, no output schema), the description adequately covers the return value and the meaning of an empty array. It explains the concept of prefab inheritance. However, it lacks details on error handling or cases where the prefabId is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description repeats the schema's description of 'prefabId' without adding new meaning or clarifying the format. It offers no additional guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns an array of prefabs that are part of the inheritance of a given prefab, using specific verbs like 'get' and 'array'. It explains the concept of prefab variants and distinguishes itself from sibling tools like 'scene-get-nested-prefabs-instances', which deals with instances rather than inheritance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It only describes what the tool does without mentioning contexts, prerequisites, or exclusions such as when the prefab has no variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the scene in the editor.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Open' is vague; it does not disclose side effects (e.g., making the scene active), required permissions, or whether it closes other scenes. This is insufficient for a mutation-like action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words. It is appropriately sized for a simple operation, though it might benefit from slight expansion. The structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is nearly adequate. However, for an 'open' action that likely changes editor state, more context on the effect (e.g., sets as active scene) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. The parameter description in the schema is detailed (explains sceneId is not the name). The tool description adds nothing beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open the scene in the editor' clearly states the verb 'open' and the resource 'scene in the editor'. It distinguishes from siblings like 'ide-get-active-scene' and 'ide-save-scene' by implying a loading action, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives (e.g., when to open versus get active scene or save). It lacks any context about prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the the editor of the given scene. When the scene is saved, the editor generates its code. Use this tool to sync the scene with the code it represents. It is important to keep both the scene content and the scene's code file in sync if you are working in both files at the same time. Also, it is very important that you save prefab scenes after changing them, so the changes can be propagated in all the scenes that contains the instances of the prefab.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It mentions code generation and prefab propagation, but omits details like whether the operation is safe to redo, what gets overwritten, or any side effects. Lacks thorough disclosure for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with some redundancy (e.g., 'Save the the editor' and later 'When the scene is saved'). Could be more concise and front-loaded. Adequate but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and no output schema, the description covers purpose and usage scenarios. However, lacks behavioral details (e.g., persistence guarantees, error cases), leaving it slightly incomplete for a save operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter, but description adds value by clarifying that sceneId is a unique identifier, not the name, and explains how to obtain it. This reduces ambiguity beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a scene and triggers code generation, distinguishing it from other scene manipulation tools. The phrasing 'Save the the editor' is slightly awkward but the core action is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to save: when working simultaneously in scene and code files, and after modifying prefab scenes to propagate changes. Does not list when not to use, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an editable tilemap to the scene. An editable tilemap is different to a Tiled map because all the data can be edited by the user in the scene editor. However, it follows many of the concepts of Tiled. The editable tilemap is also a plain object so you can manipulate it using most of the plain object tools.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Label of the object. It is used to name the object in the scene and as the variable name in code. | |
| width | Yes | The width of the editable tilemap in tiles. | |
| height | Yes | The height of the editable tilemap in tiles. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| tilesets | Yes | The tilesets used by the tilemap. | |
| tileWidth | Yes | The width of each tile in pixels. | |
| tileHeight | Yes | The height of each tile in pixels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Discloses that the tilemap is editable and a plain object, but omits side effects, error conditions, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with action, no redundancy. Could be more concise but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 required parameters and no output schema, description lacks return type information and does not fully contextualize the tool's role among siblings. Missing detail on what the tool produces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. Description adds no additional meaning beyond 'follows Tiled concepts', so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it adds an editable tilemap, contrasting with Tiled maps. However, does not explicitly differentiate from sibling tools like scene-add-editable-tilemap-layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for creating an editable tilemap, but no explicit when-to-use or alternatives provided. Lacks prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an editable tilemap layer to an editable tilemap. Because the complexity of the editable tilemaps, we provide a couple of dedicated tools. An editable tilemap is different to a Tiled map because all the data can be edited by the user in the scene editor. This method adds a layer to the tilemap data but also it adds an EditableLayer game object to the scene.
| Name | Required | Description | Default |
|---|---|---|---|
| layer | Yes | ||
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| tilemapId | Yes | The `id` of the editable tilemap to add the layer to. An 'editable tilemap' is not the same as a Tiled tilemap. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It discloses that the tool adds both a layer to tilemap data and an EditableLayer game object to the scene. However, it does not mention prerequisites (e.g., existing editable tilemap) or side effects. The behavioral info is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences with some redundancy (e.g., 'complexity' mentioned twice). It could be more concise while retaining key information. The most important action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and nested parameters, the description explains the tool's effect but lacks prerequisites, error conditions, and return value info. It covers the basic function but is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by noting that the layer name is used for code variable generation and that sceneId is a unique identifier requiring scene data. These details help the agent use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'editable tilemap layer'. It distinguishes from Tiled maps and hints at dedicated tools, but does not explicitly differentiate from specific sibling tools like 'scene-fill-editable-tilemap-layer-data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the complexity of editable tilemaps and that dedicated tools exist, but does not explicitly state when to use this tool versus alternatives. It provides context but no clear when-not or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add multiple filters to parent game objects in the scene
| Name | Required | Description | Default |
|---|---|---|---|
| objects | Yes | ||
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states a write operation ('Add') without mentioning prerequisites (e.g., parent object must exist), side effects, or whether filters are appended or overwritten. This is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the action and target. No unnecessary words. It could be longer to improve completeness, but as a concise statement it succeeds.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple filter types, nested parameters) and the presence of sibling tools, the description lacks critical context: what happens to existing filters, how properties relate to filters, and any return values. It is not complete enough for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 50%, the description should compensate by explaining parameters. It does not mention sceneId or objects at all, adding no value beyond the schema. The schema already provides some descriptions, but the description fails to clarify the connections or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add multiple filters') and the target resource ('parent game objects in the scene'), distinguishing it from sibling tools like scene-delete-game-object-filters or scene-add-game-objects. However, it could be more specific about whether it appends to existing filters or replaces them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as scene-update-game-object-filters or scene-delete-game-object-filters. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add multiple new game objects to the scene. If you are adding prefab instances, then you should include the "unlock" property which contains an array of the name of the properties you are setting to the object. By default, are properties are locked in a prefab instance, so you need to unlock them before setting them, otherwise, the prefab instance will get the values defined originally in the prefab scene.
| Name | Required | Description | Default |
|---|---|---|---|
| objects | Yes | ||
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions the unlock behavior for prefabs, but does not disclose other behavioral traits like idempotency, error handling, permissions, or effects on existing objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains a typo ('By default, are properties are locked') that could confuse. It is not overly long, but the structure could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of adding multiple game objects with prefab unlock logic, the description covers the essential use case but omits details like return values, prerequisites (e.g., scene must be open), and error conditions. No output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (sceneId and objects) with meaningful text. The description adds value by explaining the 'unlock' property for prefab instances, which is not in the schema, and clarifies how properties interact with prefabs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add multiple new game objects to the scene.' It uses a specific verb ('Add') and resource ('game objects'), and distinguishes itself from sibling tools like scene-delete-game-objects or scene-add-editable-tilemap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific guidance for prefab instances (unlock property), but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage context is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an Object List, which is an array with the ids of game objects. The user can use this array to group objects for a purpose. One of the most common purpose of objects lists are grouping the objects to be part of an arcade physics colliders.
| Name | Required | Description | Default |
|---|---|---|---|
| lists | Yes | The object lists to add to the scene. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It merely states the creation action without disclosing side effects, permissions, or constraints beyond what is in the schema (e.g., needing to read scene data for id). The write nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, but contains a minor grammatical awkwardness ('One of the most common purpose'). Still, it is front-loaded and efficiently communicates core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic purpose but lacks prerequisites (e.g., scene must exist, objectIds must reference valid objects), return value information, and how the list integrates with other tools. Given no output schema, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline is 3. The description adds example context (physics colliders) but does not provide new semantic meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an Object List (an array of object ids) for grouping objects, and gives a common use case (physics colliders). However, it does not explicitly differentiate from sibling tools like scene-update-object-list or scene-remove-object-list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new object lists via the creation verb and example use case, but no explicit guidance on when to use vs. alternatives (e.g., update/remove). The agent must infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add multiple new plain objects to the scene.
| Name | Required | Description | Default |
|---|---|---|---|
| objects | Yes | ||
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral aspects beyond the basic action. It fails to mention side effects (e.g., scene modification in-place), prerequisites, or post-conditions, which is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 7-word sentence, making it concise but overly minimal. It lacks structured information such as usage context or parameter hints, which would benefit from additional sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two required parameters, nested object structure, no output schema, and mutation semantics), the description is insufficient. It does not explain the concept of 'plain objects', how they interact with the scene, or what the agent should expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 50%, the tool description adds no additional meaning to parameters. It does not explain the 'objects' array structure or the purpose of 'sceneId' beyond what the schema provides, missing an opportunity to compensate for incomplete schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and resource 'plain objects to the scene', aligning with the tool name. It distinguishes from sibling add tools like scene-add-game-objects by specifying 'plain objects', though it could be more explicit about what defines a plain object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as scene-add-game-objects or scene-add-editable-tilemap, leaving the agent guessing about context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a tileset to an editable tilemap. This will add the tileset to the tilemap data, but it will not add the tileset asset itself. It also will update the ID of the tiles of every layer in the map.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| tileset | Yes | ||
| tilemapId | Yes | The `id` of the editable tilemap to add the tileset to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses two behaviors: not adding the asset and updating tile IDs across layers. However, it lacks details on side effects, idempotency, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description adequately covers the action and key behaviors, but could mention return value or common errors for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes parameters, and the description adds no additional semantic meaning beyond the schema. With high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'tileset to an editable tilemap'. It distinguishes from sibling tools like scene-add-editable-tilemap (adds the tilemap itself) and scene-delete-tileset-from-editable-tilemap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (adding a tileset to a tilemap) but does not provide explicit guidance on prerequisites or when to avoid, nor does it compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the current scene.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description does not disclose the tool's behavior, such as whether it is destructive, what objects are affected, or if it requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (5 words), but this brevity comes at the cost of clarity. It could be restructured to include essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, output schema, and a single parameter, the description is insufficient. It fails to provide context about what 'clearing' entails or how it differs from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description explains that sceneId is not the name. The description adds minimal additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Clear the current scene' is ambiguous. It does not specify whether 'clear' means delete, reset, or remove content. The parameter sceneId suggests it clears a specific scene, contradicting 'current scene'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives. No mention of prerequisites like obtaining the scene id via other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new user property for the given prefab.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the user property. The editor compiles a prefab user property as a field of the prefab class. This name is used as variable name for that field. | |
| type | Yes | ||
| label | Yes | The display name of the property. It is used in the editor to show the property name in the user interface. | |
| sceneId | Yes | The `id` of the prefab scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. This id refers only to the scenes that are prefabs. | |
| tooltip | Yes | A very short description. | |
| defValue | No | A user property is always initialized with a default value. It could never be null or undefined. Its raw type is string, number, or boolean, but the format/syntax of the value depends on the type of the property. If the property is an array, then this property refers to the default element of the array when the user adds a new element. To set the default array, use the `defArrayValue` property. If the type is `option`, then the default value should be one of the provided options. Look the `type` property for more details. | |
| defArrayValue | No | If the property is an array, this is the default array. If the property is not an array, this value is ignored. The type of each element of the array must follow the same rules as the `defValue` property. Look the `defValue` property for more details. | |
| customDefinition | No | By default, a user property is generated in code as a field. If you set this property to true, then the editor skips the generation of the field definition in code, so the user can write a custom property declaration. Most of the time the user doesn't need to do this. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'create', implying mutation, but lacks information on side effects, authentication needs, rate limits, or error conditions. The schema describes parameters but not behavioral aspects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it lacks essential context for a complex tool. While it avoids verbosity, it is too minimal to be fully helpful. It earns 3 for not being wordy but loses points for under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, no output schema), the description is too sparse. It does not explain what happens after creation, return values, or any dependencies. The detailed schema partially compensates, but the description should provide overarching context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, meaning parameters are well documented in the schema. The description adds no additional meaning to parameters, but the schema already provides detailed descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new user property for the given prefab' clearly states the action (create) and resource (user property for prefab). It is specific and differentiates from sibling tools like scene-delete-prefab-property, though it does not explicitly mention that the prefab must be a prefab scene. The tool name reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, conditions, or exclusions. Sibling tools include deletion and other operations, but no comparative context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete the given filters from the scene.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| filterIds | Yes | The `id`s of the filters to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states only the basic action without disclosing error handling, side effects, or reversibility. For a deletion operation, important behavioral traits 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description is minimally adequate. However, it could benefit from mentioning that the operation is irreversible or that filters are permanently removed, especially given the number of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes both parameters (sceneId and filterIds). The description adds no additional meaning beyond the schema, which is adequate but not exemplary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete the given filters from the scene' clearly states the verb and resource. However, it does not explicitly differentiate from sibling tools like scene-update-game-object-filters or scene-add-game-object-filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, exclusions, or prerequisites, 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.
Delete the given game objects from the scene.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| objectIds | Yes | The `id`s of the game objects to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavioral traits. However, it only states the action without disclosing whether deletion is permanent, if it affects children, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that efficiently conveys the core purpose without extraneous details. It is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description covers the basic action, but it lacks information about return values, error scenarios, or behavior when objectIds are incorrect. Without output schema, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already explains that sceneId is the id (not name) and objectIds are ids. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Delete' and specifies the resource 'game objects from the scene', directly stating the action and target. It distinguishes itself from siblings like 'scene-add-game-objects' or 'scene-delete-game-object-filters'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any conditions or when not to use it. The description lacks context about prerequisites or consequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete the given plain objects from the scene. Plain objects are Tilemap, Key, Collider...
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| objectIds | Yes | The `id`s of the plain objects to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details beyond 'Delete'. No annotations are provided, so the description carries the full burden but omits safety, reversibility, or side effects such as impact on dependent objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short but incomplete sentence ending with '...' suggests truncation. Not as concise as it could be if complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks sufficient context for a deletion tool with no output schema. Does not explain how to obtain object IDs, what happens after deletion, or how it fits with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (100% coverage), so the description adds no extra value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes plain objects and defines them as Tilemap, Key, Collider, distinguishing it from other delete tools like scene-delete-game-objects. However, the description is truncated, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as scene-delete-game-objects or scene-delete-game-object-filters. The description does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a user property from the given prefab.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the user property to delete. | |
| sceneId | Yes | The `id` of the prefab scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. This id refers only to the scenes that are prefabs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the deletion action without mentioning side effects (e.g., irreversibility), required permissions, or what happens if the property does not exist. This leaves significant ambiguity for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the core action. Every word is necessary, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and minimal behavioral context, the description is adequate for a simple delete operation but lacks details on consequences, required permissions, and error handling. With only 2 parameters and full schema coverage, it meets the minimum but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters ('sceneId', 'name'), so the baseline is 3. The description adds no additional semantic meaning beyond the schema, but also does not contradict it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the target ('a user property'), and the context ('from the given prefab'). It is specific and distinct from sibling tools like 'scene-declare-prefab-property' (which creates/declares) and other delete tools that target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The purpose is implied but not explicitly compared to siblings like 'scene-declare-prefab-property'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a tileset from an editable tilemap. This will remove the tileset from the tilemap data, but it will not delete the tileset asset itself. It also will update the ID of the tiles of every layer in the map.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| tilemapId | Yes | The `id` of the editable tilemap to delete the tileset from. An 'editable tilemap' is not the same as a Tiled tilemap. | |
| tilesetName | Yes | The name of the tileset to delete from the editable tilemap. This should match the name defined in the tilemap's tilesets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tileset asset is not deleted and that tile IDs are updated across layers. Provides useful side effects beyond the input schema, compensating for lack 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that efficiently convey purpose and key behaviors. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers the deletion operation, including what is not affected and side effects. Lacks details on return value or prerequisites, but acceptable for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds minimal extra meaning beyond the input schema, which already covers all three parameters with detailed explanations. Baseline 3 due to high schema coverage (100%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Delete a tileset from an editable tilemap.' which specifies the action and resource. Distinguishes from siblings like scene-add-tileset-to-editable-tilemap and scene-fill-editable-tilemap-layer-data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when wanting to remove a tileset, but no explicit guidance on when not to use or alternatives. Context from sibling tools suggests inverse of adding a tileset, but lacks clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Removes the Arcade physics body from the given game objects.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | The IDs of the game objects to remove the Arcade physics body from. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors fully. It only states the removal action but omits crucial details like whether the operation affects other properties, reversibility, error handling, or requirements for the game object to have an active physics body.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 12 words with no redundancy. Every word contributes to the purpose. Front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is minimally adequate but lacks context about usage context, error scenarios, or relationship to sibling tool. No output schema, so explanation of return value would be helpful but not strictly required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are clear (e.g., 'ids' as array of strings, 'sceneId' with note about reading data). The tool description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Removes' and resource 'Arcade physics body', clearly stating the action. It uniquely identifies the tool among siblings, especially noting the presence of an 'enable' counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like scene-enable-arcade-physics-body. Missing context about prerequisites (e.g., body must exist) or scenarios where disabling is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds an Arcade physics body to the given game objects. To set the physics body properties you first have to create the body with this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| updates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool creates the body and that subsequent property setting is separate. However, it lacks details on error handling (e.g., if body already exists), required physics world state, or return value. No annotations are present to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no superfluous information. Every sentence earns its place, and it is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficient. It omits critical details like how game object IDs are obtained, what happens if a body already exists, prerequisites, and return behavior. The hint about setting properties is helpful but not enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the two required parameters (sceneId and updates). With schema description coverage at 50% (only sceneId has a description), the description does not compensate by explaining how to find sceneId or what the updates array requires.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Adds an Arcade physics body to the given game objects.' This is a specific verb+resource, and it distinguishes the tool from its sibling 'scene-disable-arcade-physics-body' which removes the body.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by noting that to set properties, you first create the body with this tool. However, it does not explicitly state when to use it vs. alternatives, nor does it mention prerequisites like scene activity or existing game objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill a region of the tile data of an editable tilemap layer with a single tile ID. This is useful to do things like clear the layer (fill the full layer with a -1 tile), or to paint backgrounds, filling the layer with the background tile, or filling just a part of the layer like for making a floor, or any other level element.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | The x coordinate of the top left corner of the region to fill. | |
| y | Yes | The y coordinate of the top left corner of the region to fill. | |
| width | Yes | The width of the region to fill in tiles. | |
| height | Yes | The height of the region to fill in tiles. | |
| tileId | Yes | The tile ID to fill the region with. The tile ID is a global ID that is computed by the index (starting from 1) of the tile in the tileset. If there are more than one tileset, then the global ID is computed by adding the length of each tileset. | |
| layerId | Yes | The `id` of the editable tilemap layer to fill. An editable tilemap layer is also a game object, so you can use the `id` of the EditableLayer game object. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates it is a mutating operation but provides minimal additional behavioral details beyond that, such as overwriting behavior or reversibility. No annotations are present to supplement this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information, front-loaded with action, and efficiently covers purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides examples but lacks information on return value, error conditions, and prerequisites (e.g., layer existence). Given 7 required params and no output schema, more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage), and the description adds minor context (e.g., tile ID computation), but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fills a region of tile data with a single tile ID and provides specific use cases like clearing the layer or painting backgrounds, which distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly lists common scenarios (clear, background, floor) but does not explicitly mention when not to use or alternative tools, though context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the selected tile data of an editable tilemap layer. It returns a 2D array with the tile IDs. The selection is always a rectangular region of the tilemap layer.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns a 2D array of tile IDs and that the selection is rectangular, but with no annotations provided, it does not explicitly state that the operation is read-only or non-destructive. Additional context about behavior with no selection or empty layers would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, wastes no words, and front-loads the core action. Every sentence adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one well-documented parameter and no output schema, the description covers the return format and a key constraint (rectangular selection). It does not specify behavior when no selection exists or when the layer is empty, but overall it is sufficiently complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'sceneId' is fully described in the input schema (100% coverage). The tool description adds no additional semantic detail beyond the schema, so it meets the baseline expectation but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('get'), the resource ('selected tile data of an editable tilemap layer'), and the output ('2D array with tile IDs'). It also clarifies that the selection is always rectangular, which distinguishes it from other tilemap tools that may handle arbitrary shapes or entire layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like scene-write-editable-tilemap-layer-data or scene-fill-editable-tilemap-layer-data. It does not mention when not to use it or any prerequisites, leaving the agent to infer context 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.
Get all the nested prefab instances of the given prefab instance. A prefab instance can have other prefab instances as children that are exposed as nested prefab instances. This tool returns all the nested prefab instances, not the direct children. You can use this tool to get the info of the nested prefab instances and perform operations like updating the nested prefabs or, in case they are containers-like objects, add objects to them. You cannot delete a nested prefab instance. A nested prefab instance also have a prefabId that points to an object inside the root prefab. You can modify a nested prefab instance just like any other prefab instance, you have to provide the id, the values of the properties, and update the unlock field. Each nested prefab instance contains its own data.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The `id` of the prefab instance game object in the scene. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: it returns all nested instances (not direct children), cannot delete, and explains how to modify nested prefabs (provide id, values, unlock field). It does not cover return format or side effects, but is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, front-loading the main purpose in the first sentence. While it includes useful detail, some sentences could be merged for tighter structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's function and limitations but lacks details on the return format or structure of the nested prefab instances. For a tool with no output schema, this is a notable gap, though the description does mention some content (prefabId, own data).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameters is 100%, so baseline is 3. The description mentions the 'id' parameter but adds no additional meaning or constraints beyond what the schema already provides for 'sceneId' or 'id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get all nested prefab instances of a given prefab instance. It distinguishes nested instances from direct children, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context on when to use this tool (to get nested prefab info for updating or adding objects) and includes a constraint (cannot delete). However, it does not explicitly contrast it with sibling tools like scene-get-objects-data or scene-update-game-objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the data of the given objects
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| objectIds | Yes | The ids of the objects to get the data from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'Get the data' without disclosing read-only nature, return format, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of what 'data' includes; without output schema, description should clarify return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions; the tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves data of given objects, which is clear but does not differentiate from siblings like scene-get-scene-data or scene-get-nested-prefabs-instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives among many scene getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all objects in the current scene, including their properties.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by stating 'Get', but it does not explicitly confirm no side effects, authentication requirements, or performance implications. With no annotations, the description provides basic behavioral context but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 11 words with no unnecessary information. Every word contributes to conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description adequately communicates what it does and what it returns. It could be improved by noting the data format or the absence of pagination, but it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a full description for the sole parameter 'sceneId', including that it is an id, not a name. The description adds no additional semantic value beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'all objects in the current scene', and includes the scope 'including their properties'. It effectively distinguishes the tool from siblings like 'scene-get-objects-data' by specifying it returns all objects and their properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative tools such as 'scene-get-objects-data' or 'scene-get-nested-prefabs-instances'. The description lacks context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the dimensions of the current scene.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states 'Get the dimensions' without disclosing behavior such as read-only nature, error handling, or whether it requires scene data to be loaded. The description fails to compensate for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loading the purpose. No unnecessary words, but it is overly brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what dimensions are returned (e.g., width, height, bounds). It does not, leaving the agent uninformed about the tool's output. Minimal completeness for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema provides detailed parameter description. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get the dimensions of the current scene,' but the required parameter is a sceneId, implying it might not be the 'current' scene. This creates ambiguity. It does distinguish from sibling tools by specifying dimensions, but the mismatch reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like scene-get-scene-data, which might also provide dimensions. No exclusions or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a screenshot of the scene.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | The x coordinate of the top left corner of the screenshot. | |
| y | Yes | The y coordinate of the top left corner of the screenshot. | |
| width | Yes | The width of the screenshot. | |
| height | Yes | The height of the screenshot. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral transparency. It does not disclose any side effects, error handling, output format, or requirements (e.g., if the scene must be visible). This is insufficient for a tool with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. However, it could benefit from adding structured information about output or behavior without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good schema descriptions, the tool lacks output schema and the description omits critical context such as coordinate system (pixels or relative), image format, and response behavior. This leads to an incomplete understanding for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with detailed explanations for each parameter (e.g., sceneId explains it is not the name). The tool description adds no extra parameter context, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a screenshot of a scene, providing a specific verb and resource. It distinguishes itself from sibling tools as the only screenshot-related tool, though it could be more precise about the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any preconditions or exclusions mentioned. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sort objects in the current scene.
| Name | Required | Description | Default |
|---|---|---|---|
| move | Yes | Move the objects upm down, top, or bottom in the render list. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| objectIds | Yes | The `id`s of the objects to sort. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details beyond the minimal purpose. The description does not disclose side effects (e.g., impact on rendering order) or any constraints. No annotations provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one sentence, but it is not overly verbose. Could be improved by front-loading more specific action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 required parameters, no output schema, and no annotations, the description is incomplete. It does not explain what 'sort' entails, return values, or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameter meanings. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sort objects in the current scene' is somewhat vague; 'sort' could imply ordering by a criterion, but the schema reveals it's about moving objects in the render list. It does not differentiate from sibling tools like scene-move-game-objects-to-parent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as scene-delete-game-objects or scene-update-game-objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move the given objects to the given parent.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| parentId | No | The `id` of the parent to move the objects to. If no parent is given, the objects will be moved to the root of the scene. | |
| objectIds | Yes | The `id`s of the objects to move. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only says 'move' without detailing side effects (e.g., reparenting, removal from old parent), success conditions, or error states. Schema covers parameter format but not behavioral consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise and front-loaded. However, it omits important behavioral details, making it slightly too brief for a complete understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but the description fails to explain the concept of parent-child hierarchy or that objects are reparented. No output schema exists, so the return value is unspecified. Incomplete for an agent to reliably use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds no extra meaning beyond 'move objects to parent', so it meets the baseline without enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Move the given objects to the given parent' clearly states the verb (move) and the resource (objects to a parent). It differentiates from sibling tools like 'scene-move-game-object-in-render-list' by specifying 'to parent', though it does not explicitly contrast with similar reparenting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as 'scene-pack-objects-in-container' or 'scene-delete-game-objects'. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a container to group the given objects. The container and objects are positioned so the container size is minimal.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| objectIds | Yes | The `id`s of the objects to move. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the container and objects are positioned for minimal container size, but omits details about the container type (e.g., new parent object, collider shape), side effects (e.g., reparenting, possible destruction of existing groups), or whether the operation is reversible. Additional behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the action and outcome. Every word adds value, no redundant phrasing. Perfectly sized for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but lacks necessary context for a complex scene manipulation tool. It does not explain what the container is (e.g., new parent object, collider), how objects are reorganized, or the impact on the scene hierarchy. With no output schema and no annotations, more detail is needed for complete agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described in the schema. The description adds minimal semantic value beyond the schema—only 'the given objects' and 'container is minimal'. It does not explain the relationship between objectIds and the resulting container or any constraints. Baseline 3 is appropriate as description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create a container to group' and the resource 'the given objects', with the outcome 'the container and objects are positioned so the container size is minimal.' It effectively distinguishes from sibling tools like 'scene-move-game-objects-to-parent' (which moves without packing) and 'scene-add-game-objects' (which adds without grouping).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for grouping objects into a minimal container, but does not explicitly state when to use this vs alternatives. No guidance on when not to use (e.g., if objects should stay independent) or comparison to similar sibling tools. The context of minimal packing suggests specific use cases, but lacking explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an Object List from the scene.
| Name | Required | Description | Default |
|---|---|---|---|
| listIds | Yes | The ids of the object lists to remove. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the action without details on side effects (e.g., cascading removal), permissions required, or whether the change is immediate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded but could benefit from slightly more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the outcome of removal (e.g., return value, success indication), error conditions, or next steps. No output schema or annotations support the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('Object List'), with scope ('from the scene'). It distinguishes from sibling tools like scene-add-object-list and scene-update-object-list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, and no context about the effect on the scene or related objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize an editable tilemap layer. This will resize the layer data, but it will not resize the layer game object itself. It also will update the ID of the tiles of every layer in the map.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | The new width of the layer in tiles. | |
| height | Yes | The new height of the layer in tiles. | |
| layerId | Yes | The `id` of the editable tilemap layer to resize. An editable tilemap layer is also a game object, so you can use the `id` of the EditableLayer game object. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the layer game object is not resized and that tile IDs are updated across all layers. However, it does not cover potential data loss or constraints (e.g., what happens if new dimensions are smaller).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three sentences, front-loading the main action. Every sentence adds meaningful behavioral context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite concise description, the tool covers a mutation operation with several implications (data truncation, padding, ID updates). No explanation of return values, success indicators, or failure modes. Given no output schema, the description should provide more context about the operation's effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the tool description adds little beyond what the schema already provides. Parameters are clearly described in the schema, and the tool description does not offer additional guidance on constraints or relationships between width/height.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resizes an editable tilemap layer, with specific details about what is affected (layer data) and what is not (game object itself). It also mentions a side effect (updating tile IDs across layers) that distinguishes it from sibling tools like scene-add-editable-tilemap-layer or scene-fill-editable-tilemap-layer-data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description focuses on what the tool does but does not explicitly state when to use it or when not to. There is no mention of alternatives or prerequisites, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the list where the filter is placed. A filter could be on the internal or external filter list. The internal filters are rendered in the game object space. The external filters are rendered in the camera space.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| filterId | Yes | The `id` of the filter to update. | |
| internal | Yes | If `true`, the filter is added to the internal filter list of the game object. If `false`, the filter is added to the scene's filter list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should fully disclose behavior. It indicates mutation ('update') but does not explain consequences, side effects, or permissions. The rendering distinction is helpful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences are reasonably concise, but the first sentence is vague ('Update the list where the filter is placed'). Some redundancy exists with the schema, but overall structure is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too minimal. It explains internal/external rendering but lacks information on what 'update' does, return values, or error conditions. The tool has 3 required params but the description does not fully prepare an agent for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; the internal/external mentions are already covered by the 'internal' parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it updates a filter list but lacks specificity about what 'update' entails (e.g., replacing, adding, removing). It distinguishes internal vs external lists, vaguely differentiating from sibling tools like scene-update-game-object-filters, but does not clearly separate concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like scene-update-game-object-filters or scene-add-game-object-filters. The internal/external distinction is present but not explained as a decision guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add multiple filters to parent game objects in the scene
| Name | Required | Description | Default |
|---|---|---|---|
| objects | Yes | ||
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether filters are replaced or merged, whether changes are reversible, or what 'parent game objects' means. The description is too minimal to inform safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but misleading (says 'add' when tool is 'update'). It lacks structural clarity and fails to convey the tool's actual behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has nested parameters, many sibling tools, no output schema, and no annotations, the description is severely incomplete. The agent cannot determine proper usage, expected outcomes, or how this tool fits with other scene filter tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (sceneId and id have descriptions; internal has a description; type is an enum; properties references system prompt). The description adds no additional meaning beyond the schema; for example, it does not clarify the relationship between 'id' and 'type' or how properties are applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add multiple filters' but the tool name is 'update-game-object-filters', and the schema's property 'id' is described as 'The id of the filter to update', indicating an update operation. This contradiction confuses the tool's purpose. Additionally, there is a sibling tool 'scene-add-game-object-filters' for adding, so the description fails to distinguish the tool from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives like scene-add-game-object-filters or scene-delete-game-object-filters. The agent is given no context about which scenarios call for update vs. add vs. delete, leaving it to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update multiple game objects in the scene. If you are updating prefab instances, then you should include the "unlock" property which contains an array of the name of the properties you are setting to the object. By default, are properties are locked in a prefab instance, so you need to unlock them before setting them, otherwise, the prefab instance will get the values defined originally in the prefab scene. It is important that you be smart when setting the unlock property, because its value will override the unlock state of the object. This means, if you are going to update a property but want to keep the values of the other properties unlocked in the prefab instance then you have to include them in your update arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| objects | Yes | The game objects to update in the scene. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses important behavioral details such as the locking mechanism for prefab instances and the side effect that setting 'unlock' overrides other unlocks. This adds significant transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about 100 words, packing multiple ideas. While it front-loads the core action, it could be more concise and structured (e.g., bullet points) to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 required parameters and no output schema, the description covers the main use case and the critical prefab locking behavior. However, it omits details about error handling, return values, or what happens with invalid inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial meaning by explaining the 'unlock' property inside the properties object, which is not defined in the schema. This clarifies how to handle prefab instances, compensating for the schema's open-ended nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update multiple game objects in the scene,' specifying the verb and resource. It distinguishes itself from sibling tools like 'scene-add-game-objects' and 'scene-delete-game-objects' by focusing on updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific guidance for prefab instances (using 'unlock' property) but does not compare this tool with similar siblings like 'scene-update-plain-objects' or 'scene-update-object-list', leaving ambiguity about when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an Object List, which is an array with the ids of game objects.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The id of the object list to update. | |
| label | No | Label of the object. It is used to name the object in the scene and as the variable name in code. | |
| scope | No | The scope of the variable. By default, the editor may generate or not a variable ('local' scope). It depends on if it needs a variable to update the object just after the creation. However, you can force to generate a variable and assign a scope to it, so you can access the object from different parts of the code. When you set a 'public' scope, the editor generates a public field in the class. The same with the `class` scope, but the field is private (in TypeScript). The 'method' scope says to the editor to generate a local variable. The 'nested_prefab' scope is like the public scope but also indicates that the object is a nested prefab. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. | |
| objectIds | Yes | The ids of the game objects in the list. The ids are used to reference the game objects in the scene. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden of behavioral disclosure. It merely says 'Update' but does not explain the update semantics (e.g., replaces entire list, merges), side effects, required permissions, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, no filler, but could be more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It does not cover return values, error handling, or prerequisites, leaving the agent with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so baseline is 3. The description adds minimal context by explaining that the object list is an array of IDs, but does not elaborate on parameter details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'an Object List', and explains that it's an array of game object IDs. However, it does not differentiate from sibling tools like scene-add-object-list or scene-remove-object-list, which could confuse the agent about when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context such as prerequisites (e.g., needing the scene ID) or scenarios where updating an object list is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update multiple plain objects in the scene.
| Name | Required | Description | Default |
|---|---|---|---|
| objects | Yes | ||
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only says 'update', but fails to disclose any behavioral traits such as mutation effects, permissions, or error handling. This is inadequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only one sentence with no extraneous text. While it is efficient, it lacks structure (e.g., no bullet points or sections) and may be too minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and usage guidance, the description is insufficient for an agent to fully understand the tool's behavior, error cases, or effects. It does not cover what happens if objects do not exist or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond the schema. With schema description coverage reported at 50%, the tool description does not compensate for missing parameter details. However, the schema itself partially describes parameters, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates multiple plain objects, using a specific verb-resource combo. However, it does not differentiate from sibling tools like 'scene-update-game-objects' or 'scene-add-plain-objects', which could lead to confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., adding vs. updating), nor on prerequisites or context. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write part of the tile data of an editable tilemap layer. This is useful to update a layer's data without having to send the whole layer data again.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | The x coordinate of the top left corner of the data to write. | |
| y | Yes | The y coordinate of the top left corner of the data to write. | |
| data | Yes | The tile data to write to the layer. Each item is a tile ID, or -1 for an empty tile. The tile ID is a global ID that is computed by the index (starting from 1) of the tile in the tileset. If there are more than one tileset, then the global ID is computed by adding the length of each tileset. The data is a 2D array, where each inner array represents a row of tiles. | |
| layerId | Yes | The `id` of the editable tilemap layer to write to. An editable tilemap layer is also a game object, so you can use the `id` of the EditableLayer game object. | |
| sceneId | Yes | The `id` of the scene. The `id` is not the name of the scene, else a unique identifier is set in the scene data. You need to read the scene data to get the `id`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects, permissions, or constraints beyond the operation itself, such as whether data at coordinates is overwritten or if the layer must be editable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loads the core purpose, and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, five parameters, and no output schema, the description adequately covers the use case. It could be more complete by mentioning coordinate system or error scenarios, but it is sufficient for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal value by restating what the schema already provides, though it clarifies the data format for tile IDs and empty tiles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'write', the resource 'part of the tile data of an editable tilemap layer', and distinguishes from the sibling tool 'scene-fill-editable-tilemap-layer-data' which writes the whole layer data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool ('update a layer's data without having to send the whole layer data again'), implying its utility for partial updates, but does not explicitly mention when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.6assets-add-google-font-to-asset-packassets-get-available-animationsassets-get-available-asset-packsassets-get-available-bitmapfontsassets-get-available-spine-atlasesassets-get-available-spine-skeletonsassets-get-available-texturesassets-get-available-tilemapsassets-get-bitmapfont-imageassets-get-google-font-familiesassets-get-google-font-infoassets-get-spine-skeleton-infoassets-get-spine-skin-imageassets-get-spritesheet-imageassets-get-texture-binaryassets-get-texture-content-bounding-boxassets-get-texture-sizeassets-get-tilemap-dataget-system-instructionside-create-new-prefab-sceneide-create-new-sceneide-get-active-sceneide-get-all-prefabs-in-projectide-get-all-scenes-in-projectide-get-prefab-inheritanceide-open-sceneide-save-scenescene-add-editable-tilemapscene-add-editable-tilemap-layerscene-add-game-object-filtersscene-add-game-objectsscene-add-object-listscene-add-plain-objectsscene-add-tileset-to-editable-tilemapscene-clear-scenescene-declare-prefab-propertyscene-delete-game-object-filtersscene-delete-game-objectsscene-delete-plain-objectsscene-delete-prefab-propertyscene-delete-tileset-from-editable-tilemapscene-disable-arcade-physics-bodyscene-enable-arcade-physics-bodyscene-fill-editable-tilemap-layer-datascene-get-editable-tilemap-layer-selection-datascene-get-nested-prefabs-instancesscene-get-objects-datascene-get-scene-datascene-get-scene-dimensionscene-get-screenshotscene-move-game-object-in-render-listscene-move-game-objects-to-parentscene-pack-objects-in-containerscene-remove-object-listscene-resize-editable-tilemap-layerscene-update-game-object-filter-listscene-update-game-object-filtersscene-update-game-objectsscene-update-object-listscene-update-plain-objectsscene-write-editable-tilemap-layer-dataEach tool has a clear, distinct purpose, with domain prefixes (assets, ide, scene) and specific actions. Despite the large number, there is no overlap in functionality; every tool targets a unique operation on a specific resource type.
All tool names follow the consistent pattern of <domain>_<action>_<object> in snake_case, such as 'assets-add-google-font-to-asset-pack' and 'scene-delete-game-objects'. The naming is uniform and predictable.
With 61 tools, the server is extremely heavy. This far exceeds the typical well-scoped range (3-15) and even the 'too many' threshold of 25+, making it overwhelming for an agent to navigate efficiently.
The tool set provides comprehensive coverage of the Phaser Editor domain, including asset management, scene creation/editing, prefab handling, tilemap operations, physics bodies, and object lists. All common lifecycle operations (create, read, update, delete) are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Build, version, review, and export websites, web apps, and games from a conversation.
Build a game's 2D art layer with your agent: characters, animations, tilesets, levels, 5 engines.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/phaserjs/editor-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
