Skip to main content
Glama

cocos_batch_scene_ops

Execute multiple scene operations in one file cycle to optimize Cocos Creator scene building. Batch add nodes, components, and properties for faster performance when making sequential modifications.

Instructions

PREFERRED for ≥3 sequential mutations on the same scene.

Execute multiple scene operations in a single file read/write cycle. ~80× faster than calling individual cocos_add_* / cocos_set_* tools when building more than a handful of nodes/components on the same scene; the file is parsed once, mutated in memory, and serialized once at the end.

Rule of thumb: if you would otherwise call cocos_add_*, cocos_attach_*, cocos_set_*, or cocos_link_* three or more times in a row on the same scene, use this tool instead. Pass all the ops in one call; use "$N" back-references for ids that earlier ops produced.

Each operation is a dict with an op key and operation-specific params. Returns {object_count, ops_executed, results, named_results}:

  • results is the positional list (preserved for callers that use "$N" index back-refs).

  • named_results is a dict keyed by the name field set on any op — ops without name don't contribute. Let's you use "$bird" instead of "$0" which stays stable across edits.

Supported ops: Structural: - {"op": "add_node", "parent_id": N, "name": "...", "lpos": [x, y, z]?, "lscale": [sx, sy, sz]?, "pos_x": ..., "pos_y": ..., "pos_z": ..., "sx": ..., "sy": ..., "sz": ..., "layer": L?, "active": true/false?, "sibling_index": -1?} (lpos / lscale tuple forms match direct sb.add_node; pos_x/y/z and sx/sy/sz scalars are the legacy form. Tuple wins when both supplied. Prior releases silently dropped lscale — every batch-created node was left at (1,1,1) regardless of op input.) - {"op": "attach_script", "node_id": N, "script_uuid_compressed": "...", "props": {...}} (36-char standard UUIDs auto-compressed, matching cocos_add_script.) - {"op": "link_property", "component_id": N, "prop_name": "...", "target_id": M} - {"op": "set_property", "object_id": N, "prop_name": "...", "value": ...} - {"op": "set_uuid_property", "object_id": N, "prop_name": "...", "uuid": "..."} - {"op": "set_position", "node_id": N, "lpos": [x, y, z]? OR "x": ..., "y": ..., "z": ...} - {"op": "set_scale", "node_id": N, "lscale": [sx, sy, sz]? OR "sx": ..., "sy": ..., "sz": ...} - {"op": "set_rotation", "node_id": N, "angle_z": deg} - {"op": "set_layer", "node_id": N, "layer": L} - {"op": "set_active", "node_id": N, "active": true/false}

Components: - {"op": "add_uitransform", "node_id": N, "width": W, "height": H, "anchor_x": ..., "anchor_y": ...} - {"op": "add_widget", "node_id": N, "align_flags": 45, "target_id": M?} - {"op": "add_sprite", "node_id": N, "sprite_frame_uuid": "...", "size_mode": 0} - {"op": "add_label", "node_id": N, "text": "...", "font_size": 40, "color_r"...} - {"op": "add_graphics", "node_id": N} - {"op": "add_camera", "node_id": N, "ortho_height": ..., "clear_color_r"...} - {"op": "add_mask", "node_id": N, "mask_type": 0, "inverted": false, "segments": 64} - {"op": "add_richtext", "node_id": N, "text": "Hi", "font_size": 40, ...} - {"op": "add_button", "node_id": N, "transition": 2, "zoom_scale": 1.1} - {"op": "add_layout", "node_id": N, "layout_type": 1, "spacing_x": ..., ...} - {"op": "add_progress_bar", "node_id": N, "mode": 0, "total_length": 100, "progress": 1.0, "bar_sprite_id": M?} - {"op": "add_audio_source", "node_id": N, "clip_uuid": "...", "volume": 1.0, "loop": false, "play_on_awake": false} - {"op": "add_animation", "node_id": N, "default_clip_uuid": "...", "clip_uuids": [...], "play_on_load": true} - {"op": "add_rigidbody2d", "node_id": N, "body_type": 2, ...} - {"op": "add_box_collider2d", "node_id": N, "width": W, ...} - {"op": "add_circle_collider2d", "node_id": N, "radius": R, ...} - {"op": "add_polygon_collider2d", "node_id": N, "points": [[x,y], ...], ...} - {"op": "add_component", "node_id": N, "type_name": "cc.X", "props": {...}}

Physics 2D joints (Cocos 3.8 has eight — all present): - {"op": "add_distance_joint2d", "node_id": N, "connected_body_id": M?, "distance": 100, ...} - {"op": "add_hinge_joint2d", "node_id": N, "enable_motor": true, "motor_speed": 50, ...} - {"op": "add_spring_joint2d", "node_id": N, "frequency": 5, "damping_ratio": 0.7, ...} - {"op": "add_mouse_joint2d", "node_id": N, "max_force": 1000, "target_x": ..., "target_y": ...} - {"op": "add_slider_joint2d", "node_id": N, "angle": 0, "enable_motor": true, ...} - {"op": "add_wheel_joint2d", "node_id": N, "angle": 90, ...} - {"op": "add_fixed_joint_2d", "node_id": N, "angle": 0, ...} (cc.FixedJoint2D — previously mis-named "weld"; 3.8 renames it.) - {"op": "add_relative_joint2d", "node_id": N, "linear_offset_x": 10, ...}

Back-reference forms inside any op value:

  • "$N" — positional id of op index N (0-based).

  • "$name" — named id, resolves against prior ops' name field.

Example mixing both forms::

[{"op": "add_node", "parent_id": 2, "name": "bird"}, # $0 or $bird {"op": "add_uitransform", "node_id": "$bird", "width": 50, "height": 50}, {"op": "add_rigidbody2d", "node_id": "$bird", "body_type": 2}, {"op": "add_circle_collider2d", "node_id": "$bird", "radius": 25}]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scene_pathYes
operationsYes
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it's a mutation tool (executes operations on scenes), explains the performance optimization (single file read/write cycle), details the return structure ({object_count, ops_executed, results, named_results}), and mentions implementation details like back-references. However, it doesn't cover potential error conditions, permissions needed, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately front-loaded with purpose and usage guidelines, but becomes very lengthy due to exhaustive listing of all supported operations. While this detail is valuable, it makes the description quite long. Some of the operation details (like specific parameter names for each component type) might be better placed in a separate reference rather than in the core description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (batch mutation operations with many possible operation types), no annotations, no output schema, and 0% schema coverage, the description provides exceptional completeness. It covers purpose, usage guidelines, performance characteristics, parameter semantics, return structure, back-reference system, and exhaustive documentation of all supported operations. The only minor gap is lack of error handling information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for the 2 parameters, the description fully compensates by providing extensive semantic information. It explains that 'operations' is an array of dicts with 'op' keys and operation-specific params, documents all supported operation types with their parameter structures, and provides detailed examples of back-reference syntax ('$N', '$name'). The 'scene_path' parameter's purpose is implied through context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Execute multiple scene operations in a single file read/write cycle.' It specifies the verb ('execute') and resource ('scene operations'), and distinguishes it from siblings by explicitly naming alternative tools (cocos_add_*, cocos_set_*, etc.) and providing a rule of thumb for when to use this batch tool instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool vs alternatives: 'PREFERRED for ≥3 sequential mutations on the same scene' and 'Rule of thumb: if you would otherwise call... three or more times in a row on the same scene, use this tool instead.' It also mentions performance benefits (~80× faster) and lists specific sibling tools to replace.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

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

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