Skip to main content
Glama

Game Manage

game_manage

Interactively inspect and control a running Godot game: read scene tree, node properties, and UI elements, then simulate keyboard, mouse, gamepad, and action input to test behavior.

Instructions

Runtime game inspection and input simulation.

These ops target the running game process through Godot's EngineDebugger bridge. Start the project first with project_run and poll editor_state until game_capture_ready=true.

Ops:

  • get_scene_tree(depth=10, root_path="") Inspect the running scene tree. root_path accepts an absolute runtime path or a scene-relative path rooted at the current scene.

  • get_node_info(path, include_properties=True) Inspect one running node's metadata and optional property snapshot.

  • get_ui_elements(root_path="", include_hidden=False, include_disabled=True, max_depth=10) Inspect visible runtime Control nodes for UI testing. Includes path, type, text where present, disabled state, and rect metadata.

  • suspend() Suspend the running game through Godot's native debugger path.

  • resume() Resume a suspended game. Idempotent when it is already running.

  • next_frame() Advance exactly one process tick while suspended. The response reports verification and any Embedded Game View focus handoff. Runtime-control mutations also report path="embed_signal" or "direct_session"; the direct fallback works without embedding but cannot synchronize the Game View suspend button's visual pressed state.

  • debug_status() Probe suspend state and the game-helper process tick counter through the debugger capture, including while SceneTree processing is suspended.

  • input_key(key, pressed=True, echo=False) Send a key press/release to the running game.

  • input_mouse(event, position=None, button="left", pressed=True) Send a mouse motion or button event. event: "motion" | "button". position is a {x, y} object or [x, y] array; omit it to use the game's current cursor position. A present but malformed position is rejected rather than silently falling back to the cursor.

  • input_gamepad(device=0, control="button", index=0, pressed=True, value=0.0) Send a joypad button or axis event. control: "button" | "axis".

  • input_action(action, pressed=True, strength=1.0) Set a project action's pressed state directly in the running game.

  • input_sequence(steps, settle_frames=0) Apply a frame-timed action timeline in one call — the frame-accurate, multi-step form of input_action. Each step is {at_frame, action, pressed=True, strength=1.0}; the game applies each step's action on its scheduled frame, awaits settle_frames more, then replies once. Use this instead of separate input_action calls whenever timing matters (jump arcs, combos, walk-into-trigger): per-call network latency makes hitting a target frame impossible otherwise. Steps must be ordered by non-decreasing at_frame; frames (not ms) are the timing basis. Action-based input is focus-independent, so it works on a backgrounded game window. Cannot run inside batch_execute.

  • input_state(actions=None) Read current action pressed states. Empty actions = all project actions.

Canonical call shape: {"op": "<verb>", "params": {...}}. Flat op parameters are accepted as a compatibility alias when the client transmits them; op and session_id remain top-level.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opYes
paramsNo
session_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.0.3
    • changedInput schema / properties / op / enum
      Previous value: -[
      -  "get_node_info",
      -  "get_scene_tree",
      -  "get_ui_elements",
      -  "input_action",
      -  "input_gamepad",
      -  "input_key",
      -  "input_mouse",
      -  "input_sequence",
      -  "input_state"
      -]New value: +[
      +  "debug_status",
      +  "get_node_info",
      +  "get_scene_tree",
      +  "get_ui_elements",
      +  "input_action",
      +  "input_gamepad",
      +  "input_key",
      +  "input_mouse",
      +  "input_sequence",
      +  "input_state",
      +  "next_frame",
      +  "resume",
      +  "suspend"
      +]
  2. Changed1 schema field changedv3.1.4
    • changedInput schema / properties / op / enum
      Previous value: -[
      -  "get_node_info",
      -  "get_scene_tree",
      -  "get_ui_elements",
      -  "input_action",
      -  "input_gamepad",
      -  "input_key",
      -  "input_mouse",
      -  "input_state"
      -]New value: +[
      +  "get_node_info",
      +  "get_scene_tree",
      +  "get_ui_elements",
      +  "input_action",
      +  "input_gamepad",
      +  "input_key",
      +  "input_mouse",
      +  "input_sequence",
      +  "input_state"
      +]
  3. First observedv2.9.1

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and meets it thoroughly. It discloses debugger-bridge behavior, suspend/resume idempotence, next_frame verification and focus handoff, the direct-session fallback's visual limitation, frame-based timing, focus-independence, and rejection of malformed mouse positions. This is rich behavioral context beyond a simple mutation/read hint.

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?

The description is long but necessarily so for a multi-op tool, and it is well-structured: a one-line purpose, prerequisite context, grouped ops with consistent formatting, and a closing canonical-call note. The summary is front-loaded, and each op entry earns its place by adding behavior or parameter detail not available in the 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?

Given the tool's complexity, 0% schema coverage, and no annotations, the description is unusually complete: prerequisites, all 13 ops, parameter formats, timing semantics, failure/rejection behavior, and execution restrictions are covered. An output schema exists, so return-value details are not required here, and the description still notes response behavior for key operations like next_frame and input_sequence.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does extensively. It defines each op's parameters, defaults, accepted value formats (e.g., position as {x, y} or [x, y], event enums like 'motion' | 'button'), and the canonical call shape with op/session_id top-level. The step schema for input_sequence and the 'flat parameters alias' are also explained, making the generic params object actionable.

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 opens with a specific verb and resource: 'Runtime game inspection and input simulation' targeting 'the running game process through Godot's EngineDebugger bridge.' It then enumerates concrete ops with distinct verbs and payloads, so an agent can tell this tool from editor-side tools. It also names the prerequisite project_run and editor_state, reinforcing its runtime-focused identity.

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?

It gives explicit preconditions: start the project with project_run and poll editor_state until game_capture_ready=true. It also gives when-not guidance ('Cannot run inside batch_execute') and explicitly prefers input_sequence over separate input_action calls whenever timing matters, including the rationale about network latency. It provides alternatives and context clearly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.