Godot AI

Overview Schema Source Related Servers Discussions Admin

resource_manage

Manage Godot resources: search, load, assign, create, and edit assets including curves, environments, and physics shapes.

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. • 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", scene_file="") Generate a StaticBody3D or Area3D 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: box | sphere | capsule | cylinder (or the class name); a sphere/capsule/cylinder under a non-uniformly scaled parent is refused. body_type: static | area. 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}], 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

Name	Required	Description	Default
`op`	Yes
`params`	No
`session_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv4.0.3Sep 9, 2026

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"
+]

Addedv3.1.4Aug 10, 2026
Removedv3.0.7Jul 26, 2026
First observedv2.9.1Jul 11, 2026

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 transparency burden and does so thoroughly: it notes undoable operations, read-only calls, auto-creation of resources, bounded work limits, refusal conditions, one-undo-action batching, and candidate paths in error data. It also discloses return shapes for key operations such as physics_shape_generate.

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 well-structured with a clear purpose statement, bulleted operations, and a canonical call-shape note. Each operation is compactly specified with relevant constraints and options, and the length is justified by the number of distinct resource operations covered.

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 broad scope of 11 operations and minimal schema coverage, the description is complete enough for an agent to select and invoke the correct operation. It includes required filters, shape-type mappings, preset names, return flags, undo behavior, and boundary conditions for complex operations.

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 only defines op, params, and session_id with 0% coverage, so the description must explain all parameters and does so extensively per operation. It documents each operation's parameters, defaults, accepted enum-like values, and the distinction between assigning to a property versus saving to a resource_path.

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 clearly identifies resource management as a multi-operation tool covering search, inspection, assignment, creation, and specialized authoring. It names concrete operations and distinguishes specialized resource families (Curve, Environment, shapes, textures) from generic resource handling.

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 gives explicit guidance for when to use dedicated operations (e.g., preferring curve_set_points, environment_create, physics_shape_*) over generic create, and explains canonical call shape and flat alias compatibility. It does not explicitly contrast with sibling node/scene/material tools, but internal usage boundaries are clear.

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