Skip to main content
Glama
Sign In
godot-omni

godot-omni

by bebabinlarsson-blip
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

world_manage

Configure Godot WorldEnvironment resources: create procedural or panorama skies, enable volumetric fog, adjust camera attributes, and inspect active post-processing settings.

Instructions

WorldEnvironment, Sky, and Post-Processing Management.

Ops:

  • configure_world_environment(node_path="", properties={}) Configure properties of WorldEnvironment and its Environment resource.

  • create_sky_material(node_path="", sky_type="procedural", sky_top_color="", ground_bottom_color="", texture_path="") Create and assign procedural or panorama sky material to Environment.

  • set_volumetric_fog(node_path="", enabled=True, density=None, albedo=None, emission=None, anisotropy=None, length=None) Enable and configure volumetric fog parameters on Environment.

  • configure_camera_attributes(node_path="", attribute_type="practical", properties={}) Configure CameraAttributesPractical or CameraAttributesPhysical.

  • get_world_info(node_path="") Inspect active world environment, fog, sky, and post-processing settings.

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "op": "<op>"
    },
    "name": "world_manage"
  }
}

Input Schema

NameRequiredDescriptionDefault
opYes
paramsNo
session_idNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv5.0.28

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits. It mentions actions like 'Create and assign' and 'Enable and configure,' implying modification, but does not state side effects, required permissions, or reversibility. It also does not explain what happens if node_path is empty or whether changes are immediately applied to the scene. This is insufficient for a tool that mutates environment settings.

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 well-structured with a clear header and a bulleted list of operations, making it easy to scan. It front-loads the domain and then details each op. The canonical call shape note adds value without redundancy. While lengthy, the detail is necessary given the multiple operations and their parameters.

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 the main operations but omits crucial context such as whether a WorldEnvironment node must already exist, how node_path resolves, and what the output schema provides. Since an output schema exists (not shown here), the description need not explain return values, but it should clarify prerequisites and edge cases. It is adequate for basic use but lacks depth for robust agent decision-making.

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 input schema is highly generic (op, params, session_id) with 0% description coverage, so the description must compensate. It does so by listing each operation's specific parameters with defaults, e.g., 'create_sky_material(node_path="", sky_type="procedural", ...)'. This provides the agent with necessary parameter meaning that the schema lacks, though it could be more explicit about parameter types and allowed values.

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 clearly states the domain ('WorldEnvironment, Sky, and Post-Processing Management') and enumerates specific operations with concise summaries, such as 'Configure properties of WorldEnvironment and its Environment resource.' It distinguishes from siblings like camera_manage by focusing on world environment attributes, though it doesn't explicitly state what it does not cover. Overall, the purpose is specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives like camera_manage or rendering_manage. It lists operations but does not state conditions, prerequisites, or when to prefer this tool. The only usage note is about the canonical call shape, which is about invocation syntax, not usage context. This leaves the agent without clear direction on selecting this tool.

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