Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_function_parameter

Add an input or output parameter to an existing Blueprint function graph and rebuild its Entry/Result node to update the function signature.

Instructions

Add an input or output (return) parameter to an existing Blueprint FUNCTION graph -- interface-override graphs included -- and reconstruct its Entry/Result node. TWO HARD LIMITS, both silent-ish: it cannot create an ARRAY parameter (there is no is_array; the param comes out SCALAR with success), so redesign the signature to read the array where it lives; and it cannot reach a CUSTOM EVENT ("Function graph not found"), so a Server/Client RPC WITH arguments must be authored as a function plus set_bp_function_rpc. On a Blueprint just given a new function, compile_blueprint between creation and this call.

Returns: { blueprint_name, function_name, param_name, param_type, is_output } -- param_name is the pin name actually created (uniquified). Verify with get_graph_nodes at compact=false: compact hides the new, still-unlinked pin and makes it look like nothing was created.

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.
is_outputNoWhen true, add an output/return param (an input pin on the Result node) instead of an input; defaults to false
param_nameYesNew parameter name; made unique, so the applied name is the one echoed back in the response.
param_typeYesType string: bool, int, int64, float, string, name, text, byte, Vector, or a struct/enum/class/object name or path. Arrays are NOT expressible.
function_nameYesName of an existing function graph (FunctionGraphs or an interface-override graph). A custom event is NOT a function graph and is rejected here.
blueprint_nameNoBlueprint name or path.
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.8/5.0
Behavior5/5

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

With annotations limited to readOnlyHint=false, destructiveHint=false, idempotentHint=false, the description carries substantial extra context: the PIE refusal reason (world-GC fatality / silent no-write), the silent-scalar array failure, the confusing custom-event error, and the non-obvious verification gotcha that compact mode hides the new unlinked pin. This is behavioral detail well beyond what the annotations reveal.

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?

It is dense but front-loaded, leading with the core action before the limits. Some sentences are heavily nested with parentheticals, which slightly taxes readability, but almost every clause conveys non-obvious constraint information rather than filler.

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?

For a mutation tool with no output schema, the description supplies the exact return shape, the silent-failure modes, the PIE precondition, and the verification step, so an agent has everything needed to call and confirm success.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema documents each parameter, but the description adds meaning beyond it: it explains the uniquification of param_name (applied name is echoed back), the type-string constraint that arrays are not expressible, and the risk profile of force in PIE. It stops short of syntax examples, so not a 5.

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 precise verb (add) and resource (input/output parameter) scoped to an existing Blueprint FUNCTION graph, and explicitly includes interface-override graphs and the Entry/Result reconstruction side effect. This clearly differentiates it from siblings like rename_function_parameter, add_blueprint_variable, and add_function_local_variable.

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 explicit when/when-not guidance: it cannot take an ARRAY parameter, it cannot reach a CUSTOM EVENT ('Function graph not found'), and RPCs with arguments must be authored as a function plus set_bp_function_rpc instead. It even prescribes sequencing (compile_blueprint between function creation and this call), which is actionable routing information.

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