Skip to main content
Glama

Write code that runs in an R3 project

r3_code_write
Destructive

Add or replace a Code component: JavaScript that makes a project DO something. It runs on ONE event you choose (event): RENDER_BEFORE (default) every frame, for movement (held keys: this.keysPressed); KEY_DOWN / KEY_UP once per press / release; MOUSE_CLICK, SWIPE, MUSIC_BEAT, PHYSICS_COLLISION once per click, swipe, beat, collision. A script per event: r3_docs_read("HOWTO_CODE_EVENTS.md"). Kept at once in the live copy every open R3 tab runs, nothing to save (r3_editor_code is the same tool); the answer gives its seq and codeVersion.

r3_project_load names the entityRefs code uses; r3_docs_read("CODE_PATTERNS.md") is the API (a guessed one saves, then silently does nothing).

The code: a function body that RETURNS its hooks:

this.start = function() {
  // once, at start
};
this.update = function(data) {
  this['mesh_cube_1'].rotation.y += data.delta;
};
return {start: this.start, update: this.update};   // REQUIRED — nothing runs without it

Reach a component as this['<entityRef>'], infrastructure with this.getProject() / getScene() / getCamera() / getRenderer() / getWorld() / getAudioListener() / getEntityInstance(). Anything else returned is an api other scripts call: this['<entityRef>'].api.<name>(...). Code that creates things (scene objects, timers, listeners) frees them in a returned dispose: R3 calls it on re-save, Stop and delete.

No getComponentByRef, this.state, this.getSibling or R3 global: code using them is REFUSED.

EVENTS (by NAME; default RENDER_BEFORE): RENDER_BEFORE, RENDER_AFTER, KEY_DOWN, KEY_UP, MOUSE_DOWN, MOUSE_UP, MOUSE_MOVE, MOUSE_WHEEL, MOUSE_CLICK, TOUCH_START, TOUCH_MOVE, TOUCH_END, TOUCH_CANCEL, SWIPE, MUSIC_BEAT, MUSIC_BAR, PHYSICS_COLLISION. Their data (mouse: nested, -1..+1): the how-to's table.

Pass entityRef + baseVersion (the codeVersion r3_code_read gave) to REPLACE a script (and its event); name (or neither) to create one. Never merged: a write on an older version is refused with the current code.

Input Schema

NameRequiredDescriptionDefault
codeYesThe JavaScript. A function body that returns {start, update} — see the description.
nameNoLabel for a NEW Code component, e.g. "Spin". Cannot be combined with entityRef.
eventNoWhich event runs it, by NAME: RENDER_BEFORE, RENDER_AFTER, KEY_DOWN, KEY_UP, MOUSE_DOWN, MOUSE_UP, MOUSE_MOVE, MOUSE_WHEEL, MOUSE_CLICK, TOUCH_START, TOUCH_MOVE, TOUCH_END, TOUCH_CANCEL, SWIPE, MUSIC_BEAT, MUSIC_BAR, PHYSICS_COLLISION. Default RENDER_BEFORE on create; left unchanged on update.
entityRefNoThe entityRef of an EXISTING Code component to replace, as reported by r3_project_load. Cannot be combined with name.
projectIdYesThe project to write into, from r3_project_create or r3_project_load.
baseVersionNoREQUIRED with entityRef: the codeVersion r3_code_read answered for that script. A write on an older version is refused with the current code, never merged. Leave it out when creating.
componentIdNoOr the id of the EXISTING Code component to replace (instead of entityRef).

Output Schema

