Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_directional_light_cascade_settings

DestructiveIdempotent

Configure Cascaded Shadow Map parameters on a directional light, such as cascade count and fadeout, with partial updates. Errors if not a directional light.

Instructions

Configure Cascaded Shadow Map (CSM) settings on a directional light: dynamic shadow distance (movable/stationary), cascade count, distribution exponent, transition fraction, distance-fadeout fraction, and per-object inset shadows for movable objects. Partial update (idempotent): only fields present are written; the engine setters auto-dedup, and the inset-shadows bit (no setter) is guarded by hand. Errors honestly if the actor is not a directional light. Verify by read-back (every field is echoed) or via get_directional_light_cascade_settings.

Returns: { light_name, light_subtype, settings_applied: {...}, applied_count, dynamic_shadow_distance_movable, dynamic_shadow_distance_stationary, num_dynamic_shadow_cascades, cascade_distribution_exponent, cascade_transition_fraction, shadow_distance_fadeout_fraction, use_inset_shadows_for_movable_objects }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
light_nameYesName of the directional light actor to modify
cascade_transition_fractionNoProportion of the blended fade region between cascades (0 = hard transitions)
num_dynamic_shadow_cascadesNoNumber of cascades the view frustum is split into for the whole-scene dynamic shadow
cascade_distribution_exponentNoDistributes cascades closer (larger) or farther (smaller) from the camera
dynamic_shadow_distance_movableNoHow far CSM dynamic shadows cover for a movable light, measured from the camera (0 disables)
shadow_distance_fadeout_fractionNoSize of the fade-out region at the far extent of the dynamic shadow, as a fraction of the shadow distance
dynamic_shadow_distance_stationaryNoHow far CSM dynamic shadows cover for a stationary light, measured from the camera (0 disables)
use_inset_shadows_for_movable_objectsNoStationary lights: use per-object inset shadows for movable components even though CSM is enabled

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: partial-update semantics, engine setter auto-dedup, a hand-guarded inset-shadows bit with no setter, and honest erroring on non-directional-light actors, plus echoed read-back for verification. This meaningfully supplements the idempotent/destructive/readOnly hints.

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 core purpose and is information-dense, though the closing Returns block re-lists field names already enumerated at the start. Given no output schema exists, that echo earns its place but could be tighter.

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 explicit Returns block fully describes the response shape, and the description covers error behavior, partial-update semantics, and both verification paths. Nothing needed to invoke it correctly is missing.

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 all eight parameters are already documented in the schema; the description simply re-groups the same fields (movable/stationary pairs) without adding syntax, ranges, or units beyond what the schema states. Baseline 3 applies.

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 (Configure) and resource (Cascaded Shadow Map settings on a directional light), then enumerates exactly which settings are affected. It also names the sibling get_directional_light_cascade_settings for reading the same values, so an agent can distinguish it from other light tools 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 Guidelines4/5

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

Gives clear context for when it applies (directional light only, partial/idempotent update) and how to verify results via read-back or the named getter. It stops short of naming alternative setters such as configure_light_shadows or set_light_properties, so it doesn't fully delimit the choice among siblings.

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