Sangsik Gdscript Graph

A function-level call-graph indexer for GDScript/Godot projects, exposed as an MCP server so AI coding assistants can answer questions like "what calls this function?" or "what would break if I change this signal?" without re-reading the whole codebase.

It parses every .gd file in a Godot project with gdtoolkit's GDScript grammar, resolves calls and signal connections across files (autoloads, class_name, inheritance, inner classes, lambdas, property accessors, chained signal receivers, etc.), and stores the result in a SQLite database that the MCP server queries on demand.

Features

• Call resolution across bare calls, self. calls, super. calls, autoloads, class_name-typed receivers, and locally-typed variables — including inheritance chains.
• Signal resolution for .connect(...) on both the signal side and the handler side: bare/self/inherited signals, and chained receivers (GameManager.card_drawn.connect(handler)).
• Scoping: inner classes, property accessors (get:/set(value):), lambdas, static functions are all tracked with correct scope boundaries.
• Robust by design: pathologically deep GDScript files are isolated (a parse/recursion failure in one file doesn't abort the whole build), builds are atomic (a failed rebuild never corrupts an existing database), and known ReDoS-prone .tscn parsing paths are hardened.
• Transitive impact analysis: BFS over the call graph to answer "everything that calls (or is called by) this function, up to N hops."
• Auto-sync while the server runs: an OS-level file watcher (FSEvents/inotify/ReadDirectoryChangesW) rebuilds the graph automatically a short debounce window after you edit a .gd/.tscn/project.godot file — no manual rebuild needed during a normal editing session.
• Incremental rebuilds: each build caches every file's parsed tree (keyed by content hash); a rebuild reuses the cache for every unchanged file and only re-parses what actually changed, with output identical to a full rebuild either way. On a 433-file test project this cut rebuild time by ~3x overall (parsing itself, which dominates build time, got ~4.5x faster).
• Reconciles offline edits on startup: a live file watcher only sees changes made after it starts, so every server start also runs one reconciliation rebuild in the background (cheap thanks to the incremental cache) to catch up on anything edited while no server was running — e.g. an MCP client spawning a fresh server each session after you edited the project in the Godot editor in between.

Installation

pip install -e .

Requires Python 3.10+.

Usage

1. Build the graph

gdscript-graph build /path/to/godot/project -o graph.db

This scans every .gd file (plus project.godot for autoloads and .tscn files for autoload scenes), resolves calls and signal connections, and writes a SQLite database to graph.db (defaults to <project>/.gdscript_graph.db if -o is omitted).

2. Run the MCP server

gdscript-graph mcp graph.db

This starts an MCP server over stdio and, by default, watches the project directory (recorded in the database at build time) for changes -- editing a .gd/.tscn/project.godot file triggers an automatic rebuild ~2 seconds after your last edit, with no restart needed. Pass --no-watch to disable this, or --debounce-ms <n> to change the delay.

Point your MCP client (Claude Code, Claude Desktop, etc.) at this command, e.g. in a Claude Code MCP config:

{
  "mcpServers": {
    "gdscript-graph": {
      "command": "gdscript-graph",
      "args": ["mcp", "/path/to/graph.db"]
    }
  }
}

Available MCP tools

file/scope disambiguate when multiple declarations share a name (same-named function in different files or inner classes).

Development

pip install -e . pytest
pytest -q

The MCP server re-reads the DB file fresh on every query, so any rebuild while the server is running (whether triggered by the file watcher or run manually) is picked up immediately without a restart.