Skip to main content
Glama

get_world_settings_detail

Read-onlyIdempotent

Read a world's gravity, KillZ, bounds checks, and time dilation to verify physics settings, distinguishing editor-authored values from the running PIE, server, or client session.

Instructions

Read a world's physics/bounds side of WorldSettings: GlobalGravityZ plus the override flag AND the effective GetGravityZ, KillZ and its damage type, enable_world_bounds_checks, world_to_meters, time dilation, default GameMode and force_no_precomputed_lighting. This is the read-back for set_world_gravity / set_kill_z, and the place that tells you whether world-bounds checks are even on; use get_world_settings instead for the GameMode/pawn/PlayerController/HUD wiring. World-aware: world='editor' (default -- and it is the EDITOR world that set_world_gravity/set_kill_z actually write) | 'server' | 'client' | 'pie:N' | 'pie' read the RUNNING duplicate instead, which is how you tell "the map is authored with this gravity" apart from "the session is running with it".

Returns: { world: string, world_name: string, global_gravity_z: number, global_gravity_set: bool, effective_gravity_z: number, kill_z: number, kill_z_damage_type: string, enable_world_bounds_checks: bool, world_to_meters: number, time_dilation: number, default_game_mode: string, force_no_precomputed_lighting: bool, world_package: string|null, world_type: string|null, net_mode: string|null, pie_instance: number }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
worldNoOptional world selector: absent/'editor' (default -- the world set_world_gravity and set_kill_z write, so this is their read-back) | 'server' | 'client' | 'pie:N' | 'pie' (ambiguous) | 'game' (alias of 'pie') read the live PIE duplicate. An unrecognised value FAILS naming the worlds that exist; it never falls back to another world in silence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: an unrecognised world value fails loudly and never silently falls back, and the editor-vs-PIE distinction explains that setters write the editor world while 'pie' reads the running duplicate.

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?

Front-loaded with what is read, then routing guidance, then world semantics, then a full return-type listing. Dense and largely waste-free, though the returns enumeration makes it long; every clause still carries information.

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?

No output schema exists, and the description compensates by fully enumerating the returned fields. Combined with annotations and the world-selector discussion, an agent has everything needed to call and interpret this tool correctly.

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?

Schema coverage is 100% on a single parameter, so the baseline is 3. The description exceeds it by explaining the default's relationship to the setters and the authored-vs-running semantics of each selector value, adding meaning beyond the schema's enumeration.

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?

States a specific verb and resource ('Read a world's physics/bounds side of WorldSettings') and enumerates exactly which fields it exposes. It explicitly distinguishes itself from the sibling get_world_settings, which handles the GameMode/pawn/PC/HUD wiring.

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

Usage Guidelines5/5

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

Explicitly names the alternative ('use get_world_settings instead for the GameMode/pawn/PlayerController/HUD wiring') and its condition. It also tells the agent when the editor vs PIE world is the right read, and identifies set_world_gravity/set_kill_z as the write counterparts this reads back.

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