NameRequiredDescriptionDefault
seqNo
nameYes
eventYes
actionYes
answerYesThis answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.
fileNameYes
warningsNo
entityRefYes
projectIdYes
codeVersionYes
componentIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / event / description
      Previous value: -"Which event runs it, by NAME: RENDER_BEFORE, RENDER_AFTER, KEY_DOWN, KEY_UP, MOUSE_DOWN, MOUSE_UP, MOUSE_MOVE, MOUSE_WHEEL, MOUSE_CLICK, TOUCH_START, TOUCH_MOVE, TOUCH_END, TOUCH_CANCEL, SWIPE. Default RENDER_BEFORE on create; left unchanged on update."New value: +"Which event runs it, by NAME: RENDER_BEFORE, RENDER_AFTER, KEY_DOWN, KEY_UP, MOUSE_DOWN, MOUSE_UP, MOUSE_MOVE, MOUSE_WHEEL, MOUSE_CLICK, TOUCH_START, TOUCH_MOVE, TOUCH_END, TOUCH_CANCEL, SWIPE, MUSIC_BEAT, MUSIC_BAR, PHYSICS_COLLISION. Default RENDER_BEFORE on create; left unchanged on update."
  2. Changed1 schema field changed
    • changedInput schema / properties / event / description
      Previous value: -"Which event runs it, by NAME: RENDER_BEFORE, RENDER_AFTER, KEY_DOWN, KEY_UP, MOUSE_DOWN, MOUSE_UP, MOUSE_MOVE, MOUSE_WHEEL, MOUSE_CLICK, TOUCH_START, TOUCH_MOVE, TOUCH_END, TOUCH_CANCEL. Default RENDER_BEFORE on create; left unchanged on update."New value: +"Which event runs it, by NAME: RENDER_BEFORE, RENDER_AFTER, KEY_DOWN, KEY_UP, MOUSE_DOWN, MOUSE_UP, MOUSE_MOVE, MOUSE_WHEEL, MOUSE_CLICK, TOUCH_START, TOUCH_MOVE, TOUCH_END, TOUCH_CANCEL, SWIPE. Default RENDER_BEFORE on create; left unchanged on update."
  3. Changed2 schema fields changed
    • addedOutput schema / properties / answer
      Added value: +{
      +  "description": "This answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.",
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "projectId",
      -  "action",
      -  "componentId",
      -  "entityRef",
      -  "name",
      -  "fileName",
      -  "event",
      -  "codeVersion"
      -]New value: +[
      +  "projectId",
      +  "action",
      +  "componentId",
      +  "entityRef",
      +  "name",
      +  "fileName",
      +  "event",
      +  "codeVersion",
      +  "answer"
      +]
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructive=true and readOnly=false, and the description goes well beyond them: it discloses that code lives in the live copy every open tab runs with nothing to save, that dispose is called on re-save/Stop/delete, that writes on an older version are refused with the current code and never merged, and that disallowed APIs (getComponentByRef, this.state, this.getSibling, R3 global) cause the code to be REFUSED. These are exactly the side effects an agent needs to avoid silent corruption.

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?

Purpose, constraints and the code contract are front-loaded, and the worked JS example is high-value. It loses a point for duplication: the full event list appears in both the description and the `event` schema property, and the infra-method list is dense prose that could be compressed.

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?

Output schema exists, and the description still adds the key return facts (seq and codeVersion). For a 7-parameter, destructive, event-driven write tool it covers execution model, versioning, cleanup obligations, and refusal conditions — nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the shape of `code` (a function body that must `return {start, update}` or nothing runs), the create-vs-replace semantics of name/entityRef, and the versioning contract for baseVersion. It does not add much beyond the schema for event/componentId, which keeps it from a 5.

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?

Opens with a specific verb+resource ("Add or replace a Code component: JavaScript that makes a project DO something") and immediately distinguishes itself from siblings by noting that r3_editor_code is the same tool. An agent can tell what it produces and which event-driven execution model applies without opening any schema.

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?

Explicit routing: pass entityRef + baseVersion to REPLACE, name (or neither) to CREATE, and read baseVersion from r3_code_read first. It also points to r3_docs_read("HOWTO_CODE_EVENTS.md") and CODE_PATTERNS.md for the event table and API, and names the alternative alias r3_editor_code. When-to-use and when-not (mutually exclusive name/entityRef) are both stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources