Skip to main content
Glama

call_function

Destructive

Invoke a UFUNCTION on an editor-world object instance, passing typed parameters and returning typed return values and out-params. Use it for BlueprintCallable or BlueprintEvent functions.

Instructions

Invoke a UFUNCTION on an object instance in the EDITOR world and get its return value and out-params back typed. Arguments go in a dict named parameters (each sibling uses a DIFFERENT key — call_object_method uses args_json, call_component_function uses params — and an unknown key is a hard error, so read the signature with get_function_info first). Marshals scalars, ENUM by entry name, Blueprint STRUCTs as JSON objects, ARRAY/set as JSON arrays, FGameplayTag (validated against the registry) and FGuid. Choose call_object_method to reach a CDO/archetype/live PIE subobject or to pass world, call_component_function to hit a component without hand-building its path, and call_library_function for a static/library call with no instance at all. Only BlueprintCallable+Public or BlueprintEvent functions are callable; pass transact=true to make the write undoable and actually dirty an OFPA package.

Returns: { object_path: string, function_name: string, success: bool, message: string, return_value: any (typed: bool/number/string natively, struct/map as object, array/set as array, object-ref as path string), out_params: object (same typed values), transaction?: { requested, modified: [path], saved_to_transaction_buffer, is_package_external, package_name, package_file, package_file_exists, package_dirty_before, package_dirty_after }, verification?: object (only when transact=true) }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNoAlias of `parameters` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `parameters`.
paramsNoAlias of `parameters` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `parameters`.
transactNoOptional (default false). When true, wrap the invocation in an FScopedTransaction and Modify() the target (and, for a component, its owner) BEFORE calling, so whatever the function writes is undoable AND marks the owning package dirty. Without this, a CallInEditor-style function that fills state on a World Partition (OFPA) actor leaves the package clean and save_level reports success while writing nothing. REFUSED for pure/const functions and for PIE-world targets (both would only produce a false-positive dirty flag).
args_jsonNoAlias of `parameters` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `parameters`.
parametersNoOptional {param_name: value} dict. Scalars map directly; pass an ENUM by its entry name as a string (e.g. "Harvest"); pass a STRUCT param as a JSON object {Field: val, ...} and an ARRAY/set as a JSON array (nativized via FJsonObjectConverter — nested structs + enum-by-name inside structs supported; JSON keys match the field's authored name). A UE-format text string (e.g. "(X=1,Y=2,Z=3)") is also accepted for structs.
object_pathYesPath or name of the object instance, resolved in the EDITOR world: full object path, asset path, CDO/archetype, or a dotted "Actor[.Component[.Subobject]]" whose first segment is the actor's internal name. This command has NO `world` parameter — use call_object_method for a live PIE target.
function_nameYesName of the function to call, exactly as declared (a Blueprint graph named "Add Item" keeps its spaces)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations mark it non-read-only and destructive; the description goes far beyond that, disclosing hard-error on unknown keys, marshaling rules (scalars/enum/struct/array/gameplay tag/guid), that only BlueprintCallable+Public or BlueprintEvent functions are callable, that transact=true makes writes undoable and dirties an OFPA package, and when transact is refused (pure/const, PIE targets).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and the sibling routing well, but the description is long and dense with parenthetical asides (keys, transact refusal conditions) that make it slower to scan than needed for the amount of content.

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?

Given a 7-parameter mutation tool with no output schema, the description covers argument marshaling, function eligibility, error behavior, sibling alternatives, and the transact write/undo caveat, plus the full return shape, leaving nothing essential unstated.

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 description coverage is 100%, so the baseline is 3; the description still adds value by naming the `parameters` dict, explaining alternate argument keys, the get_function_info prerequisite, and the transact semantics and refusals that go beyond the schema's own phrasing.

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: invoke a UFUNCTION on an object instance in the EDITOR world, returning typed values. It explicitly distinguishes itself from its three closest siblings (call_object_method, call_component_function, call_library_function) by naming the scenarios each covers.

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?

Explicit when-to-use guidance: choose call_object_method for CDO/archetype/PIE subobjects or to pass `world`, call_component_function to hit a component without hand-building a path, call_library_function for static/library calls. Also states a prerequisite (read the signature with get_function_info first) and notes the argument-key hazard and available function types.

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