Skip to main content
Glama

overlap_scene

Read-onlyIdempotent

Query sphere, box, or capsule overlaps in an Unreal world to find actors and components inside a volume, returning JSON for proximity checks like water containment or blocked build spots.

Instructions

Sphere / box / capsule overlap query against the world: "what is inside this volume?", returning one JSON entry per overlapping actor+component instead of export-text, so no Python is needed to parse it. Use it over raycast_scene when the question is proximity/containment rather than line of sight -- e.g. is the pawn actually inside a water body's real collision, is anything blocking a build spot. Accepts the same world selector (editor / server / client / pie:N): an editor-world query does NOT see World-Partition/OFPA actor collision, so pass a live PIE world, and in co-op say WHICH one or an empty result is uninterpretable.

Returns: { overlaps: [{actor_path, actor_name, component_name, item_index, blocking}], count: int, world: string, world_name: string|null, world_package: string|null, world_type: string|null, net_mode: string|null, pie_instance: number }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
shapeYes"sphere" | "box" | "capsule"
worldNoWhich world to query: absent/"editor" (default) | "server" (the PIE world with authority) | "client" | "pie:N" | "pie" (ambiguous) | "game" (alias of "pie"). Pass a live world to hit World-Partition/OFPA actor collision (only cooked in the PIE physics scene).
radiusYesSphere/capsule radius (required for those shapes)
locationYesWorld-space [x, y, z] shape center
half_extentNoBox HALF-extent [x, y, z], not the full size (required for box)
half_heightYesCapsule half-height (required for capsule)
ignore_actorsNoActor names/labels to exclude from the overlap.
trace_channelNoCollision channel, canonical ("ECC_Visibility") or friendly ("Visibility"). Defaults to "Visibility".

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 readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: editor-world queries do not see World-Partition/OFPA collision, co-op results are ambiguous unless you name the world, and it returns structured JSON rather than export-text. That is strong added value, though it stops short of discussing rate limits or performance cost of the query.

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 purpose and the raycast_scene contrast are front-loaded, and each sentence carries distinct information (usage rule, world caveat, return shape). The inline returns block is long, but since no output schema exists it earns its place; the description is dense rather than padded.

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?

With no output schema, the description correctly supplies the return structure (overlaps array fields, count, world metadata), and 100% of parameters are documented in the schema. For a read-only query tool whose annotations cover safety, nothing an agent needs to call it correctly is missing.

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%, so the baseline is 3, but the description meaningfully elaborates the `world` selector (editor vs server vs client vs pie:N) and why it matters, which is the most error-prone parameter. It does not add syntax detail for the shape/geometry params beyond the schema, so it is not a full 5.

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 ('overlap query against the world') plus the shape support (sphere/box/capsule) and the exact question it answers. It explicitly differentiates itself from the sibling raycast_scene, so an agent can route between them without opening a schema.

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 the alternative ('Use it over raycast_scene when...') and gives the selecting condition (proximity/containment vs line of sight) with concrete examples (inside a water body's collision, blocking a build spot). It also states when to pass a live PIE world and the co-op caveat, leaving little to inference.

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