godot-mcp MCP Server

MCP server for Godot game engine integration — control the Godot editor with AI

Publisher claimed. No tool list reported, and Pod has not connected to this server.

Status

Pod has not dialled godot-mcp yet, so everything on this page is what its publisher reported rather than what we observed. Registries describe servers; they do not connect to them. Until a check runs, treat the tool list below as a claim.

Connect

Published as godot-mcp-server on npm. Runs locally.

Known issues

30 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded — those are release checklists and internal refactors, not things that will go wrong for you. Showing 12.

Most discussed

Delete .uid files

Hi, can i suggest a small behavior addition to delete_script tool? I have been using this MPC and noticed that the .uid files are not being deleted when the script is deleted, which is leaving orphaned .uid files in the project.

In my project, i added the code below to godot_mcp/tools/script_tools.gd::delete_script tool to adjust this behavior:

# =============================================================================
# delete_file
# ==========================================

[Read the thread](https://github.com/tomyud1/godot-mcp/issues/47) · 2026-05-02 · open · external user · 3 comments

### Feature: configurable timeout and port via environment variables

## Problem

1. The 30-second tool timeout (`DEFAULT_TIMEOUT` in `godot-bridge.ts`) is too short for some operations (e.g. `map_project` on large codebases). No way to override without editing source.
2. The WebSocket port (6505) is hardcoded. Multiple Godot instances or MCP sessions can't coexist.

## Proposed Fix

Two environment variables:
- **`GODOT_MCP_TIMEOUT_MS`** — override tool timeout (default: 30000)
- **`GODOT_MCP_PORT`** — override WebSocket port (default: 6505)

```typescript
const 

[Read the thread](https://github.com/tomyud1/godot-mcp/issues/20) · 2026-03-28 · closed · external user · 3 comments

### Feature: classdb_query tool — expose ClassDB to prevent API hallucination

## Problem

AI assistants frequently hallucinate non-existent Godot methods (e.g. using Godot 3 API in Godot 4 code, or inventing methods that don't exist). There's no way for the AI to verify that a class, method, or property exists before writing code that uses it.

## Proposed Tool

### `classdb_query`
- Input: `class_name` (required), `query` (optional: `"all"`, `"properties"`, `"methods"`, `"signals"`)
- Output: properties with types, methods with argument signatures and return types, signa

[Read the thread](https://github.com/tomyud1/godot-mcp/issues/19) · 2026-03-28 · closed · external user · 3 comments

### Feature: run_scene / stop_scene / is_playing tools

## Problem

There's no way for an AI agent to run a scene, check if it's running, or stop it. This means the edit→run→debug loop requires the user to manually press Play in the editor, breaking the autonomous workflow.

## Proposed Tools

### `run_scene`
- Defaults to main scene
- Accepts `scene: "current"` for the open scene, or a `res://` path for a specific scene
- Returns error if a scene is already running

### `stop_scene`
- Stops the currently running scene

### `is_playing`
- Returns `{ 

[Read the thread](https://github.com/tomyud1/godot-mcp/issues/18) · 2026-03-28 · closed · external user · 3 comments

### WebSocket server should bind to IPv4 (127.0.0.1) — fixes connection failures

## Problem

The WebSocket server in `godot-bridge.ts` creates a server without specifying a host:

```typescript
this.wss = new WebSocketServer({ port: this.port });

The ws library defaults to binding on :: (IPv6). Godot's WebSocketPeer connects to ws://127.0.0.1:6505 (IPv4). On systems where IPv6 dual-stack doesn't transparently bridge to IPv4, the connection silently fails — the plugin logs [MCP] Connecting to ws://127.0.0.1:6505... but never succeeds.

This is likely the root c

Read the thread · 2026-03-28 · closed · external user · 3 comments

Most recent

Primary MCP server lingers as orphan after its only stdio client (single DSH) exits, breaking the next session

Summary

With a single MCP client (e.g. DeepSeek Harness DSH, or a lone Codex/Claude session), when the client exits, the PRIMARY \godot-mcp-server\ process does not exit (by design: \stdin close does NOT kill the server). It keeps listening on :6505/:6506 while Godot stays connected.

On the next launch, the freshly spawned server detects the lingering PRIMARY via the :6506 probe and enters PROXY mode against that orphan. If the orphan's stdio is gone but it still holds the

Read the thread · 2026-08-25 · closed · external user · 1 comment

run map_project cannot show visual

this is cursor tip:

" The injected JSON is corrupted (unescaped newlines appear). The HTML gets truncated by in the middle of