Cocos MCP Kit

English | 简体中文

Cocos MCP Kit is an open-source extension that runs an MCP server inside Cocos Creator. It lets an MCP client inspect a project, work with scenes and assets, and verify results in the editor. It is built on Funplay MCP for Cocos 0.6.3 and has its own package, extension, and configuration identity.

The current target is Cocos Creator 3.8.x; the editor checks linked below were performed on 3.8.8. Available tools are not a promise that every workflow or Creator version has been validated. See the tool reference, development plan, requirements, and official Cocos CLI comparison for the exact scope.

Quick start

Before installation

• This repository is a Creator extension, not a game project. Use an existing Cocos project; start with a disposable test project and back up authored scenes/assets before editing.

• The recorded editor acceptance uses Windows / Creator 3.8.8. Other 3.8.x versions and operating systems need their own checks. The local stdio bridge requires Node.js 18+; no npm runtime dependencies are bundled or need installation.

• Version 0.1.0 is distributed as a GitHub Pre-release, not a stable release. Download CocosMcpKit.v0.1.0.zip and SHA256SUMS.txt from the project-owned release and verify the checksum before installation. Manual-installation evidence is limited to Windows / Creator 3.8.8; extension-manager installation remains unverified. npm/Registry publication and default automatic updates remain disabled. Do not use an upstream installer or npx package as a substitute.

Install into one project

1. Prepare <Cocos project>/extensions/cocos-mcp-kit. From a clean source checkout, copy package.json, browser.js, scene.js, bin/, lib/, panel/, i18n/, and the documentation explicitly listed in package.json.files, including LICENSE. Do not copy the entire working directory: exclude .git, AGENTS.md, local configuration, caches, tests and test projects. For a local ZIP candidate, use its extracted cocos-mcp-kit folder; for an npm TGZ candidate, place the extracted package contents in the same extension directory. These are manual file layouts, not a claim of Creator extension-manager installation approval.

2. Check that package.json, browser.js, scene.js and LICENSE are directly inside extensions/cocos-mcp-kit, not inside an extra package/ or cocos-mcp-kit/ layer. When replacing an installation, first save your work, close the target Creator project and keep a backup of its old extension outside extensions/; avoid merging old and new files. Then open the project in Creator. Do not run duplicate project/global copies of this extension for the same project.

3. Open Cocos MCP Kit > MCP Server. Confirm that the server says Running and copy the URL shown in the panel. The default listener is local (127.0.0.1); its port is derived from the project path, so use the displayed URL rather than a fixed port.

4. Select your client in the panel and choose Configure for its MCP entry. Configure + Skills also installs the optional project skills. If your client needs stdio instead of a direct HTTP MCP URL, run the bundled bridge from the Cocos project root:

   node extensions/cocos-mcp-kit/bin/cocos-mcp-kit.js --url http://127.0.0.1:PORT/

Replace PORT with the port shown in the panel. The bridge requires Node.js 18 or newer. Use Cocos MCP Kit > Tool Exposure to select core, full, or a custom tool set. core is the default; full includes scene editing and component tools such as list_available_component_types. Select full for the editing workflow below. The generated tool reference shows each tool's profile and access type. Project settings are stored in cocos-mcp-kit.config.json at the Cocos project root.

Confirm the connection

Reconnect the MCP client after configuration or tool-profile changes. Before any write, call get_project_info and verify the returned project path/name and Creator version against the intended project. get_tool_catalog reports tool exposure; the default catalog currently has 43 core / 154 full tools, while custom filters can change the visible set. A running process or a health response alone does not prove that the client is connected to the intended scene.

For a manually configured stdio client, use command node and arguments containing the absolute path to bin/cocos-mcp-kit.js, --url, and the panel's URL. The relative command above assumes the Cocos project root as its working directory. The bridge does not launch Creator or discover the project port; without an explicit URL it falls back to port 8765, which may be the wrong endpoint. Running node extensions/cocos-mcp-kit/bin/cocos-mcp-kit.js --help checks CLI availability only, not MCP connectivity. A bridge waiting quietly for client input is normal.

Project-derived ports and client entry names depend on the project path. After moving/copying a project, or changing its endpoint, configure that project's client entry again and recheck its identity. Old configurations without portMode can retain a fixed port. Resolve a temporary fallback-port warning before writing client configuration. Configuration conflicts should be reviewed, not fixed by deleting other projects' entries. Configure + Skills writes optional project files; plain Configure does not install skills. See project workflows.

