Cocos Creator Local MCP

by lightblink

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency5/5
All tools follow the exact pattern cocos_local_verb_noun in snake_case, with consistent verb usage. The naming is uniform and predictable.
Tool Count5/5
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.
Completeness5/5
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.
Average 3/5 across 19 of 19 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
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.
Conciseness3/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool 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.
Behavior2/5
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.
Conciseness2/5
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.
Completeness1/5
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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description 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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool 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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It 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.
Conciseness3/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, 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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states '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.
Conciseness3/5
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.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description is 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource '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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. 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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses 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.
Conciseness4/5
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, 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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a 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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create/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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations 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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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