Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/godot-mcp-satelliteoflove/issues.md or /mcp/godot-mcp-satelliteoflove/issues.json, or Pod over MCP.

Reported issues for Godot MCP

Pod holds 24 of 100 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Godot MCP.

Most discussed

Websocket instability: "awaiting WebSocket handshake"

I'm running into stability issues that seem to be coming from the websocket connection between the MCP server and the Godot addon. While the tool calls do occasionally function, many simply return with:

Error: Error: Not connected to Godot

from my MCP client (Cline).

I'm also noticing a lot of log events on the Godot side where the plugin initializes, sees a tcp connection and first websocket connection, but then seems to keep failing or resetting after that.

Godot Output Console:

[go

Read the thread · 2026-01-06 · closed · external user · 10 comments

godot_input: add mouse / coordinate input (move, click, drag) for driving pointer-based games

Problem

godot_input can inject named Input Map actions (sequence) and type_text, but its own description says:

Note: Mouse/coordinate input not yet supported.

That means any pointer-driven game cannot be driven by input injection — point-and-click, RTS/city-builders, tile placement, drag-select, or even just clicking a UI button at a screen position. Named actions can express "place" as a verb, but they can't supply the coordinate the handler needs.

How it surfaced

Disco

Read the thread · 2026-05-31 · closed · 4 comments

On Windows, Godot MCP server does not shut down after claude exits

On Windows, I've configured the .mpc.json in Claude Code as per instructions:

"godot-mcp": {
      "command": "npx",
      "args": ["-y", "@satelliteoflove/godot-mcp"]
    }

The MCP server starts up successfully, and I confirm it connects to the plugin in Godot.

When I close claude, or reconnect to the MCP, the existing server continues running in the background. A second copy of the server is spawned, and attempts to connect to the Godot plugin, and fails:

[godot-mcp] TCP co

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/157) · 2026-03-08 · closed · external user · 4 comments

### Feature: Bidirectional Console Logging & Audit Trail

## Overview
Implement bidirectional console/logging integration between Godot and MCP server, with comprehensive audit trails including correlation IDs, timestamps, and user identifiers.

## Motivation

### 🔍 Primary Goal: Visibility & Auditability
Currently, there's a disconnect between Godot's console output and MCP server operations:
- **Godot console messages** (print statements, errors, warnings) are invisible to MCP clients
- **MCP tool executions** are invisible in Godot's console/logs
- 

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/126) · 2026-01-28 · closed · outside contributor · 4 comments

### Feature: Daemon + IPC Architecture with Interactive CLI

## Overview
Add daemon process management and IPC (Inter-Process Communication) architecture to godot-mcp, enabling persistent background connections and multiple client modes.

## Motivation

### 🚀 Primary Goal: Performance Through Persistent Connections
The **key improvement** is keeping the Godot WebSocket connection alive between MCP client requests. Without a daemon, each MCP request requires:
1. Starting a new process
2. Establishing WebSocket connection to Godot
3. Executing the request
4

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/125) · 2026-01-28 · closed · outside contributor · 4 comments

### README.md MCP config guide update for VSCode GH Copilot, GH Copilot and/or generic guide

## Problem Statement
The godot-mcp server currently only documents configuration for Claude Desktop and Claude Code. Users of other MCP clients (VSCode with GitHub Copilot, GitHub Copilot CLI, and potentially other MCP clients) need clear documentation and configuration examples to use the server.

## Proposed Approach
Expand the README.md to include configuration instructions for VSCode and GitHub Copilot CLI, following the existing pattern used for Claude Desktop and Claude Code. Alternatively

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/124) · 2026-01-28 · closed · outside contributor · 4 comments

### Feature: Godot MCP Plugin Module System

# Godot MCP Plugin Module System Implementation Plan

## Problem Statement
The current Godot MCP plugin is monolithic - all components are loaded in `plugin.gd` and a crash in any component brings down the entire plugin. During development and usage of the MCP system, errors in command handlers, WebSocket issues, or connection problems require a full plugin restart, which is disruptive and time-consuming.

## Proposed Solution
Refactor the plugin into a slim, robust core (`plugin.gd`) that dynam

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/123) · 2026-01-28 · closed · outside contributor · 4 comments

### SPIKE: game perception beyond pixels (runtime state digest + state-over-time)

## Context (SPIKE: design, not implementation)

The only reason to screenshot the game is so Claude can interpret game state. The game bridge already traverses the live runtime `SceneTree` (`find_nodes`, `get_active_processes`, `get_signal_connections` in `game_bridge/mcp_game_bridge.gd`), so structured runtime introspection is already proven feasible. This spike explores tools that convey game state more efficiently and more effectively than pixels, including state-over-time without devouring c

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/191) · 2026-05-29 · closed · 3 comments

## Most recent

### runtime_state: watch_stop/collect don't take a final sample, so end can contradict the timeline