Keep the service local and connect only trusted clients. core is not read-only: it includes stateful and script-execution tools. Tool filtering and JavaScript safety checks are not an OS sandbox or an authorization boundary; do not expose the editor service to an untrusted network.

Related MCP server: Cocos MCP Server

Bundled UI knowledge

Read cocos://knowledge/index through MCP Resources for a compact catalog, then request a topic such as cocos://knowledge/topic/widget-layout or component links through cocos://knowledge/component/cc.Widget. Six original Chinese summaries cover Creator 3.8.x UI concepts with official sources, review dates and project limitations. Queries are offline and read-only; they do not inspect a scene or prove runtime correctness. Requires a Resources-capable client. See the knowledge contract.

What it can do

Full-profile verify_ui adds a bounded wait, edit-mode structure checks and optional strictly targeted Scene/Game View PNGs with separate metadata. In preview mode structure is explicitly not_checked; a captured image is never a visual pass. Missing/ambiguous targets fail without window fallback, and clipped Game View captures are marked as partial. See the workflow and screenshot limits.

For explicit UI nodes, full-profile validate_ui checks UITransform, project design bounds, Sprite/Label asset references and serialized Button events, with rule/node exclusions. Missing data and truncated results remain incomplete. It never repairs, saves, invokes callbacks or proves visual correctness; Widget/Animation coexistence is only a potential-conflict warning. See the validation contract and Creator 3.8.8 checks.

These are examples, not the complete catalog. Some entries come from the Funplay base; newer tools have separate Creator verification records under docs/verification. The tool profile controls what an MCP client can see, and read-only, mutating, and stateful tools are marked in the tool reference.

A safe editing workflow

Build and check a first UI

1. Verify the project identity, select full, and open a saved scene in ordinary Scene edit mode. A fresh unsaved default scene must first be saved or replaced manually in Creator; guarded tools do not discard it. For a new Canvas/Camera scene, follow the explicit create_scene(mode="ui") entry in the UI builder guide, including its expectedSceneUuid and needsSave handling.

2. Import a project-owned white image and resolve its actual SpriteFrame subasset, not just the image UUID. For working buttons, prepare an imported/registered project script with the intended callback method; the extension does not create game logic.

3. Call get_ui_template with pause_menu, settings_dialog or result_dialog, then inspect its returned ui. Supply the current scene asset UUID and Canvas/UI parent node UUID to build_ui. If a newly created scene has been opened successfully, these are its returned info.uuid and ui.parentUuid. These two kinds of UUID are not interchangeable. See the template example.

4. Inspect the build result and actual nodes before repeating a write. Same-name roots are rejected, not updated. Unbound actions use static gray styling; manually enabling them also requires restoring Sprite/Label colors. This does not migrate old scenes or implement runtime state transitions.

5. Run verify_ui in edit mode with the scene UUID and all node UUIDs to check, not just the root: it does not recursively validate descendants. Save explicitly, reopen the saved scene, and recheck assets, scripts and event references. Resolve any unsaved-content warning before switching scenes.

6. Start embedded Game View separately when needed, physically click the buttons and inspect the rendered result. Use verify_ui(screenshot="game") only for preview evidence; preview structure is not_checked. A clipped image is partial evidence: adjust the visible Game View scale/layout before taking a complete screenshot. The verification guide explains provenance and result fields. Do not infer business behavior from a test callback alone.

Edit existing nodes

1. Inspect the target with get_scene_info, find_nodes, or list_components. Prefer a node UUID or a unique path; ambiguous names are rejected, and multiple selectors must agree.

2. For component work, call list_available_component_types or inspect_component before editing. The type catalog marks missing and non-Component classes; attachable means a registered Component subclass was found, not that every node will accept it.

3. Make one bounded change with a tool such as set_component_property, move_node, or set_sprite_frame. For example, this sets a Label's top-level string field (valueJson is a JSON-encoded string):

   {
     "uuid": "<node-uuid>",
     "componentName": "cc.Label",
     "propertyPath": "string",
     "valueJson": "\"Hello Cocos\""
   }

4. Save the scene, reopen it in Creator, and inspect the node or resource again. For a visual or interactive change, also check the running preview. An MCP success response alone does not prove persistence or visible behavior.

inspect_asset is a read-only exact lookup by UUID, db:// URL, assets/... path, or an absolute file path inside the project's assets directory. It does not add guessed extensions. Its stable details projection identifies the requested target and source asset, project-relative source file, disk presence and size, target/source/metadata importers, metadata ownership, and main/subasset linkage. Bounded raw info and metadata remain available for deeper inspection; serialized asset data is omitted unless includeData: true. Depth, item, node, string, and character limits bound returned snapshots and report truncation. A missing reported source file makes complete false. Treat complete: true as a complete bounded query under the requested options, not as proof that runtime string-based references or visual behavior are valid.

