Skip to main content
Glama
bebabinlarsson-blip

godot-omni

by bebabinlarsson-blip
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

scene_manage

Create and save scenes, list open roots, batch-instantiate them, and run diagnostics to fix scene issues.

Instructions

Scene authoring (create, save_as, list open roots).

Resource form: godot://scene/current and godot://scene/hierarchy — prefer for active-session reads.

Ops: • create(path, root_type="Node3D", root_name="") Create the initial .tscn with the given root and open it. root_name defaults to filename basename when empty. This initial root is written immediately, but later node_create/node_set_property mutations remain in editor memory until scene_save or save_as is called. • save_as(path) Save the currently edited scene to a new file path. • get_roots() List scenes currently open in the editor; flag the edited one. • instantiate_batch(instances, parent_path="") Instantiate multiple PackedScenes into the active scene in a single UndoRedo action. instances: [{scene_path, name?, position?, rotation?, scale?, properties?}]. • diagnose(root_path="") Comprehensive health check / scene doctor for the open scene. Validates orphan collision shapes, unassigned shapes, non-uniform scaling, missing textures, camera configuration, and control hierarchy with actionable error/warning reports and fix suggestions.

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: -[
-  "create",
-  "get_roots",
-  "instantiate_batch",
-  "save_as"
-]New value: +[
+  "create",
+  "diagnose",
+  "get_roots",
+  "instantiate_batch",
+  "save_as"
+]
  2. Changed1 schema field changedv5.0.14
    • changedInput schema / properties / op / enum
      Previous value: -[
-  "create",
-  "get_roots",
-  "save_as"
-]New value: +[
+  "create",
+  "get_roots",
+  "instantiate_batch",
+  "save_as"
+]
  3. First observedv4.1.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does so well: it discloses that the initial root is written immediately while later node_create/node_set_property mutations persist in editor memory until save, and that instantiate_batch is one UndoRedo action. It also documents the flat-parameters compatibility alias. It does not cover failure modes or permissions, but the core write/persistence behavior is explicit.

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 summary and resource-routing note are front-loaded, then each op is a compact bullet with enough detail. Despite length, each sentence contributes, including the canonical call shape and compatibility alias note, so the structure is efficient for a five-op tool.

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 no annotations, a permissive schema, and five distinct ops, the description is complete: it covers call shape, op behaviors, defaults, persistence semantics, and the read-alternative resource form. An output schema exists, so the absence of return-value prose is not a gap.

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?

Schema description coverage is 0% and the params object is permissive, so the description is the only documentation of parameters. It provides full signatures, defaults (root_type='Node3D', parent_path=''), the root_name default-to-basename rule, and the fields of instances. This exceeds what the input schema offers.

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 scope ('Scene authoring') and enumerates five operation verbs with their resources: create, save_as, get_roots, instantiate_batch, and diagnose. It also marks the resource form for active-session reads, distinguishing this authoring tool from read-oriented siblings such as scene_get_hierarchy.

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?

It gives an explicit when-not-to-use signal: godot://scene/current and godot://scene/hierarchy should be preferred for active-session reads. It also explains op-specific contexts, e.g., save_as writes to a new path and create opens the initial scene. It does not directly contrast every sibling such as scene_save, but the op descriptions largely disambiguate.

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