Skip to main content
Glama

set_reflection_capture_properties

DestructiveIdempotent

Set properties on a Sphere or Box reflection capture actor: adjust radius, transition distance, brightness, box scale, or assign a cubemap, then mark it dirty for recapture and read values back.

Instructions

Set properties on an existing reflection-capture actor (Sphere or Box). Dispatches by the actor's concrete capture-component class; a sphere-only param on a box (or vice versa) is a no-op and reports its _set=false. box_extent maps to the actor scale (the box capture has no extent UPROPERTY; its size derives from the transform scale). cubemap loads a UTextureCube by path and flips ReflectionSourceType to SpecifiedCubemap. Marks the capture dirty for recapture; reads every set property back.

Returns: { actor_name: string, actor_internal_name: string, capture_type: string, influence_radius_set: bool, influence_radius: number, box_transition_distance_set: bool, box_transition_distance: number, brightness_set: bool, brightness: number, box_extent_set: bool, box_extent: [number], cubemap_set: bool, cubemap: string, reflection_source_type: string, marked_dirty: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cubemapNoPath to a UTextureCube; assigning it sets ReflectionSourceType=SpecifiedCubemap
actor_nameYesLabel or internal name of the reflection-capture actor
box_extentNoBox capture extent as actor scale [X, Y, Z] (Box only; SetActorScale3D)
brightnessNoCapture Brightness multiplier (clamped to [0.5, 4])
influence_radiusNoSphere capture InfluenceRadius in cm (Sphere only)
box_transition_distanceNoBox capture BoxTransitionDistance (Box only)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: class-dispatch semantics, no-op reporting via <prop>_set=false, box_extent→actor-scale remapping, and the cubemap side effect that flips ReflectionSourceType to SpecifiedCubemap. It also notes the capture is marked dirty for recapture. It does not explain the destructiveHint=true (what prior state is overwritten), which is the one gap.

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 core purpose and the dispatch/no-op rule are front-loaded across tightly packed sentences with no filler. The Returns block is verbose, but since there is no output schema it earns its place by documenting the response shape.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, describing the full return object is valuable and done thoroughly; all six parameters are addressed and side effects disclosed. The only omission is the nature of the destructive operation implied by destructiveHint=true, which the agent would still have to infer.

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 schema already documents each param, establishing a baseline of 3. The description adds cross-parameter meaning the schema cannot: sphere-only vs box-only parameters becoming no-ops, box_extent mapping to SetActorScale3D rather than an extent property, and cubemap's reflection-source mutation.

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 ('Set properties on an existing reflection-capture actor (Sphere or Box)') and immediately scopes behavior by concrete capture-component class. It clearly distinguishes itself from read sibling get_reflection_capture_properties and the spawn_* siblings by emphasizing it operates on an *existing* actor.

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 how sphere-vs-box selection governs parameter applicability and explains that a mismatched param is a no-op rather than an error. It stops short of explicitly naming an alternative (e.g. get_reflection_capture_properties to inspect first), so it lacks the full when/when-not framing.

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