Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

raycast_scene

Read-onlyIdempotent

Trace the world to get real JSON hit results (actor, component, impact point, normal, distance) without parsing export text. Specify a world context for accurate collision checks.

Instructions

Line trace / raycast the world and get a REAL JSON hit result -- what actor and component was hit, impact point, normal and distance -- instead of the UE export-text FHitResult blob that call_function on a line-trace UFUNCTION returns, so no Python parsing is needed. Accepts a world selector (editor / server / client / pie:N), which matters twice: an EDITOR-world trace does not hit World-Partition/OFPA actor collision (only cooked in the PIE physics scene) and reads as a clean miss, and in co-op a miss on the client world looks identical to a missing collider -- pass "server" or "pie:N" so a hit:false is interpretable. Also the honest way to prove a custom collision CHANNEL blocks: trace the same segment on a known-good channel (Visibility) and on the new one and compare actor/component/Z/distance, because get_collision_profile does not see +EditProfiles overrides.

Returns: { hit: bool, blocking_hit: bool, actor_path: string, actor_name: string, component_name: string, location: {x,y,z}, impact_point: {x,y,z}, normal: {x,y,z}, impact_normal: {x,y,z}, distance: float, bone_name: string, physical_material: string, face_index: 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
endYesWorld-space [x, y, z] trace end
startYesWorld-space [x, y, z] trace start
worldNoWhich world to trace: absent/"editor" (default) | "server" (the PIE world with authority) | "client" | "pie:N" | "pie" (ambiguous: PlayWorld, else the first PIE context) | "game" (alias of "pie"). Editor-world traces do NOT hit World-Partition/OFPA actors, so pass a live world to verify obstacle collision; with 2+ PIE instances prefer "server"/"pie:N".
ignore_actorsNoActor names/labels to exclude from the trace.
trace_channelNoCollision channel, canonical ("ECC_Visibility") or friendly ("Visibility", "Camera", or a custom channel name). Defaults to "Visibility". A channel created THIS session is not in the live profile table yet -- restart the editor before trusting a trace on it.
trace_complexNoTest against complex (per-poly) collision instead of simple. Defaults to false.
return_physical_materialNoPopulate physical_material in the result. Defaults to false.

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 the safety profile is covered. The description still adds real behavioral context beyond them: editor-world traces silently miss World-Partition/OFPA collision and read as a clean miss, client-world misses are ambiguous in co-op, and a channel created this session isn't in the live profile table until restart. It omits pagination/auth concerns, but those are largely N/A for a synchronous trace.

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 is front-loaded in the first sentence and the Returns block is informative. However, the 'Accepts a `world` selector...' sentence is a long paragraph that partially restates the schema's world description, so a small amount of the text does not earn its place.

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 enumerates the full return payload field-by-field and documents the world/type/net_mode metadata, plus the interpretive caveats needed to read hit:false correctly. For a 7-parameter trace tool this is as complete as an agent needs.

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% and the schema's own parameter descriptions already carry the editor-vs-PIE and channel-restart caveats, so the description earns only modest extra credit. What it does add is interpretive framing for how parameter choices change result meaning (a miss being 'interpretable', comparing two channel traces), which goes slightly beyond the raw schema text.

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?

The opening states a specific verb+resource ('Line trace / raycast the world') and the concrete payoff ('get a REAL JSON hit result'), then explicitly contrasts it with the sibling call_function path on a line-trace UFUNCTION and the FHitResult text blob. An agent can distinguish this from call_function without opening either 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?

It names the alternative (call_function on a line-trace UFUNCTION) and the condition that selects this tool, gives when-to-use guidance for the world selector ('pass "server" or "pie:N" so a hit:false is interpretable'), and supplies a concrete verification workflow against get_collision_profile's gap on +EditProfiles overrides. This is explicit when/when-not/routing content.

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