GodotLens: Godot's own view of your GDScript project

An MCP server that lets an AI agent ask Godot itself about your project — where a symbol is used, what a method's real signature is, whether an edit compiles, how a scene is wired, and what the game actually printed when it ran.

Why

An agent editing GDScript from text alone is guessing. It cannot tell a call from a comment, cannot know which methods exist on a CharacterBody2D in your Godot version, cannot see that a signal handler is wired by name inside a .tscn, and cannot see what happened at runtime.

GodotLens never answers those questions itself. It asks the engine and returns the engine's answer. Measured on Godot 4.7.1, in a project where take_damage is defined in player.gd, called twice from enemy.gd, once from player.gd, and named in a comment:

That principle — delegate every judgement to Godot — is what makes the answers trustworthy, and it is why the tool names tell you where an answer came from. gdscript_* is the language server. scene_* and project_config run the engine. debug_* is the debugger.

Related MCP server: Godot MCP Server

Requirements

Godot 4.6 is the floor because the language server changed materially at 4.5 (URI encoding) and 4.6 (document ownership). Older versions are refused with a clear message rather than silently misread.

The editor does not need a visible window — this is what CI uses:

godot --path <project> --editor --headless --lsp-port 6005 --dap-port 6006

Install

npx (recommended). The package bundles the server; there are no runtime dependencies.

{
  "mcpServers": {
    "godotlens": {
      "command": "npx",
      "args": ["-y", "godotlens-mcp"]
    }
  }
}

pip

pip install godotlens-mcp

{
  "mcpServers": {
    "godotlens": { "command": "godotlens-mcp" }
  }
}

The loop

The tools are designed around one cycle. Read it once and the rest of this document is a reference.

flowchart LR
    U["<b>Understand</b><br/>gdscript_find<br/>gdscript_references<br/>gdscript_hover"]
    W["<b>Write</b><br/>gdscript_engine_api<br/>gdscript_complete<br/>gdscript_validate"]
    S["<b>Sync</b><br/>gdscript_sync_file"]
    V["<b>Verify</b><br/>gdscript_diagnostics<br/>scene_validate"]
    R["<b>Run</b><br/>debug_run<br/>debug_output"]

    U --> W --> S --> V --> R
    R -- "something is wrong" --> U

    classDef step fill:#f5f7fa,stroke:#4a6785,stroke-width:1px,color:#1b2733;
    class U,W,S,V,R step;

1. Understand. gdscript_find locates a symbol by name; gdscript_references and gdscript_hover explain how it is used and what type it is.

2. Write. gdscript_engine_api gives real signatures instead of recalled ones, gdscript_complete offers scene-aware candidates, and gdscript_validate checks proposed content before it reaches disk.

3. Sync. Godot's language server does not watch the filesystem. After editing a .gd file, call gdscript_sync_file or it keeps answering from the old text.

4. Verify. gdscript_diagnostics for compile errors, scene_validate for the wiring the compiler cannot see.

5. Run. debug_run starts the game and returns what it printed.

Two conventions apply throughout:

• All line and character parameters are 0-indexed, matching the LSP. Editor line 1 is line 0. gdscript_find exists partly so you rarely have to compute one by hand.

• Results carry a verified flag where it matters. verified: false with an empty diagnostics list means Godot never reported back — that is not a clean bill of health.

Tools

Understanding code

Writing code

Keeping Godot in step

Project and scenes

These invoke the Godot binary so scenes resolve exactly as the engine builds them, inherited scenes included. They do not parse .tscn as text.

Runtime

Godot serves a Debug Adapter Protocol server from the editor, no addon required. The language server tells you whether code compiles; only the debugger tells you what it did.

What Godot cannot tell you

Worth knowing before you trust a result:

• The language server reads .gd files only. A signal handler wired in a .tscn [connection] block is invisible to it, so renaming that handler leaves the scene pointing at a method that no longer exists — and that fails at runtime with no compile error. This is why scene_validate exists and why gdscript_rename warns.

• Autoload and input action names are bare strings. GameState.add_score(1) and Input.is_action_pressed("jump") are validated by nothing at all. Check them against project_config before writing them.

• gdscript_references is expensive on 4.6+, reparsing every script in the project. Prefer gdscript_references_in_file when one file is enough.

Architecture

Three mechanisms, one process. Each tool group maps to exactly one of them, which is how you know where an answer came from.

flowchart TD
    Agent["AI Agent"]
    GL["<b>GodotLens</b><br/>MCP server · JSON-RPC 2.0<br/>Python 3.10+ · no dependencies"]

    Agent <-- "stdio" --> GL

    GL -- "TCP 6005<br/>language server" --> Editor
    GL -- "TCP 6006<br/>debug adapter" --> Editor
    GL -- "subprocess<br/>--headless --script" --> Binary

    Editor["<b>Godot Editor</b><br/>must be open<br/><i>gdscript_* · debug_*</i>"]
    Binary["<b>Godot binary</b><br/>invoked on demand<br/><i>scene_* · project_config</i>"]

    classDef svc fill:#eef4fb,stroke:#4a6785,stroke-width:1px,color:#1b2733;
    classDef godot fill:#f3f0fb,stroke:#6b5b95,stroke-width:1px,color:#1b2733;
    class Agent,GL svc;
    class Editor,Binary godot;

The MCP and LSP/DAP protocols are implemented directly against the standard library, so the package has zero runtime dependencies and the npm bundle is a handful of .py files.

Configuration

Contributing

pip install -e ".[dev]"
pytest -m "not integration"   # no Godot needed
ruff check .

Integration tests launch a real headless Godot and skip cleanly without one:

GODOT_BIN=/path/to/godot pytest -m integration

CI runs the suite on Linux, Windows and macOS across Python 3.10–3.13, runs the integration tests against a real Godot on all three, and installs the built npm tarball and executes it.

License

Apache License 2.0 — see LICENSE and NOTICE.