godot-mcp 4.1.9, Godot 4.7.2. Frozen recipe: \`watch_start\` on \`/root/GameState\` fields \`floor_number\`, \`victory\`, \`game_over\` (20 Hz, 5,000 ms) plus signals \`floor_changed\` and \`run_ended\`; then \`step_until GameState.game_over\` with a \`report\`; then \`watch_stop\`.

The step's report read \`victory: true\`. The watch timeline had \`run_ended [true]\` at 1,907 ms. But the field summaries for the same call said:

\`\`\`
"/root/GameState:game_over": {"samples": 39, "start": false,

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/389) · 2026-08-27 · closed · 0 comments

### game_time: step has no report, step_until does

\`step_until\` takes \`report\` and returns the expressions with the result. \`step\` doesn't, so after a step carrying inputs I need a second call (an \`exec\`, or a \`step_until\` with a trivially true predicate) to read what the inputs did.

Case from Beatdive: \`step duration_ms 560\` with one \`move_right\` at 478 ms to land it on the beat, then \`exec\` to read the player's cell and \`Conductor.last_input_judgment\`. With \`report\` on \`step\` that's one call, and the read is on the exact

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/388) · 2026-08-27 · closed · 0 comments

### tilemap_read: get_used_cells has no tile identity, and region reads are ~90 bytes a cell

Two related things from reading a 20×12 floor in Beatdive (Godot 4.7.2, godot-mcp 4.1.9).

\`get_used_cells\` returns coordinates only: 240 \`{x, y}\` pairs, 3.5 KB, and nothing about which tile is at each. So it can't answer "where are the hazards on this floor" and I had to follow it with \`get_cells_in_region\` over the whole map anyway.

\`get_cells_in_region\` over that map came back at 21,543 bytes. Each cell is a full object (\`coords\`, \`source_id\`, \`atlas_coords\`, \`alternative_tile

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/387) · 2026-08-27 · closed · 0 comments

### Numeric watch fields carry no change events, so a value's jump has no timestamp

Godot 4.7.2, godot-mcp 4.1.8 (PR #381 head).

Numeric watch fields carry no change events, so the summary can prove a value moved but not say when.

What I did: a HUD bar's y went 58 → 69 → 58 inside a 3.8 s window (a combo threshold changed a label's font size, the row above grew, the bar shifted, an off-beat press reset it). The watch reply, at 20 Hz with the `Conductor.beat` signal recorded:

"beat_bar_y": {"start":58,"end":58,"min":58,"max":69,"mean":60.57,"slope":0,"events":[]} timeline

Read the thread · 2026-08-27 · closed · 1 comment

watch_start silently drops pos.* fields on a Control while counting them as resolved

Godot 4.7.2, godot-mcp 4.1.8 (PR #381 head).

watch_start with fields: ["pos.y"] on a Control reports the field as resolved and then leaves it out of the result.

What I did: the question was whether a HUD bar moves a few pixels when a key is pressed.

watch_start specs: [{path: "/root/Main/HUD/Margin/VBox/BeatBar", fields: ["pos.y"]},
                    {path: "/root/Main/HUD", fields: ["combo_font_size"]}]
→ resolved_fields: 2
watch_collect
→ fields: { "/root/Main/HUD:combo_font_siz

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/383) · 2026-08-27 · closed · 0 comments

### Proposal: nav action on godot_runtime_state (agent path state, map sync, find_path)

Godot 4.7.2, godot-mcp 4.1.7 (addon and server). Proposal rather than a bug.

Navigation state is reachable only through `godot_exec`. That works, but the diagnosis that prompted this took more than it should have, and it's a pattern that will recur in any project with a NavigationAgent.

What happened: a patrol guard on a freshly baked `NavigationRegion3D` didn't move for 8 s of stepped time with a valid, reachable target. `step_until` with `report` showed the position unchanged. A 5 s watch sh

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/380) · 2026-08-27 · closed · 2 comments

### godot_scene3d does not include GridMap in bounds or spatial info

Godot 4.7.2, godot-mcp 4.1.7 (addon and server).

`godot_scene3d` doesn't see GridMaps. A level that is a 10×8 GridMap (114 cells, world extent 0–20 × 0–16) plus two capsules and two small crates:

get_bounds → Visual nodes: 5 Combined AABB: pos: (-1.707, 0.200, -1.707), size: (12.707, 11.214, 17.107) Max: (11.000, 11.414, 15.400)


Nothing from the map. `get_spatial_info` on the GridMap node returns position/rotation/scale/visible with no `aabb`.

`scene3d_commands.gd` only takes a b

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/379) · 2026-08-27 · closed · 0 comments

### watch_start ignores hz: samples at a frame stride derived from one fps reading

Godot 4.7.2, godot-mcp 4.1.7 (addon and server).

`godot_runtime_state watch_start` doesn't sample at the `hz` it's given.

What I did: three watches on one node, all `hz: 10`, `duration_ms: 5000`.

- Game launched frozen, window driven by `step_until`: 144 samples in a 3,674 ms window, then 120 in 3,037 ms. About 39 Hz.
- After `thaw`, real time: 40 samples in 2,003 ms. 20 Hz, which is the default.

The cause is in `mcp_runtime_state_sampler.gd`:

_sample_interval = max(1, int(Engine.get_fr

Read the thread · 2026-08-27 · closed · 0 comments

Possible fix(deps): 9 vulnerable dependencies in package-lock.json

This might be a false positive, but server/package-lock.json around line 1987 looked worth a second pair of eyes.

The project uses fast-uri 3.1.0, which is vulnerable to CVE-2026-13676. The library fails to correctly canonicalize Unicode (IDN) hostnames, allowing an attacker to craft URLs that bypass host‑based security checks (e.g., deny‑lists, loopback filters) when the URL is later parsed by Node's native URL or fetch APIs. This can lead to unauthorized redirects, proxy abuse, or access to

Read the thread · 2026-08-26 · open · external user · 0 comments

Per-function time attribution in godot_profiler (by_function on get_data)

Godot 4.7.2, godot-mcp 4.1.4 (addon and server).

godot_profiler can say a frame spiked, but nothing in it can say which script did it.

What I did: a node with a _process that stalls 20 ms every 60th frame, attached via exec. get_data caught the spikes cleanly (20.26, 20.28, 20.44 ms at frame indices 60 apart). From there the tool has nothing: get_active_processes lists scripts that have a _process callback, not what they cost, and in this project most of the work doesn't run in `_pro