create_asset is a full-profile, create-only path for new UTF-8 .json and .txt assets. The parent directory must already exist under assets/. It refuses existing source files, .meta files, or asset-db identities; validates JSON and a 1 MiB content bound; creates through asset-db:create-asset; then verifies the exact source bytes, metadata UUID/importer, imported Cocos type, database readiness, and a settled second read. It never overwrites, auto-retries an uncertain native create, or accepts scene, prefab, script, metadata, or binary formats. Use the specialized scene/prefab workflows for Cocos serialized assets.

save_asset is the corresponding full-profile update path for existing, writable, fully imported UTF-8 .json and .txt main assets up to 1 MiB. It accepts an optional expectedSha256 to reject stale edits before mutation, returns a verified no-op when content is unchanged, and otherwise issues exactly one asset-db:save-asset request. Success requires the exact new source, unchanged UUID/importer/metadata, database readiness, and a settled second read. Scenes, prefabs, animation clips, scripts, images, audio, directories, and imported subassets are refused with type-specific guidance. write_file and replace_in_file remain filesystem helpers and do not prove Cocos resource persistence.

reimport_asset is a full-profile, existing-resource operation for imported JSON, text, image, and audio main assets up to 64 MiB. It sends one asset-db:reimport-asset request, then requires at least one library output to be regenerated and stable, with unchanged source bytes, main/subasset UUIDs, and nested importer settings. It rejects directories, subassets, scenes, prefabs, scripts, unsupported formats, and linked source paths. A native return without regenerated library output is reported as unverified; it is never retried automatically.

import_asset is a full-profile, create-only operation for one external JSON, UTF-8 text, image, or audio file up to 64 MiB. Give source as a local absolute path and target as a new path under an existing assets/ directory with the same extension; optional expectedSha256 protects against a stale source. It calls asset-db:import-asset once, then checks the imported bytes, new UUID, disk and database metadata, subasset identities, library output, readiness, and a settled second read. It rejects existing targets, external .meta sidecars, linked source paths, unsupported formats, and Cocos serialized assets. Uncertain native results are not retried automatically. See the Creator 3.8.8 verification.

import_folder is the full-profile counterpart for one external directory. It creates a new directory below an existing assets/ parent and limits the source to 64 supported files, 16 directories, four nested levels, and 64 MiB total. It rejects .meta sidecars, symbolic links, unsupported files, and existing targets before one native import. Success requires an exact directory tree, matching file bytes, distinct directory/file/subasset UUIDs, matching metadata, available library outputs, and stable asset-db reads. Partial or uncertain imports are left for explicit inspection; the tool never retries or deletes them automatically. See the verification record.

refresh_asset is a full-profile exact-file refresh for one existing project JSON, text, image, or audio source (up to 64 MiB). It accepts the file's db://assets/ URL or path, sends one asset-db:refresh-asset request, and checks unchanged source bytes, imported metadata, main/subasset identities, available library outputs, database readiness, and settled reads. A file not yet registered in asset-db may gain a new identity. This checks consistency after refresh; it does not claim that library files were regenerated when Creator already considered the asset current. It refuses a directory or root target and never broadens a failed exact refresh to the entire project. Use reimport_asset when regeneration itself must be demonstrated. See the Creator 3.8.8 verification.

check_asset_ready is a read-only full-profile status probe. Without a target it requires two stable asset-db:query-ready responses; with an exact UUID or db://assets / db://internal URL it also requires an imported, non-invalid asset record, matching UUID and URL lookups, and a stable second read. Its polling budget defaults to 1.5 seconds (waitMs up to 10 seconds), with a 3-second cap on each native query; a zero wait returns an unconfirmed one-shot observation. Busy, missing, importing, inconsistent, timed-out, and unconfirmed states never report ready: true. This is evidence about asset-db queries only; it does not prove an empty importer queue, unchanged source bytes, or completed build outputs.

query_asset_path is a read-only full-profile lookup for an exact UUID, db URL, project-relative assets/ path, or absolute path inside the project assets directory. It cross-checks asset identity and native path mappings. For an imported subasset, source.path is the parent asset's real file, while nativeMapping.path may contain Creator's @subasset alias and is marked isPhysicalSource: false. Missing, unimported, inconsistent, or absent source files return an incomplete result. This tool does not open or modify the asset. See the Creator 3.8.8 verification.

