Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
tierNoCLI flag --tier: 'cheap' (default) or 'premium' profile
GODOTNoPath to the Godot 4.7 executable used by the check tool (alternative to --godot)
godotNoCLI flag --godot: path to the Godot 4.7 executable
projectNoCLI flag --project: path to the Godot project folder
GODOTWRIGHT_HOMENoDirectory to store the learning file somewhere else
GODOTWRIGHT_LEARNNoSet to 0 to stop learning (or use 'godotwright learn off')

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
godot_scanA

Map a Godot 4 project from its files, without running Godot: scenes with node trees, scripts with class_name, signals, functions and exports, autoloads, input actions, key settings, and broken references. Call this first in a project, and again after large changes. For one name use godot_usages; for engine classes use godot_api. detail brief gives one line per scene and script; full adds node trees with line numbers, signal connections, input events and settings. Read-only. Returns an error when there is no project.godot at or above path.

godot_apiA

Exact lookup in the official Godot 4.7 class reference, offline: Class, Class.member, Class.Enum.VALUE, @annotation or a global function. A class gives its parents, properties with defaults, methods, signals and enums; a member gives its exact signature and description, found through inheritance. Use it before calling any engine API you are not sure about; when you do not know the exact name, use godot_api_search first. detail brief gives the signature and the first paragraph; full gives the whole entry. An unknown name returns an error with close matches, and a Godot 3 name with its Godot 4 name. It changes no project files; when learning is on, it counts the lookup in Godotwright's local learning file so later misses get better hints (GODOTWRIGHT_LEARN=0 turns that off).

godot_api_searchA

Search the Godot 4.7 class reference offline by words: class, method, property and signal names, keywords and descriptions, best matches first. Use it when you know what you need but not its name ('raycast 3d', 'change scene'), then call godot_api on the best match for its full entry. For where your own project uses a name, use godot_usages. Returns one line per match with its kind and signature, e.g. method CharacterBody2D.is_on_floor() -> bool const, or 'no matches'. limit caps the list (default 10, at most 50). Read-only.

godot_reviewA

Static AAA review of the project, no Godot needed: API correctness (Godot 3 code, unknown classes, functions, members, signals, wrong argument counts, missing input actions), performance, code quality and structure. Returns a 0-100 score per category, then one line per finding: res://file.gd:12: error [rule] message; detail full adds the fix under each finding. Pass files to list only findings in files you changed. Pass code and file to review GDScript before writing it to disk. Pass only_new: true while you are fixing: new findings in full, the ones you already saw as one short line each, and how many are fixed. It never changes your code; it keeps the last review in .godot/godotwright/ for only_new and counts rule hits in the local learning file. For errors only the engine finds, run godot_check after it; godot_checklist lists every rule.

godot_usagesA

Find every place a name is used in the project, offline and without the editor: a function, signal, variable, constant, class_name, autoload, input action, group or node name, or a res:// path / uid:// (which files refer to it, and whether it exists). Looks in GDScript code (not comments), in strings where Godot looks names up (connect, emit_signal, is_action_pressed, add_to_group, get_node, load), in scene connections, node names and groups, and in project settings. Call it before you rename, move or delete anything; to make the change everywhere, use godot_rename. For engine API names use godot_api. Returns where the name is defined, then each file with the line number, the kind of use and the line itself (very common names are capped). Read-only.

godot_renameA

Rename a function, signal, variable, class_name, autoload, input action, group or node name everywhere it is used (GDScript, scene connections, node paths, groups, project settings), or move a res:// file together with its .uid and .import files and every reference to it. from and to are both names or both res:// paths. Without write it changes nothing and returns the exact lines it would change and what it could not change; with write: true it applies them and reports the review errors before and after (an error result when there are more after). Refuses, with an error, when the new name is already taken. Call godot_usages first to see what it will touch. For a setting value, an input event or a node property, use godot_project_edit or godot_scene_edit instead.

godot_project_editA

