UAsset Reference MCP: Building a Unity Asset Reference Graph

UAsset Reference MCP turns a Unity project’s serialized assets into a queryable reference graph. The indexer reads Unity’s .meta GUIDs and YAML reference records, stores the result in SQLite, then exposes that database through a CLI, an MCP server, and a local web viewer.

The goal is to answer asset questions before they become production problems. If a developer wants to delete a material, rename a prefab folder, split an Addressables group, or understand why a scene pulls in a dependency chain, the graph gives them a concrete answer instead of a manual search across the Project window.

Unity Already Stores the Asset Graph

Unity assets have stable identity through .meta files. A prefab, scene, material, texture, script, or Addressables asset has a GUID that other serialized files can reference.

When a project uses text serialization, Unity writes asset references into YAML-like files as records such as {fileID, guid, type}. That format is not a guess. It is the same reference information Unity uses to reconnect serialized fields to project assets.

UAsset Reference MCP builds on that property. The indexer scans project assets, parses each asset’s .meta GUID, extracts serialized reference records, resolves those GUIDs back to asset paths, and stores the result as directed edges.

Assets/Scenes/Battle.unity
  -> Assets/Prefabs/Enemy.prefab
  -> Assets/Materials/BattleFloor.mat

Assets/Prefabs/Enemy.prefab
  -> Assets/Textures/Enemy_Diffuse.png
  -> Assets/Animations/Enemy.controller

That graph becomes useful once it is durable. A one-off scan can answer one question, but a SQLite index lets command-line tools, MCP clients, and the web viewer share the same model.

SQLite Is the Boundary Between Indexing and Querying

The indexer writes .asset-memory/index.db inside the Unity project. That database stores assets as nodes, references as edges, unresolved references as broken links, and Addressables metadata in normalized tables.

SQLite keeps the tool simple. There is no service to deploy, no graph database to run, and no MCP client lock-in. The MCP server can expose curated tools for agents, while external scripts can still inspect the artifact directly when needed.

The core workflow looks like this:

unity-asset-reference-mcp-index index /path/to/UnityProject --force

After indexing, the project has a local graph database:

/path/to/UnityProject
└── .asset-memory
    └── index.db

The same index can support impact analysis, dependency tracing, unused-asset review, broken-reference reporting, and JSON export without rescanning the project for every query.

MCP Gives Agents a Curated Query Surface

The MCP server runs over stdio and works with MCP-compatible hosts. Instead of giving an agent raw SQL access, it exposes specific tools with bounded behavior.

{
  "mcpServers": {
    "unity-asset-graph": {
      "command": "npx",
      "args": ["-y", "unity-asset-reference-mcp", "--project", "/path/to/UnityProject"]
    }
  }
}

An agent can then ask practical Unity questions through tools such as find_references, get_dependencies, trace_path, find_unused_assets, search_assets, and get_overview.

That boundary matters. The agent receives a project-specific graph interface, not a general file-system search habit. It can answer, “what references this prefab?” or “why is this texture reachable?” with graph data instead of scanning every YAML file during the conversation.

Verification Keeps the Parser Honest

The Node indexer parses Unity serialization outside the Unity Editor. That keeps indexing scriptable and agent-friendly, but it also means the parser needs a way to prove its results against Unity’s own view of the project.

The companion Unity package exports a verification file from the Editor:

Tools > Asset Reference Memory > Export Verification

The CLI compares that export against the SQLite graph:

unity-asset-reference-mcp-index verify-index /path/to/UnityProject \
  --verify /path/to/UnityProject/.asset-memory/verify.json

This makes parser accuracy measurable. Missed edges, extra edges, and unresolved references can be reported as data instead of discovered later through a broken production workflow.

What This Series Will Cover

This first post sets the boundary of the tool: Unity text serialization in, SQLite graph out, MCP and viewer queries on top. The rest of the series can go deeper into the implementation details that made the asset useful in real projects.

Future posts can cover the GUID and YAML parser, the SQLite schema, incremental indexing, Addressables modeling, MCP tool design, the web viewer, and the Unity verification harness.

The useful part is not that Unity assets can be scanned. The useful part is turning Unity’s existing serialized reference data into a durable graph that both developers and agents can query before changing a project.