Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

create_lake_water_body

Spawn a Lake water body actor in Unreal Engine, optionally link it to a WaterZone, and read back the wave height the factory attached to verify the result.

Instructions

Spawn a Lake AWaterBody actor, optionally link to a WaterZone, and READ BACK the wave height the factory attached (a lake is born with the OCEAN's waves and nothing else reveals it).

Returns: { actor_label: string, actor_name: string, body_type: string, water_zone_label: string, linked_to_zone: bool, affects_landscape: bool, max_wave_height: number (RE-READ from UWaterBodyComponent::GetMaxWaveHeight() AFTER any disable_waves), max_wave_height_on_spawn: number (RE-READ as the factory left it), has_waves: bool, waves_disabled: bool, warning?: string (emitted when a lake was born with waves), requested: { actor_label, location, water_zone_label, affects_landscape, disable_waves } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
locationNoOptional [X, Y, Z] world location (defaults to origin)
actor_labelYesLabel to assign to the new water body actor
disable_wavesNoOPT-IN, default FALSE. Sets water_waves = None right after the spawn and RE-READS GetMaxWaveHeight() to prove it went to 0. Use it on any basin shallower than ~5 m: the engine's Lake factory attaches the ocean's wave asset (measured 508.125 uu = 5.08 m of crest), which on a pond a few meters deep breaks the water surface -- crest above the lip of the basin, trough below the bed -- with every property of the actor reading green.
water_zone_labelNoOptional label of an existing AWaterZone to auto-link the body to. If given and the zone is not found, `success` is FALSE (the body is still spawned; `linked_to_zone` says so).
affects_landscapeNoWhen true the body carves the existing landscape via the water landscape brush; defaults to FALSE (non-destructive)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4/5.0
Behavior4/5

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

With readOnlyHint=false, destructiveHint=false, and idempotentHint=false, the annotations give only a bare safety profile; the description meaningfully adds that this spawns an actor, can auto-link a zone, and that a lake is born carrying the ocean's wave asset (with a warning emitted). It stops short of stating persistence, permissions, or rate/response behavior, but the disclosure of the wave side-effect is genuinely useful context beyond annotations.

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-loads the action ('Spawn a Lake AWaterBody actor...') then a structured Returns block. It is dense and technical, but with no output schema the return enumeration earns its place; the parenthetical RE-READ explanations are verbose but informative rather than filler.

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, so the description must carry the return contract, and it does: full field list with types plus the max_wave_height / max_wave_height_on_spawn distinction and the optional warning. An agent has everything needed to call and interpret this creator.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already carries the parameter-level detail (location default, disable_waves opt-in with the shallow-basin rationale, zone-not-found failure, landscape carving). The description text itself adds little about parameter meaning, only restating that the zone link is optional, so the baseline 3 for full schema coverage is appropriate.

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+resource ('Spawn a Lake AWaterBody actor'), the optional secondary action (link to a WaterZone), and the read-back behavior, which cleanly separates it from sibling creators like create_ocean_water_body and create_river_water_body without needing their schemas.

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

Usage Guidelines3/5

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

The description implies the lake-spawning use case and explains the wave gotcha, but it never says explicitly when to choose this over the ocean/river body creators or what preconditions apply. Any when-to-use guidance (the shallow-basin rule) lives in the schema's parameter text rather than the description body, so usage is only implied.

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