Change project.godot safely, without the editor: set or unset a setting (name and type checked against the Godot 4.7 reference), add events to an input action or remove it, add or remove an autoload (the file must exist and be a Node script or a scene; the name must not clash with a class). Only the lines of that entry change. Events: Key:Space, Key:Ctrl+S, Mouse:Left, JoyButton:A, JoyAxis:left_y-. op picks the change and which fields it needs: set (key, value), unset (key), input_add (action, events, deadzone), input_remove (action), autoload_add (name, file, global), autoload_remove (name). Without write it changes nothing and returns the diff and warnings; with write: true it writes and reports the review errors before and after (an error result when there are more after). A missing field or a change it refuses (bad event, unknown action, name clash) returns an error and writes nothing. Use it instead of editing project.godot by hand: the input map format is easy to break. For .tscn files use godot_scene_edit; to rename an action or autoload everywhere, use godot_rename.

godot_scene_editA

Change a .tscn safely, without the editor: add a node (a Godot class or an instanced scene), remove a node (with its children, connections and the resources only it used), set a property (name and type checked against Godot 4.7; enums by name, resources as res:// files), connect or disconnect a signal (checks the signal exists, and warns when the method is missing or takes the wrong number of arguments, with the func line to add), or attach a script (refuses one that extends another node type). Node paths are relative to the scene root, which is ".". op picks the change and which fields it needs: add_node (parent, name, and type or instance), remove_node (node), set (node, property, value), connect and disconnect (from, signal, to, method), attach_script (node, script). Only the lines of that change are touched. Without write it changes nothing and returns the diff and warnings; with write: true it writes and reports the review errors before and after (an error result when there are more after). A missing field or a change it refuses returns an error and writes nothing. Use it instead of editing .tscn files by hand. For project.godot use godot_project_edit; to rename a node everywhere, use godot_rename.

godot_migrateA

Rewrite Godot 3 GDScript to Godot 4 where that is mechanical: @export/@onready/@tool, renamed classes, functions, properties and constants, yield() to await, connect()/emit_signal() to signals, funcref() to callables, members that moved (OS.get_ticks_msec() to Time). Strings, comments and node paths are left alone. Without write it only reports the changes; with write: true it rewrites the scripts. It also lists what still needs a hand (setget, move_and_slide arguments, rpc keywords, export hints it does not know). Scenes and project settings are not migrated; Godot's --convert-3to4 does those. files limits it to some res:// scripts; detail brief shows up to 12 changes per file, full shows every change. Running it twice changes nothing more. Use it before fixing Godot 3 findings from godot_review one by one, and run godot_review afterwards.

godot_exportA

Compare the export presets (export_presets.cfg) with what the scripts and scenes load, without exporting: files that exclude_filter leaves out although they are preloaded or loaded (Godot leaves them out even when something needs them, so the build fails there), plain data files (text, binary, GeoJSON, cfg, XML, YAML; JSON and imported CSV are fine) that Godot only exports when include_filter names them, and paths built at run time under an excluded folder; plus whether export templates are installed. preset limits it to one preset (name or number). Read-only. Run it before an export and after changing what the game loads.

godot_depsA

Follow what loads what, from where the game starts (main scene, autoloads, every res:// path in project.godot, export include filters, the shipped file list from godotwright.json, add-ons, tests, editor scripts), through ext_resource, preload, load, class_name, folders and file names the code builds paths from, textures next to models and import settings. op unused: files nothing reaches, biggest first, whole folders as one line (when in doubt a file counts as used, so the list can be trusted). op why (file): the chain from the game to the file, before you delete or move it. op of (file): what a scene or resource loads with it, biggest first, what it can load later, and paths that do not exist. op cycles: scenes or resources that load each other through ext_resource, which Godot cannot load (it reports "[ext_resource] referenced non-existent resource" for a file that is there). Read-only.

godot_undoA

Undo what Godotwright wrote, newest first: scene and project edits, renames (moved files go back), migrations, fixes and model builds each keep the files as they were, in .godot/godotwright/journal/ (the last 40 writes). steps undoes that many writes (default 1); list only shows them. A file changed after the write (by hand or by another tool) stops the undo there, so your later edits are never lost silently; force undoes anyway. Use it when a write made things worse, instead of repairing by hand.

godot_sessionA

Load a scene in Godot 4.7 headless once and keep it running between calls, paused at frame 0, so godot_game can look at the live game and move it frame by frame without loading the world again (a big world can take a minute to load; godot_play loads it on every call). op start (scene: default the main scene; restart: true loads it again), status, or stop. Only this machine can reach it (a loopback port with a token), the project is not changed (the script lives in .godot/godotwright/), and the game quits by itself after idle_minutes without a request (default 15). Stop it when you are done.

godot_gameA

Ask the game that godot_session started. op tree (the live node tree: path, class, script; root, depth, limit), get (values now: watch ["Hero.position", "Hero.is_on_floor()"]), set (target "Hero.position", value "Vector3(0, 30, 0)" as Godot writes values), call (node, method, args), eval (a Godot Expression with the scene root as base, e.g. get_node("Hero").velocity.length()), step (play frames frames with an input timeline counted from this step, sample watch, stop early until a condition holds; the same frame-exact input as godot_play), signals (record these signals; later steps list when they fired), layout (3D objects: global position, size, lowest point, and whether each rests on, floats above or sinks into what is below, plus scale mistakes), ray (from, to: what a physics ray hits), ui (visible controls at one or more window sizes, with clipped text, off-screen panels, overlapping buttons and small targets), errors (what the game printed since the last call), reload (load the scripts you edited into the running game: every node keeps its values and runs the new code from the next step, so you try a fix without loading the world again; files, default every script changed since the last reload; a script that does not compile is left as it was). Every answer ends with the errors and warnings the game printed since the last call, runtime errors with their call chain. Time only moves on a step, so the session stays deterministic. Use it to try a fix live, find a state that is hard to reach, or watch a long scenario in parts.

godot_perfA

Run a scene in Godot 4.7 headless and measure it the way a player feels it: frame-time p50, p95, p99 and max against a budget (default 16.6 ms), the physics step apart from the rest of the frame, the slowest frames with what changed on them (nodes made or freed in one frame, a heavy physics step, script work), node and orphan counts, and the change since the last run of the same scene (kept in .godot/godotwright/perf/). Headless measures the CPU side (scripts, physics, scene work), not the GPU. input plays a timeline as godot_play does, to measure while something happens. An error result when p95 is over budget or more than 10% worse than last time. Lessons that fit the numbers are named. Measure before and after every performance change.

godot_doctorA

One call for a project you do not know yet, or when something is broken and you do not know where to start: runs the review and, when Godot is installed, loads every script and scene with Godot; groups the findings by cause (twenty findings from one missing file are one problem), puts the most urgent first (Godot's errors, then the review's), and gives each the place, the lesson from real projects that explains it, the fix, and whether godot_fix or godot_migrate can do it. Pass symptom with what you see going wrong ("helicopter bounces on the moving deck") to add the lessons for it. Ends with numbered next steps. Read-only. Use godot_review for the full list and godot_check for Godot's raw output.

godot_fixA

Apply the mechanical fixes for review findings instead of editing them one by one: api/coroutine-without-await, api/freed-check-order, api/get-meta-null-default, api/infer-variant, api/multimesh-format-after-count, api/timer-start-outside-tree, quality/mojibake, quality/standalone-ternary, quality/string-signal. Each fix rewrites only the line a finding points to, only when it looks exactly as expected, and is labelled safe (it only removes the problem: a freed check put first, get_meta() with has_meta(), a lone ternary as if/else, text encoded twice decoded, emit_signal() as signal.emit(), a MultiMesh format moved before instance_count, Timer.start() moved after add_child(), weakref() typed WeakRef) or check (it changes more: an await added to a coroutine call makes its caller a coroutine; a guessed type). Without write it shows the changes; with write: true it applies them and reviews the changed files again, returning what is left. Only safe fixes unless include_check: true. Lines it cannot fix are listed with the reason. Run godot_review first to see the findings, and godot_check after writing.

godot_checkA

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.

godot_screenshotA

Render a scene, or a .glb/.gltf model framed by a camera and lit, to a PNG with Godot 4.7 (Compatibility renderer, works on software OpenGL; on Linux without a display it uses xvfb-run). Returns the picture and a short text: how much of each view is drawn and where, so you can tell an empty or off-screen picture even without reading the image. For a model, views front (from +Z, where models face), back, side, top and iso; several make a grid. width and height are per view; frames lets the scene settle before the picture. The PNG is written next to the model (car.glb gives car.png) or, for a scene, to .godot/godotwright/screenshot.png. An error result when Godot is missing or the scene cannot run. Use it to look at what you built. Without Godot, godot_model_view shows a model as text; to check behaviour rather than looks, use godot_play.

godot_playA

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. until stops the run at the first frame a condition holds ("Heli.is_on_floor() == true"); signals records when signals fire, with their arguments; summary: true gives one line per watched value (start, end, min, max, first change) instead of a table, which saves tokens on long runs; expect checks claims such as "Heli.health > 0" or "Heli.position.y < 1 @ 90" and makes the result an error when one fails, so a play run doubles as a test. 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.

godot_testA

Run the project's GUT or GdUnit4 tests in Godot 4.7 headless and return only the totals and the failing tests, each with res://file:line and the failure message, plus script errors from the run. Use it after a change to see whether the tests still pass. Needs Godot on this machine and GUT (res://addons/gut) or GdUnit4 (res://addons/gdUnit4) in the project. framework picks one when both are installed; dirs chooses the test folders or scripts (default: the framework's config, else res://test and res://tests); filter runs only matching GUT tests. An error result when a test fails, or when Godot or a framework is missing. Test files are not changed; reports go to a temporary folder or .godot/godotwright/. To try input without writing tests use godot_play; for load errors only use godot_check.

godot_feedbackA

Tell Godotwright that a godot_review finding was wrong (a false alarm you verified) or right, or whether a lesson from godot_lessons helped. Pass finding (the line exactly as godot_review printed it) or lesson (its id), not both. For a finding, verdict wrong hides it in later reviews on this machine and right counts it as confirmed; a rule marked wrong far more often than right is then reported one level lower. For a lesson, right means it helped and ranks it higher; wrong makes it show up less. Only use it after checking the code (godot_api, godot_check); fix real findings instead of marking them. It writes to the local learning file only (godotwright learn reset forgets everything). Returns a one-line confirmation; an error when the line is not a finding, the lesson does not exist, or learning is off.

godot_lessonsA

Answer from lessons learned in real Godot 4 projects and on this machine: what went wrong, why in Godot terms, the fix, and how to test it. Find them by query (words such as 'helicopter slides off moving ship', or a lesson id), by error (a Godot message exactly as printed: the lessons that explain it), by rule (the lessons behind a review or model rule), or narrow by topic (gdscript, physics, rendering, import, models, world, performance, gameplay, ui, audio, tooling, process). Without any of them it lists the lessons. gaps: true instead lists the Godot errors seen on this machine (and by other installs) that no review rule predicted and no lesson explains yet: what to teach Godotwright next. Use it when Godot shows an error you do not understand, and before you build moving platforms, vehicles, ships, large worlds, runtime-loaded models, shaders or headless tests. detail brief gives the title and fix; full adds symptom, cause, test, rules and the Godot message. Returns plain text; lessons learned here are marked. It counts which lessons were shown in the local learning file (GODOTWRIGHT_LEARN=0 turns that off). Say whether one helped with godot_feedback (lesson).

godot_lesson_addA

Keep a lesson you learned in this project, so Godotwright (and the next session) knows it: when the same Godot message or question comes back, godot_check and godot_lessons show your fix. Write it in general words: title is the lesson in one line, fix what to do; add symptom, cause, error (the Godot message as printed, kept as a template), topic, tags, rules and test when you can. Names of this project (classes, nodes, files, its title), paths, links, e-mail addresses, codes, keys and source code are replaced before anything is stored; a lesson that is mostly names is refused with what to change. The same title again updates that lesson. It writes only to the local learning file and is never sent; godotwright lessons export prints these lessons for a person to propose for everyone. Add one whenever a fix took more than one try, and not for what a review rule already reports. Returns the stored lesson and what was replaced; an error when it is refused or learning is off.

godot_checklistA

List the fixed AAA checklist that godot_review applies: plain text grouped by category (api, performance, quality, structure), one line per rule with its fix (on the premium profile also its id and severity). Read it before writing code to know the rules, or to look up a rule id from a finding. It does not look at the project; to check the project against these rules, use godot_review. Read-only.

godot_model_identifyA

Say what a thing is before you build or check a 3D model of it: its family, the parts a model needs (and which move, about which axis, with the pivot where), a typical size range with its source and a confidence class, variants, Godot conventions (+Y up, front faces +Z), what to anticipate and the usual mistakes. Works from a name in English or Dutch (plurals, typos, compounds like 'vrachtauto') or a description ('something with wheels and an engine'). A word that means two things is reported as ambiguous; something unknown gets the nearest family, marked generic. Use it for the full facts about a thing, and its archetype name for godot_model_lint; for one short page that also names the ready-made kind and the spec format, use godot_model_brief instead. Read-only.

godot_model_briefA

One page to read before building a 3D model, made for small models: what the thing is, the ready-made kind to start from (with its build command), the parts to name your nodes after, typical size, rules, the usual mistakes, the order of tools to call, and a short spec cheat sheet. text is a name or a short description in English or Dutch; typos and plurals work. Replaces calling godot_model_identify and godot_model_spec separately when you just want to start; call those instead when you need every detail (all variants and sizes, or the full spec). Returns plain text. Read-only.

godot_model_specA

Explain the model spec: a JSON tree of named parts that godot_model_build turns into a .glb. Returns plain text: the spec rules, a JSON example (a small car), then one line per ready-made kind with its parameters and their defaults. Read it before you write a spec or pass params to godot_model_build; skip it when a ready-made kind with its defaults is enough. godot_model_brief has a shorter cheat sheet. Read-only.

godot_model_buildA

Build a clean .glb (UVs, tangents, one node per part, same bytes every time) from a ready-made kind or a model spec, write it to out, and lint it. Pass collision so Godot adds collision shapes when it imports the file (most models need one; nobody remembers to add it by hand). If the spec has an "archetype" (or the kind has one), the result is also checked against what that thing should be. Give kind (with optional params), spec or spec_file; contract_out also writes a model.contract.json that godot_model_lint can hold later versions to. out is replaced if it exists. Returns the size, triangle and node count, then the lint report (detail full lists every finding with its fix); an error result when the lint finds errors, though the file is still written. Call godot_model_identify first and godot_model_spec for the format. To check a .glb you did not build here, use godot_model_lint.

godot_model_lintA

Score a .glb or .gltf without Godot: flipped faces, open edges, missing normals, UVs or tangents, textures, node names, budgets. Pass archetype (a name such as 'car' or 'helikopter', or an id) to also check it is what it should be: required parts, pivots, wheel axes, size (unit mistakes), direction. Pass contract to hold it to a model.contract.json, and max_triangles to flag a heavy model. Returns an overall score, a score per category (geometry, materials, performance, rig, and archetype when given) and the findings: detail brief shows up to 25 errors and warnings, full shows every finding with its fix. An error result when there are errors. Read-only. godot_model_build already lints what it builds; to see the shape use godot_model_view, for the raw contents godot_model_inspect.

godot_model_viewA

Look at a .glb or .gltf without Godot or a picture: three views (front, side, top) drawn with letters, one letter per part, then a list of the parts with their sizes and heights, and which parts do not touch the rest of the model (a ladder away from its tree, a wheel without an axle, something floating). only shows one of the views; width sets the characters per view (default 48). Use it after building to check the shape, proportions and that everything is attached. Read-only. For a rendered picture use godot_screenshot (needs Godot); for triangles, materials and textures use godot_model_inspect; for problems use godot_model_lint.

godot_model_inspectA

Show what is in a .glb or .gltf, without Godot: file size, triangles, nodes, materials, textures with a memory estimate, the size in metres and the lowest point, then the node tree with triangles per mesh. detail brief lists the first 40 nodes; full lists every node, the materials and the textures. Use it for the numbers, for example to check a triangle budget or why a model floats. Read-only. To see the shape use godot_model_view; to find problems use godot_model_lint.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.3/5.0

Scored across 32 tools

Disambiguation4/5

Most tools are clearly separated by workflow: static review vs engine check vs play/session/perf, and the model tools each produce a distinct artifact. Some boundaries remain subtle, especially godot_model_identify/brief/spec and godot_review/doctor/check, where descriptions are needed to disambiguate.

Naming Consistency5/5

All 32 tools use godot_ snake_case, with stable subdomain prefixes such as godot_model_ and godot_api_ and predictable suffixes. Minor noun/verb variation like doctor and checklist does not break the overall consistency.

Tool Count2/5

32 tools is well above a typical well-scoped set, and while the server covers many workflows, the surface is heavy and several model/review tools could likely be consolidated. Each tool has a purpose, but the count makes selection and maintenance costly.

Completeness4/5

The surface covers discovery, API lookup, static and dynamic checks, editing, migration, dependencies/export, undo, runtime play/session, performance, screenshots, tests, and a model pipeline. Minor gaps exist around generic asset/animation/shader/UI authoring and project creation, but core Godot lifecycle coverage is strong.

Maintenance

ActivityMaintained
ResponsivenessResponsive