godot-mcp-rts
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEBUG | No | Set to 'true' for verbose stderr logging. | |
| GODOT_PATH | No | Path to the Godot executable. If unset, auto-detects common install locations on macOS/Windows/Linux. |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| launch_editorC | Launch Godot editor for a specific project |
| run_projectC | Run the Godot project and capture output |
| get_debug_outputB | Get the current debug output and errors |
| stop_projectA | Stop the currently running Godot project |
| get_godot_versionA | Get the installed Godot version |
| list_projectsA | List Godot projects in a directory |
| get_project_infoB | Retrieve metadata about a Godot project |
| create_sceneA | Create a new Godot scene file |
| add_nodeB | Add a node to an existing scene |
| load_spriteC | Load a sprite into a Sprite2D node |
| export_mesh_libraryB | Export a scene as a MeshLibrary resource |
| save_sceneC | Save changes to a scene file |
| get_uidB | Get the UID for a specific file in a Godot project (for Godot 4.4+) |
| update_project_uidsB | Update UID references in a Godot project by resaving resources (for Godot 4.4+) |
| test_get_infoC | Get information about the test harness capabilities and game project |
| test_get_game_stateC | Get a snapshot of game state including available autoloads, constants, and configuration |
| test_validate_scenarioA | Validate that a test scenario configuration is valid before running it |
| test_check_entityC | Check if a unit, building, or resource scene exists and get its properties |
| test_validate_pathsB | Validate that all unit/building scene paths exist for a race |
| test_run_scenarioB | Run the game with test harness mode enabled for a specific scenario |
| test_check_mlxB | Check MLX local LLM server health and Apple Silicon platform compatibility |
| get_scene_treeA | Get the hierarchical node tree of a scene file as JSON |
| remove_nodeB | Remove a node from a scene and save |
| set_node_propertyA | Set one or more properties on an existing node and save the scene |
| create_scriptB | Create a new GDScript file with optional content or default template |
| attach_scriptB | Attach an existing GDScript to a node in a scene |
| list_scriptsA | Recursively list all .gd scripts in the project or a subdirectory |
| take_screenshotA | Render a scene headlessly via --script and capture a PNG. Best for standalone scenes without autoload deps. For real game scenes, prefer test_take_screenshot against a running game. |
| test_take_screenshotA | Capture a screenshot of the currently running game via file-based IPC with TestController. Requires the game to already be running (use run_project or test_run_scenario first). Works with autoloads and real scenes. |
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 29 tools
Most tools have clearly distinct purposes, though test_check_entity and test_validate_paths overlap somewhat in validating scene paths. The two screenshot tools are adequately differentiated by their descriptions, but the large number of test_* tools could cause brief confusion.
All tool names follow a consistent verb_noun pattern, using lowercase with underscores. Prefixes like 'get_', 'list_', 'create_', 'test_' are applied uniformly, making the naming predictable and readable.
At 29 tools, the count exceeds the 25 threshold for 'too many' per the calibration. While the server covers multiple sub-domains (project management, scene editing, testing, screenshots), the sheer number makes the toolset feel heavy and harder to navigate.
The toolset covers the core lifecycle of Godot project management, scene editing, scripting, testing, and screenshots. Missing operations like scene deletion or project settings editing are minor gaps that agents can work around.