Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

get_niagara_event_handlers

Read-onlyIdempotent

List a Niagara emitter's event handlers and their properties, such as usage IDs, source events, execution modes, and spawn/event counts, to inspect or remove them.

Instructions

List a Niagara emitter's event handlers and their properties. Reads FVersionedNiagaraEmitterData::GetEventHandlers(); each entry reports its usage_id (the remove key), source_event_name, execution_mode, spawn/event counts and source_emitter_id.

Returns: { system_path: string, emitter_name: string, event_handler_count: int, event_handlers: [{usage_id, source_event_name, execution_mode, spawn_number, max_events_per_frame, min_spawn_number, random_spawn_number, source_emitter_id, has_script}] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
system_pathYesAsset path of the Niagara System.
emitter_nameYesDisplay name of the emitter handle within the system.

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

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine non-annotation context: the exact engine function read and the enumerated fields returned, including that usage_id is the removal key. It stops short of auth/permission or pagination notes, but for a read tool this is solid added value.

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 purpose in the first sentence, followed by implementation detail and a structured Returns block. The prose 'spawn/event counts' is somewhat redundant with the field list that follows, but the overall layout is efficient and well-ordered.

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 compensates by giving a full return shape inline (count plus per-entry fields), so an agent knows what to expect. The only minor gap is that nested structure is asserted but the coverage is sufficient for a 2-parameter read tool.

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 system_path and emitter_name are already documented as asset path and emitter handle name. The description adds no parameter syntax or format detail beyond the schema, 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?

States a specific verb and resource ('List a Niagara emitter's event handlers') and even names the underlying API call (FVersionedNiagaraEmitterData::GetEventHandlers). This is clearly distinguishable from sibling add/remove_niagara_event_handler and get_niagara_emitter_handles 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 Guidelines3/5

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

There is no explicit when-to-use statement or exclusion, but the parenthetical '(the remove key)' implicitly routes the agent to remove_niagara_event_handler for the returned usage_id. Usage is implied rather than spelled out.

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