R3

Import a Blender model into an R3 project

r3_blender_import

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).

Input Schema

Name	Required	Description
`camera`	No	Set the project camera to frame the model, for a NEW project's first model only: refused, with nothing added, when the project already holds a mesh (its camera is then the user's). Omit it to keep the camera.
`meshes`	No	Import only these meshes (by mesh name), each with its own placement. Default: the whole model.
`reparse`	No	Re-read the .blend instead of using what was stored at upload time. This is R3's Re-parse button. Slow (it re-parses and re-optimises every texture) but it is the only way to recover object placements and flat shading that an older import never captured. Default false.
`projectId`	Yes	The project to import into, from r3_project_create.
`blenderModelId`	Yes	Which Blender model, from r3_blender_list.

Output Schema

Name	Required	Description
`root`	No
`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.
`entity`	No
`fileId`	Yes
`status`	Yes
`objects`	No
`filename`	Yes
`reparsed`	Yes
`warnings`	No
`cameraSet`	No
`meshCount`	No
`projectId`	Yes
`textureCount`	No
`materialCount`	No
`blenderModelId`	Yes
`componentCount`	No
`appliedInBlender`	No
`cameraControlsAdded`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026
- addedOutput schema / properties / cameraControlsAdded
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / camera

Added value: +{
+  "additionalProperties": false,
+  "description": "Set the project camera to frame the model, for a NEW project's first model only: refused, with nothing added, when the project already holds a mesh (its camera is then the user's). Omit it to keep the camera.",
+  "properties": {
+    "lookAt": {
+      "additionalProperties": false,
+      "description": "The point it looks at, e.g. the centre of the model.",
+      "properties": {
+        "x": {
+          "type": "number"
+        },
+        "y": {
+          "type": "number"
+        },
+        "z": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "x",
+        "y",
+        "z"
+      ],
+      "type": "object"
+    },
+    "position": {
+      "additionalProperties": false,
+      "description": "Where the camera stands (world units, Y up).",
+      "properties": {
+        "x": {
+          "type": "number"
+        },
+        "y": {
+          "type": "number"
+        },
+        "z": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "x",
+        "y",
+        "z"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "position",
+    "lookAt"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / cameraSet
```
Added value: +{
+  "type": "boolean"
+}
```

Changed2 schema fields changedOct 19, 2026

addedOutput schema / properties / objects / items / properties / kind

Added value: +{
+  "enum": [
+    "mesh",
+    "empty"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / objects / items / required

Previous value: -[
-  "name",
-  "entityRef",
-  "id",
-  "meshName"
-]New value: +[
+  "name",
+  "kind",
+  "entityRef",
+  "id",
+  "meshName"
+]

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: -[
-  "status",
-  "projectId",
-  "blenderModelId",
-  "fileId",
-  "filename",
-  "reparsed"
-]New value: +[
+  "status",
+  "projectId",
+  "blenderModelId",
+  "fileId",
+  "filename",
+  "reparsed",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations flag a non-readonly, non-idempotent, open-world mutation; the description goes well beyond them by explaining the object-to-entity mapping, mesh/geometry sharing, root Empty behavior, the entityRef report, the camera refusal semantics, and reparse's cost ('Slow... re-parses and re-optimises every texture'). The one gap is what a repeated import of the same model does, which matters given idempotentHint=false.

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?

Front-loaded with the core action, then supporting semantics; nearly every clause carries decision-relevant information. It is dense to the point of being one long block, and the mesh/Empty mapping detail is the least essential part, but nothing is redundant filler.

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?

With an output schema present, return values (entityRef per object) need not be spelled out further, and the annotations carry the safety profile. The definition covers mutation effects, failure modes, and prerequisites, leaving only the repeated-import/idempotency question unresolved.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description still adds value by tying meshes to per-object placement and by giving a concrete trigger for reparse ('when the import warns that its meshes were placed at the origin') rather than restating the schema. It does not add syntax detail beyond what the schema already documents.

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

Purpose5/5

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

States a specific verb and resource: adds/imports an uploaded Blender model's current version into an existing R3 project, with optional mesh-level scoping. It is clearly distinguishable from r3_blender_upload (which supplies the model) and r3_blender_update (which moves meshes), both of which it names.

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

Usage Guidelines5/5

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

Explicit routing: 'Use r3_blender_list to choose a model', r3_blender_update 'moves them, if the user wants', reparse only 'when the import warns that its meshes were placed at the origin', and camera only for a NEW project's first model. Exclusions are stated, not implied.

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?