R3

Delete one of the account's images, models, audio files, Blender models (kind blender: a whole uploaded .blend with every version; its meshes in use stay) or texture sets (kind textureSet: the set and its maps, r3_texture_create made it) — the same reference-guarded delete as the R3 app. With asset:delete:created, only an asset YOU created (this agent key or app connection; today: images made with r3_image_create); with asset:delete:owned, any of the user's assets, and only when the user asked for it: pass owned: true for one you did not create (an app connection is then asked for that right). Two calls, every time: without `confirm` nothing is deleted, and the answer says what would go and which of the user's projects use it; the same call with `confirm: true`, when that is what the user wants, deletes it. An asset another user's project uses can never be deleted. A model takes the images only it used with it, an HDR / EXR image its preview image. There is no trash and no undo. Ids come from r3_image_list, r3_audio_list and r3_blender_list.

The account's images, models and audio files that nothing uses — no project, no entity template, no other user's project — with each one's size and date, biggest first, and the total. The same report as the R3 app's Settings → Storage, by the same rules the deletes use. A model lists the images only it uses, an HDR / EXR image its preview image: they go with it. A texture set nothing uses is one item (kind textureSet) with its maps under it; a map of a set is never listed on its own. Blender (.blend) files are not part of it: they are the user's to keep or delete, listed by r3_blender_list. Pass `kind` to see one kind, `limit` for more rows (the totals always cover everything). It only reads; r3_asset_delete deletes an item by its kind and id (a plan, then a confirm), for what the user asked to remove. The scan can take several seconds.

List the audio files this R3 account owns, with the URL to use for each one. That URL is exactly what R3ComponentAudio.url takes, so this is how you find a sound the account already has — a footstep, a drum hit, a music bed — and then point an Audio component at it with r3_component_set. Search by name rather than paging: search: "kick" is matched against every audio file on the account by the server, not against the page you happen to be holding. You cannot upload an audio file from here — a tool argument is JSON, this server cannot read your disk, and audio is megabytes. A person uploads those in the R3 app. There is no tool that generates audio either: R3 synthesises sound with its music components (Transport, Beat, Pattern, DrumGrid), which stay editable and in tempo: they are how a project gets sound without a recorded file.

Does this project hold the same Blender model more than once (two whole imports side by side)? Answers "N copies of <model>: … Keep one?" with each copy (its Entity, entityRef, part count) and its delete plan. It changes nothing: which copy stays is the user's choice, and the other is removed with r3_editor_delete({projectId, componentIds, confirm: {mode: "bundle", planToken}}) once they have chosen.

Get a .blend of one of the user's OWN Blender models (from r3_blender_list) to open in Blender: the current version, or the version fileId names. Answers a one-time download ticket (5 minutes) and the download endpoint (URL, method, Authorization header); the response body is the file. When the current version is the copy R3 made by applying modifiers, the answer says so and names the original upload, with its modifiers intact, to download instead. Another user's model cannot be downloaded.

While you build a model in Blender for the user, push an APPLIED copy of your working .blend after each step (body done, wheels done, materials done): the user's Blender page shows it as a 3D preview they can orbit. A draft is not a saved version: one draft per user, the newest wins, kept 24 hours. Answers a one-time ticket (5 minutes) and the draft endpoint (URL, method, Authorization header; the body is the file's raw bytes); sending it needs file access where the .blend is. The draft is a copy with its modifiers applied and its textures packed; r3_blender_upload saves the real file once the user is happy. Up to 20 MB. Needs the blender:upload right.

Add a Blender model the account has uploaded (its current version) to an existing R3 project — the whole model, or only the meshes you name. Every Blender mesh object becomes an R3 Mesh keeping its own position, rotation, scale and origin, with its geometry, materials and textures wired up; objects sharing one mesh share one geometry; a Blender Empty becomes an R3 Empty, the objects under it keeping their place relative to it. A whole model is one Entity whose parts hang from a `<model>_root` Empty: move that Empty to move the model. Reports each object's entityRef so you can reach it with r3_component_set or from code. Use r3_blender_list to choose a model. Pass reparse: true to re-read the .blend itself when the import warns that its meshes were placed at the origin; other projects keep the meshes they use (r3_blender_update moves them, if the user wants). Pass camera to frame the model in a NEW project (its first model: refused on a project that already holds a mesh).

