Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_niagara_system_warmup_time

DestructiveIdempotent

Set a Niagara System asset's warmup time in seconds and save it, then read back the applied time and tick count to confirm any tick rounding.

Instructions

Set the warmup time in seconds of a Niagara System asset and save it; a failed save returns success false. With a non-zero warmup_tick_delta the engine rounds the time down to a whole number of ticks, so read new_warmup_time and warmup_tick_count back.

Returns: { system_path: string, old_warmup_time: number, new_warmup_time: number, warmup_tick_count: int, applied: bool, saved: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
system_pathYesNiagara System asset path, e.g. "/Game/FX/NS_Fire"; the call fails without it.
warmup_timeYesWarmup time in seconds (>= 0; 0 disables warmup); the call fails without it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.2.0
    • changedInput schema / properties / system_path / description
      Previous value: -"Asset path of the Niagara System."New value: +"Niagara System asset path, e.g. \"/Game/FX/NS_Fire\"; the call fails without it."
    • changedInput schema / properties / warmup_time / description
      Previous value: -"Warmup time in seconds (>= 0; pass 0 to disable warmup)."New value: +"Warmup time in seconds (>= 0; 0 disables warmup); the call fails without it."
    • addedInput schema / required
      Added value: +[
+  "system_path",
+  "warmup_time"
+]
  2. First observedv1.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is covered. The description adds real behavior beyond that: it saves the asset, a failed save surfaces as success=false, and non-zero tick deltas cause rounding to whole ticks, which is why the caller should re-read the new values.

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: action + save, the rounding caveat, then the return shape. It is front-loaded and wastes little, though the warmup_tick_delta aside is the one line that does not strictly belong in this tool's description.

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?

No output schema exists, but the description supplies the return object's fields and covers the failure mode and rounding side effect, which is what an agent needs for a two-parameter mutation. The missing piece is any guidance on choosing this tool over its warmup-tick siblings.

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% for both parameters, so the baseline is 3. The description does add one genuinely useful semantic — that warmup_time is rounded down to a whole number of ticks — but it also references warmup_tick_delta, which is not a parameter of this tool, so the net added value is modest and partly confusing.

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?

The description states a specific verb (set) and resource (a Niagara System asset's warmup time in seconds) and adds that it saves, which distinguishes it from the get_ and tick-count/tick-delta setters in the sibling list. The only wrinkle is the reference to 'warmup_tick_delta', which is a sibling tool's parameter, not this tool's, adding mild noise to an otherwise clear purpose.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the agent learns that with a non-zero tick delta the engine rounds down and it should read back new_warmup_time/warmup_tick_count, which suggests when this tool's outputs matter. There is no explicit when-to-use or when-to-prefer get_niagara_system_warmup_time / set_niagara_system_warmup_tick_count instead.

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