UAsset Reference MCP: Modeling Unity Addressables Separately

Addressables changed the unused-asset question in UAsset Reference MCP. A texture, prefab, or scene can be unreferenced by serialized assets and still be intentionally loaded through an Addressables entry.

That means a reference graph needs two different kinds of evidence. One answers whether a serialized asset points to another asset. The other answers whether an asset is reachable because the project declares it as Addressable content.

Serialized References and Addressables Answer Different Questions

The first release of UAsset Reference MCP focused on Unity’s serialized reference records. In text mode, Unity writes links as {fileID, guid, type} values. Those records are direct asset-to-asset edges.

Addressables are not the same shape. An Addressables group file describes entries, labels, read-only state, group membership, and an address that can be loaded at runtime. That metadata does not mean another asset serialized a field reference to the entry. It means the project author declared the entry as loadable content.

Flattening both concepts into one edge type would make the graph easier to query but harder to trust. A developer reviewing unused assets needs to know why an asset is reachable.

Serialized edge:
Assets/Scenes/Battle.unity -> Assets/Prefabs/Enemy.prefab

Addressables reachability:
Addressables group "RemoteCharacters" contains Assets/Prefabs/Enemy.prefab

Those statements support different decisions. The scene edge explains a concrete dependency. The Addressables entry explains runtime availability.

Normalized Tables Keep the Model Honest

UAsset Reference MCP stores Addressables metadata in separate SQLite tables instead of hiding it inside the regular edges table.

addressable_groups
addressable_entries
addressable_entry_labels

The group table records the Addressables group identity and source file. The entries table records the asset GUID, address, owning group, read-only state, and indexed source bytes. Labels live in their own table because one entry can have multiple labels, and queries need deterministic filtering.

This structure keeps regular graph traversal simple while still letting the query layer answer Addressables-specific questions. find_unused_assets can treat Addressables entries as roots when configured to do so, while get_addressable_info can explain the exact group and labels that make one asset reachable.

Reachability Is a Review Signal

reachableOnlyBecauseAddressable is deliberately a review signal. It tells the user that an asset is not reachable through scenes or serialized asset references, but it is reachable through Addressables metadata.

That distinction matters because Unity projects often load content through code:

Addressables.LoadAssetAsync<GameObject>("EnemyBoss");

Static graph indexing does not prove whether string-based runtime loading is used correctly. It can show that the asset is declared as an Addressables entry and that no serialized edge points at it. A developer still needs to review the loading code before deleting or moving the asset.

The tool avoids presenting Addressables reachability as deletion safety. It reports the graph evidence and leaves the production decision with the engineer.

MCP Tools Make Addressables Queryable

The Addressables release added read-only MCP tools for common inspection paths.

get_addressable_info(asset)
search_addressables(query?, group?, label?, pathPrefix?, type?, reachableOnlyBecauseAddressable?, limit?)
list_addressable_groups()

get_addressable_info resolves one asset or Addressables address and returns membership, owning group, labels, reference counts, and reachability signals. search_addressables gives agents bounded discovery across entries. list_addressable_groups gives a compact inventory of groups, labels, entry counts, and indexed source bytes.

The tools are intentionally read-only. They help an agent explain the project; they do not rewrite Addressables configuration, move entries between groups, or predict bundle output.

Verification Uses Real Project Exports

Addressables parsing has more edge cases than plain .meta GUID scanning. Group files can have different layouts, entries can be read-only, labels can be absent, and generated metadata can vary between package versions.

The implementation was verified against Unity-side exports from a real project. The verification flow compares what Unity reports with what the Node indexer stored. That gives the parser a concrete contract: group identity, entry identity, labels, and reachability data must match the project Unity understands.

The result is still scoped. Stage 1 models Addressables discovery and query behavior. Group schemas, profiles, providers, packing, compression, build/load paths, content-update settings, and bundle analysis remain outside this release.

Addressables support is useful because it keeps the asset graph from pretending every reachable asset is reachable for the same reason. Serialized references, Addressables entries, and runtime string loads need separate evidence. UAsset Reference MCP models the first two directly and makes the third explicit as a limitation.