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. ALWAYS two calls: first without `confirm` — nothing is deleted, the answer says what would go and which of the user's projects use it; then, if that is what the user wants, the same call with `confirm: true`. 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. Find ids with 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; to delete an item, use r3_asset_delete with its kind and id (plan first, then confirm) — and only 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, so reach for those rather than for a recorded file you do not have.

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. Apply modifiers on a copy and pack textures before pushing; save the real file with r3_blender_upload when 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 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. 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).

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. Ask the user first; "not now" is no call. Only the mesh shapes and materials change; each project keeps its own placement, and 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. Pack textures first (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). Check r3_bug_reports_mine first: when the user already reported it, point them to that one instead of filing it twice. Make it useful: say what you did (the tool calls), what you expected and what happened, and put what you MEASURED in `measurements` — the values you read back with r3_component_read or r3_editor_inspect, the exact error text. Pass `projectId` when it happens in a project, so R3 can open it. Tell the user you filed it, with the link. 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). Read it BEFORE r3_bug_report: when one already covers the fault, tell the user about that one (its link) instead of filing 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 runs in the browser and makes a project DO something (spin a mesh, respond to keys, drive physics). Kept at once in the project's live copy: every R3 tab with the project open gets the new code now, no editor needed and nothing to save (r3_editor_code is the same tool). The answer says what was kept, its seq and the new codeVersion. Call r3_project_load FIRST: code addresses components by their entityRef, and that tool tells you those names. Read r3_docs_read("CODE_PATTERNS.md") before your first Code component: a guessed API saves cleanly and then does nothing. HOW TO WRITE IT — the code is a function body, and it PUBLISHES its hooks by returning them: ```js this.start = function() { // once, when the code starts }; this.update = function(data) { this['mesh_cube_1'].rotation.y += data.delta; // any component, by entityRef }; return {start: this.start, update: this.update}; // REQUIRED — nothing runs without it ``` Reach any component with `this['<entityRef>']`, and the project's infrastructure with the host accessors this.getProject() / getScene() / getCamera() / getRenderer() / getWorld() / getAudioListener() / getEntityInstance() — never by a guessed ref. Anything else you return alongside start/update becomes a public API other Code components call as `this['<entityRef>'].api.<name>(...)`. There is NO getComponentByRef, no this.state, no this.getSibling and no R3 global — those do not exist in R3, and code using them is REFUSED here rather than saved. EVENTS (pass the 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. What `data` each one delivers (the mouse payload is nested, in normalized device coordinates) is in r3_docs_read("CODE_PATTERNS.md"). Pass entityRef to REPLACE the code of an existing Code component; pass name (or neither) to create a new one. REPLACING needs baseVersion, the codeVersion r3_code_read gave: code is never merged, so 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).

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. Call r3_project_load FIRST: components are addressed by entityRef, and that tool is what tells you 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 its mesh (Configure from Mesh: radius, connectionPoint, axle), only the values still at their defaults; the answer says what was measured and what was kept (PHYSICS_USAGE.md → Vehicles). Giving a ColliderCuboid / Sphere / Cylinder / Capsule its mesh or rigidBody fits it to the mesh the same way (Fit to Mesh: size, and position on the mesh's centre).

Every R3 document this server can give you, IN THE ORDER TO READ THEM, with what each one covers and how big it is. Start here: no model has R3 in its pretraining, and code written from tool descriptions alone saves cleanly and then silently does nothing. Read one with r3_docs_read.

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 — read this first r3_docs_read("PHYSICS_USAGE.md") colliders, rigid bodies, joints 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 ~246KB.

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 its camera sees it 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. 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. Ask the user which mode, 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. 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 (with none, open it in R3 first: r3_editor_open). r3_component_read reads the kept values without a tab. Select with any of: `ids` (component ids from r3_project_load), `type` ("Mesh", "RigidBody", …) 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: call r3_editor_open first. 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). Use it to show the user the project you are working on, or before r3_editor_inspect. 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. 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 make a version only when the user asks for one (or at a milestone you tell them 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. Call it once the project looks right (r3_editor_capture first to check), 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). Do not then force the old value back over theirs: tell the user and let them decide. `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; do not build your own overlay in a Code component. The body is markdown — headings, bullets, `code`, links. Write the controls the way a player would need 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 you what they have already put there; check that first, because using the account's own artwork beats generating a 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 — make it descriptive. 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 24 hours and does NOT make the project public. Use this to show the user 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.

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 on your own when the preview link is what blocks an r3_project_delete you were asked to do: a preview link is temporary, so you may remove it then, and you must tell the user you did. 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. Call r3_whoami first if you have not confirmed the account.

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. 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, 24 hours), you may remove it on your own with r3_preview_remove and delete again, and you must tell the user you removed it. If the project is live, other people can open it: ask the user before taking it offline, never on your own. 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. Start here whenever the user names a project ("my slot machine") rather than giving an id: search for it, then pass its projectId to r3_project_load. 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 — if more than one project matches, show the user the candidates (name, team, last saved) and ask which one. 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, or without a plan the free live project (an update uses none). When there is no room, nothing is published and the answer says how many live projects the plan (or the free 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: call it WITHOUT planToken first; it changes nothing and says what restoring would change, with a planToken. Tell the user, and only if they agree call it again with that planToken. 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. Take the release number 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.