Godot MCP vs Godotiq
A side-by-side look at the Godot MCP 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 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 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
godot_scene, godot_node_read, godot_node_edit.
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 | 178 | 54 |
| Directory activity | 3 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | 21 | 38 |
| Full listing | View Godot MCP | View Godotiq |
Tools & capabilities
Godot MCP tools 21
godot_sceneManage scenes in the editor: open a scene, save the open scene, or reload an open scene from disk after you edit its .tscn directly (so the editor picks up the change without a full restart). To create a new scene, write the .tscn file directly — header [gd_scene format=3] without a uid (the editor assigns one when it imports the file), then one [node name="X" type="Node2D"] block per node — and open it with this tool.godot_node_readInspect scene nodes in the editor: read a node's effective properties (including class defaults a .tscn read cannot show), view the full scene tree as the editor sees it (including children inside instanced sub-scenes), and find nodes by name or type. Use it to discover node paths and verify the live state of the open scene before or after making changes. It cannot modify anything; to update properties or reparent a node, use godot_node_edit.godot_node_editModify scene nodes in the editor: update a node's properties, or reparent it (the editor rewrites child paths and signal connections correctly; hand-editing .tscn for a reparent does not). Use it to change existing nodes in the open scene. To inspect properties, the scene tree, or search for nodes, use godot_node_read; to add or remove nodes, or attach scripts and connect signals, edit the .tscn file directly, then verify with godot_node_read's get_scene_tree.godot_editor_readObserve the editor and running game: get editor state (open scene, play state, camera, viewport), read the current node selection, pull editor log messages (with an incremental cursor) and stack traces, and capture lossless PNG screenshots of the running game or an editor viewport. Reach for it to check what the editor sees before and after a change; screenshot_game needs a running game, while every other action works in the bare editor. It changes nothing - to select nodes, run/stop/restart, or move the 2D viewport use godot_editor_edit; errors from the running game (not the editor process) come via minimal-godot-mcp's get_console_output when that companion server is installed.godot_editor_editDrive the editor: select a node, run or stop the project, restart the editor, rescan the filesystem to import assets written outside the editor, and center/zoom the 2D viewport. Use run with frozen=true as the deterministic-playtest entry point (game time holds at frame 0 until godot_game_time steps or thaws it). To test edited gameplay scripts just stop then run — the launched game loads .gd/.tscn fresh from disk; reserve restart for EDITOR-side staleness (edited @tool/addon code, a stale project.godot, or a cached .gdshader). For observation only (state, selection, logs, screenshots) use godot_editor_read instead; restart does not start a cold editor, so one must already be running.godot_projectRead project-level data from the editor: name, path, Godot version, and main scene (get_info), plus project settings including input mappings (get_settings). After editing project.godot as a file, use check_stale to detect whether the editor is still running stale autoloads or input map from before the edit; restart via godot_editor_edit to reload. Use addon_status to diagnose addon/server version skew when commands misbehave or the connection drops; it also reports whether the running server build is stale relative to its source checkout. For scene contents or node properties, use godot_node_read instead.godot_animation_readInspect animation data on AnimationPlayer nodes in the editor: list players in the scene, read a player's state and libraries, get an animation's tracks and properties, and read a track's keyframes. Reach for it to verify what the editor actually loaded, including after editing animation resources by hand. It changes and previews nothing; use godot_animation_edit to create, modify, or play animations.godot_animation_editCreate and modify animations on an AnimationPlayer and preview them in the editor: create, delete, or update animations, add and remove tracks and keyframes, backfill RESET keys for existing tracks (create_reset_keys), and play, stop, or seek the editor's preview (playback controls the editor, not the running game). Pair each change with an immediate play or seek to check the result; this is the only way to verify animation feel without running the whole game. To inspect animation data without changing it, use godot_animation_read.godot_tilemap_readInspect TileMapLayer data in the open scene: list layers, get layer and TileSet info, read used cells, a single cell, or a rectangular region, and convert between local positions and map coordinates. Use it whenever you need to know what tiles are placed where; cell data is stored base64-encoded in the .tscn, so reading the file is not an alternative. To place, erase, or clear tiles, use godot_tilemap_edit instead.godot_tilemap_editModify TileMapLayer cells in the open scene: set a single cell, erase a cell, clear a whole layer, or set many cells in one batch. Use it to paint or remove tiles; cell data is stored base64-encoded in the .tscn, so editing the file is not an alternative, and set_cells_batch beats repeated set_cell calls for anything beyond a few tiles. To inspect layers, TileSets, or existing cells without changing anything, use godot_tilemap_read.godot_gridmap_readInspect GridMap data in the open scene: list GridMap nodes, get map and MeshLibrary info, and read used cells, a single cell, or every cell using a given item. Use it whenever you need to know which mesh items occupy which 3D grid cells; cell data is stored base64-encoded in the .tscn, so reading the file is not an alternative. To place or clear cells, use godot_gridmap_edit instead.godot_gridmap_editModify GridMap cells in the open scene: set a single cell to a MeshLibrary item with an orientation, clear a cell, clear the whole map, or set many cells in one batch. Use it to build or remove 3D grid content; cell data is stored base64-encoded in the .tscn, so editing the file is not an alternative, and set_cells_batch beats repeated set_cell calls for anything beyond a few cells. To inspect the map, its MeshLibrary, or existing cells without changing anything, use godot_gridmap_read.- +9 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
{
"mcpServers": {
"godot-mcp-2": {
"command": "npx",
"args": [
"-y",
"@satelliteoflove/godot-mcp"
]
}
}
}
Godotiq
{
"mcpServers": {
"godotiq": {
"command": "uvx",
"args": [
"godotiq"
],
"env": {
"GODOTIQ_PROJECT_ROOT": "YOUR_GODOTIQ_PROJECT_ROOT_HERE"
}
}
}
}
Frequently asked questions
Godot MCP is categorized under Gaming and uses a local stdio subprocess. Godotiq belongs to Gaming and uses a local stdio subprocess. Pick Godot MCP 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 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 godot-mcp-2 and godotiq as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Godot MCP has a quality signal of 69/100 (Great) with 3 views, 0 installs and 178 GitHub stars. Godotiq has 60/100 (Good) with 2 views, 0 installs and 54 GitHub stars.