query_asset_uuid is a read-only full-profile lookup for an exact asset UUID, db URL, project-relative assets/ path, or absolute path inside the project assets directory. It verifies the asset record and Creator's URL-to-UUID mapping, including the parent link for an imported subasset. A relative path is normalized to a db URL before querying because Creator's native query-uuid does not resolve it directly. uuid is populated only when every identity check passes; missing or inconsistent targets return null. See the Creator 3.8.8 verification.

query_asset_url is a read-only full-profile lookup for the same exact targets. Its top-level url is the verified canonical URL from the imported asset record; nativeMapping.url reports Creator's native UUID-to-URL result separately. For an imported image subasset, that native value can be an @ alias instead of the canonical /texture URL. Both forms must resolve to the same UUID before a URL is selected. Missing, unimported or inconsistent targets return url: null. See the verification record.

copy_asset is a full-profile, create-only copy path for imported JSON, text, image, and audio main assets up to 64 MiB. The target must use the same supported extension and an existing parent under assets/. It copies once through asset-db:copy-asset, refuses every source-file, .meta, or asset-db target conflict, and verifies exact bytes, copied importer settings, a distinct main UUID, distinct image subasset UUIDs, an unchanged source, database readiness, and a settled second read. It does not copy folders, imported subassets, scenes, prefabs, scripts, metadata files, or unsupported formats, and never overwrites or automatically retries an uncertain native copy.

move_asset is the corresponding full-profile move/rename path for imported JSON, text, image, and audio main assets up to 64 MiB. It requires the same extension and an existing parent under assets/, refuses case-only renames and every file, .meta, or asset-db target conflict, and issues asset-db:move-asset only once. Success requires the old source and .meta paths to disappear while the target bytes, importer settings, main UUID, image subasset UUIDs, import state, and a settled second read all match. UUID-based main and subasset references remain valid; string or path-based references are not discovered or rewritten. It does not move folders, imported subassets, scenes, prefabs, scripts, metadata files, or unsupported formats, and an uncertain native result must be inspected at both exact paths before retrying. See the Creator 3.8.8 verification.

list_assets searches project assets by default and returns a compact, URL-sorted page instead of an unbounded raw asset-db result. Combine name with contains, prefix, or exact matching, an exact ccType, and an assets directory. Extensionless exact names such as IconPair can match IconPair.prefab; when an exact name has multiple matches, selection.candidates retains their UUIDs, URLs, types, and main/subasset identities so the caller must choose explicitly. Name-filtered results also report duplicate-name groups. Use includeSubassets: false to omit imported SpriteFrames/textures, or scope: "all" when internal editor assets are intentionally required.

Use find_asset_by_name when a later operation needs one exact resource identity. It reports not_found, unique, or ambiguous; selected is populated only for a unique result. A filename extension is optional, but main assets and imported subassets can share a display name, so narrow ambiguous results with ccType, directory, includeSubassets, or case-sensitive matching. Candidate output is bounded by maxCandidates; the tool never chooses the first duplicate silently.

set_component_property currently accepts one supported top-level field at a time: CCClass-declared project-script fields and selected Cocos UI fields. It converts compatible Color, vector, node/component, and asset references, but rejects dot paths, undeclared script state, incompatible values, and linked prefab instances. SpriteFrame assignment can resize UITransform; set contentSize afterward if a custom size is needed. reset_component_property_to_default restores a declared CCClass default; reset_component_property only clears a field.

The component catalog is bounded to 256 project scripts and 32 requested class-name probes. A script reported as no-component-registration may be a normal utility module, not a compilation failure. list_components shows CCClass-declared project-script fields by default; includeRuntimeFields: true reveals additional live fields without proving that they are public or persistent.

Linked prefab instance edits have tool-specific rules. Ordinary node move, duplicate, add/remove component, and property assignment reject linked prefab hierarchies; prefab instance apply/revert and Button click overrides use separate editor workflows. Check the relevant tool description and verification record before relying on a persistent prefab change.

For bind_button_click_event, the target node must have exactly one matching component and the handler must be a component-owned method, not an engine lifecycle method. customEventData is a literal string of at most 1024 characters. List existing events before binding or unbinding; duplicate bindings are reported without adding another event. batch_bind_button_click_events applies up to 50 ordered bindings with stop or continue on error and reports each result; successful entries remain changed if a later entry fails.

