Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

trigger_input_action

Destructive

Inject an Enhanced Input action value into a local player's subsystem during a running PIE or game session so real bound handlers fire, then verify with get_input_action_state.

Instructions

Inject a value for an Enhanced Input action into a local player's UEnhancedInputLocalPlayerSubsystem in a running PIE or game session, so the real bound handlers run with the action's own modifiers and triggers (headless key injection never reaches Enhanced Input). dispatched true does not prove a handler fired: compare get_input_action_state before and after.

Returns: { dispatched: bool, note: string, action_path: string, value_type: string, injected_value: [x,y,z], player_index: number, hold_seconds: number, world: string, 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: absent/'pie' (default: PlayWorld, else the first PIE context) | 'server' (the PIE world with authority) | 'client' | 'pie:N' | 'game' (alias of 'pie'). With 2+ players the default may drive the OTHER player's pawn.
actionNoFull object path of a UInputAction, or its short asset name (required).
value_jsonNoThe value to inject, coerced to the action's ValueType: bool (Boolean), number (Axis1D), or a [x,y]/[x,y,z] array or {x,y,z} object (Axis2D/Axis3D). If omitted, Boolean actions default to true (pressed) and axis actions default to zero.
action_nameNoAlias of action, read only when action is absent or empty and action_path is absent: InputAction object path or short asset name.
action_pathNoAlias of action, read when action is absent or empty: InputAction object path or short asset name.
hold_secondsNoOptional float. When > 0, the value is re-injected every tick for this many seconds (so a movement AXIS actually moves the pawn), then a final neutral/zero value is injected to release. Fire-and-forget: the command returns immediately and the hold runs across the next hold_seconds of PIE. Omit (or 0) for a single one-shot sample.
player_indexNoLocal player index used to resolve the PlayerController (default 0).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.2.0
    • addedInput schema / properties / action_name / description
      Added value: +"Alias of action, read only when action is absent or empty and action_path is absent: InputAction object path or short asset name."
    • addedInput schema / properties / action_path / description
      Added value: +"Alias of action, read when action is absent or empty: InputAction object path or short asset name."
    • removedInput schema / required
      Removed value: -[
-  "action"
-]
  2. First observedv1.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Adds real behavioral context beyond the annotations: the 'dispatched true does not prove a handler fired' caveat, the fire-and-forget hold semantics, and the reason headless injection is insufficient. The destructionHint/readOnly flags are already covered by annotations, so the description's added insight is what earns credit.

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-loads the core action in the first sentence, adds a valuable caveat, and appends the return shape. Slightly dense with the parenthetical and long return list, but every element carries information.

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

Completeness4/5

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

With no output schema, the description helpfully enumerates return fields, and it covers the mutation context and verification need. For a 7-parameter mutation tool it is largely complete, missing only minor edge-case guidance.

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%, so the schema already documents world/value_json/hold_seconds/player_index fully. The description adds no parameter-level detail beyond what the schema provides, so it sits at the baseline 3.

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 and resource (inject a value for an Enhanced Input action) plus the target subsystem and session context. It also distinguishes itself from headless key injection (inject_key_input-style siblings), which never reaches Enhanced Input, so an agent can tell it apart from other input tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Clearly scopes usage to a running PIE or game session and implicitly contrasts the alternative (headless key injection) that would fail for Enhanced Input. It also prescribes a verification workflow (compare get_input_action_state before/after). It stops short of explicitly naming the sibling to use instead, so 4 rather than 5.

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