Click on "Deploy 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., "@Cocos Creator Local MCP Create a new Cocos Creator 3.8 project called MyPlatformer"
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.
English | 简体中文
cocos-creator-local-mcp is an MCP server for local Cocos Creator automation. It gives coding agents a practical tool surface for creating Cocos Creator 3.8 projects, installing a project-local editor bridge, assembling scenes, saving editor state, and building local WeChat Mini Game packages.
This project is intentionally focused on local project automation, not AI asset generation. Pair it with an asset pipeline MCP when your workflow needs generated sprites, audio, UI packs, or tilesets.
Coding agents can write TypeScript, but Cocos games are not finished by code alone. A playable local prototype also needs scene files, node hierarchies, serialized component references, editor imports, build configuration, and platform output checks.
This MCP closes that local loop:
create project -> create scene -> generate scripts -> open editor
-> apply scene blueprint -> save scene -> write build config
-> build wechatgame -> inspect outputIt is designed for agent-driven development on a developer machine where Cocos Creator is installed locally.
Related MCP server: mcp-bridge
Local-first Cocos Creator 3.8 workflow with no cloud service dependency.
Project creation from Cocos Creator built-in templates.
Project-local editor bridge extension for scene inspection and mutation.
Generated mini-game starter scripts and scene blueprints.
Scene opening, node creation, component attachment, property assignment, and save operations through the bridge.
High-level sprite placement helpers for generated Cocos assets.
Repeatable wechatgame build configuration and command-line build execution.
Output checks for required WeChat Mini Game files and package-size warnings.
WeChat DevTools CLI helpers for opening local builds, preview artifacts, cache cleanup, and explicit runtime-evidence vocabulary.
Static runtime package audits for oversized textures, audio, scripts, and first-package risk.
Vertical-slice evidence aggregation that separates build success, DevTools opening, and verified gameplay.
Clean responsibility boundary: this MCP automates Cocos locally; asset generation belongs in a separate asset MCP.
Node.js 20 or newer.
macOS for the default paths currently documented here.
Cocos Creator 3.8.8 installed locally, or pass creatorPath to tools.
WeChat DevTools is optional unless you want to open/debug the built package in the simulator.
Default Cocos Creator executable path on macOS:
/Applications/Cocos/Creator/3.8.8/CocosCreator.app/Contents/MacOS/CocosCreatorDefault WeChat DevTools CLI path on macOS:
/Applications/wechatwebdevtools.app/Contents/MacOS/cligit clone https://github.com/lightblink/cocos-creator-local-mcp.git
cd cocos-creator-local-mcp
npm install
npm run buildRun locally during development:
npm run devUse the built server:
node dist/index.jsValidate the project:
npm run checkExample for MCP clients that launch stdio servers:
{
"mcpServers": {
"cocos-creator-local": {
"command": "node",
"args": [
"/absolute/path/to/cocos-creator-local-mcp/dist/index.js"
],
"startup_timeout_sec": 120
}
}
}If you also use an asset generation MCP, keep it as a separate server:
{
"mcpServers": {
"cocos-creator-local": {
"command": "node",
"args": [
"/absolute/path/to/cocos-creator-local-mcp/dist/index.js"
]
},
"cocos-asset-forge": {
"command": "node",
"args": [
"/absolute/path/to/cocos-asset-forge-mcp/dist/index.js",
"--config",
"/absolute/path/to/cocos-asset-forge-mcp/examples/config.example.json"
]
}
}
}Tool | Purpose |
| Detect local Cocos Creator and WeChat DevTools CLI paths. |
| Create a local Cocos Creator 3.8 project from a built-in template. |
| Launch or reuse Cocos Creator for a project and optionally wait for the bridge. |
| Create a Cocos scene from local Creator templates. |
| Inspect project folders, settings, scenes, scripts, bridge files, and build output. |
| Create a Cocos Creator TypeScript component. |
| Generate baseline mini-game scripts and a scene blueprint. |
| Generate an optional multi-system TypeScript architecture starting point for games such as tower defense. |
| Install the project-local editor bridge extension. |
| Check bridge files and optionally ping the HTTP bridge. |
| Poll until the bridge responds. |
| Call a bridge HTTP route directly. |
| Open a scene in the running Cocos editor. |
| Apply a scene blueprint through the bridge and optionally save. |
| Assign a resolved SpriteFrame asset to an existing node's |
| Assign ordered generated frame assets to a component array property such as |
| Ensure one Sprite node exists and assign a generated SpriteFrame asset. |
| Place multiple generated sprite assets into the scene in one operation. |
| Write a repeatable local WeChat Mini Game build config, including optional |
| Run a local Cocos |
| Inspect build output for required files and size warnings. |
| Open a local |
| Run WeChat DevTools preview and optionally write QR/info artifacts. |
| Clean DevTools cache, close a project, or quit DevTools locally. |
| Audit output/assets for package budgets, oversized textures/audio, and first-package risk. |
| Aggregate scene, bridge, build, DevTools, screenshot, log, and manual gameplay evidence into a verification status. |
This repository includes optional Codex skills under skills/. The MCP provides executable local automation tools; the skills teach an agent when and how to use those tools for game architecture, scene/prefab assembly, and local WeChat Mini Game builds.
Included skills:
cocos-creator-gameplay-architecture: build maintainable Cocos Creator gameplay code, UI systems, and runtime flow.
cocos-game-balance-director: design tunable numbers, probability tables, economy loops, progression curves, and balance sanity checks.
cocos-game-design-director: turn a Cocos mini-game idea into a playable design brief, core loop, vertical slice, and downstream handoffs.
cocos-game-reference-research-director: research reference games, genre expectations, IP-safe design pillars, and downstream handoffs before planning.
cocos-interaction-ux-director: define touch-first controls, HUD states, feedback, readability, and adaptive layout requirements.
cocos-level-content-design: design levels, waves, missions, procedural rules, pacing, and reusable content data.
cocos-playtest-qa-director: plan playtest gates, collect runtime evidence, and verify whether local playability claims are supported.
cocos-scene-prefab-assembly: wire scenes, prefabs, components, serialized properties, and generated assets into playable local scenes.
cocos-wechat-local-build: prepare, build, inspect, and debug local wechatgame packages without publishing.
To install them for Codex:
mkdir -p ~/.codex/skills
cp -R skills/cocos-creator-gameplay-architecture ~/.codex/skills/
cp -R skills/cocos-game-balance-director ~/.codex/skills/
cp -R skills/cocos-game-design-director ~/.codex/skills/
cp -R skills/cocos-game-reference-research-director ~/.codex/skills/
cp -R skills/cocos-interaction-ux-director ~/.codex/skills/
cp -R skills/cocos-level-content-design ~/.codex/skills/
cp -R skills/cocos-playtest-qa-director ~/.codex/skills/
cp -R skills/cocos-scene-prefab-assembly ~/.codex/skills/
cp -R skills/cocos-wechat-local-build ~/.codex/skills/Use these skills together with an MCP client entry that exposes this server as cocos_creator_local. If your workflow also generates sprites, audio, UI packs, or tilesets, pair this server with the separate Cocos Asset Forge MCP.
When paired with an asset generation MCP, write generated PNGs under the Cocos project assets/ folder, wait for Cocos AssetDB import, then place them with cocos_local_place_sprite_assets.
Example sprite placement payload:
{
"projectRoot": "/absolute/path/to/my-cocos-project",
"openScene": true,
"sprites": [
{
"assetPath": "assets/generated/background.png",
"nodePath": "Scene/Canvas/GameRoot/Background",
"position": { "x": 0, "y": 0, "z": -10 },
"scale": { "x": 1, "y": 1, "z": 1 }
},
{
"assetPath": "assets/generated/player.png",
"nodePath": "Scene/Canvas/GameRoot/Player",
"position": { "x": 0, "y": -120, "z": 0 },
"scale": { "x": 1, "y": 1, "z": 1 }
}
]
}assetPath accepts db://assets/..., assets/..., an absolute project path, or a SpriteFrame UUID. The tool resolves AssetDB info and prefers SpriteFrame sub-assets when assigning Sprite.spriteFrame.
For generated frame-by-frame animation, import the individual PNG frames under assets/, add a component with an array property such as @property([SpriteFrame]) frames, then call cocos_local_assign_sprite_frame_sequence:
{
"projectRoot": "/absolute/path/to/my-cocos-project",
"nodePath": "Scene/Canvas/GameRoot/Player",
"componentType": "SpriteFrameAnimator",
"property": "frames",
"assetPaths": [
"assets/art/characters/run/frame-001.png",
"assets/art/characters/run/frame-002.png",
"assets/art/characters/run/frame-003.png"
],
"addComponent": true
}The sequence tool preserves the provided order, resolves each PNG to its imported SpriteFrame sub-asset, assigns the resulting asset array through the editor bridge, and saves the scene when requested.
Call cocos_local_get_environment to confirm local paths.
Call cocos_local_create_project with a target projectRoot.
Call cocos_local_open_project with waitForBridge: true; by default it reuses an already-open editor for the same project instead of launching a duplicate window.
For non-trivial gameplay, consider cocos_local_create_architecture_skeleton before feature scripts, then prune or merge the suggested systems to fit the actual slice.
Call cocos_local_apply_scene_blueprint to create and wire the starter scene.
Call cocos_local_create_wechat_build_config with startScenePath: "assets/scenes/Main.scene" and an explicit designResolution such as { "width": 720, "height": 1280, "fitWidth": true, "fitHeight": false } for phone-first mini-games.
Call cocos_local_build_wechatgame.
Call cocos_local_check_wechat_build_output.
Call cocos_local_audit_runtime_package to catch package-budget and asset-size risks before opening the simulator.
Call cocos_local_open_wechat_devtools to open the local build/wechatgame output.
After observing launch, first input, core loop, result/failure, restart, and logs, call cocos_local_collect_runtime_evidence.
Cocos Creator returns exit code 36 for a successful command-line build.
Use precise verification language:
Build verified: the build completed and output files passed inspection.
DevTools opened: WeChat DevTools accepted the local build path.
Runtime verified: launch, first input, core loop, result/failure, restart, logs, and screenshot or scene-summary evidence were checked.
Do not describe a vertical slice as runtime-verified from build output alone.
The bridge is installed into the target Cocos project as a project-local extension:
extensions/codex-editor-bridge/It exposes a localhost HTTP API while the project is open in Cocos Creator. The MCP uses that API to inspect and edit the active scene. The extension is local to the project being automated and should not be shipped with your game runtime.
This server is for local development and packaging only. It does not:
upload WeChat Mini Game builds
submit review or release candidates
manage production app credentials
change payment, ads, login, or backend configuration
generate art or audio assets
Use placeholder WeChat appids only for pure local gameplay checks. Use a real appid before testing platform APIs.
npm install
npm run typecheck
npm test
npm run buildThe unit tests verify the editor bridge scaffold and generated mini-game skeleton. A full local smoke test also requires Cocos Creator 3.8.8 on the host machine.
Cocos Creator and WeChat are trademarks of their respective owners. This project is an unofficial local automation tool and is not affiliated with or endorsed by Cocos or Tencent.
Read a generated scene blueprint JSON and apply it to the currently open Cocos scene through the editor bridge.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| openScene | No | ||
| saveScene | No | ||
| scenePath | No | assets/scenes/Main.scene | |
| timeoutMs | No | ||
| projectRoot | Yes | ||
| blueprintPath | No | .codex/cocos/starter-scene-blueprint.json | |
| openSceneDelayMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions applying through the editor bridge but does not describe side effects, destructiveness, or prerequisites beyond 'currently open scene'. This is minimal and leaves the agent guessing about safety.
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 lacks structure. It does not front-load key information or break down the tool's operation. For a tool with 8 parameters, this is 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?
Given 8 parameters, no annotations, and no output schema, the description is severely incomplete. It omits the process, side effects, prerequisites (like editor bridge installation), and parameter guidance. The agent cannot use this tool effectively without additional 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 0%, and the description mentions no parameters. The agent is left with only parameter names (e.g., projectRoot, blueprintPath) which may be ambiguous. The description should add meaning to at least some parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (read and apply) and the resource (generated scene blueprint JSON to the currently open Cocos scene) with specific verb and resource. It differentiates from sibling tools like cocos_local_create_scene_from_template or cocos_local_open_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 is provided on when to use this tool vs alternatives like cocos_local_create_scene_from_template. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a Cocos asset path or SpriteFrame UUID and assign it to an existing node's Sprite.spriteFrame property.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| nodePath | Yes | Existing scene node path, e.g. Scene/Canvas/GameRoot/Player. | |
| assetPath | Yes | Sprite asset reference: db://assets/..., assets/..., absolute project path, or a SpriteFrame UUID. | |
| openScene | No | ||
| saveScene | No | ||
| scenePath | No | assets/scenes/Main.scene | |
| timeoutMs | No | ||
| projectRoot | Yes | ||
| addSpriteComponent | No |
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 basic action but omits important behavioral traits such as side effects (e.g., the saveScene parameter defaults to true, implying scene file modification), error behavior, or prerequisites like requiring an open editor. The default addSpriteComponent=true is not mentioned, which could lead to unexpected node modifications.
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 main action. However, it sacrifices detail for brevity; it could include a bit more context without becoming verbose. Still, it is well-structured and easy to read.
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 (9 parameters, 3 required, no output schema, no annotations), the description is insufficient. It does not explain return values, error states, prerequisites (e.g., editor running, project loaded), or the behavior of key parameters like addSpriteComponent or saveScene. The description leaves significant gaps for an agent to understand the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%. The description does not elaborate on any of the 9 parameters beyond the brief schema descriptions. For example, it doesn't explain the meanings of port, openScene, saveScene, scenePath, timeoutMs, projectRoot, or addSpriteComponent. With low coverage, the description should compensate but fails to provide meaningful additional context.
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 resolves an asset path or UUID and assigns to an existing node's Sprite.spriteFrame property. It is specific about the verb (resolve and assign) and resource (Sprite.spriteFrame), and it distinguishes from sibling tools like cocos_local_create_sprite_node which creates a new node.
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 existing nodes ('assign it to an existing node') but does not provide explicit guidance on when to use it versus alternatives, nor does it mention when not to use it. No exclusions or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Cocos Creator command-line build for the wechatgame platform using a configPath or raw build options.
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | ||
| logDest | No | Optional Cocos build log file path. | |
| timeoutMs | No | ||
| configPath | No | Build config JSON path created by cocos_local_create_wechat_build_config. | |
| creatorPath | No | ||
| projectRoot | Yes | ||
| buildOptions | No | Raw Cocos --build option string. Overrides configPath when provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects (e.g., file creation), required permissions, error behavior, or duration. For a build tool that likely mutates output, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and target platform. It is concise, though the phrase 'command-line build' is slightly redundant given 'Run Cocos Creator'.
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 a build tool with 7 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, required parameters (beyond projectRoot), or build behavior, leaving the agent underinformed.
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 low (43%), and the tool description adds no additional meaning beyond what the schema provides. Parameters like dryRun, timeoutMs, creatorPath lack explanations, and the description only mentions configPath and buildOptions without clarifying their roles or syntax.
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 (run build), target platform (wechatgame), and methods (configPath or raw options). It distinguishes from sibling tools like cocos_local_check_wechat_build_output and cocos_local_create_wechat_build_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for building the wechatgame platform), but does not provide explicit guidance on when to choose configPath vs raw buildOptions, nor does it mention prerequisites or alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call the localhost HTTP bridge exposed by the Cocos editor extension after it is enabled in Cocos Creator.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| port | No | ||
| route | No | HTTP route exposed by the editor bridge, such as /health or /scene/summary. | /health |
| method | No | GET | |
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but discloses minimal behavior: it mentions the bridge must be enabled but omits important traits such as HTTP request nature, error handling, return values, or potential destructive effects. The tool's behavior as a network call is only inferred from parameter names.
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 directly states the action. It is concise and front-loaded, though the precondition 'after it is enabled' could be clarified or placed separately.
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 5 parameters (including a nested object) and no output schema, the description is insufficient. It fails to explain how to construct calls, what the body should contain, or what responses are expected, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%) and the description adds no parameter information beyond the schema. The 'body' parameter (a generic object) is unexplained, and the purposes of port, method, and timeout are left to defaults without context.
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 a means to call the localhost HTTP bridge of the Cocos editor extension, using a verb+resource format. It distinguishes from sibling tools by being a generic caller, but could be more precise about its role as an HTTP client for arbitrary endpoints.
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 the many sibling tools (e.g., cocos_local_check_editor_bridge, cocos_local_assign_sprite_frame). The description implies usage for custom calls but does not explicitly state context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the project-local Codex editor bridge extension files exist and optionally ping its localhost HTTP server.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| pingHttp | No | ||
| projectRoot | Yes | ||
| extensionName | No | codex-editor-bridge |
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 mentions checking file existence and optional ping, but does not explain what happens if files are missing, what the HTTP ping checks, or what the tool returns on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is front-loaded with the main action. However, it could be slightly more structured by listing the two checks separately.
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 4 parameters, no output schema, and no annotations, the description is too sparse. It lacks information about return values, error states, and how the tool fits into the workflow of using the editor bridge. The sibling tools indicate a workflow but the description does not acknowledge it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain each parameter. It only implies usage of projectRoot, port, and pingHttp, but omits extensionName entirely. The phrase 'optionally ping' hints at pingHttp, but no parameter details are given.
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 'check' and the resource: existence of the Codex editor bridge extension files, with optional HTTP ping. This distinguishes it from sibling tools like 'cocos_local_install_editor_bridge' and 'cocos_local_call_editor_bridge'.
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. It does not mention that it should be used as a prerequisite check before calling or installing the bridge, nor does it suggest any conditions for omitting the ping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a local Cocos wechatgame build output for required files and package-size budget warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| outputDir | No | Path to built wechatgame folder. Defaults to <projectRoot>/build/wechatgame. | |
| projectRoot | Yes | ||
| mainPackageLimitBytes | No | ||
| totalPackageLimitBytes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose behavioral traits such as whether the tool is read-only, destructive, or requires specific permissions. It states it checks for warnings but does not describe side effects, error behavior, or output format, which is insufficient for safe invocation.
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 key purpose. Every word contributes meaning, with no redundant or unnecessary text.
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 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain what the tool returns on success or failure, how to interpret results, or any constraints (e.g., timeout, file system access). More detail is needed for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only outputDir has a description), and the tool description adds no parameter-level information. The meaning of projectRoot, mainPackageLimitBytes, and totalPackageLimitBytes is not explained, leaving significant ambiguity for the agent despite their presence in 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 the tool checks a local Cocos wechatgame build output for required files and package-size warnings. It differentiates from sibling check tools like cocos_local_check_editor_bridge by specifying 'wechatgame build output'. However, it could be more explicit about what constitutes 'required files'.
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 or conditions for use. It lacks any 'when-to-use' or 'when-not-to-use' context, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Cocos Creator 3.8 TypeScript Component script with ccclass, typed properties, and lifecycle stubs.
| Name | Required | Description | Default |
|---|---|---|---|
| baseClass | No | Component | |
| className | Yes | Cocos component class name, e.g. GameManager or PlayerController. | |
| lifecycle | No | ||
| overwrite | No | ||
| properties | No | ||
| scriptPath | No | Path under project assets, e.g. assets/scripts/GameManager.ts. Defaults to assets/scripts/<className>.ts. | |
| description | No | Optional short comment describing component responsibility. | |
| projectRoot | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral aspects. It mentions the script includes ccclass, typed properties, and lifecycle stubs, but does not disclose side effects (e.g., file creation, overwrite behavior), error conditions, or required permissions. Critical gaps exist for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 15-word sentence that immediately conveys the tool's purpose. No extraneous information is present, making it efficient 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?
Given the tool has 8 parameters, no output schema, no annotations, and 38% schema coverage, the description is too sparse. It omits essential context about parameter usage, outcome, and error handling, leaving significant gaps 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?
Schema description coverage is only 38%, and the tool description does not add parameter-specific details. It hints at lifecycle and properties but fails to explain parameters like overwrite, scriptPath, projectRoot, or baseClass. The high-level summary does not compensate for the low 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 specifies 'Create a Cocos Creator 3.8 TypeScript Component script with ccclass, typed properties, and lifecycle stubs.' It clearly states the verb (Create) and the resource (Component script), and distinguishes from sibling tools that create other Cocos artifacts like scenes or projects.
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 component scripts, and the tool name and title make it clear. However, it does not explicitly state when to use this tool versus alternatives like cocos_local_create_scene_from_template, but the context of sibling tools and the title provide sufficient clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a minimal Cocos Creator 3.8 mini-game runtime skeleton plus a scene assembly blueprint for Editor Bridge application.
| Name | Required | Description | Default |
|---|---|---|---|
| gameName | No | Codex Mini Game | |
| overwrite | No | ||
| scriptDir | No | Directory under project assets/ for generated TypeScript components. | assets/scripts/codex |
| projectRoot | Yes | ||
| targetScore | No | ||
| blueprintPath | No | Where to write the scene assembly blueprint JSON under the project root. | .codex/cocos/starter-scene-blueprint.json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as side effects, permissions, or what files are created. It lacks details on the runtime skeleton's structure or the blueprint format, leaving the agent without critical context about the tool's impact.
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 lacks structure. It front-loads the core action but could benefit from a bulleted list or clearer separation of the two outputs. Every sentence earns its place, but more detail could be added without verbosity.
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 six parameters, the description is incomplete. It does not explain the blueprint's purpose, the default values' significance, or any prerequisites (e.g., project must exist). The complexity is moderate, but the description leaves 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 description coverage is only 33% (two out of six parameters have descriptions). The tool description does not explain any parameters beyond the schema's built-in descriptions, failing to compensate for the low coverage. For example, the 'gameName' and 'overwrite' parameters are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a minimal Cocos Creator 3.8 mini-game runtime skeleton and a scene assembly blueprint for Editor Bridge. It specifies the verb 'Create' and the resource, and the context distinguishes it from sibling tools like 'cocos_local_apply_scene_blueprint' which applies a blueprint.
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. The description implies it's for initial setup, but does not mention when not to use it or provide comparisons with sibling tools like 'cocos_local_create_project' or 'cocos_local_create_scene_from_template'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a local Cocos Creator 3.8 project from a built-in template, optionally adding Codex mini-game skeleton scripts and the editor bridge.
| Name | Required | Description | Default |
|---|---|---|---|
| gameName | No | Project package name. Defaults to the project directory name. | |
| overwrite | No | ||
| scenePath | No | assets/scenes/Main.scene | |
| createScene | No | ||
| creatorPath | No | Optional explicit CocosCreator executable path used to locate built-in templates. | |
| projectRoot | Yes | ||
| templateName | No | empty-2d | |
| createSkeleton | No | ||
| editorBridgePort | No | ||
| installEditorBridge | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions creation and optional additions but fails to note side effects like overwriting an existing project (overwrite defaults to false), or what happens if creatorPath is invalid. No mention of error conditions or required dependencies.
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 20-word sentence that efficiently conveys the tool's core function and optional features. Every part earns its place without 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 10 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return value, prerequisites (e.g., Cocos Creator installation), or how this tool relates to siblings like cocos_local_create_minigame_skeleton (whether it calls that internally).
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 low (20%), and the description adds minimal parameter context. It hints at createSkeleton and installEditorBridge via 'optionally adding Codex mini-game skeleton scripts and the editor bridge,' but does not explain projectRoot, scenePath, templateName, or overwrite behavior beyond defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a local Cocos Creator 3.8 project from a built-in template, with optional additions. It uses a specific verb ('Create') and resource ('local Cocos Creator 3.8 project'), and the optional features (Codex mini-game skeleton and editor bridge) distinguish it from sibling tools like cocos_local_create_scene_from_template.
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 setting up a new Cocos project, but it lacks explicit guidance on when to use this tool vs. alternatives like cocos_local_create_minigame_skeleton or cocos_local_open_project. No 'when not to use' or 'if you need X, use Y instead' instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Cocos Creator scene asset from the local Creator 3.8 built-in default scene templates.
| Name | Required | Description | Default |
|---|---|---|---|
| template | No | 2d | |
| overwrite | No | ||
| sceneName | No | Main | |
| scenePath | No | assets/scenes/Main.scene | |
| creatorPath | No | ||
| projectRoot | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Create... from templates'. It does not disclose behavioral traits like whether existing files are overwritten (despite an 'overwrite' parameter), required permissions, or side effects. The tool's impact on the project or the environment (e.g., editor running) is omitted.
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, making it concise, but it lacks structure and front-loading of important constraints. Every word earns its place, but the brevity sacrifices informativeness. A slightly expanded description could improve clarity without losing 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?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description is woefully incomplete. It does not explain the return value, error conditions, or prerequisites (e.g., project existence, editor state). Users are left guessing about outcomes and valid usage contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning beyond the schema. However, it only contextualizes the 'template' parameter by mentioning 'built-in default scene templates'. Other critical parameters like 'sceneName', 'scenePath', 'overwrite', 'creatorPath', and 'projectRoot' are not explained. Defaults are not mentioned in the description, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'Cocos Creator scene asset from local Creator 3.8 built-in default scene templates'. It distinguishes this tool from sibling tools like 'cocos_local_create_project' or 'cocos_local_create_component_script' by specifying the origin and type.
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. It does not mention prerequisites, limitations, or scenarios where another tool might be preferable, such as creating scenes from custom templates or using the editor directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ensure a scene node exists, attach a Sprite component, resolve a SpriteFrame asset, assign it, and optionally save the scene.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| sprite | Yes | ||
| openScene | No | ||
| saveScene | No | ||
| scenePath | No | assets/scenes/Main.scene | |
| timeoutMs | No | ||
| projectRoot | Yes | ||
| openSceneDelayMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It outlines key steps (ensure node, attach, resolve, assign, save) but omits behavior on conflicts (e.g., node already exists), error handling, or side effects. 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 single-sentence description is concise and front-loaded with key actions. It efficiently communicates the main purpose, though it could be slightly expanded for clarity on optional steps. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, nested objects, no output schema, and no annotations, the description is too brief. It fails to explain parameters like port, timeout, openSceneDelayMs, or what happens on success. The tool's complexity demands more detail.
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 low (~25%). The description adds meaning to 'sprite.assetPath' by specifying it resolves a SpriteFrame. However, other parameters (e.g., port, timeout, saveScene) lack explanation. The description only partially compensates for low 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 'create/ensure' and the resource 'sprite node', detailing multiple steps: ensure node exists, attach Sprite component, resolve asset, assign, optionally save. It distinguishes from siblings like 'cocos_local_assign_sprite_frame' which presumably only assigns.
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 creating a sprite node within a scene but provides no explicit guidance on when to use versus alternatives (e.g., 'cocos_local_place_sprite_assets') or when not to use. No exclusions or conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Cocos Creator 3.x command-line build config JSON for the wechatgame platform.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | No | wx0000000000000000 | |
| debug | No | ||
| scenes | No | Optional Cocos build scenes array. | |
| gameName | No | Cocos WeChat Game | |
| md5Cache | No | ||
| packages | No | Optional extra platform package config to merge under packages.wechatgame. | |
| buildPath | No | project://build | |
| overwrite | No | ||
| configPath | No | Where to write the build config JSON. Defaults to .codex/cocos-build/wechatgame.build.json under the project. | |
| outputName | No | wechatgame | |
| startScene | No | Optional start scene UUID. | |
| projectRoot | Yes | ||
| startScenePath | No | Optional scene asset path such as assets/scenes/Main.scene; used to read the startScene UUID from its .meta file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits such as side effects, overwrite behavior, required permissions, or whether it modifies project files. It only states the output type without further 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 a single concise sentence. However, it is overly succinct and omits critical context that could be added without significant verbosity.
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 13 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain the JSON structure, usage context (e.g., before building), or how the output is consumed. Maximum viable score is 3, but it's below that due to 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 description coverage is only 38% (5 of 13 parameters have descriptions). The tool description does not add any parameter meaning beyond the schema. Several important parameters like 'projectRoot' and 'debug' lack 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 clearly states the action ('Create'), the resource ('build config JSON'), and the platform ('wechatgame'). It distinguishes from siblings like 'cocos_local_build_wechatgame' which performs the actual build.
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 vs. alternatives. It does not mention prerequisites, exclusions, or contextual cues among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect local Cocos Creator and WeChat DevTools CLI paths for local WeChat Mini Game development.
| Name | Required | Description | Default |
|---|---|---|---|
| creatorPath | No | Optional explicit CocosCreator executable path. | |
| wechatDevToolsCliPath | No | Optional explicit WeChat DevTools CLI path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, required permissions, or failure behaviors (e.g., if paths are not found). Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with purpose. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lacks details on return values or error states. For a simple detection tool, it is marginally complete but could be improved.
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 does not add meaning beyond the schema's parameter descriptions, merely restating the detection scope.
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 detects Cocos Creator and WeChat DevTools CLI paths, using a specific verb ('detect') and resource. It distinguishes from sibling tools like building or creating scenes.
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 when-to-use or alternative guidance. The description only states functionality, leaving the agent to infer usage context without exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a Cocos Creator project root for the files and folders needed before local preview or wechatgame build.
| Name | Required | Description | Default |
|---|---|---|---|
| projectRoot | Yes | Absolute or relative path to a Cocos Creator project root. |
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 implies a non-destructive inspection but does not explicitly state whether it modifies anything, what happens on success/failure, or what exactly is checked. This 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 is a single, clear sentence, making it concise and front-loaded. It wastes no words, though it could be structured with more details (e.g., bullet points) without losing 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?
Given the lack of annotations and output schema, the description is too brief. It does not explain what the tool returns (e.g., list of missing files, boolean status) or how to interpret the result. This leaves the agent with insufficient information 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?
The schema already describes the single parameter 'projectRoot' with 100% coverage. The description adds no additional meaning beyond what the schema provides, so the 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 uses the specific verb 'Inspect' and clearly identifies the resource as 'a Cocos Creator project root'. It states the tool's purpose: checking for files and folders needed before local preview or wechatgame build. This distinguishes it from sibling tools like building or opening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool should be used 'before local preview or wechatgame build', providing clear context for its usage. However, it does not explicitly exclude other times or mention alternatives, but its purpose is unique among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a project-local Cocos Creator 3.x editor extension that exposes a localhost bridge for scene inspection and simple scene operations.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| overwrite | No | ||
| projectRoot | Yes | ||
| extensionName | No | codex-editor-bridge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits but only mentions installation and bridge exposure. It omits side effects like file creation, overwrite behavior (despite overwrite parameter), permission requirements, or idempotency. Critical behavioral context is 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, concise sentence of 21 words that front-loads the main action. While efficient, it could benefit from additional context without becoming verbose. It earns a 4 for appropriate length but slight 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 has 4 parameters, no annotations, and no output schema, the description is notably incomplete. It does not explain return values, installation verification, required permissions, or effects on the project. Sister tools like check_editor_bridge could provide verification but are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of parameters (port, overwrite, projectRoot, extensionName). With 0% schema description coverage, the description fails to compensate by adding meaning beyond parameter names and default values. Users must infer semantics from names 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 it installs a project-local Cocos Creator 3.x editor extension that exposes a localhost bridge for scene inspection and operations. The verb 'Install' and specific resource 'Cocos Creator 3.x editor extension' make the purpose unambiguous, and it distinguishes from sibling tools like call, check, wait.
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 as a setup step before using bridge-related tools, but it lacks explicit guidance on when to use vs. alternatives, such as when not to install or prerequisites. No exclusion criteria or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch Cocos Creator 3.8 for a local project and optionally wait until the Codex editor bridge responds.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| dryRun | No | ||
| timeoutMs | No | ||
| creatorPath | No | ||
| projectRoot | Yes | ||
| waitForBridge | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only mentions launching and optional waiting. No details on behavior like whether it checks for existing instances, blocking nature, or side effects. Annotations are absent, so description carries the burden but fails to disclose important traits.
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, front-loaded with main action. However, it is too brief for a complex tool, sacrificing necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 6 parameters, the description is severely incomplete. It lacks return value info, error conditions, and parameter roles.
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 0% and the description provides no explanation of any of the 6 parameters (port, dryRun, timeoutMs, creatorPath, projectRoot, waitForBridge). Agents cannot infer 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 'Launch Cocos Creator 3.8 for a local project' with the verb 'Launch' and resource. It distinguishes from siblings like 'open_scene' which opens an existing scene, but does not explicitly contrast with other 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 (e.g., when to also use 'waitForBridge'). No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a Cocos Creator scene asset in the running editor through the Codex editor bridge.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| scenePath | No | assets/scenes/Main.scene | |
| sceneUuid | No | ||
| timeoutMs | No | ||
| projectRoot | Yes |
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 what happens if the scene does not exist, if the editor is not running, or whether the tool modifies state. Only states the action, lacking behavioral detail.
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 short (one sentence), which is concise but lacks structure. It could be improved by front-loading key constraints or parameters.
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 5 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain how to identify the scene (path vs uuid), default behavior, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions. The tool description adds no information about any of the 5 parameters (projectRoot, scenePath, sceneUuid, port, timeoutMs), leaving the agent to infer their meaning from names 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 action ('open'), the resource ('Cocos Creator scene asset'), and the context ('in the running editor through the Codex editor bridge'). It differentiates from sibling tools like cocos_local_create_scene_from_template or cocos_local_apply_scene_blueprint, which involve creation or modification.
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. With many siblings (e.g., cocos_local_open_project, cocos_local_create_scene_from_template), the agent would benefit from conditions like 'Use when you need to open an existing scene for editing.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place multiple generated sprite assets into the active Cocos scene as Sprite nodes in one bridge operation.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| sprites | Yes | ||
| openScene | No | ||
| saveScene | No | ||
| scenePath | No | assets/scenes/Main.scene | |
| timeoutMs | No | ||
| projectRoot | Yes | ||
| openSceneDelayMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only hints at batch behavior ('in one bridge operation'). It does not disclose side effects (e.g., scene saving default), required editor state, or failure modes.
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 that efficiently conveys the core action. 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?
Lacks details on return values, error conditions, and how the batch placement works. Given the complexity (8 parameters, nested sprites array), more context is needed for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is very low (only assetPath and nodePath within items have descriptions). The description does not explain any parameters, leaving the agent to infer from names and defaults.
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 places multiple generated sprite assets into the active Cocos scene as Sprite nodes in one operation. This distinguishes it from siblings like cocos_local_create_sprite_node (single node) and cocos_local_assign_sprite_frame (frame assignment).
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. It does not mention scenarios or trade-offs compared to other sprite-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll the localhost Codex editor bridge until it responds or a timeout is reached.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| timeoutMs | No | ||
| intervalMs | No |
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 polling and timeout behavior, but lacks details about side effects (e.g., blocking, errors on timeout), whether it modifies state, or what 'responds' means. Behavior is partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It is very concise, though additional details about parameters or return behavior would improve it without significantly increasing length.
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 3 parameters with no schema descriptions, no output schema, and many sibling tools, the description is insufficient. It does not explain the bridge context, what 'responds' means, or what the tool returns. Completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any parameter semantics, such as the meaning of 'port', 'timeoutMs', or 'intervalMs'. The schema provides constraints but no descriptions, making it hard for an agent to correctly use the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('poll'), the resource ('localhost Codex editor bridge'), and the termination condition ('until it responds or a timeout is reached'). This distinguishes it from sibling tools like 'check_editor_bridge' which likely checks once.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the bridge availability is needed, but it does not explicitly state when to use this tool vs. alternatives (e.g., 'check' or 'call'), nor provides when-not scenarios or prerequisites.
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.
v0.1.0cocos_local_apply_scene_blueprintcocos_local_assign_sprite_framecocos_local_build_wechatgamecocos_local_call_editor_bridgecocos_local_check_editor_bridgecocos_local_check_wechat_build_outputcocos_local_create_component_scriptcocos_local_create_minigame_skeletoncocos_local_create_projectcocos_local_create_scene_from_templatecocos_local_create_sprite_nodecocos_local_create_wechat_build_configcocos_local_get_environmentcocos_local_inspect_projectcocos_local_install_editor_bridgecocos_local_open_projectcocos_local_open_scenecocos_local_place_sprite_assetscocos_local_wait_for_editor_bridgeScored across 19 tools
Each tool has a distinct verb-noun pair clearly indicating its action (create, inspect, build, etc.) on a specific domain object (scene, script, build config, etc.). No two tools have overlapping purposes.
All tools follow the exact pattern cocos_local_verb_noun in snake_case, with consistent verb usage. The naming is uniform and predictable.
19 tools cover the full lifecycle of local Cocos Creator mini-game development without being excessive. Each tool serves a clear purpose within the domain.
The set covers project creation, scene management, sprite handling, scripting, editor bridge operations, building, and environment detection. No obvious gaps for the stated purpose of local Cocos Creator development.
MCP server for agentverse documentation, generated by doc2mcp.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Open-source Zapier/n8n alternative as an MCP server: agents build, run and debug your workflows.
Remote MCP server for AI.TV creators — delegate account operations to your AI agent over MCP.
