godot-omni

Overview Schema Source Related Servers Discussions Admin

resource_manage

Search, inspect, assign, and create Godot resources, including curves, environments, physics shapes, and textures. Load resource files, auto-fit collision shapes, and generate procedural resources from parameters.

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 changedv5.0.9Sep 19, 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",
-  "physics_shape_generate",
-  "search"
-]New value: +[
+  "assign",
+  "create",
+  "curve_set_points",
+  "delete",
+  "environment_create",
+  "get_info",
+  "gradient_texture_create",
+  "load",
+  "move",
+  "noise_texture_create",
+  "physics_shape_autofit",
+  "physics_shape_generate",
+  "search"
+]

First observedv4.1.0Sep 17, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden and does well: it discloses undoable writes, read-only get_info, auto-creation behavior, refusal cases, bounded work, and single-undo writes. However, the op enum also includes delete and move, which are completely undocumented, so behavior is not fully transparent for all operations.

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?

The description is long but well-structured with a summary, per-operation signatures, and explanatory bullets. Each section is dense with necessary detail, though the missing delete/move coverage and the trailing compatibility note add some bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with a generic schema, the description is unusually complete, covering operation signatures, side effects, edge cases, and even one return shape. The notable gap is the omission of delete and move from the documented operations despite them being valid enum values; an agent could not invoke those safely without more information.

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 is generic—only op, params, and session_id—with 0% schema description coverage, so the description must define parameter semantics. It does so thoroughly for nearly every operation, including allowed values for presets, fill modes, noise types, and shape_type short/class names.

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 opens with a clear statement of scope—resource search, inspection, assignment, and creation—and enumerates the specific operations. It distinguishes the tool from siblings by focusing on Resource assets and specialized authoring families, which prevents confusion with filesystem_manage or node_manage.

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 practical when-to-use guidance, such as requiring at least one filter for search, choosing between path+property and resource_path for create, and preferring dedicated ops for Curve/Environment families. It does not name sibling tools explicitly, but the context is clear enough to route an agent.

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