Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_niagara_light_renderer

Adds a light renderer to a Niagara emitter with defaults for radius, falloff, translucency, and color shift, then compiles and saves the system.

Instructions

Add a NiagaraLightRendererProperties (UNiagaraLightRendererProperties) to a Niagara emitter with light-specific defaults applied via reflection. Companion to add_niagara_renderer with renderer_type='Light' — use this cmd when you want to seed light config (radius scale, falloff mode, affects-translucency, color add) in the same call. Then requests a system compile and saves.

Returns: { system_path, emitter_name, renderer_index, renderer_class, radius_scale, default_exponent, specular_scale, diffuse_scale, color_add:{}, renderer_count, save_error? }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
color_addNoOptional [r, g, b] static color shift.
system_pathYesAsset path of the Niagara System (e.g. "/Game/Niagara/NS_Example").
emitter_nameYesName of the emitter handle.
radius_scaleNoOptional float (default 1.0, ClampMin=0).
diffuse_scaleNoOptional float (default 1.0, ClampMin=0).
specular_scaleNoOptional float (default 1.0, ClampMin=0).
default_exponentNoOptional float (default 1.0, ClampMin=0); only used when use_inverse_squared_falloff=false.
allow_mega_lightsNoOptional bool (default false). True => MegaLights path (Lumen); see bMegaLightsCastShadows below.
affects_translucencyNoOptional bool (default true). Set false for cheaper lights that shouldn't bleed through translucent surfaces.
alpha_scales_brightnessNoOptional bool (default true). When true, particle color alpha modulates brightness.
mega_lights_cast_shadowsNoOptional bool (default false).
use_inverse_squared_falloffNoOptional bool (default true). True => UE physical light; false => use DefaultExponent below.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedInput schema / required
      Previous value: -[
-  "emitter_name"
-]New value: +[
+  "system_path",
+  "emitter_name"
+]
  2. First observedv1.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations declare the write/safe/non-idempotent profile, and the description adds side effects the annotations do not cover: it requests a system compile and saves, and applies defaults via reflection. It does not spell out duplicate-add behavior or required permissions, but the extra side-effect disclosure is real value beyond the structured fields.

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 action, then the sibling relationship, then side effects and an inline return shape. It is dense but every clause carries information; the inline Returns block is somewhat list-like but justified because no output schema exists.

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?

For a 12-parameter mutation with no output schema, the description covers the action, the alternative, the side effects, and the return fields. Nothing critical for correct invocation is obviously missing, though duplicate-invocation semantics and failure modes are left implicit.

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 12 parameters are already documented, including defaults and ClampMin values. The description only echoes a subset of parameter names (radius scale, falloff mode, affects-translucency, color add) without adding syntax or format meaning, so the 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?

Names a specific verb and resource (add NiagaraLightRendererProperties to a Niagara emitter) and immediately differentiates itself from its closest sibling by naming add_niagara_renderer with renderer_type='Light'. An agent can tell which add_niagara_* renderer tool to pick without opening any 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?

Gives an explicit selection rule: use this cmd instead of add_niagara_renderer when you want to seed light config (radius scale, falloff, affects-translucency, color add) in the same call. The alternative and the condition that selects it are both stated.

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