list_prefabs returns a sorted, paged asset catalog (50 per page by default, up to 100). Set includeMetadata for a compact .meta status and includeSceneInstances to join links from the active scene. Instance counts are partial if the bounded scene scan reports truncation.

inspect_prefab reports the asset and metadata identity, serialized root/node/component summary, and UUID-like references with an explicit truncation flag. Set includeSceneInstances to find matching roots in the active scene; a serialized prefab reference alone does not prove that a nested instance remains linked.

validate_prefab_references checks explicit serialized asset references beyond the inspection display limit, plus component entry links and declared nested prefab assets. It reports incomplete scans and lookup errors separately; it cannot prove dynamic runtime loads or that a serialized custom component class is registered.

create_prefab_from_node clones an ordinary scene hierarchy, rejects linked nested instances and editor-only nodes, and validates a single connected node tree, component ownership, PrefabInfo metadata, and explicit asset references before writing through asset-db. It then verifies the imported UUID, metadata, root name, and node/component counts; the source scene hierarchy is not modified.

create_prefab_instance and instantiate_prefab now share a native editor workflow: create once, verify the linked root/asset/instance identity, and assign and verify the parent-local position. parentUuid selects an exact parent; if parentPath is also provided, both must match. Omitted name/position use the prefab root defaults. An imported, saved scene is required; call save_current_scene explicitly afterward (needsSave: true is not persistence proof).

UI prefabs require an existing Canvas ancestor. Linked parent hierarchies, Canvas roots, enabled root Widgets and enabled parent Layouts are refused to avoid unsupported nesting or editor-controlled placement. There is no runtime fallback on uncertain native creation; failed verification only attempts cleanup of a node confirmed inside this creation scope. Inspect the hierarchy before retrying an uncertain result. See the Creator 3.8.8 instantiation verification and limits.

unlink_prefab_instance uses the native editor message on an explicitly selected, independent instance root in a saved scene. It verifies node/component identities, hierarchy, transforms and removal of link metadata without editing the source prefab; save the scene explicitly afterward. Linked ancestors and nested prefab subtrees are refused: a Creator 3.8.8 control test lost a valid cross-instance component reference after outer-instance unlink/save. verified: true is a structural check, not an audit of every component property. There is no automatic retry or relink after uncertain results. See the unlink verification and limits.

apply_prefab_instance immediately writes property changes back to the source prefab and can affect other instances; discarding the scene does not undo that asset write. It requires an explicit non-nested instance root in a saved scene, unchanged node/component structure, and no outgoing external scene references. It compares the native serialized preview against the imported source file, rechecks instance identity, and still requires an explicit scene save. The raw native result can be false even after a successful write; use the verified tool result, not that boolean. Uncertain writes are never retried or rolled back automatically. See the apply verification and limits.

revert_prefab_instance discards property overrides on an explicit non-nested instance root in a saved scene through one native restore-prefab request. It preserves the root name, position and rotation, but restores scale, other node properties and component data from the source. It verifies serialized values, live identities and unchanged source/metadata files twice; save the scene explicitly afterward. Structure changes, outgoing external scene references and unverifiable serialization are refused. An uncertain result is not automatically retried or rolled back. See the restore verification and limits.

enter_prefab_edit_mode (full profile) enters native editing for an exact non-nested project prefab from one clean, saved scene. It compares live serialization with disk even when the dirty flag is clear, verifies the actual editor mode and prefab root, and checks that source/origin files remain unchanged. It returns sourceHash for guarded saves. Re-entering the same clean prefab verifies it without reloading; dirty, multi-scene and other-prefab states are refused. It never auto-saves, discards or exits. The generic open_asset does not provide these guards. See the entry verification and limits.

save_prefab_edit_mode (full profile) saves property-only edits of the current non-nested prefab using its explicit prefabUuid and the expectedSourceHash from entry or the last verified save. It rejects source conflicts, structure changes, outgoing scene references and an unsaved origin scene. Saving immediately writes the asset and can affect same-source instances; discarding the scene will not undo that write. It checks content even when dirty is false, waits a bounded time for the target's reimport, and verifies source/live/origin state twice. Use the returned new hash for subsequent saves; a clean, unchanged repeat performs no native save. On a conflict or uncertain result, inspect and reconcile changes before retrying, rather than simply replacing the hash. It never auto-exits, retries the write, rolls back or saves the origin scene; needsSave: false refers only to the prefab. Generic save_current_scene does not acquire these prefab-specific guards. See the save verification and limits.

