Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_custom_event_node

Idempotent

Create a new custom event node in a Blueprint event graph to serve as an entry point, then compile it. Re-adding the same name returns the existing node to prevent duplicate function errors.

Instructions

Add a NEW Custom Event node (an entry point you invent, not an override of anything) and compile. Idempotent by name: an existing custom event with that name in the graph is returned with already_existed:true, because re-adding one compiles into "more than one function with the same name" and breaks the Blueprint. HARD LIMIT: a custom event cannot be given PARAMETERS -- add_function_parameter answers "Function graph not found" and there is no other route -- so anything that needs arguments (an RPC in particular) must be a function instead. To override an inherited/interface event use override_interface_member.

Returns: { node_id, class, title, pins:[...], blueprint_name, graph_name, event_name, node_title, already_existed } -- the node WITH its pins ('then' and the delegate output), ready for connect_pins. already_existed is only present when an existing event was reused.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoOptional. This command is REFUSED while a Play-in-Editor session is running: it either compiles a Blueprint (the reinstancer can retain a world, and CheckForWorldGCLeaks is Fatal -- it KILLS the editor) or writes to disk (Editor.AllowSavingAssetsDuringPIE=0 makes the engine refuse the write, so it would report success without writing a byte). Stop PIE and retry instead; force=true runs it anyway, at your own risk.
event_nameYesName for the custom event (becomes CustomFunctionName). Must not collide with an overridable inherited function or lint_blueprint_graph flags it as custom_event_shadowing_override.
graph_nameNoTarget graph name; defaults to the Blueprint's event graph when omitted
position_xNoNode X position on the graph canvas (ignored when node_position is set)
position_yNoNode Y position on the graph canvas (ignored when node_position is set)
node_positionNoNode canvas position as [x, y]; takes precedence over position_x/position_y
blueprint_nameNoName (or full object path) of the Blueprint.
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare idempotentHint and destructiveHint=false, but the description goes well beyond: it explains the idempotency mechanism (already_existed:true, name collision breaking compilation as 'more than one function with the same name'), the hard parameter limitation, and the PIE compile hazard. This is rich behavioral context beyond 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 core action and well organized into purpose, idempotency, hard limit, routing, and return shape. It is dense and long, but nearly every sentence earns its place by stating a real constraint.

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

Completeness5/5

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

No output schema exists, and the description compensates by enumerating the return fields (node_id, class, pins, already_existed, etc.) and noting pins are ready for connect_pins. Combined with the routing and limits, an agent has everything needed to call and consume the result.

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%, including the detailed PIE/force semantics, so the schema carries the parameter burden. The description adds the constraint that a custom event cannot take parameters, which is behavioral rather than parameter-syntax detail. Baseline 3 is correct when the schema already documents every parameter.

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+resource ('Add a NEW Custom Event node') and immediately scopes it as an entry point you invent, not an override. It explicitly distinguishes itself from override_interface_member and function, so an agent can tell it apart from siblings without opening schemas.

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?

Explicitly routes the agent: use a function if arguments are needed (an RPC in particular), and use override_interface_member to override an inherited/interface event. It also warns not to re-add an existing name. Nothing is left to inference.

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