Read the thread · 2026-08-26 · open · 1 comment

get_data reports the last 300 frames only, without saying so

Godot 4.7.2, godot-mcp 4.1.4 (addon and server).

godot_profiler get_data returns statistics over the last 300 frames only, and nothing in the description or the reply says so.

What I did: start, thaw, let the game run about ten seconds at 240 fps, get_data. The reply:

"frame_count":300,"total_frames_collected":7614

Every percentile, the spike list, and the monitor trends cover those 300 frames — the last 1.25 s. The buffer is a ring (MAX_FRAMES := 300 in `mcp_frame_profiler.g

Read the thread · 2026-08-26 · closed · 0 comments

Profiler spike threshold has no floor, and actual_fps contradicts the fps monitor

Godot 4.7.2, godot-mcp 4.1.4 (addon and server).

Two things in the godot_profiler get_data reply that made it harder to read than it needs to be.

Spike threshold has no floor. It's 2 × p50. On an idle 2D game at 240 fps (median 0.25 ms, budget 4.2 ms) that comes out as >0.5ms, and the reply listed six "spikes" of 0.52–0.95 ms — none of them a quarter of the budget. With a deliberate 20 ms stall every 60th frame the five real spikes were caught fine, but each was followed by its succe

Read the thread · 2026-08-26 · closed · 0 comments

get_active_processes only walks the current scene; autoloads and exec-holder nodes are never listed

Godot 4.7.2, godot-mcp 4.1.4 (addon and server).

godot_profiler get_active_processes starts its walk at tree.current_scene, so anything hanging off /root beside the scene — autoloads, and the bridge's own exec holder — is never listed.

What I did: a 2D scene with a Conductor autoload that ticks _process every frame, plus a throwaway _process node attached under the exec holder that stalls 20 ms every 60th frame. get_active_processes returned one script:

Active processing s

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/369) · 2026-08-26 · closed · 0 comments

### digest can't reach runtime-spawned UI, and `paths` on a Control returns only its type

Godot 4.7.2, godot-mcp 4.1.2. This one is an enhancement, with numbers from a HUD built to be hard to verify from files.

What I ran into:

- `digest name: "Dmg*"` returns 0 entities with `selection: group` whenever anything is in `mcp_watch`. The tier is picked before the name filter runs, so a Label spawned at runtime is unreachable. Emptying the group just falls to `method`; there's no way to ask for the visibility tier directly.
- `digest select: none, paths: [".../Floaters/Dmg1"]` resolves 

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/360) · 2026-08-26 · closed · 0 comments

### `sequence` waits out its timeout instead of reporting that the game quit

Godot 4.7.2, godot-mcp 4.1.2.

A `sequence` of [game_pause, ui_down, ui_down, ui_accept] pressed the Quit button in my pause menu. The game exited, as it should. The call returned `[TIMEOUT]` after 17.6 s. A `godot_game_time status` a few seconds later returned `NOT_RUNNING` in 4 ms, so the server already knew.

It would be nice if any in-flight game-side call (sequence, step, step_until, exec, watch_collect) failed fast with something like `GAME_EXITED` when the debugger session closes. That tu

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/359) · 2026-08-26 · closed · 0 comments

### `sequence` times out when a `report` probe changes Variant type between before and after

Godot 4.7.2, godot-mcp 4.1.2 (addon and server).

With a pause menu open and a button focused, I ran a `sequence` (ui_down ×3, ui_up ×2, ui_accept) with this probe:

"report": ["str(root.gui_get_focus_owner().get_path()) if root.gui_get_focus_owner() else """]


The inputs all landed (the menu resumed the game), but the call came back with `[TIMEOUT] Timed out waiting for input sequence to complete` after ~17.8 s. Same inputs with `"report": ["tree.paused"]` complete in 810 ms. Reproduc

[Read the thread](https://github.com/satelliteoflove/godot-mcp/issues/358) · 2026-08-26 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/satelliteoflove/godot-mcp/issues).