List the Blender models this R3 account has uploaded — one per .blend file name, the current version of each — with what it will produce: how many Blender objects land in the scene, how many meshes and materials, its screenshot, and any PENDING update (a re-upload that changes meshes the user's projects use, waiting for r3_blender_update). An upload with unapplied modifiers is applied in Blender by R3 itself; a model says what was applied, per object. community: true lists everyone's public models instead. Add one (or some of its meshes) to a project with r3_blender_import. A .blend gets here two ways: a person uploads it in the R3 app (Models -> Upload .blend), or you save one you built in Blender with r3_blender_upload (a one-time ticket and an upload endpoint: never a tool argument).

A re-uploaded Blender model is always its latest version; the user's projects keep the meshes they have until asked. This tool asks and answers that one question: choice update_projects without reportId shows which projects and entity templates use an older version (or an earlier import of the same file) and what changed; with the reportId and the projectIds / entityTemplateIds the user chose, it moves just those to the current version. Which ones move is the user's choice; "not now" means no call. Parts are matched by Blender OBJECT name: each takes its new mesh, materials and placement, objects new in the model are added under the copy's root Empty, parts the model no longer has are kept (removeGone: true removes them). Published releases never change. Needs the blender:update right.

Save a .blend you made or changed (in Blender, through a Blender MCP) as the newest version of one of the user's Blender models: the model is named by the file name, so "monster-truck.blend" adds a version to the user's monster-truck model, or makes the model. A tool argument cannot carry the file, so this answers a one-time upload ticket (5 minutes) and the upload endpoint: its URL, method, Authorization header and that the body is the file's raw bytes. Sending it needs file access where the .blend is (the R3 sandbox, or the user's own machine); without it, the user uploads on the Blender page. The endpoint's answer names the model, the version number and its sha256; R3 applies unapplied modifiers itself, and when the user's projects use an older version it asks one question (answer it with r3_blender_update). Then r3_blender_import puts the model in a project. Textures travel only when packed (bpy.ops.file.pack_all()). Up to 100 MB. Needs the blender:upload right.

Send R3 a bug report about R3 ITSELF (the engine, the editor, these tools), in the user's name and naming you (your agent key or app connection). It becomes one of the user's support issues, which only the user and R3's team see. Use it when R3 does something its documentation says it should not, after checking the docs (r3_docs_read) — not for problems in the user's own project, and not for feature wishes (those are r3_roadmap_suggest). r3_bug_reports_mine lists what the user already reported, so a fault is not filed twice. A useful report says what was done (the tool calls), what was expected and what happened, with what was MEASURED in `measurements` — the values read back with r3_component_read or r3_editor_inspect, the exact error text. `projectId` (when it happens in a project) lets R3 open it. The answer carries the report's link for the user. Rate-limited per agent key or app connection (a few an hour). Needs the support:write right.

The user's own support issues — bug reports and questions they or their agents (agent keys and app connections) sent R3 — newest first, with status, date, the project and whether an agent filed it (and which), each with its link. It shows whether a fault is already reported, before r3_bug_report would file it twice. Needs the support:write right.

