Skip to main content
Glama

Change a resource or import settings

godot_resource_edit
Destructive

Edit Godot .tres/.tscn resources and .import settings without opening the editor, using ordered operations, diff previews, and optional write plus headless reimport verification.

Instructions

Edit a .tres (or the sub_resources of a .tscn) and import settings, without the editor. .tres: set/unset properties on [resource] or a sub_resource (sub: its id), add_sub (type, optional id), remove_sub; names and types checked against Godot 4.7 (enums by name, resources as res:// or SubResource("id"), byte arrays as [0, 255] or base64:...); uids kept, only changed lines touched. Import (give the asset or its .import): get (key: type, default, choices), diff (options changed from default), set/unset an option (names checked against what the importer reads, enums by name: Forward, VRAM Compressed), per sub-resource with sub animations/, meshes/, materials/, nodes/PATH: (loop_mode, shadow meshes, external materials, cast shadow), importer (as: animation_library, scene, image, texture, keep), reimport. Ops run in order; one write. Without write it returns the diff. With write a .import is reimported headless and checked: Godot kept each value, output changed or not (an error result when Godot dropped a value or the import failed). godot_undo reverts.

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": {
      "file": "<file>",
      "ops": "<ops>"
    },
    "name": "godot_resource_edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
opsYeschanges or questions, applied in order
fileYesres://path or a path: .tres, .tscn, an asset or its .import
writeNowrite (default false: diff only)
reimportNoafter a .import write, reimport with Godot and verify (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare destructive/non-idempotent, and the description goes well beyond them: 'only changed lines touched,' 'uids kept,' ops run in order with 'one write,' and a post-write headless reimport that verifies Godot kept each value and returns an error if a value was dropped. That is unusually rich disclosure of side effects and failure modes.

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 tool's purpose and roughly proportionate to a tool with eight ops and a nested schema; nearly every clause carries information. The semicolon-chained single block makes it harder to scan than a bulleted breakdown would, but there is little genuine padding.

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?

With no output schema, the description still covers return behavior (diff without `write`, verification result or error on write), operation ordering, write atomicity, and undo. An agent has what it needs to call this correctly and interpret failure.

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 real value: value encodings (enums by name, res:// or SubResource("id"), byte arrays as [0, 255] or base64:...), and the `sub` grammar for imports (animations/<name>, meshes/<name>, nodes/PATH:<node>). It is dense prose rather than a per-parameter map, which keeps it just below a 5.

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 set: edits .tres files, sub_resources of .tscn, and .import settings, done 'without the editor.' The scope itself separates it from godot_scene_edit (scene nodes) and godot_project_edit (project settings), though no sibling is named explicitly.

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 operating context: 'Without `write` it returns the diff' establishes a preview-first workflow, and 'godot_undo reverts' points at the recovery sibling. It stops short of explicit when-not guidance, e.g. when to prefer the scene or project edit tools instead.

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