Skip to main content
Glama

Resource Manage

resource_manage

Search, inspect, assign, and create Godot resources directly from the editor. Covers generic Resource subclasses plus specialized authoring for curves, environments, physics shapes, and textures.

Instructions

Resource (asset) search, inspection, assignment, and creation. Covers generic Resource subclasses plus specialized authoring (Curve, Environment, physics shapes, gradient/noise textures).

Ops: • search(type="", path="", offset=0, limit=100) Search for resources by type or path. Type matching includes subclasses. At least one filter required. Paginated. • load(path) Inspect a .tres / .res — returns type and editor-visible properties. • inspect(node_path, property, depth=2) Read a live native resource graph without loading or modifying files. Depth 0..3; shared references, omission reasons, fixed traversal and 64 KiB encoded-result limits. Scripted/dynamic properties excluded. • assign(path, property, resource_path) Load and assign a resource to a node property. Undoable. • get_info(type) Introspect a Resource class — properties, parent, abstract flag, concrete_subclasses (for abstract bases). Read-only. • create(type, properties=None, path="", property="", resource_path="", overwrite=False) Instantiate a Resource subclass. Either path+property (assign to a node, undoable) or resource_path (save to .tres). For specific families (Curve, Environment, etc.) prefer the dedicated ops. • curve_set_points(points, path="", property="", resource_path="") Replace all points on a Curve / Curve2D / Curve3D. Auto-creates the curve resource if the slot is empty (curve_created flag). • environment_create(path="", preset="default", properties=None, sky=None, resource_path="", overwrite=False) Build Environment + Sky chain. Presets: default | clear | sunset | night | fog. sky may be bool or a procedural sky dict such as {"sky_material": "procedural", "sky_top_color": "#0f172a"}. Either assign to a WorldEnvironment node or save .tres. • physics_shape_autofit(path, source_path="", shape_type="") Size a CollisionShape2D/3D to a nearby visual's bounds. Searches direct siblings then parent-siblings (handles nested Body→Collision layouts). Ambiguous matches return candidate paths in error.data.candidates. Auto-creates the concrete Shape subclass if needed. shape_type accepts either the short form ("box", "sphere", "capsule", "cylinder" for 3D; "rectangle", "circle", "capsule" for 2D) or the matching Godot class name ("BoxShape3D", "RectangleShape2D", etc.). • physics_shape_generate(paths, shape_type="box", body_type="static", reparent_mesh=False, scene_file="", overwrite=False) Generate a physics body sibling (named Collider) with a CollisionShape3D for every MeshInstance3D path. Shapes are fitted in body-local space; a mesh that already has a collider sibling, a duplicate path, or a scene-root mesh is refused before anything is written. shape_type: auto | box | sphere | capsule | cylinder | convex | trimesh (or the class name for explicit shapes). Opt-in auto selects matching primitives for BoxMesh, SphereMesh, CapsuleMesh and CylinderMesh, with box bounds for every other mesh. The default remains box. Auto uses bounding fits (including tapered cylinders), not exact mesh geometry. convex/trimesh derive the shape from the mesh's own triangles, with the mesh scale baked into the shape, and are limited to 2048 triangles and 6144 vertices per mesh, with bounded mesh types (the hull build runs synchronously inside one editor-frame item); trimesh needs a static or area body, and a non-uniformly scaled parent chain refuses every type except box. body_type: static | area | rigid | character. rigid/character always wrap the mesh under the generated body (a detached dynamic body would fall away from the stationary visual); reparent_mesh=True does the same for static/area while preserving the mesh's world transform, and the reported mesh_path is then the post-move path. overwrite=True refreshes only a marked generated collider's shape and collision transform, preserving body/collision identity and user settings. Requested body type and wrapping must match; unmarked legacy bodies or broken provenance links are refused. Mixed fresh/refresh batches prepare all resources before one undo action; stale edits refuse the batch. scene_file pins the request to that edited scene. Up to 1024 paths are processed in bounded work across editor frames; inside batch_execute at most 16. The bulk write is one undo action. Returns: {created: [{mesh_path, body_path, shape_path, shape_type, body_type, operation: "create"|"refresh"}], undoable: true}. • gradient_texture_create(stops, width=256, height=1, fill="linear", path="", property="", resource_path="", overwrite=False) Build GradientTexture2D from color stops. fill: linear | radial | square. • noise_texture_create(noise_type="simplex_smooth", width=512, height=512, frequency=0.01, seed=0, fractal_octaves=0, path="", property="", resource_path="", overwrite=False) Build NoiseTexture2D wrapping FastNoiseLite. Noise types: simplex | simplex_smooth | perlin | cellular | value | value_cubic.

