Skip to main content
Glama

call_library_function

Destructive

Invoke a static or BlueprintCallable function on a class's Class Default Object using the class name or Blueprint path. Use for UKismetSystemLibrary, UGameplayStatics, etc. when no instance exists.

Instructions

Invoke a static / BlueprintCallable library function on a class's Class Default Object, addressing the class by NAME or by Blueprint asset path so you never have to hand-build a "Default__X_C" object path. This is the way to reach UKismetSystemLibrary, UGameplayStatics, UGameplayTagLibrary and any Blueprint Function Library when there is no instance to talk to. Arguments go in a dict named parameters (call_object_method uses args_json, call_component_function uses params), with the same marshaling: scalars, ENUM by entry name, STRUCT as a JSON object, ARRAY/set as a JSON array, FGameplayTag (validated) and FGuid. Note it always runs on the CDO and takes no world selector — use call_object_method(world=...) or call_component_function(world=...) for anything that must run inside a live PIE world.

Returns: { success: bool, class_name: string, class_path: string, function_name: string, returns_json: object ({ return_value?: any, out_params?: object }) }

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`.
args_jsonNoAlias of `parameters` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `parameters`.
class_nameYesClass NAME (bare/native e.g. "KismetSystemLibrary", /Script path, or a Blueprint asset path — resolved via ResolveClass; a Blueprint path yields its GeneratedClass). The function is invoked on this class's Class Default Object.
parametersNoOptional {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"} (validated); FGuid as a hex/braced string.
function_nameYesName of the function to call (BlueprintCallable+Public or a BlueprintEvent). Static library functions and BlueprintPure getters work here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations give the safety profile (destructiveHint=true, openWorldHint=false), and the description adds the crucial behavioral facts that go beyond them: it always runs on the CDO, takes no world selector, and lists the exact argument-marshaling rules. It also flags that it reaches static/BlueprintPure getters. This is rich context an agent needs to avoid misuse.

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

Conciseness5/5

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

Front-loads purpose, then the naming/marshaling guidance, then a compact return-shape summary. Each sentence carries non-redundant information and the total is appropriately sized for a 6-param, arbitrarily-typed call tool.

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, but the description supplies the return shape ({ success, class_name, class_path, function_name, returns_json }), and it fully covers invocation mechanics, CDO semantics, marshaling, and sibling routing. Nothing needed to call the tool correctly is missing.

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 baseline is 3, but the description adds value beyond the schema by explaining the aliasing rationale (args/params/args_json exist because sibling tools spell the parameter differently, and `parameters` is preferred) and restating the marshaling contract in prose. This helps an agent construct the call correctly rather than just naming fields.

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 (invoke) and resource (static/BlueprintCallable library function on a class's CDO), and explicitly scopes it to cases 'when there is no instance to talk to' such as UKismetSystemLibrary and UGameplayStatics. An agent can distinguish it from the instance-based siblings 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 Guidelines5/5

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

Names the alternative tools explicitly ('use call_object_method(world=...) or call_component_function(world=...) for anything that must run inside a live PIE world') and states the condition that selects them, i.e. the absence of a world selector here. When-to-use and when-not-to-use are both covered.

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