Skip to main content
Glama

get_landscape_height_at

Read-onlyIdempotent

Sample terrain height at a world coordinate to place actors, check water levels, or verify terrain flatness without collision or PIE.

Instructions

How high is the ground here: sample the terrain surface height (world Z) at one world (x, y) -- the tool for placing an actor on the terrain, checking a spawn point is above water, or proving a region is not flat. Reads the heightmap texture directly (FHeightmapAccessor + bilinear interpolation), so unlike raycast_scene it needs NO collision, NO PIE and no cooked physics: it answers in the editor world where a line trace just misses the landscape. Honest at the edges -- outside the extent it clamps to the nearest vertex and says in_bounds=false, and it reports the (col,row) vertex it sampled so you can verify the pixel-to-world mapping. Use export_landscape_heightmap instead when the question is about the WHOLE terrain (min/max, unfilled regions, did an import land): a handful of probes has repeatedly suggested flips and offsets that were not there.

Returns: { landscape_actor_name: string, x: number, y: number, height: number, vertex: [int, int], in_bounds: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoWorld-space X coordinate to sample
yNoWorld-space Y coordinate to sample
landscape_actor_nameNoOptional landscape actor name or label, defaults to first found

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds substantial behavioral context beyond them: it reads the heightmap texture directly (no collision, no PIE, no cooked physics), clamps outside extent and sets in_bounds=false, reports the sampled vertex for pixel-to-world verification. This is far more than the annotations convey.

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 the core question and operation, then supports it with use cases and contrast. It is fairly long but every clause earns its place; slightly verbose in the use-case list.

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, yet the description enumerates the return object (landscape_actor_name, x, y, height, vertex, in_bounds) and explains the edge-clamping semantics, so an agent has everything needed to call and interpret it.

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 baseline is 3. The description explains what (x, y) and the return fields mean (world coordinates, in_bounds, vertex), adding some interpretive value, but the parameter syntax is already fully documented in the schema.

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?

Specific verb+resource+scope: sample terrain surface height in world Z at (x, y). It explicitly names the use cases (placing an actor, checking spawn above water, proving a region isn't flat) and contrasts itself with raycast_scene and export_landscape_heightmap.

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?

Names two explicit alternatives with the conditions that select them: use raycast_scene for collision-based queries (and explains this tool works where a trace just misses), and use export_landscape_heightmap when the question concerns the WHOLE terrain rather than a handful of probes.

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