Godot MCP Runtime vs Godotiq
A side-by-side look at the Godot MCP Runtime and Godotiq MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Godot MCP Runtime for gaming work as a local process; choose Godotiq for gaming as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Godot MCP Runtime when
- You need dedicated capabilities in the Gaming domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
launch_editor, run_project, attach_project.
Choose Godotiq when
- You need dedicated capabilities in the Gaming domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
GODOTIQ_PROJECT_ROOT. - You want tools like
godotiq_ping, godotiq_project_summary, godotiq_file_context.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Gaming | Gaming |
| Quality signal | 69/100 · Great | 60/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | No auth required | Not declared |
| Pricing | Free | Not declared |
| Required env vars | None listed | GODOTIQ_PROJECT_ROOT |
| Verified owner | Community listing | Community listing |
| GitHub stars | 93 | 54 |
| Directory activity | 5 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | 39 | 38 |
| Full listing | View Godot MCP Runtime | View Godotiq |
Tools & capabilities
Godot MCP Runtime tools 39
launch_editorOpen the Godot editor GUI for a project for the human user. Use only when the user explicitly asks to "open the editor"; for any agent-driven work, use the headless scene/node tools (add_node, set_node_properties, etc.) instead - the editor cannot be controlled programmatically. Returns plain-text confirmation after spawning the editor process. Errors if projectPath has no project.godot.run_projectSpawn a Godot project as a child process with stdout/stderr captured. Required before take_screenshot, simulate_input, get_ui_elements, run_script, or get_debug_output. Set profiling: true at launch to enable the profiler tools. Use attach_project for one you launched yourself. Verifies MCP bridge readiness before returning success. Returns status with the assigned bridge port. Call stop_project when done. Errors if projectPath is not a Godot project or another session is already active.attach_projectInject the MCP bridge into a Godot process you launch yourself, then wait up to 20s for the bridge to start listening and up to 45s total once it has, so a large project's cold start is absorbed; a port that listens but answers no ping gives up sooner. Call BEFORE Godot launches - Godot reads autoloads only at process start, so a late call returns "bridge did not respond." Recommended pattern: kick off the Godot launch in parallel with this call so the wait absorbs startup. Prefer run_project unless MCP must not spawn Godot. Only one attach session is supported per project at a time (attach mode has no env-var channel, so port and token must be baked into the one shared script); a second attach_project on a project another session already attached to is refused, naming that session. Returns plain-text status with the resolved bridge port. Call detach_project or stop_project when done.detach_projectClear attached-mode runtime state and remove the injected McpBridge autoload. Does NOT stop the manually launched Godot process - that stays running. Use after attach_project when you are done driving the game from MCP. For spawned sessions (run_project), use stop_project instead. Mostly optional now: when the bridge disconnects (you closed Godot), the next runtime tool call probes once and ends the attached session itself, removing the autoload. Calling it afterwards still succeeds idempotently, wording the message to distinguish "an attached session existed and already ended" from "this server never attached to a project". Returns: message confirming detach plus externalProcessPreserved (always true here - that is the point of detach vs stop_project). Errors only when a spawned session is what is active; use stop_project for those.get_debug_outputGet captured stdout/stderr from a spawned Godot project. Use whenever runtime tools fail unexpectedly - script errors, missing nodes, and crash backtraces all surface here. Still works after the process exits or crashes: the session clears itself on exit but the captured logs are retained until stop_project. Requires run_project (not attach_project; attached mode does not capture output). Returns: output/errors (last `limit` lines each, default 200), running (false after exit, null when attached), exitCode after exit, attached:true with empty arrays in attached mode.stop_projectStop the spawned Godot project and clean up bridge state. Call when done with runtime testing, even after a crash, and even if you closed the Godot window yourself: it frees the process slot and clears the flag blocking scene-editing tools. A process that exited on its own already removed the bridge autoload at that moment, and this still succeeds - it reports alreadyExited:true with the exit code and the logs captured before the exit, and leaves a finished profiler capture readable. Attached sessions detach without killing the external process. Returns: message, mode, externalProcessPreserved, alreadyExited, exitCode (already-exited case), and condensed finalOutput/finalErrors (capped at 200); get_debug_output has the full log. Errors only when there is no session and no exited process to report.take_screenshotCapture a PNG of the running viewport. responseMode: preview (default - saves full PNG, returns bounded inline preview at 960x540), full (full inline PNG; use for small text or pixel-level inspection), path_only (saved-path only, no inline image). Saved under .mcp/godot-runtime/screenshots/ (persists after stop_project). Returns: inline image block (full/preview modes), plus path and size of the saved PNG; previewPath/previewSize in preview mode; warnings for non-fatal runtime errors. Errors if no session or bridge times out (default 10000ms).simulate_inputSimulate sequential input in a running project and report what each action did. Action `type`: key, mouse_button, mouse_motion, click_element, action, text, wait. For key/mouse_button/action, omit `pressed` to tap (press+release); set it to hold or release. click_element resolves by node path/name (see get_ui_elements), not visible text. Returns: results[] per action with ok, timing, signals fired, the Control hit, UI `changes` (appeared/disappeared/changed), `watch` samples, and `errors` from input handlers (spawned sessions only). Invalid batches inject nothing; a runtime failure stops the batch and skips the rest.get_ui_elementsWalk the running scene tree and return all Control nodes with positions, sizes, types, and text content. Always call this before simulate_input click_element actions to discover valid element names and paths. Requires an active runtime session (run_project or attach_project). visibleOnly defaults true; pass false to include hidden Controls. filter narrows by class. Returns: elements[] with path/type/rect/visible plus optional text/disabled/tooltip.run_scriptExecute a custom GDScript in the live running project with full scene tree access. Requires an active runtime session. Script must extend RefCounted and define func execute(scene_tree: SceneTree) -> Variant. Return values are JSON-serialized (primitives, Vector2/3, Color, Dictionary, Array, and Node path strings). Use print() for debug output - it appears in get_debug_output, not in the result. In spawned mode, stderr runtime errors escalate to errors (when the script returns null) or surface as warnings. Returns: { success, result, warnings?, tip? } where result is the JSON-serialized return value of execute().list_autoloadsList all registered autoloads in a project with paths and singleton status. Use first when diagnosing headless failures - broken autoloads crash all headless ops, so this tells you what is loaded. No Godot process required (reads project.godot directly). Returns: [{ name, path, singleton }].add_autoloadRegister a new autoload in a project. autoloadPath accepts "res://..." or a project-relative path (auto-prefixed). singleton defaults true (accessible globally by name). No Godot process required. Warning: autoloads initialize in headless mode - a broken script will crash every subsequent headless op; validate before adding. Returns plain-text confirmation with the registered name, path, and singleton flag. Errors if an autoload with the same name already exists; use update_autoload to modify.- +27 more on the listing page
Godotiq tools 38
godotiq_pingHealth check tool. Returns server status, version, license tier, receipt status, bundle status, tool count, and any available update. The returned dict is a public contract (consumed by the release checklist and the mirror README template). Keys are stable for 0.5.0. Args: detail: Output verbosity — "brief" (summary), "normal" (default), or "full" (everything). Currently does not gate output shape; reserved for future use.godotiq_project_summaryCall FIRST in every session. Architecture, autoloads, conventions, file counts. Replaces manual project exploration — one call gives full context. Use detail="brief" for counts only. Args: detail: "brief" (counts + autoload names), "normal" (+ architecture), "full" (+ scene structure, signal health).godotiq_file_contextCall BEFORE editing any file. Returns public API, dependencies, signals, who imports this file, scene usage. Without this you risk breaking callers. DO NOT read .gd/.tscn files directly — this gives structured cross-referenced data. Args: file: Path to file (res:// or relative). Works for .gd scripts and .tscn scenes. detail: "brief" (public API only), "normal" (+ deps, signals, safety), "full".godotiq_dependency_graphComplete dependency graph: what this file emits, who listens, what it imports, who imports it, impact rating. Call before refactoring function signatures or renaming signals. DO NOT grep the codebase — this traces the full graph in one call. Args: file: Path to .gd file (res:// or relative). depth: How many levels deep to trace (1 = direct deps only, 2 = deps of deps). detail: "brief" (signal names + refs only), "normal" (+ listeners, autoloads), "full" (+ depth_trace always).godotiq_signal_mapProject-wide signal wiring: who emits, who listens, orphan/missing signals. DO NOT grep for .connect() calls — this traces the complete signal graph in one call. Use find="orphans" to find dead signals, "missing" to find typos. Args: scope: "all" for entire project, "autoloads" for autoload scripts only, or "file:res://path.gd" for a single file's signals. find: "all" (everything), "orphans" (emitted but no listeners), "busiest" (most connected), "missing" (emitted but never defined — likely typos). detail: "brief" (orphans + missing only — the actionable items), "normal" (default), "full".godotiq_impact_checkPredict what breaks BEFORE making a change. Returns affected files, callers, risk level, and safe alternatives. Call before renaming, removing, or changing any function/signal/class signature. DO NOT manually search for callers — this finds them all. Args: file: Path to .gd file being modified. action: "modify_function", "rename_signal", "add_parameter", "remove_function", "change_return_type", "rename_class". target: The function/signal/class being changed. change_description: Free-text description of the intended change (used in safe_alternative suggestions). detail: Output verbosity — "brief" (summary), "normal" (default), or "full" (everything).godotiq_validateConvention check: missing type hints, missing class_name, orphan signals, naming violations, incomplete scene nodes (Sprite2D/Sprite3D/TextureRect without texture, CollisionShape2D/CollisionShape3D without shape, MeshInstance3D without mesh — nodes that render/collide as nothing). Run after every code change and before declaring scene work done. Use on "project" for full scan or target a single .gd/.tscn file. Args: target: "project" for full scan, or path to a specific .gd script or .tscn scene. detail: "brief" (default — severity counts only), "normal" (pass explicitly for the issue list), "full".godotiq_scene_mapSpatial understanding of a .tscn scene: positions, distances, directions, bounds. ALWAYS call before placing or moving 3D objects — never guess positions. 3D-only: on 2D scenes returns incomplete or misleading data. DO NOT read .tscn files directly — they are unreadable resource format. Use focus + radius to zoom into an area. NOTE: static .tscn analysis from disk, not the running game — runtime-spawned nodes are not visible here; for the running game use state_inspect, ui_map, or exec with context="game". Args: scene: Path to .tscn file (res:// or relative). focus: Node name or path to center the view on. Returns nearby nodes sorted by distance. radius: Distance filter around focus node (meters, default 5.0). Only used with focus. include: List of node types or groups to include (e.g. ["MeshInstance3D", "enemies"]). detail: "brief" (default — name/type/position only), "normal" (pass explicitly for groups, scripts, bounds), "full" (+ properties, distance matrix).godotiq_spatial_auditAutomated 3D scene linter: floating objects, scale mismatches, z-fighting, overlapping instances, extreme positions. 3D-only: on 2D scenes returns incomplete or misleading data. Run on any 3D scene to catch spatial issues before they become visual bugs. Use detail="brief" for only real problems. The "coverage" block in the result declares what each geometric check could and could not evaluate — treat 0 issues with low coverage as "not verified", not "verified clean". Args: scene: Path to .tscn file (res:// or relative). checks: Specific checks to run (default all 6): "floating_objects", "scale_mismatch", "z_fighting", "empty_markers", "overlapping", "extreme_positions". min_severity: Minimum severity: "warning" (default, filters info), "info" (everything), "critical". detail: "brief" (critical + warning only), "normal" (excludes cosmetic z-fighting/overlapping), "full" (everything). floating_threshold: |Y| above which floating_objects flags a node (default 100.0). Lower it (e.g. 5.0) for ground-level scenes where Y=1 floats matter.godotiq_placementFind safe placement positions for new objects. DO NOT guess positions or manually calculate coordinates. 3D-only: on 2D scenes returns incomplete or misleading data. Checks Marker3D slots first (designer-intended spots, highest confidence), then grid-searches nearby space with wall/overlap validation. Returns up to 3 suggestions with confidence scores. Args: scene: Scene file path (.tscn). Uses project main scene if empty. near: Node name to place near (e.g. "PrinterSlot_P3"). near_position: [x, y, z] coordinates to place near (alternative to 'near'). object_type: Semantic type hint (e.g. "printer", "shelf") — finds similar objects for scale/rotation reference. constraints: {on_floor: bool, min_wall_distance: float, min_object_distance: float, face_direction: str, marker_group: str}. max_suggestions: Maximum number of suggestions (default 3). detail: Output verbosity — "brief" (summary), "normal" (default), or "full" (everything).godotiq_asset_registryComplete asset inventory: find unused assets, missing references, assets by type. Use to audit project assets and clean up bloat. Args: category: "all", "models", "textures", "audio", "scenes", "scripts", etc. check_usage: Check which assets are actually used in scenes (default true). detail: "brief" (default — counts only), "normal" (pass explicitly for counts + top 20 unused), "full" (everything). path_filter: Filter assets by path substring (e.g. "kenney_furniturekit"). max_results: Max number of assets to return (0 = no limit).godotiq_suggest_scaleRecommend scale + position for a model based on similar assets in the scene. Never guess scales — this analyzes existing objects and suggests matching values. 3D-only: on 2D scenes returns incomplete or misleading data. Respects asset_origins from .godotiq.json. Args: scene: Path to .tscn file (res:// or relative). model: Model asset path (res://). Omit for reference mode (returns scale stats for matching nodes). near_node: Node name to suggest position near. intended_use: Semantic hint (e.g. "printer", "shelf"). Required when model is omitted. detail: Output verbosity — "brief" (summary), "normal" (default), or "full" (everything).- +26 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Godot MCP Runtime
{
"mcpServers": {
"erodenn-godot-mcp-runtime": {
"command": "npx",
"args": [
"-y",
"godot-mcp-runtime"
]
}
}
}
Godotiq
{
"mcpServers": {
"godotiq": {
"command": "uvx",
"args": [
"godotiq"
],
"env": {
"GODOTIQ_PROJECT_ROOT": "YOUR_GODOTIQ_PROJECT_ROOT_HERE"
}
}
}
}
Frequently asked questions
Godot MCP Runtime is categorized under Gaming and uses a local stdio subprocess. Godotiq belongs to Gaming and uses a local stdio subprocess. Pick Godot MCP Runtime for gaming work and Godotiq for gaming.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Godot MCP Runtime is listed as free. Auth: no auth required. Godotiq has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add erodenn-godot-mcp-runtime and godotiq as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Godot MCP Runtime has a quality signal of 69/100 (Great) with 5 views, 0 installs and 93 GitHub stars. Godotiq has 60/100 (Good) with 2 views, 0 installs and 54 GitHub stars.