R3

Save an Entity as a template

r3_entity_save_template

Save an Entity of a project as an entity template version: its members (the components bound to it, with the positions, rotations and colours they hold). Without templateId it updates the template the Entity was imported from (or makes a new one, under the Entity's id); asNew: true always makes a new template. Updating an existing template needs baseVersion, the version read with r3_entity_read: if the template changed since, nothing is saved and the answer names the current version. The project itself is not changed. The answer lists every reference a member holds to a component outside the Entity (outsideReferences): infrastructure (scene, world, camera, listener, renderer, transport) is expected and re-bound on import; anything else (a geometry or material left outside) is listed first, because an import into another project leaves it empty. The save is not refused for them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>",
      "entityRef": "<entityRef>"
    },
    "name": "r3_entity_save_template"
  }
}

Input Schema

Name	Required	Description
`note`	No	What changed, kept with the version.
`asNew`	No	true saves a NEW template, never updating one.
`entityRef`	Yes	The Entity (its entityRef, or its id).
`projectId`	Yes	The project holding the Entity.
`templateId`	No	The template to update (default: the one the Entity came from, else a new one).
`baseVersion`	No	The template version you read (r3_entity_read): required to update an existing template.

Output Schema

Name	Required	Description
`name`	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.
`version`	Yes
`templateId`	Yes
`memberCount`	Yes
`versionCreated`	Yes
`outsideReferences`	Yes
`valueComponentCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

addedOutput schema / properties / outsideReferences

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "expected": {
+        "type": "boolean"
+      },
+      "field": {
+        "type": "string"
+      },
+      "member": {
+        "type": "string"
+      },
+      "memberRef": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "targetId": {
+        "type": "string"
+      },
+      "targetType": {
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "member",
+      "memberRef",
+      "field",
+      "targetId",
+      "targetType",
+      "expected"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "templateId",
-  "name",
-  "version",
-  "versionCreated",
-  "memberCount",
-  "valueComponentCount",
-  "answer"
-]New value: +[
+  "templateId",
+  "name",
+  "version",
+  "versionCreated",
+  "memberCount",
+  "valueComponentCount",
+  "outsideReferences",
+  "answer"
+]

AddedNov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: it declares that the project itself is not changed, documents optimistic concurrency ('if the template changed since, nothing is saved and the answer names the current version'), and explains the outsideReferences reporting behaviour, including that the save is not refused because of dangling references. These are exactly the mutation/conflict/auth-adjacent traits annotations do not convey.

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 and the default/override branching before secondary details. It is dense and slightly meandering late on—the parenthetical list of infrastructure types ('scene, world, camera, listener, renderer, transport') and the trailing 'The save is not refused for them' are wordier than needed, though they still carry information.

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?

For a non-idempotent, open-world mutation with an output schema, the description covers what is persisted, what is deliberately untouched, how conflicts surface, and how to interpret the returned outsideReferences. An agent has everything needed to invoke it correctly and to read the result.

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 the baseline is 3, but the description adds genuine meaning on top: it explains the default resolution of templateId (imported-from template, else new under the Entity's id) and the failure semantics of baseVersion rather than just restating that it is required. The note parameter is not mentioned in the description, which is a minor gap.

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: 'Save an Entity of a project as an entity template version', and immediately specifies what is captured ('its members ... with the positions, rotations and colours they hold'). This distinguishes it from siblings like r3_entity_read (which it names as the version source) and r3_entity_import (which it describes as the consumer of the produced template).

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

Usage Guidelines4/5

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

Gives explicit branching conditions: without templateId it updates the originating template (or creates one under the Entity's id), with asNew:true it always creates a new one, and updating requires baseVersion from r3_entity_read. It stops short of naming an alternative tool for the 'save as a different kind of asset' case or stating when not to use it, so it is strong but not exhaustive.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?