Skip to main content
Glama

call_object_method

Destructive

Invoke a UFUNCTION on any UObject, not just level actors, including components, CDOs, assets, and live PIE subobjects. Choose server or client with a world selector.

Instructions

Invoke a UFUNCTION on ANY UObject — component archetype, class default object, asset, or a LIVE PIE subobject — not just level actors, and unlike call_function it takes a world selector so the same method can be driven on the server or on a client and the response stamps which world ran it. Arguments go in a dict named args_json (call_function uses parameters, call_component_function uses params); it marshals scalars, ENUM by entry name, STRUCT as a JSON object, ARRAY/set as a JSON array, FGameplayTag (validated) and FGuid, and reports return_value plus out_params typed. Use call_component_function instead when the target is a component you would otherwise have to path by hand, and call_library_function for a static library call. transact=true makes an editor-world write undoable and dirties the owning (OFPA) package; it is refused for pure functions and for PIE targets.

Returns: { success: bool, object_path: string, function_name: string, world: string, returns_json: object ({ return_value?: any, out_params?: object }), 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), world_name: string|null, world_package: string|null, world_type: string|null, net_mode: string|null, pie_instance: number }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
worldNoOptional world selector (takes precedence over use_pie_world): absent/'editor' (default) | 'pie' (ambiguous: PlayWorld, else the first PIE context) | 'server' (the PIE world with authority) | 'client' | 'pie:N' | 'game' (alias of 'pie').
paramsNoAlias of `args_json` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `args_json`.
transactNoOptional (default false). Wrap the invocation in an FScopedTransaction and Modify() the target (and, for a component, its owner) first, so the write is undoable AND dirties the owning package — without it a write into an OFPA actor is never saved even though save_level reports success. REFUSED for pure/const functions and for PIE-world targets.
args_jsonNoOptional {param_name: value} dict. Same marshaling as call_function: scalars map directly; ENUM by entry name string; STRUCT param as a JSON object; ARRAY/set as a JSON array; FGameplayTag as {"TagName":"A.B"}.
parametersNoAlias of `args_json` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `args_json`.
object_pathYesPath or name of the object; resolved in the editor world by default, or in the PIE world when use_pie_world=true (full/PIE path, or dotted Actor[.Component[.Subobject]] by name/label).
function_nameYesName of the function to call.
use_pie_worldNoOptional (default false). Resolve object_path in the running PIE world instead of the editor world. Equivalent to world='pie'; `world` wins when both are given.

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?

Annotations already flag destructiveHint=true/readOnlyHint=false, but the description goes further: transact=true wraps an FScopedTransaction, dirties the OFPA package, and is REFUSED for pure functions and PIE targets; the response stamps which world ran it. That is exactly the mutation-safety context an agent needs and it is not derivable from annotations.

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 purpose, then routes to siblings, then semantics, then returns. Every sentence is substantive, but the description is dense and would benefit from tighter grouping; the long enumerated return-shape sentence is lengthy yet justified given there is no output schema.

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?

With 8 parameters, nested objects, and no output schema, the description compensates by spelling out the full return shape including transaction, verification and world_* fields, plus the transact refusal conditions. An agent has everything needed to call this correctly and interpret the result.

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 already documents each parameter. The description adds cross-tool context the schema cannot: why the arg dict is named args_json while siblings use parameters/params, and which value types are marshaled. Marginal but genuine added meaning.

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?

The description states a specific verb+resource (invoke a UFUNCTION on a UObject) and immediately scopes it against the obvious assumption ('not just level actors'), naming the exact target classes (archetype, CDO, asset, live PIE subobject). It distinguishes itself from call_function, call_component_function and call_library_function in the same paragraph.

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 routing rules: use call_component_function 'instead when the target is a component you would otherwise have to path by hand', call_library_function for static library calls, and call_function as the base case. It also documents when world='pie'/'server'/'client' should be selected. This is when-to-use/when-not coverage with named alternatives.

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