Skip to main content
Glama

The project's files as a graph: unused, why used, what a scene loads

godot_deps
Read-onlyIdempotent

Trace Godot project dependencies from startup scenes and autoloads to resources: find unused files, explain why a file is reached, list what a resource loads, and detect load cycles. Read-only.

Instructions

Follow what loads what, from where the game starts (main scene, autoloads, every res:// path in project.godot, export include filters, the shipped file list from godotwright.json, add-ons, tests, editor scripts), through ext_resource, preload, load, class_name, folders and file names the code builds paths from, textures next to models and import settings. op unused: files nothing reaches, biggest first, whole folders as one line (when in doubt a file counts as used, so the list can be trusted). op why (file): the chain from the game to the file, before you delete or move it. op of (file): what a scene or resource loads with it, biggest first, what it can load later, and paths that do not exist. op cycles: scenes or resources that load each other through ext_resource, which Godot cannot load (it reports "[ext_resource] referenced non-existent resource" for a file that is there). Read-only.

Input Schema

NameRequiredDescriptionDefault
opYesunused, why, of or cycles
fileNowhy and of: the res:// file
pathNoThe project folder, or any file or folder inside it (Godotwright walks up to project.godot). Relative paths start at the server's folder. Default: the current project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the simple 'Read-only' annotation, the description details the immense scope of the analysis, including textures, import settings, and how file paths are constructed. This specific technical detail is a rich disclosure of behavioral capabilities.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, every sentence is packed with technical, high-density information and is logically structured from overall function down to specific operational details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of Godot's internal dependency graph, the description is extremely complete, covering scope, implementation logic, and the exact data returned by each operational query.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the description adds maximum value by defining the semantic meaning of each enum value for the 'op' parameter. It explains exactly what result the AI should expect for 'why' versus 'of'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description immediately establishes the tool's high-level purpose: treating project files as a dependency graph. It clearly outlines the four distinct operations (unused, why, of, cycles) available under this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The tool provides specific guidelines by defining the use case for each operation (e.g., when to look for an unused file vs. when to trace a load chain). The broad scope mentioned ('from project.godot' to 'godotwright.json') also provides clear boundaries for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.