Skip to main content
Glama
hi-godot

Godot AI

by hi-godot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

game_manage

Manages a live Godot game via the EngineDebugger: inspect scenes and node properties, simulate input, and control execution with pause, resume, and frame stepping.

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 does an excellent job: it discloses focus-independent input behavior, the direct fallback limitation for suspend state synchronization, rejection of malformed positions, and frame-timing semantics. These are meaningful behavioral details beyond a simple operation list.

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 efficiently organized: a two-line summary, a scannable bullet list of operations with parameter details, and a brief canonical call-shape note. Each sentence serves a clear purpose, and the structure makes 13 operations easy to navigate.

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 multi-operation complexity, the description provides complete operational context: prerequisites, input methods, restrictions, and compatibility aliases. Since an output schema exists, omitting per-op return types is acceptable, and the description covers the remaining use context thoroughly.

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?

The input schema is generic (only op, params, session_id), so the description compensates thoroughly by documenting every operation's parameters, defaults, allowed values, and special cases such as position accepting an object or array.

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 precise summary—'Runtime game inspection and input simulation'—and names the specific resource (the running game via Godot's EngineDebugger bridge). It clearly distinguishes this tool from static scene/editor tools by focusing on runtime state and input.

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 prerequisites ('Start the project first with project_run and poll editor_state until game_capture_ready=true') and explicit restrictions ('Cannot run inside batch_execute'). It also provides internal guidance such as using input_sequence instead of separate input_action calls when timing matters.

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