Skip to main content
Glama
Sign In
laaielichter

Godotwright

by laaielichter
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Check with real Godot

godot_check
Idempotent

Run headless Godot 4.7 project checks that import, load every script and scene, optionally run a scene for N frames, and return printed output plus errors as file:line.

Instructions

Run Godot 4.7 headless on the project: import, load and instantiate every script and scene, and optionally run the main scene (or the scene you name) for run_frames frames and return what it printed. Reports engine errors as res://file:line. Put print() calls in the code you are testing and read them back here. run_frames defaults to 0 (load only), or 120 when you pass scene; timeout_seconds caps each Godot run. Returns the errors and warnings with file:line, the totals and the printed output; an error result when Godot reports an error or is not installed. Your scenes and scripts are not changed: Godot updates its import cache in .godot/, where Godotwright also puts its checker script. Needs Godot on this machine and is slower than godot_review, so review first. To drive input and watch values use godot_play; for unit tests use godot_test.

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.
sceneNorun this scene (a res:// path) instead of the main scene
run_framesNoalso run the main scene for this many frames and return its output (default 0; 120 when scene is given)
timeout_secondsNotimeout per Godot run (default 600)

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?

Goes well beyond annotations: discloses side effects ('Godot updates its import cache in .godot/, where Godotwright also puts its checker script'), reassures 'your scenes and scripts are not changed', states timeouts cap each run, and describes the error result when Godot errors or is missing. This is consistent with readOnlyHint=false and rich enough that the agent knows what it will leave behind.

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?

Dense and front-loaded with the core action, then defaults, then return values, then prerequisites and alternatives. Every sentence earns its place; it is a touch long and packs a lot of clauses into single sentences, but nothing is redundant.

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?

Covers return values (errors/warnings with file:line, totals, printed output, error result), side effects on .godot/, prerequisites, cost relative to siblings, and alternative tools. With no output schema, the description fully carries the burden for a tool that shells out to an external engine.

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 real meaning the schema lacks: the conditional default ('run_frames defaults to 0, or 120 when you pass scene') and how timeout_seconds applies ('caps each Godot run'). Minor gap: it doesn't explain res:// path semantics for scene, but the schema covers that.

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 ('Run Godot 4.7 headless on the project') and enumerates exactly what that entails: import, load/instantiate every script and scene, optionally run a scene for N frames, return printed output. An agent can distinguish it from godot_review, godot_play and godot_test purely from the description.

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?

Explicit when-to-use and when-not: 'review first' with godot_review, use godot_play to drive input and watch values, use godot_test for unit tests. Also flags the prerequisite ('needs Godot on this machine') and relative cost ('slower than godot_review'). Nothing is left to inference.

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