R3

Update projects to a Blender model's current version

r3_blender_update

Destructive

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 and placement; when only its shape changed it keeps the project's materials and the edits made to them in R3, when its materials changed in Blender it takes Blender's materials, and edits made in R3 to its materials are replaced. 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. The plan only reads; moving projects needs the blender:update right.

Input Schema

Name	Required	Description
`choice`	Yes	Required: update_projects. There is no default.
`reportId`	No	The report being answered, from the plan (this tool without reportId). Leave it out to plan.
`projectIds`	No	With a reportId: the projects to update.
`removeGone`	No	Also remove the parts the current version no longer has (default false: they are kept and listed). Plan with it and answer that report with it.
`blenderModelId`	Yes	The Blender model, from r3_blender_list.
`entityTemplateIds`	No	With a reportId: the entity templates to update.

Output Schema

Name	Required	Description
`kept`	Yes
`live`	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.
`choice`	Yes
`reportId`	No
`freedRows`	Yes
`repointed`	Yes
`duplicates`	No
`environment`	Yes
`projectParts`	No
`currentFileId`	Yes
`versionNumber`	No
`blenderModelId`	Yes
`behindProjectIds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 24, 2026
- addedOutput schema / properties / projectParts
```
Added value: +{
+  "items": {},
+  "type": "array"
+}
```
- addedOutput schema / properties / versionNumber
```
Added value: +{
+  "type": "number"
+}
```

Changed2 schema fields changedOct 22, 2026

addedInput schema / properties / removeGone

Added value: +{
+  "description": "Also remove the parts the current version no longer has (default false: they are kept and listed). Plan with it and answer that report with it.",
+  "type": "boolean"
+}

addedOutput schema / properties / duplicates

Added value: +{
+  "items": {},
+  "type": "array"
+}

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

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: -[
-  "blenderModelId",
-  "choice",
-  "currentFileId",
-  "repointed",
-  "kept",
-  "freedRows",
-  "environment"
-]New value: +[
+  "blenderModelId",
+  "choice",
+  "currentFileId",
+  "repointed",
+  "kept",
+  "freedRows",
+  "environment",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A5/5.0

Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: it explains matching by Blender OBJECT name, material-preservation rules, handling of new and gone parts, removeGone semantics, and the required blender:update right. It is consistent with destructiveHint=true and readOnlyHint=false by clearly describing the plan as read-only and execution as mutating.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense but well-structured paragraph that front-loads the core model-update concept and then layers usage, matching behavior, and authorization details. Every sentence contributes operational context for a complex destructive tool.

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

Completeness5/5

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

Given six parameters, a destructive annotation profile, an output schema, and a nontrivial Blender-to-project update workflow, the description covers planning, execution, matching semantics, material handling, removal behavior, and permissions. No additional explanatory sentence is needed for an agent to invoke it correctly.

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

Parameters5/5

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

Although schema coverage is 100%, the description meaningfully explains the conditional relationship between parameters: choice without reportId plans, while reportId plus projectIds/entityTemplateIds executes. It also clarifies removeGone's effect and the choice between planning and answering a report.

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?

The description states a precise verb and resource (update projects to a Blender model's current version) and immediately distinguishes its planning mode from its execution mode. It also distinguishes the tool's scope from other Blender tools by explaining that published releases never change and that it only moves selected projects/entity templates.

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?

It gives explicit when-to-use guidance: call without reportId to produce a plan, call with reportId and selected IDs to apply changes, and make no call for 'not now'. It also states that published releases are unaffected, removing ambiguity about scope.

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?