exit_prefab_edit_mode (full profile) closes a saved, unchanged non-nested prefab through one native close-scene request. Supply its prefabUuid; set returnSceneUuid to previousScene.uuid returned by initial entry or verified save. Dirty prefab state, unsaved serialization even with dirty=false, a mismatched origin, nesting or unverifiable references are refused before closing. It verifies the restored scene and unchanged source/origin files twice; repeating in the matching verified scene does not close that scene. Saved prefab updates may mark the restored scene dirty, so inspect needsSave and save that scene explicitly if needed. There is no automatic save, discard, retry, reopen or rollback; saving and exiting remain separate operations. See the exit verification and limits.

test_prefab_edit_mode (full profile) accepts only an explicit prefabUuid and performs read-only diagnostics: editor context, source/reference and retained-scene checks, plus live-content comparison only when that target is already open. An unopened target stays unopened (editing: null, complete: false); each check reports passed, failed or not_checked. readChecksPassed means no read check failed, while complete means all read checks passed; neither grants permission or proves that enter/save/exit works. Unsaved differences can coexist with successful reads, including dirty=false edits. observationsStable is true/false for a successful/failed recheck and null when prerequisites are unavailable, not a transaction guarantee. The outer ok only confirms report generation. All mutationTests remain not_run: there is no automatic open, save, close, snapshot, creation or discard, and no replacement source hash for guarded saves. See the diagnostic verification and limits.

delete_asset requires an exact UUID, db URL, or file path; it does not guess extensions. It safely handles project prefabs and imported JSON, text, image, or audio main assets up to 64 MiB. Before one asset-db deletion request it verifies writable imported identity, real source/metadata paths, unchanged bytes and metadata, and native asset/script plus active-scene references for the main UUID and imported subasset UUIDs. Internal links among subassets of the same image do not block deletion; external references do. Referenced assets and currently edited prefabs are rejected, with no force/cascade or filesystem fallback. Success requires UUID/URL records, both mappings, the source, and .meta to be absent. A verification failure may occur after deletion, so inspect the exact asset before retrying. Folder, subasset, scene, script, other-format, dynamic string/path loading, and references outside native queries remain unsupported. See the prefab verification and regular-asset verification.

Troubleshooting

Known limits and delivery status

• Recorded persistence, UI clicks and screenshots cover specified Creator 3.8.8 samples, not all projects, text lengths, materials, aspect ratios or devices. Touch, other Creator versions/OSes, the extension-manager installer, updates and uninstall remain unverified. First-release evidence and disabled-style follow-up state the tested scope; previous physical-click evidence is not a new-package click retest.

• UI templates are fixed-layout starter JSON. They do not implement pause/resume logic, audio preferences, rewards, navigation, modal input blocking or focus management. Custom colors/art and long text need visual review.

• Batch cleanup covers newly created nodes, not arbitrary script effects or scene-asset creation. Single-Undo recording is verified only on Creator 3.8.8; specialized prefab operations retain their documented non-nested/property-only limits. Partial or uncertain results require inspection, not automatic retries.

• The strict Scene/Game View screenshot workflow requires a visible matching Creator window. It does not capture an external browser/Simulator, prove runtime scene freshness, or provide automatic visual approval: visualValidation remains not_run. The optional official CLI backend is not configured.

• Default npm run release:package still produces a local candidate; explicit --github-prerelease packaging requires clean, tagged source and records the owned GitHub destination. Neither command publishes. Windows uses tar.exe; non-Windows requires zip/unzip and remains unverified. Each invocation preserves earlier artifacts in a new releases/<version>/candidate-<unique>/. Verify SHA256SUMS.txt before manual installation. See the release workflow and Windows local-install evidence.

Development and documentation

Run development commands from a source checkout, not the installed runtime package: npm run check for JavaScript syntax, npm test for tests, npm run docs:check for the generated catalog, npm run release:check for package/license guards, and npm run pack:dry-run for the npm file list. Tests and build scripts are intentionally not shipped in the runtime package. The development plan distinguishes implemented tools from broader requirements still in progress; verification reports record what was tested in Creator. This fork currently has no configured release update channel or package registry publication; install it locally.

Attribution and license

Thanks to the authors and contributors of Funplay MCP for Cocos for releasing the MIT-licensed foundation. The Copyright (c) 2026 Funplay notice, complete MIT terms, and disclaimer remain in LICENSE. Cocos MCP Kit is an independent fork, not an official Funplay release. See CONTRIBUTING.md for contribution rules and sources and licenses for package boundaries. Development and verification records stay in the source repository rather than the install package.