Godette
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GODOT_PROJECT | No | The path to the Godot project root. The server auto-detects the Godot project root from the working directory or this environment variable. |
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_scene_treeA | Get the scene tree structure of a .tscn file with node types, scripts, groups, and hierarchy. |
| find_nodeC | Find nodes across all indexed scenes by name, type, group, or attached script. |
| find_signal_connectionsA | Find all signal connections for a node in a scene, or all connections for a signal name across the project. |
| find_group_membersB | Find all nodes belonging to a specific group across all indexed scenes. |
| get_scene_dependenciesB | Get all external resources, instanced scenes, and script dependencies of a scene. |
| trace_signal_chainB | Trace a signal chain: emission → handlers → chained emissions → further handlers. Returns a graph. |
| find_scene_instancesB | Find all scenes that instance (use) a given scene, with parent node paths. |
| get_node_propertiesC | Get all properties on a specific node in a scene. |
| find_resourceC | Find resources by type across the indexed project. |
| get_resource_propertiesB | Get the properties and sub-resources of a .tres resource file. |
| get_resource_referencesA | Find every scene and script that references a given resource. |
| find_resources_of_typeA | Alias for find_resource — find all resources of a given Godot type (e.g. all ShaderMaterials). Includes property names. |
| get_project_settingsB | Get the Godot project settings including name, version, and main scene. |
| get_input_mapB | Get the project input action mappings. |
| get_layer_namesB | Get the named physics and render layers for the project. |
| get_autoloadsB | Get all autoload singletons configured in the project. |
| list_project_structureB | List all indexed scenes, scripts, and resources in the project. |
| read_fileC | Read a file with Godot-enriched output. For .gd files, includes parsed symbols. For .tscn files, includes scene structure. |
| list_dirC | List files in a directory with Godot-aware file type indicators. |
| find_fileB | Find files by name pattern or extension in the project. Supports substring or regex matching. |
| replace_contentC | Replace text content in a file and emit a file change event. |
| create_fileC | Create a new file with the given content. Triggers index update. |
| delete_linesB | Delete a range of lines from a file. Line numbers are 1-based. |
| insert_at_lineC | Insert content at a specific line number. Line number is 1-based. |
| find_symbolA | Find symbols by name across the project. Uses LSP when available, regex parser as fallback. Results include a metadata.source field indicating whether LSP or regex was used. Report whether results came from LSP or regex fallback, as LSP provides more accurate signatures and locations. |
| find_referencesA | Find all references to a symbol at a given position. LSP-only (returns error without LSP). Falls back to text search. |
| get_symbols_overviewA | Get the top-level symbol tree for a GDScript file: functions, signals, exports, enums, constants. |
| rename_symbolA | Rename a symbol across the entire project using the language server. LSP-only — without LSP, fall back to find_symbol + replace_content and warn about potentially missed references in non-script files (.tscn signal connections, etc.). |
| replace_symbol_bodyA | Replace the entire body of a function or symbol in a GDScript file. Hash-verified to prevent stale edits. |
| insert_after_symbolC | Insert content after a named symbol in a GDScript file. |
| insert_before_symbolC | Insert content before a named symbol in a GDScript file. |
| add_nodeB | Add a new node as a child of an existing node in a .tscn scene file. |
| remove_nodeB | Remove a node and all its children from a .tscn scene file. Also removes associated signal connections. |
| modify_node_propertyC | Set or change a property value on a node in a .tscn scene file. |
| connect_signalC | Add a new signal connection between nodes in a .tscn scene file. |
| disconnect_signalC | Remove a signal connection from a .tscn scene file. |
| add_to_groupC | Add a node to a group in a .tscn scene file. |
| remove_from_groupC | Remove a node from a group in a .tscn scene file. |
| create_sceneA | Create a brand new empty .tscn scene file with just a root node. |
| run_projectB | Run a scene in the Godot editor. Optionally specify a scene path, enable the runtime harness, or watch specific nodes. |
| stop_projectA | Stop the currently running Godot project. |
| capture_stateC | Capture a snapshot of the game state from the running project. Optionally specify a node path to narrow the capture. |
| get_runtime_stateB | Get the runtime state of a specific node path in the running scene tree. |
| get_signal_logA | Get the log of signals emitted during runtime (requires start_signal_logging first). Optionally filter by signal name or time. |
| screenshotC | Take a screenshot of the running Godot project. |
| get_console_outputC | Get console output from the running Godot project. Optionally filter by text or error level. |
| start_signal_loggingB | Start logging signal emissions on a node and its children. After starting, call get_signal_log to retrieve captured signals. |
| get_live_scene_treeA | Get the live scene tree from the running Godot project, reflecting runtime-added/removed nodes. Returns compact structure (name/type/path) by default. |
| switch_modeA | Switch the active mode (planning, editing, debugging, interactive). This updates tool description hints and emits a config:mode-changed event. |
| get_configB | Get the current merged server configuration, including active context and mode. |
| onboardingC | Run the onboarding process to initialize .godette/ directory and index the project. |
| rescaffold_pluginA | DEV: Delete addons/godette/ and re-scaffold the GDScript plugin files from current templates. Useful after changing onboarding templates. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| godette://init |
TDQS
Scored across 52 tools
Most tools are clearly distinct by their target (scenes, nodes, resources, project config, runtime, files). However, there is some overlap between find_resource and find_resources_of_type (explicitly an alias), and read_file vs list_dir vs find_file could be confused for file browsing. Overall, the domains are well-separated.
The naming convention is mostly verb_noun (e.g., get_scene_tree, find_node, create_scene, modify_node_property) with a few exceptions like onboarding, rescaffold_plugin (verb alone), and switch_mode. The verb choice is mostly consistent (get/find/create/insert/delete/modify) but there are mixed verb styles (add_node vs create_scene, remove_node vs delete_lines).
With 52 tools, the server is on the heavy side, even for a comprehensive Godot IDE integration. While many tools are domain-appropriate screens, resources, file editing, runtime—the count is excessive and may overwhelm an agent. It could be trimmed to ~30-40 by consolidating overlapping operations (e.g., find_resource/find_resources_of_type, insert_after_symbol/insert_before_symbol).
The tool surface is impressively complete for the stated purpose: it covers static scene/resource inspection, file manipulation, symbol-level code editing, project configuration, and runtime control/debugging (run, stop, state capture, screenshot, console). It even includes signal tracing and mode switching. No major dead ends or missing lifecycle operations are apparent.