Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_niagara_renderer

Adds a new renderer (Sprite, Ribbon, Mesh, or Light) to a Niagara emitter, optionally sets its material, then compiles and saves the system.

Instructions

Add a new renderer (Sprite / Ribbon / Mesh / Light) to a Niagara emitter. Creates a UNiagaraRendererProperties instance of the requested concrete class (Sprite / Ribbon / Mesh / Light), optionally sets the Material UPROPERTY, and appends it to the emitter's RendererProperties array. Then requests a system compile and saves the asset.

Returns: { system_path: string, emitter_name: string, renderer_type: string, renderer_class: string, renderer_index: int, material_path: string, renderer_count: int, save_error?: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
system_pathYesAsset path of the Niagara System (e.g. "/Game/Niagara/NS_Example").
emitter_nameYesName of the emitter handle (the human-readable name in the system's emitter list).
material_pathNoOptional asset path; sets the renderer's Material property. If omitted, the renderer is added with a null material (still a valid empty renderer).
renderer_typeYesOne of "Sprite" / "Ribbon" / "Mesh" / "Light" (case-insensitive).

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only write, but the description goes further by disclosing the actual side effects: creating a UNiagaraRendererProperties instance, appending to the RendererProperties array, issuing a system compile, and saving the asset. It also surfaces a save_error field, implicitly warning that the save step can fail. It stops short of stating permissions, whether the compile is blocking, or whether the mutation is reversible.

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?

Three tight sentences front-load the mutation, then the compile/save side effect, then the return shape. The explicit Returns block is justified given there is no output schema. Minimal waste, though the renderer-type list is repeated twice within the first sentence.

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, the description correctly compensates by documenting the full return object, and it covers the write + compile + save pipeline that an agent must anticipate. The only meaningful omission is any statement of how this tool relates to its overlapping siblings, which is the remaining completeness gap for a mutation tool in a dense toolset.

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 coverage is 100%, so the schema already documents all four parameters in detail (including the renderer_type value set and the null-material fallback). The description's mention of Sprite/Ribbon/Mesh/Light and the optional Material UPROPERTY largely restates the schema, adding no format or constraint detail beyond it. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Add a new renderer ... to a Niagara emitter') and enumerates the concrete renderer classes (Sprite/Ribbon/Mesh/Light), so the action is unambiguous. However, it never differentiates itself from siblings that overlap in scope - notably add_niagara_light_renderer (which appears to do the same thing as renderer_type="Light") and add_niagara_decal_renderer - leaving the agent to guess which entry point to use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description describes what happens mechanically but gives no when-to-use guidance, no prerequisites beyond the parameter names, and no exclusions. With overlapping siblings like add_niagara_light_renderer and add_niagara_decal_renderer, the absence of any routing guidance is a real gap rather than a minor omission.

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