R3

Add an object LIVE to the user's open R3 editor

r3_editor_create

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.

Input Schema

Name	Required	Description
`name`	No	The name of what you make, e.g. "Leg front left" (r3_factory_run's name).
`params`	No	Factory options, e.g. {"color": 16711680, "position": {"y": 2}}. Rotation is in RADIANS, color a packed RGB integer.
`factory`	Yes	Factory name, e.g. "Cube", "Sphere", "PhysicsCube". See r3_factory_list.
`projectId`	Yes	The project (r3_project_list).

Output Schema

Name	Required	Description
`seq`	No
`live`	Yes
`roles`	Yes
`saved`	Yes
`answer`	Yes	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.
`editor`	Yes
`created`	Yes
`factory`	Yes
`projectId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

addedInput schema / properties / name

Added value: +{
+  "description": "The name of what you make, e.g. \"Leg front left\" (r3_factory_run's name).",
+  "type": "string"
+}

Changed1 schema field changedOct 19, 2026

changedOutput schema / properties / editor / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "lastActiveAgoMs": {
-        "type": "number"
-      },
-      "lastActiveAt": {
-        "type": "string"
-      },
-      "openProjects": {
-        "anyOf": [
-          {
-            "items": {
-              "additionalProperties": false,
-              "properties": {
-                "id": {
-                  "type": "string"
-                },
-                "name": {
-                  "type": [
-                    "string",
-                    "null"
-                  ]
-                }
-              },
-              "required": [
-                "id",
-                "name"
-              ],
-              "type": "object"
-            },
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "openedAt": {
-        "type": [
-          "string",
-          "null"
-        ]
-      }
-    },
-    "required": [
-      "openedAt",
-      "lastActiveAt",
-      "lastActiveAgoMs",
-      "openProjects"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "frames": {
+        "anyOf": [
+          {
+            "additionalProperties": false,
+            "properties": {
+              "advancing": {
+                "type": "boolean"
+              },
+              "frameSeen": {
+                "type": "boolean"
+              },
+              "sceneShown": {
+                "type": "boolean"
+              },
+              "visible": {
+                "type": "boolean"
+              }
+            },
+            "required": [
+              "advancing",
+              "visible",
+              "sceneShown",
+              "frameSeen"
+            ],
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "lastActiveAgoMs": {
+        "type": "number"
+      },
+      "lastActiveAt": {
+        "type": "string"
+      },
+      "openProjects": {
+        "anyOf": [
+          {
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "id": {
+                  "type": "string"
+                },
+                "name": {
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                }
+              },
+              "required": [
+                "id",
+                "name"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "openedAt": {
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "openedAt",
+      "lastActiveAt",
+      "lastActiveAgoMs",
+      "openProjects"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

Changed2 schema fields changedOct 15, 2026

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",
-  "factory",
-  "created",
-  "roles",
-  "live",
-  "saved",
-  "editor"
-]New value: +[
+  "projectId",
+  "factory",
+  "created",
+  "roles",
+  "live",
+  "saved",
+  "editor",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, openWorld=true, idempotent=false, so the safety profile is covered. The description adds genuinely new behavioral context: the change is applied immediately, propagates to every R3 tab with the project open, and requires no save step. It does not address calling it twice with the same name (relevant given idempotentHint=false) or whether r3_editor_undo can reverse it.

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?

A compact two-sentence description with the important live/immediate behavior front-loaded after the alias note. The parenthetical '(this is its older name)' and the trailing factory-list pointer are both useful, though the em-dash/ellipsis phrasing makes the core sentence denser than necessary.

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

Completeness4/5

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

For a live-mutation tool with a nested params object and an output schema (so return values need no prose), the description covers what the agent needs: what gets created, that it appears immediately everywhere, and where to get valid factory names. Only edge-case behavior — duplicate names or undoability — is absent.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters (name, params, factory, projectId) are already documented with examples and units (radians, packed RGB int). The description only reinforces this by pointing at r3_factory_list for the factory enumeration; it adds no format or constraint detail beyond what the schema supplies, so the baseline 3 applies.

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

Purpose4/5

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

States a concrete verb and resource ('add an object — a cube, sphere, light, physics body') plus the key scope fact that the object lands in the project's live copy. It explicitly identifies itself as the older name of r3_factory_run, so an agent knows the two are interchangeable, and points at r3_factory_list for the factory vocabulary. It does not distinguish itself from other add-style siblings such as r3_editor_add_component or r3_component_add, which is the remaining ambiguity.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: 'no editor needed and nothing to save' tells the agent this takes effect immediately, and r3_factory_list is named as the prerequisite lookup for factory names. There is no explicit when-to-use / when-not guidance and no statement about how this differs from r3_editor_add_component, leaving the agent to infer the boundary.

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

All R3 tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?