R3

Update projects to an entity template's newest version

r3_entity_update

Destructive

Bring the copies of an entity template in this account's projects up to its newest version. Without reportId it only reports, per project: what the template changed that the project did not (taken), what the project changed itself (kept, e.g. a moved ship keeps its position), scripts changed on both sides (kept: code is never merged), parts the template added, and parts it removed (kept unless removeGone: true). With that reportId it applies the report to the projects, as undoable changes every open editor sees; if anything moved since, nothing is changed and the new report is returned. projectIds limits it to those projects (default: every project holding a copy). Published releases never change. Applying needs the template:update right.

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": {
      "templateId": "<templateId>"
    },
    "name": "r3_entity_update"
  }
}

Input Schema

Name	Required	Description
`reportId`	No	The report being applied, from this tool without reportId. Leave it out to plan.
`projectIds`	No	Only these projects (default: every project of the account holding a copy).
`removeGone`	No	Also remove the parts the newest version no longer has (default false: kept and listed). Plan with it and apply that report with it.
`templateId`	Yes	The template (r3_entity_list shows its templateId).

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.
`applied`	Yes
`updated`	Yes
`projects`	Yes
`reportId`	Yes
`toVersion`	Yes
`removeGone`	Yes
`templateId`	Yes
`environment`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare destructive and non-idempotent, but the description adds substantial context beyond them: changes are undoable and visible to every open editor, apply is guarded by a staleness check (if anything moved since, nothing changes and a new report returns), code is never merged, and removals are kept unless removeGone is true. These are exactly the behavioral traits an agent needs before a destructive call.

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 purpose, then the plan mode, then apply-mode side effects and permissions. It is dense but every clause carries operational meaning; the classification parentheticals make the plan output understandable. Slightly long as a single paragraph, which keeps it just under top marks.

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 destructive, open-world mutation with four parameters, the description covers plan versus apply, scoping, concurrency behavior, undoability, permission requirements, and what is never touched. With an output schema present, it need not restate return shapes, so nothing essential is missing.

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 description coverage is 100%, so the baseline would be 3. The description nonetheless adds interpretive meaning to reportId by explaining what the report it references contains (taken, kept, both-changed scripts, added parts, removed parts) and states the default scope for projectIds, which helps an agent read the plan before applying it.

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 first sentence names the specific verb and resource: bringing copies of an entity template in this account's projects up to the newest version. It then splits the tool into its two modes (report-only without reportId, apply with reportId), so an agent can tell exactly what this does versus siblings like r3_entity_read or r3_entity_save_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 clear conditional guidance: omit reportId to plan, pass it to apply, use projectIds to limit scope, and note that applying requires the template:update right. It also states the safety rule that published releases never change. It stops short of naming alternative tools an agent might pick instead, so it is not a full 5.

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?