Canonical call shape: {"op": "<verb>", "params": {...}}. Flat op parameters are accepted as a compatibility alias when the client transmits them; op and session_id remain top-level.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opYes
paramsNo
session_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.2.1
    • changedInput schema / properties / op / enum
      Previous value: -[
      -  "assign",
      -  "create",
      -  "curve_set_points",
      -  "environment_create",
      -  "get_info",
      -  "gradient_texture_create",
      -  "load",
      -  "noise_texture_create",
      -  "physics_shape_autofit",
      -  "physics_shape_generate",
      -  "search"
      -]New value: +[
      +  "assign",
      +  "create",
      +  "curve_set_points",
      +  "environment_create",
      +  "get_info",
      +  "gradient_texture_create",
      +  "inspect",
      +  "load",
      +  "noise_texture_create",
      +  "physics_shape_autofit",
      +  "physics_shape_generate",
      +  "search"
      +]
  2. Changed1 schema field changedv4.0.3
    • changedInput schema / properties / op / enum
      Previous value: -[
      -  "assign",
      -  "create",
      -  "curve_set_points",
      -  "environment_create",
      -  "get_info",
      -  "gradient_texture_create",
      -  "load",
      -  "noise_texture_create",
      -  "physics_shape_autofit",
      -  "search"
      -]New value: +[
      +  "assign",
      +  "create",
      +  "curve_set_points",
      +  "environment_create",
      +  "get_info",
      +  "gradient_texture_create",
      +  "load",
      +  "noise_texture_create",
      +  "physics_shape_autofit",
      +  "physics_shape_generate",
      +  "search"
      +]
  3. Addedv3.1.4
  4. Removedv3.0.7
  5. First observedv2.9.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it does so extensively: read-only operations are labeled (get_info "Read-only"), mutating operations are qualified (assign/create "Undoable"), limits are disclosed (depth 0..3, 64 KiB limit, 2048 triangles, 6144 vertices, 1024 paths), and refusal conditions are explicit ("refused before anything is written", "unmarked legacy bodies or broken provenance links are refused"). It also documents canonical call shape and batch execution constraints, going well beyond a surface-level summary.

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 long but appropriately structured for a twelve-operation tool: a one-line overview, a bulleted op list with consistent signatures, a canonical call shape, and a compatibility note. The detailed physics_shape_generate section is dense but every sentence conveys a distinct constraint or behavior. No filler or tautological phrasing is present.

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 the tool's complexity, the absence of annotations, and the free-form params schema, the description is remarkably complete. It explains each op's purpose, parameter options, side effects, limits, undo behavior, and even the canonical invocation shape. Since an output schema exists, the lack of per-op return descriptions beyond the one shown is acceptable.

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?

The input schema has 0% description coverage and only exposes a free-form params object, so the description must fully compensate. It does: every operation lists its parameters with defaults, accepted enum values, and behavioral meaning (e.g., shape_type short forms versus Godot class names, environment presets, fill modes, noise types). This gives an agent everything needed to construct valid calls.

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 states specific verbs and a clear resource domain: "Resource (asset) search, inspection, assignment, and creation." It further distinguishes the tool by enumerating specialized authoring families (Curve, Environment, physics shapes, gradient/noise textures) and listing twelve concrete operations. This gives an agent a precise model of what the tool does and how it differs from node/scene/material management siblings.

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?

The description provides strong context for when to use the tool: it covers resource search, inspection, assignment, and creation, and it even routes users to dedicated ops within the tool ("For specific families (Curve, Environment, etc.) prefer the dedicated ops"). It does not, however, explicitly state when to prefer a sibling tool such as node_set_property, material_manage, or filesystem_manage, nor does it name exclusions. Clear context, but no explicit alternatives.

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