Skip to main content
Glama
bebabinlarsson-blip

godot-omni

by bebabinlarsson-blip
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

resource_manage

Manage Godot resources: search, inspect, assign, and create assets including environments, physics shapes, curves, gradients, and noise 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. • 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. • environment_setup_3d(preset="daylight", parent_path="", create_sun=True, volumetric_fog=False, glow=False) Scaffold complete 3D environment and lighting. Presets: daylight | sunset | dark_dungeon | neon_night | clear. Auto-creates WorldEnvironment and DirectionalLight3D with matching sky, lighting, shadows, and tone mapping in a single undoable step. • environment_setup_2d(preset="dungeon", parent_path="", add_torch_to="", torch_energy=1.2, torch_radius=2.0, shadows=True) Scaffold complete 2D atmospheric lighting environment. Presets: dungeon | midnight | sunset | spooky | foggy. Creates CanvasModulate ambient tint, and optionally attaches a PointLight2D radial torch with falloff texture and shadows to the target character/object. • 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
NameRequiredDescriptionDefault
opYes
paramsNo
session_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv5.0.28
    • changedInput schema / properties / op / enum
      Previous 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"
-]New value: +[
+  "assign",
+  "create",
+  "curve_set_points",
+  "delete",
+  "environment_create",
+  "environment_setup_2d",
+  "environment_setup_3d",
+  "get_info",
+  "gradient_texture_create",
+  "load",
+  "move",
+  "noise_texture_create",
+  "physics_shape_autofit",
+  "physics_shape_generate",
+  "search"
+]
  2. Changed1 schema field changedv5.0.9
    • 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"
+]
  3. First observedv4.1.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so richly. It discloses read-only behavior for get_info, undoable writes, auto-creation behavior, refusal conditions, bounded work, and an example return shape for physics_shape_generate. This goes well beyond a minimal behavioral statement.

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: a purpose summary, grouped ops with inline signatures, and the canonical call shape. Everything present earns its place, though the amount of detail is substantial. It is appropriately sized for a multi-op dispatcher but sits at the upper bound of conciseness.

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

Completeness3/5

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

The description covers 13 of the 15 ops in the schema enum and gives return details where non-obvious, such as physics_shape_generate. However, delete and move are entirely absent, and with no annotations or visible output schema help, those ops are left undocumented. For a complex dispatcher, this incompleteness prevents full self-sufficiency.

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?

The schema's params is an opaque object with 0% description coverage, so the per-op parameter lists are the only documentation. The description supplies defaults, enums-like presets, shape_type short/class name alternatives, and example sky dicts. The undocumented delete and move ops are a notable gap, but the described ops are thoroughly specified.

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?

The description states a specific purpose: 'Resource (asset) search, inspection, assignment, and creation' and then details concrete operations. It is clear about the resource domain, but it does not explicitly differentiate from overlapping siblings like curve_manage or texture_manage, and it fails to mention the delete and move ops present in the schema enum.

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 clear internal usage context, such as 'For specific families (Curve, Environment, etc.) prefer the dedicated ops' and distinguishes when to use physics_shape_autofit vs physics_shape_generate. However, it does not explicitly explain when to choose resource_manage over sibling tools or when not to use it.

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

Deploy Server

Other Tools