Read back what a Code component actually contains — its full JavaScript source and the event it runs on. r3_code_write reports what it wrote; this reports what is there. Use it before replacing a script, so an edit builds on the real source instead of overwriting it blind, and after a write whose reply you did not see, to confirm what landed. Call it with NO entityRefs to get every Code component in the project — that is how you find a script again when you never received the entityRef for it. Each script comes back with its codeVersion: pass it as r3_code_write's baseVersion. The event comes back as a NAME (RENDER_BEFORE, KEY_DOWN, …), which is the same form r3_code_write takes, so you can hand it straight back. r3_component_read reports the same field as a raw number and omits any source over 2000 characters; this is the tool for reading code. A body too large to return is left out WHOLE and reported with its size — never truncated, because a partial script written back would delete the rest of it. An entityRef that does not exist is named and the others are still read.

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: ```js 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.

Add one component of ANY registered type — a collider, a rigid body, a joint, a light, a material, a geometry … — to a saved R3 project, with its values and references set before it is created. Kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save (r3_editor_add_component is the same tool). Use r3_factory_run for a ready-made object (a cube, a physics sphere …). `type` is the short type name, e.g. "ColliderCuboid" (an unknown type is refused with the list). `values` take r3_component_set's shapes: a plain value {"friction": 0.2}; a value component as the keys to set {"halfExtents": {"x": 2, "y": 0.5, "z": 1}}; a reference as the target's entityRef or id {"rigidBody": "rigidbody_dynamic_1"} — a component of THIS project, of a type the slot accepts; "name" names it. A type that cannot exist without an option (an Audio / AudioPositional / Texture's "url") takes it in values too, and is refused without it. A Code component's code is r3_code_write's. A VehicleWheel added with a mesh is measured from it (Configure from Mesh: radius, connectionPoint, axle), and a ColliderCuboid / Sphere / Cylinder / Capsule with a mesh (its own or its rigid body's) is fitted to it (Fit to Mesh: size, and position on the mesh's centre), only the values you did not pass; the answer says what (PHYSICS_USAGE.md → Vehicles).

The size and place of meshes and imported models, in R3 units (metres): the world-space box around each (min, max, size, centre), the mesh's scale, rotation and parents applied. Name a Mesh, or the root Empty of a Blender model (r3_blender_import makes one, named "<model>_root"), and the box covers it and every mesh under it, with each part listed. Use it before scaling or placing anything relative to its size: to stand a model on the ground, move it so its min.y is the ground height (r3_terrain_height on a terrain); to make it 2 m long, scale by 2 / size. Several in one call (up to 20). Works with no R3 tab open, from the project as it is kept; read-only.

Read back what components actually hold — a material's colour and roughness, a mesh's position, which material it uses. r3_project_load gives you the names; this gives you the values behind them. Pass SEVERAL entityRefs in one call — telling six similarly-named materials apart is the case this exists for, and it is one round trip rather than six. What comes back is exactly what r3_component_set takes, so read → change → write needs no translation: value components are expanded inline ({"position": {"x": 0, "y": 2, "z": 0}}), references are the target's entityRef as a string (or null when empty), and lists of references are arrays of entityRefs. Use it before any relative change ("20% brighter", "move it up by one"), and after a write to confirm what landed. Bulk data — mesh vertex arrays and anything else megabyte-sized — is NOT returned. Every property left out is listed with the reason, so an omission is never silent. An entityRef that does not exist is reported by name and the rest are still read. Value components (a Vector3, a Color) are not read on their own: ask for the component that owns them.

Set one or more properties on a component that already exists in a project — a material's roughness, a mesh's position, which material a mesh uses. Kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save (r3_editor_set is the same tool). The answer says what was kept and its seq. Components are addressed by entityRef; r3_project_load returns those names. Properties come in four shapes and the value you pass differs: • plain value — {"roughness": 0.25}, {"visible": false} • value component (position / rotation / scale / color / size …) — pass an OBJECT of just the keys to change: {"position": {"y": 2}} leaves x and z alone. Vector3 has x/y/z, Color has r/g/b/a (0..1), Scalar has value. An EMPTY slot (a rigid body's centerOfMass is empty until set) is made from the fields given: {"centerOfMass": {"z": -0.3, "mass": 8}}; the fields not named keep their defaults. • reference to another component — pass that component's entityRef as a string: {"material": "material_cube_1"}, or null to clear it. • list of references (a mesh's materials) — pass an ARRAY of entityRefs: {"materials": ["mat_a", "mat_b"]}. The array REPLACES the whole list, in the order given — it does NOT append, so name every component you want in it; [] empties the list. The result reports the list before and after, so check that against what you intended. Several properties in one call is one round trip, and is applied all-or-nothing. An unknown property name is REFUSED and the valid names are listed, rather than written — so a typo costs a message, not a corrupted project. Renaming (name / entityRef) is refused too: it has to rewrite the code that addresses the component, which only the R3 editor does. Giving a VehicleWheel its mesh or vehicle measures the wheel from that mesh, as the R3 editor does (Configure from Mesh: radius, connectionPoint, axle); a value named in the same call is kept. Giving a ColliderCuboid / Sphere / Cylinder / Capsule its mesh fits it to that mesh (Fit to Mesh: size, and position on the mesh's centre); giving it only a rigidBody fits the values still at their defaults. The answer says what was measured or fitted and what was kept (PHYSICS_USAGE.md → Vehicles). Moving or scaling a Mesh keeps what the editor derives from it: a SCALE change re-fits every Cuboid / Sphere / Cylinder / Capsule collider fitted to that mesh (size and offset); moving or scaling a wheel's mesh re-measures the wheel; scaling a vehicle's chassis mesh also carries the wheels' suspensionRestLength and maxSuspensionTravel by the new / old scale on the up axis. The answer lists each. A Mesh's rotation and quaternion are one orientation held twice: set ONE of them and the other follows (both in one call must agree, or the call is refused). Changing the parent of a Mesh / Empty / Points / Line ({"parent": "root_empty"}, or null for the scene) keeps it where it is in the world, as the R3 editor's re-parent does: its position, rotation (and quaternion) and scale are rewritten to the values local to the new parent, and the answer lists them. A position, rotation / quaternion or scale given in the SAME call is the new LOCAL value under the new parent, taken as given (as if the parent changed first and that value were set after); the fields not given keep the world place. Under a NON-UNIFORMLY scaled parent a rotated part cannot keep its shape (it would shear): that re-parent is refused unless you give rotation and scale yourself.

Every R3 document this server can give you, IN READING ORDER, with what each one covers and how big it is. R3's documentation begins here: no model has R3 in its pretraining, and code written from tool descriptions alone saves cleanly and then silently does nothing. r3_docs_read returns one.

Return one R3 document in full, or one API symbol. Paths come from r3_docs_list: r3_docs_read("CODE_PATTERNS.md") how a Code component is written (reading order 1) r3_docs_read("PHYSICS_USAGE.md") colliders, rigid bodies, joints r3_docs_read("HOWTO_PHYSICS.md") one task step by step (how-tos: r3_docs_list) r3_docs_read("api") index of every component, system and event r3_docs_read("api/component/Mesh") one component r3_docs_read("api/system/PhysicsRapier") one system r3_docs_read("api/event/KEY_DOWN") one event, and the data it delivers The API reference is only ever read one symbol at a time — the whole file is too large to serve.

The same tool as r3_component_add (this is its older name): add one component of ANY registered type — a collider, a rigid body, a joint, a light, a material, a geometry … — with its values and references set before it is created, kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save. Use r3_editor_create for a ready-made object. `type` is the short type name, e.g. "ColliderCuboid" (an unknown type is refused with the list). `values` take r3_component_set's shapes: a plain value {"friction": 0.2}; a value component as the keys to set {"halfExtents": {"x": 2, "y": 0.5, "z": 1}}; a reference as the target's entityRef or id {"rigidBody": "rigidbody_dynamic_1"} — a component of THIS project, of a type the slot accepts. Example — swap a rigid body's collider: add a ColliderCuboid with {"rigidBody": …, "halfExtents": …}, then r3_editor_delete the old collider (mode "one").

Capture the canvas of a project open in the user's R3 editor — the scene as it looks NOW, running physics included — and LOOK at it: the answer is an image. Call it after a visual change (r3_editor_set, r3_editor_create, r3_editor_code …) to check what you built, and after r3_editor_run to see it move. By default (`camera: "editor"`) it is what the user sees: the editor's view camera, edit aids included. `camera: "project"` takes it through the project's own camera instead, with no edit aids, as a visitor sees it: use that to check a camera or a camera script. At most 1280 px each way (`width`, default 1024); a JPEG. Needs project:read.

The same tool as r3_code_write (this is its older name): replace a Code component's code, kept at once in the project's live copy: every R3 tab with the project open runs the new code now, no editor needed and nothing to save. Name it with componentId or entityRef and pass baseVersion, the codeVersion r3_code_read answered: code is never merged, so on an older version it is refused with the current code and version (apply your change to that and call again). The code is a FUNCTION BODY (a top-level `return {start, update};`); read r3_docs_read("CODE_PATTERNS.md") for the R3 APIs. A syntax error or an R3 API that does not exist is refused before anything is kept.

The same tool as r3_factory_run (this is its older name): add an object — a cube, sphere, light, physics body … — kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save. r3_factory_list lists the factories and their params.

Delete components from the project the user has OPEN in their R3 editor, exactly as the editor's delete dialog asks it — in TWO calls. First call WITHOUT `confirm`: it returns the plan and changes nothing — the selected components, what only they use (their geometry, material, colliders …), an Entity's members, the modes on offer and a planToken. Then call again with the same componentIds and confirm: {"mode": …, "planToken": …}: "one" deletes only the selection, "with_dependents" also what only it uses, "bundle" (one Entity) the entity with its members. The mode is the user's choice, unless they already said. If the project changes in between, the confirm is refused: plan again. Only when the user asked for it. The confirmed delete is kept at once in the project's live copy (every open R3 tab shows it; no editor is needed); R3 keeps what was deleted in the project's trash. The children of a deleted Empty or Mesh keep their place in the world, as the editor's delete does (their numbers become the scene's; the answer lists them). A project itself is never deleted here. Needs the editor:dispose capability.

Read what components hold RIGHT NOW in an R3 tab that has the project open: runtime values included — a moving body's position while the project runs. Use it to debug live behaviour. It needs a tab with the project open (r3_editor_open opens one). r3_component_read reads the kept values without a tab. Select with any of: `ids` (component ids from r3_project_load), `type` ("Mesh", "RigidBodyDynamic", …) and `entityRef`; they combine. `fields` keeps only the properties you name (e.g. ["position", "rotation"]). At most 50 components per call; a larger answer is refused with how to narrow it. Values are in r3_component_read's shape (value components inline, references as entityRefs), so they can be handed to r3_component_set. The project must be open in the editor (r3_editor_open opens it). Read-only: nothing is changed.

Open a project in the R3 editor the user has open in their browser (their most recently used R3 tab) and focus it, so they see it. A project already open there is just focused (never reloaded). It is how the user gets to see the project you are working on, and how a tab gets the project r3_editor_inspect reads. The same access rules as opening it by hand: the user's own projects, their teams', and public ones. The editor holds up to 4 projects; at that limit it refuses. Nothing is saved or changed. When no editor is open, the answer says where the user can open one.

Press the Run buttons of the user's open R3 editor: start physics, code, audio and music (all of them, or the ones named in `systems`), exactly as the user's own click does — a paused simulation resumes. Use it to TEST what you built: run it, then look with r3_editor_capture and read live values with r3_editor_inspect. Changes nothing saved. The systems serve every project open in that editor tab. The scene only moves while that tab is in front: a browser pauses a background tab, and the answer then says the scene is NOT advancing. Needs the editor:run right.

Save a VERSION of a project, like the editor's Save version (Ctrl+S): a named, frozen copy of the project as it is now (a release that does NOT go live). Nothing needs saving to be kept — every change is kept as it is made — so a version is for when the user asks for one (or a milestone they are told about). `name` is the version's name ("before the physics rework"). Nothing changed since the newest version: that version stands, no new one is made. r3_release_list lists the versions; r3_publish_live makes the project live. No editor is needed.

The same tool as r3_component_set (this is its older name): change properties of a component, kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save. Name the component with componentId or entityRef. `values` take r3_component_set's shapes: a plain value {"roughness": 0.25}; a value component as an object of the keys to change {"position": {"y": 2}} (an EMPTY slot, e.g. a rigid body's centerOfMass, is made from the fields given: {"centerOfMass": {"z": -0.3, "mass": 8}}); a reference as the target's entityRef {"material": "material_cube_1"} (null clears it); a list of references as an array of entityRefs (it REPLACES the list). All-or-nothing: an unknown name is refused with the valid ones. A Code component's code is r3_editor_code's.

Use what the project's camera shows NOW, in the user's open R3 editor, as the project's picture: the image on its Projects card and on its preview link. The editor waits until the scene's textures have loaded and takes it without edit aids (no grid, gizmos or outlines), as a visitor sees it; the answer is the picture it set. It is for once the project looks right (r3_editor_capture shows it beforehand), or when the user asks for a new picture. A live page keeps the picture of its live release until the next publish. Needs a tab with the project open and project:write.

Press the Stop buttons of the user's open R3 editor: stop physics, code, audio and music (all of them, or the ones named in `systems`), exactly as the user's own click does. Stopping physics puts every body back where it was placed. Changes nothing saved. Needs the editor:run right.

Undo the last change YOU (this agent key or app connection) made to a project: everything one of your tool calls changed is undone together, and the user sees it at once in any R3 tab that has the project open. Use it when your own change was wrong or the user asks you to take it back. It never undoes the user's changes or another agent's: only yours. `count` undoes your last few changes, newest first. If someone else changed the same thing after you, that change of yours is SKIPPED: nothing is changed, the answer says who changed what, and that change of yours is dropped from your history (the next call takes the one before it). Their change stands: setting your old value back over theirs is the user's decision, not this tool's. `redo: true` puts back what you undid (until you make a new change). Needs project:write (and code:write to undo a change to code).

List the R3 factories available to r3_factory_run, with each one's options, types and defaults. A factory builds a complete, correctly-wired object — a cube is a mesh plus geometry plus material plus colour, already connected. Call this before r3_factory_run if you are unsure of a factory name or its options.

Add an object to an existing R3 project — a cube, sphere, terrain, lighting, a physics body, and so on. Each factory builds a complete, correctly-wired object (mesh + geometry + material + colour, already connected), so you never assemble components by hand. Kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save (r3_editor_create is the same tool). The answer says what was kept and its seq. Use r3_factory_list to see the factories and their options.

Set the instructions that ship WITH a project — controls, what to press, what it does. R3 renders them in a modal behind a floating "?" button and the H key, in the editor and in the live portal alike, so whoever opens your preview link can read them. This is the built-in surface for that, so a Code component needs no overlay of its own. The body is markdown — headings, bullets, `code`, links: the controls as a player needs them, e.g. "## Controls\n\n- `Space` — jump". A project has ONE help. Call this again and it replaces the text rather than adding a second. REPLACING needs baseVersion, the codeVersion r3_component_read gave for the Help: text is never merged, so a write on an older version is refused with the current text. The first Help needs none. The optional title is the modal's heading ("Controls", "How to play"); leave it out to keep "Help". Kept at once in the project's live copy: every R3 tab with the project open shows it now. The result gives you the component's entityRef — pass that to r3_component_set to change the trigger key, move or hide the button, or have the help open automatically on load.

Store a small image YOU generated in this R3 account's image library and get back the URL for it — the value R3ComponentTexture.url takes. This is how you make a checkerboard, a gradient, a test grid or a noise tile and then actually put it on something with r3_component_set. Pass the image as a base64 data URL (data:image/png;base64,…), up to 1MB decoded. PNG, JPEG, GIF and WebP are stored; PNG is the right choice for a generated pattern. This is NOT a way to upload an image file you already have. You would have to emit every byte of it as base64, which for a real texture is far more output than a reply can hold — and this server cannot read your disk. A person uploads real artwork in the R3 app, and r3_image_list shows what they have already put there: the account's own artwork, where there is some, beats a generated substitute. Each call stores a NEW image, so calling it twice with the same bytes leaves two rows. The name you give is what appears in the owner's Images browser, prefixed with "agent-" so they can tell where it came from; a descriptive one says what it is. For a material's texture set (colour + normal + roughness that tile), use r3_texture_create instead: R3 renders it, so no bytes go through you.

List the images this R3 account owns, with the URL to use for each one. That URL is exactly what R3ComponentTexture.url takes, so this is how you find the account's own artwork — a wood grain, a logo, a skybox — and then point a texture at it with r3_component_set. Search by name rather than paging: search: "wood" is matched against every image on the account by the server, not against the page you happen to be holding. Each row says whether it is a "texture" (an ordinary image for a material slot) or an "environment" map (.hdr / .exr). Those two are not interchangeable: an environment map belongs on Scene.environment, Scene.backgroundTexture or MaterialStandard.envMap, and renders as garbage in an ordinary map slot. You cannot upload an existing image file from here — a tool argument is JSON, this server cannot read your disk, and a real texture is megabytes. A person uploads those in the R3 app. r3_image_create is the one exception: it takes a small image you generated yourself, such as a checkerboard or a gradient.

Create a shareable preview link for a saved R3 project, so a person can open it in a browser and see it running. The link is valid for 7 days and does NOT make the project public; making a new one is free. It is how the user sees what you built. Takes the projectId returned by r3_project_create. When an R3 tab has the project open, the project's picture (its card and the link's image) is refreshed from that tab; when none has, the picture refreshes the next time the project is opened in R3.

Remove the preview link of an R3 project: every preview link to it stops working at once (teammates' too). Only when the user asked for it, or when the preview link is what blocks an r3_project_delete the user asked for: a preview link is temporary, so it may then be removed without a separate request, and the user is told it was removed. A live project stays live; a project that was only previewed is no longer published. Deletes nothing: r3_preview_create makes a new link. A project with no open preview link is refused and left as it is. Needs the publish:preview right.

What OTHER people changed in a project — the user in any R3 tab, their other agents — oldest first, grouped per author and per thing: properties set, code and help updated (with versions), components added, deleted or restored, the project renamed. Your own changes are never listed. Every answer about a project already ends with a short "Since your last call" line; this is its full list. Without `since`: from where you last looked (and moves that mark to now, unless advance: false). The mark belongs to your agent key or app connection, not to the conversation: two conversations on one share it. With `since` (a seq, e.g. the one the "+N more" line names, or 0 for everything still in the log): from there, without moving anything. Needs project:read.

Create a new R3 project and save it to the user's account. Produces a complete, openable project — scene, world, camera, renderer, lighting, audio listener and music transport — ready for components to be added. Pass `template` for a phone project (mobile-portrait / mobile-landscape) that fills the screen when published. Returns the project id, which every other project tool takes. r3_whoami confirms which account it is created in.

Permanently delete an R3 project. With the project:delete:created right (on by default), only a project YOU created (this agent key or app connection) — use it to clean up your own abandoned attempts; the user's own projects and other agents' are refused. With project:delete:owned, any project the user owns, and only when the user asked for it: pass owned: true for a project you did not create (an app connection is then asked for that right). A published project (live, or with an open preview link) is refused: it must be taken offline first. If the refusal is for a preview link (temporary, 7 days), it may be removed without a separate request (r3_preview_remove) and the delete tried again; the user is then told it was removed. If the project is live, other people can open it: it goes offline only once the user has been asked and agreed, never as a step of the delete. This is irreversible: there is no trash and no undo.

List the projects this R3 account can work on — its own and its teams' — last updated first, with the projectId every other project tool takes. It is how a project the user names ("my slot machine") rather than giving an id is found: search for it; its projectId is what r3_project_load takes. Search by name rather than paging: search: "slot" is matched (case-insensitively, anywhere in the name) against EVERY project by the server, not against the page you are holding. Names are not unique: when more than one project matches, the candidates' name, team and last save tell them apart, and which one is meant is the user's answer. Each row says whose space it is in (personal, or a team by name), the account's role on it (a viewer cannot save changes), whether it is in the R3 Community, and whether you (this agent key or app connection) created it.

List the components in an existing R3 project — what it contains and, for each one, its entityRef: the name code addresses it by (`this['mesh_cube_1']`). Read this before writing any code for a project, and after any tool call whose outcome was reported as unknown, to see what actually landed. Value components (Vector3, Color, Scalar) are not listed individually — reach them through their owner, e.g. `mesh.position.x`.

Rename a project: the name shown in the user's project list, the editor's title and the live page. The same change as clicking the title in the R3 editor, kept at once in the project's live copy (every open R3 tab shows it). The public address does not change: a preview or live link keeps working. Scripts are not affected (they never address the project by name). Renaming a COMPONENT is not this tool: that is done in the R3 editor.

Publish an R3 project live: makes a RELEASE (a frozen copy) of the project as it is now and makes it the one its public live URL shows, for anyone. Only when the user asked for it. Changing the project does NOT change the live site; r3_publish_live does: on a project that is already live this is a publish update (a new release replaces the live one), and the answer names the release number and what changed since the previous live release. `note` (optional, up to 500 characters) is stored with the release. Going live the FIRST time uses one of the live-project slots of the project owner's plan (an update uses none); going live needs a plan. When there is no plan or no room, nothing is published and the answer says how many live projects the plan allows, how many are used and where the user picks a plan. It publishes every change kept so far (yours and the user's: there is nothing to save first). r3_release_list shows the releases, r3_release_rollback makes an older one live again. Needs the publish:live right.

Read the publish settings of one of the user's own R3 projects in this environment — what the app's Deploy → Settings shows: Works on (keyboard / touch / both / not tested), the SEO title and description that search engines and link previews show, how the live page starts (Start button, first click, on load), its controls and badge, and what Save does for a live project. Also answers a SUGGESTION for Works on, from a scan of the project's code for keyboard / touch / pointer handlers — only a suggestion. r3_publish_settings_set changes them. Needs the project:read right.

Change publish settings of one of the user's own R3 projects in this environment — the app's Deploy → Settings. Only the settings named change (the rest stay as they are). Only when the user asked for it, or approved the text: these settings shape the PUBLIC live page — its title and description in search results and link previews (seoTitle, seoDescription), Works on (keyboard puts a "made for a keyboard" note on phones and a "desktop" badge; touch a "mobile" badge; both, both; untested none — set it only after the user confirmed it or it was tested, never from the code scan alone), how it starts, its controls. Invalid values are refused with every problem named, and nothing is saved. The answer names what changed; open live and preview pages are told (a preview reloads, a live page offers a reload). Takes effect without a new release. Needs the publish:live right.

List the releases of an R3 project, newest first: number, date, who made it, note, size, which one is LIVE (what the public URL shows), pinned, and releases in the trash (restorable for 7 days). Also says whether the project has saved changes that are not live yet: saving does NOT change the live site; r3_publish_live does. Read-only. Needs the project:read right.

Put a project's working copy back the way one of its releases (saved versions) had it: components added since are removed, removed ones come back, values and scripts go back to that version (each script as a new version on top of the current one), and the name. The user sees it at once in any R3 tab that has the project open. Only when the user asked for it. Two steps: WITHOUT planToken it changes nothing and says what restoring would change, with a planToken; the same call WITH that planToken, once the user has seen the plan and agreed, restores. If the project changed in between, nothing is changed and the new plan comes back. The whole restore is ONE change of yours: r3_editor_undo takes it back. It never changes which release is LIVE (what the public URL shows): that is r3_release_rollback. The release number comes from r3_release_list. Needs project:write (and code:write when scripts change).

Make an earlier release of a live R3 project the one its public URL shows again (rollback, or forward again). Only when the user asked for it. The project must be live; this never uses a plan slot. A release in the trash or one marked incomplete is refused. Nothing is deleted: the release that was live stays in the list. Take the number from r3_release_list. Needs the publish:live right.

The public R3 roadmap: what is planned, in progress, proposed by the community and shipped, with each item's vote count and whether the user has voted for it — plus the user's OWN suggestions still awaiting R3's approval, marked pending, and the ones R3 declined, marked declined with R3's reason (only the user sees them; neither is votable); a declined item is not suggested again. It shows whether an item already covers an idea before r3_roadmap_suggest: r3_roadmap_upvote votes for that one instead of a duplicate. Narrow it with `search` (title and description, any case) and `status`.

Suggest a feature for R3's public roadmap, in the user's name and naming you (your agent key or app connection). It is HELD until R3's team approves it: not public, not votable, until then. r3_roadmap_list shows whether an item already covers it (r3_roadmap_upvote votes for that one instead). A good suggestion says what the feature lets a person do and why (what was being built when it was missed). Something broken rather than missing is r3_bug_report's. Rate-limited per agent key or app connection (a few a day). Needs the roadmap:suggest right.

Add the user's vote to a public roadmap item (its id from r3_roadmap_list), when the user wants it or it covers what you were about to suggest. One vote per user: an item the user already voted for stays voted, and this never removes a vote. Needs the roadmap:vote right.

How high the ground of a heightfield terrain is at the world (x, z) positions you ask, exactly as physics and the drawn terrain have it, plus the terrain's lowest and highest point, centre, size and footprint. Use it to place something ON a terrain: an object stands on the ground at (x, z) when its lowest point is at the returned y (a vehicle: its wheels' bottom); the returned ground normal says how steep it is there. One call takes up to 100 points; with none it describes the terrain only. `terrain` is the terrain's Mesh, GeometryHeightfield or ColliderHeightfield (entityRef or id); leave it out when the project has one terrain. It reads the user's open R3 editor when it has the project (the terrain as on screen, a heightmap image included), else the saved project. A terrain shaped by a heightmap IMAGE needs the project open in R3 (r3_editor_open), because only a browser decodes the image. Read-only: nothing is changed.

Wire a texture set to a material in a project: the colour map to `map`, the normal map to `normalMap`, the ambient-occlusion / roughness / metalness map to `aoMap` + `roughnessMap` (+ `metalnessMap` when the set is metallic), the SAME repeat on every map, and roughness 1 (THREE multiplies the roughness map by the material's roughness; the default 0.5 would halve it). Creates one Texture per map, or reuses a Texture of the project already on that image. MaterialStandard / Physical get every map; Lambert / Phong / Toon get map, normalMap and aoMap; Basic is refused (unlit). `repeat` is how often the tile repeats across the surface; or give `worldSize` in metres (repeat = worldSize / the set's tile size), e.g. 1000 for a 1 km terrain with 1 m gravel. Kept at once in the project's live copy: every R3 tab with the project open shows it.

Make a matching, seamlessly tiling texture SET for a material: a colour map, a normal map and a packed ambient-occlusion / roughness / metalness map, rendered by R3 from a procedural recipe (seeded noise, stones, bricks …). Nothing is uploaded and it is free. The maps are stored as images in the account (the owner sees them in the Images browser as "<name> · albedo.png" …). Start from a preset (gravel, sand, concrete, bricks) with optional controls: seed (another variation), scale (an integer: finer pattern), colours (the ramp's "#rrggbb" stops), contrast, bumpiness (normal strength), roughness {min, max}, size (256 / 512 / 1024 / 2048, default 1024), tileWorldSize (metres one tile covers, default 1), height (also store a 16-bit height map). Or pass a full `recipe` (r3_docs_read("TEXTURE_RECIPES.md") has the format and every preset's recipe). An invalid recipe is refused with the path of the problem. Pass `apply` {projectId, material, repeat | worldSize} to put it on a material in the same call (as r3_texture_apply). You cannot see the texture: the answer gives numbers (mean colour, brightness range, height spread, seam check) and the colour map's url; r3_editor_capture shows it in an open editor. Names are unique per account. Each call makes a NEW set; reuse a set with r3_texture_apply.

Read one texture set: its name, size, tile size, the three map urls, the numbers its render measured, the sets it was edited from, and the full RECIPE (the editable source). The account's own sets, or anyone's public one. To change a set, r3_texture_update makes a new version of it.

Change a texture set the account owns: its look (controls: seed, scale, colours, contrast, bumpiness, roughness {min, max}, size, tileWorldSize, height, applied to the set's own recipe; `scale` multiplies its pattern, so 2 is twice as fine as now) or a whole new `recipe` (read the current one with r3_texture_read, change it, pass it here). The set itself never changes: the change is saved as a NEW set ("Gravel" → "Gravel 2", or the `name` you give) that links back to it, and every project and release that uses the old maps keeps them. The answer names the user's projects still on the old maps; put the new set on a material with r3_texture_apply when the user wants it. An invalid change is refused with the path of the problem. Counts as one render toward your hourly texture budget.

Take a live R3 project offline: its public live URL stops working at once, and the live-project slot it used on the plan is free again. Only when the user asked for it. Other people open a live project, so one that blocks an r3_project_delete goes offline only once the user has been asked and agreed, never as a step of the delete. Deletes nothing: the project, and any preview link, stay; r3_publish_live makes it live again. A project that is not live is refused and left as it is. Needs the publish:live right.

Report the R3 account you act for, how you are connected (an agent key, or an app connection made with Sign in with R3), what you are allowed to do, the account's plan (its name and how many live projects it allows and uses: going live needs one), and whether the R3 platform is reachable. It verifies the credential end to end and names the capabilities it carries, so it is the call that confirms the account before any other tool. For an account with no project yet it gives the first step.