godot-forge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GODOT_PATH | No | Manual override for the Godot binary path. If not provided, the server auto-detects Godot via Steam, Homebrew, PATH, or platform defaults. |
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| godot_run_testsA | Run GUT or GdUnit4 tests headlessly and return structured pass/fail results. Auto-detects the test framework. Returns total/passed/failed counts with failure details including file paths and line numbers. |
| godot_search_docsA | Search Godot 4.x API documentation. Returns class overviews, method details, or fuzzy search results. Automatically detects Godot 3 API queries and suggests Godot 4 equivalents — the #1 source of AI-generated GDScript bugs. |
| godot_get_diagnosticsA | Get LSP diagnostics (errors, warnings) from Godot's built-in language server. Requires Godot editor to be running with the project open. |
| godot_analyze_sceneA | Parse .tscn scene files or .tres resource files and return structured analysis. Detects antipatterns (deep nesting, oversized scenes, missing scripts) and format errors (preload in .tres, custom class names in type field, integer resource IDs). |
| godot_analyze_scriptA | Analyse GDScript files for all 10 battle-tested pitfalls: Godot 3→4 API misuse, giant scripts, := on Variant, tight coupling, signal re-entrancy, autoload misuse, missing signal disconnect, _init() timing, Python-isms, and static func on autoloads. |
| godot_run_projectA | Launch, stop, or get debug output from a running Godot project. Captures stdout/stderr with timestamps. |
| godot_screenshotA | Capture a viewport screenshot from the running Godot project. Returns base64-encoded PNG image. Requires a display server (not headless mode). |
| godot_get_project_infoA | Return project structure overview: project name, Godot version, scenes, scripts, autoloads, addons, and directory tree. Uses progressive disclosure — summary by default, full details on request. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool addresses a distinct concern: testing, documentation lookup, diagnostics, scene analysis, script analysis, project execution, screenshots, and project metadata. There is no functional overlap, and the descriptions clearly delineate their purposes.
All tools share the 'godot_' prefix and most follow a verb_noun pattern (run_tests, search_docs, get_diagnostics, analyze_scene, analyze_script, run_project, get_project_info). 'godot_screenshot' deviates slightly as a noun-only name, but it remains unambiguous and consistent with the overall style.
With 8 tools, the surface is well-scoped for a Godot development assistant. Each tool serves a clear purpose in the workflow without unnecessary bloat or missing essential capabilities.
The toolset covers the core development cycle: test execution, documentation, diagnostics, static analysis of scenes and scripts, project running, and visual capture. Minor gaps exist, such as lack of scene editing or deployment support, but these are outside the intended analysis/run scope and do not create dead ends.