Skip to main content
Glama

Play a scene with input

godot_play
Idempotent

Run a Godot scene headless for set physics frames, inject timed input actions, and sample watched property values per frame to verify jumps, movement, damage, or timers without a screen.

Instructions

Run a scene in Godot 4.7 headless for a number of physics frames, press and release input actions (or keys, mouse and joypad buttons) on the frames you give, and return a table of the values you watch per frame, plus errors and prints. The game sees each input on exactly that physics frame, and runs are deterministic. input steps are a frame, a verb (press, release, tap, or hold with a frame count) and an action or an event such as Key:Space; watch entries are a node path from the scene root, a dot, then a property or a method call; every sets how often values are sampled. Use it to check that the player jumps, moves, takes damage or that a timer fires, without a screen. An error result when the run does not finish or Godot reports an error; an unknown input action gives a warning. Your scenes and scripts are not changed: Godotwright runs it through a temporary script in .godot/godotwright/ and removes it afterwards. For assertions kept in the project use godot_test; for load errors use godot_check.

Input Schema

NameRequiredDescriptionDefault
pathNoThe project folder, or any file or folder inside it (Godotwright walks up to project.godot). Relative paths start at the server's folder. Default: the current project.
everyNosample every n frames (default 10); frames with input and the last frame are always sampled
inputNotimeline: "10 press jump; 30 release jump; 40 hold right 20; 50 tap Key:Space"
sceneNothe res:// scene to run (default: the main scene)
watchNovalues to sample: Player.position, Player.velocity.y, Player.is_on_floor()
framesNophysics frames to run (default 120)
timeout_secondsNotimeout of the run (default 300)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.1
    • changedInput schema / properties / path / description
      Previous value: -"Project directory or a path inside it (default: the current project)."New value: +"The project folder, or any file or folder inside it (Godotwright walks up to project.godot). Relative paths start at the server's folder. Default: the current project."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: input is seen on exactly the given physics frame, runs are deterministic, an error result means the run did not finish or Godot reported an error, while an unknown action only warns. It also explains why readOnlyHint=false is safe here — the project is unmodified and the temporary script in .godot/godotwright/ is removed afterwards.

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 action and return value, then parameters, then use cases, then sibling routing — a sensible progression. It is dense but nearly every sentence carries information; a slightly tighter split into shorter sentences would help scanning.

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?

For a complex multi-parameter simulation tool with no output schema, the description covers the return value (per-frame table plus errors and prints), failure semantics, determinism, and side effects on disk. An agent has everything needed to call it and interpret results.

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 already 100%, but the description still adds meaning: the `input` timeline grammars are (frame, verb press/release/tap/hold with count, action or event like Key:Space), `watch` entries are node path + dot + property or method call, and `every` controls sampling cadence. Useful reinforcement rather than pure repetition.

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 concrete verb-resource pair: run a res:// scene headless in Godot 4.7 for N physics frames, inject input on specific frames, and sample watched values per frame. It is clearly distinguishable from godot_test (in-project assertions) and godot_check (load errors), which it names explicitly.

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?

Gives concrete when-to-use cases (verify the player jumps, moves, takes damage, a timer fires — without a screen) and explicit alternatives with the selection condition: godot_test for assertions kept in the project, godot_check for load errors. Nothing is left to inference about routing.

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