Quartermaster is an MCP server that lets AI agents search, inspect, validate, and import a user's locally indexed game-dev asset vault (Unity, Fab, Quixel, Gumroad, Cosmos) using hybrid keyword, semantic, and visual search.
search_owned_assets – hybrid keyword/semantic/vision search across the vault, filterable by engine, source, category, pipeline, and local-only status.
get_asset_details – fetch full metadata, gallery, usage notes, and store URL for a specific asset.
list_asset_categories – see category breakdowns and owned-asset counts.
get_stack_recommendations – map a game/feature brief onto owned packages that fit each aspect.
audit_project – detect engine, version, and render pipeline of a Unity or Unreal project to avoid mismatches.
import_asset_to_project – unpack a locally downloaded .unitypackage safely into a Unity project's Assets/ folder.
validate_stack – lint a planned asset stack for role conflicts, family notes, and missing prerequisites.
list_stack_recipes – show curated production stacks resolved against the user's own library.
get_vault_stats – summarize vault totals by source/category and local vs cloud availability.
Allows agents to search and import the user's owned Epic Games Fab library and VaultCache, including harvesting purchase history, enriching metadata, and unpacking cached assets into projects.
Allows agents to search the user's Unity Asset Store library, find owned assets by keyword, natural language, or visual similarity, validate asset compatibility, and unpack selected packages directly into a Unity project's Assets folder.
This project started because I wanted to prototype a dam.
Nothing serious — a short demo, maybe more if it worked out. Before building anything, I wanted to see what I already owned that could speed it up. So I searched my library for "dam": nothing came back. Of course nothing came back — no asset is called a dam. But spread across four packages I already owned were curved concrete meshes, a water system, some rocky terrain. Everything the dam needed. I'd had most of it for years and never once connected the pieces.
That's what ~1,500 assets across two stores did to me when this started — a library that has since grown past 7,500 assets across five ecosystems. Almost all of it from bundles and sales, none of it remembered. And it's not just me — no AI assistant knows either. Ask one for help and it either builds everything from scratch or sends you shopping, while hundreds of dollars of exactly-the-right-thing sits on your disk.
Quartermaster indexes everything you own across the Unity Asset Store, Fab, Quixel Megascans, Gumroad and Leartes Cosmos — locally, on your machine — and serves it to your coding agent over MCP. It's the tool I wished existed that day: ask about a dam, get told you already own curved concrete meshes.
you → "I want to build a dam — what do I have to work with?"
agent → search_owned_assets(...) finds the concrete meshes, water FX, terrain
└─ Nordic Coastal Cliff (Quixel) · 5785 px/m · 2.03 × 2.92 × 2.44 m
maps: Basecolor, Normal, Displacement, Cavity, AO, Roughness…
validate_stack([...]) checks none of them fight each other
import_asset_to_project(...) unpacks into Assets/, demos strippedEvery result is something you own or can claim free — nothing is invented.
Typing a description, not a name — none of those results share a word with the query.
Why Quartermaster? A quartermaster's job was never remembering what's in stores — it's making sure you're equipped when it's time to move. That's nearer the real problem than forgetting is. I hadn't lost anything; I knew I owned stuff. What I couldn't do was get from "I want to prototype a dam" to "open these four packages" without an hour of digging first — and maybe more if it worked out doesn't survive an hour of digging. Ideas that arrive that way don't get rejected. They just quietly don't happen, and you never find out whether they would have.
Source | What comes in | How |
Unity Asset Store | Owned packages, descriptions, gallery art | Authenticated harvest |
Fab (Epic) | Owned Unreal and Unity listings | Authenticated harvest |
Quixel Megascans / Megaplants | The catalog, with texel density, scan area and map lists | Public catalog sync |
Gumroad | Owned products | Authenticated harvest |
Leartes Cosmos | Owned and claimable Cosmos inventory, with deep screenshot galleries (18 on average, up to 71) | Authenticated harvest |
Everything lands in one SQLite table behind one search surface, so a query crosses all of them at once. Nothing is engine-scoped: a Megascans surface and a Unity shader come back from the same question if they both answer it.
Related MCP server: Unity API Communicator MCP Server
Neither store will admit what you own.
Unity removed /account/purchases (404 since August 2026). Fab has no ownership API, no export button, nothing. Your purchase history exists only inside their private GraphQL, behind SSO, MFA, and bot detection.
Getting at it took four attempts, three of them failures:
Playwright's bundled Chromium — Epic's captcha refuses it outright ("enable JavaScript").
Playwright driving your real browser — injects detectable hooks; Epic throws a second security wall after the password.
Debugger attached during sign-in — same result. Anything touching the login flow gets flagged.
What actually works: stop automating the sign-in entirely. You log in through an ordinary browser window — no debug port, nothing between you and the store — because the automation was itself what tripped the risk systems. Only after you're done, on a session you established yourself, does Quartermaster attach a debugger and replay the store's own paginated queries — with its own CSRF headers, its own chunking (42 IDs per request, because that's what Unity's client sends).
That trick is most of this project. The rest — search, linting, unpacking — is honestly straightforward by comparison.
Two hard-won rules baked into the design, if you ever hack on this yourself:
Browsers must close gracefully (taskkill without /F). An abrupt kill loses Unity's device-trust cookie and you'll get MFA-challenged on every future session.
Never run a library fetch headless. Headless triggers Unity's risk system even with valid cookies.
Fab's library view and the Megascans catalog are not the same list, and there is no export that reconciles them — you can hold rights to far more Megascans content than your library page displays. Whatever the cause, the practical result is the same: scrolling and hand-searching for something you already have.
Quartermaster sidesteps it. It syncs the Quixel Megascans and Quixel Megaplants seller catalogs from Fab directly — 5,580 listings as of this writing — independently of what your library view shows, and files them next to everything else you own, tagged by status:
vault_owned — in your library
catalog_grant — claimable free under the Epic Content License, not yet acquired
Both are searchable, and every result says which it is, so an agent can tell "you own this" from "you can have this for nothing" without guessing.
Megascans rows also carry their physical specs where the listing publishes them — texel density, scan area, and the map list (basecolor, normal, displacement, cavity, AO, roughness…). That is the difference between an agent telling you it found a rock and an agent telling you it found a 1×1 m scan at 8192 px/m with displacement — which is the part that decides whether it's usable.
python -m src.store_client sync-quixel # catalog
python -m src.store_client enrich-quixel # texel density, scan area, mapsSearch that understands intent & vision. This is the dam problem.
Exact keywords via SQLite FTS5.
Natural language intent via local ONNX text embeddings (BAAI/bge-small-en-v1.5) — "concrete structures for holding back water" surfaces meshes and shaders whose listings never mention dams.
Cross-modal visual understanding via ONNX CLIP embeddings (Qdrant/clip-ViT-B-32) — searching "gothic cathedral" literally scores your screenshots and promo renders, finding assets even when their text descriptions are completely silent. A visual hit also hands back which screenshot matched, not just the cover art.
Every result shows its working. Each hit carries a match field — keyword, semantic+vision, keyword+semantic+vision — so you and your agent can see which signal fired. A pure-vision hit on a listing with useless marketing copy is a different kind of result than an exact title match, and it should be legible as one.
Concept tags mined from screenshots. The offline vision pass scores every gallery image against a visual vocabulary and writes the survivors back into the FTS index, so "medieval village" and "dark horror atmosphere" become keyword-searchable on assets whose descriptions never said either. The vocabulary is a JSON file you can replace — see docs/concepts.md.
All three signals are fused with 3-way Reciprocal Rank Fusion (RRF) on your CPU. No GPU, no vector database process, no cloud API — ONNX Runtime and a numpy matrix, in the same process as everything else.
Measured on a ~7,500-asset vault: ~520 MB peak RAM with both models resident, ~1.4 s for the first query (loading BGE and CLIP), ~85 ms warm after that. The models load lazily, so an agent that never searches never pays for them.
Ground truth about your disk. Scans %APPDATA%/Unity/Asset Store-5.x/ and Epic's VaultCache so every result knows whether it's already downloaded or cloud-only. Agents prefer what's local — a zero-download import beats a 4 GB one.
A linter for stacks. Two vegetation renderers will fight. A MicroSplat module without core MicroSplat silently does nothing. A URP-only shader in an HDRP project renders pink. Quartermaster catches these before you spend an afternoon on them.
Direct unpacking. Extracts cached .unitypackage files straight into Assets/, dropping /Demo/, /Samples/, /Documentation/ and PDFs on the way in — typically 60–80% less bloat per package. Every declared path is normalized and asserted inside <project>/Assets/; escapes are structurally impossible, not just filtered.
The standalone bundle — download Quartermaster-windows-x64.zip from Releases, unzip anywhere. No Python required.
Quartermaster.exe — Desktop GUI with Win+Alt+V spotlight search, store harvesting, library browsing, and direct unpacking.
Quartermaster-mcp.exe — Standalone MCP stdio server for Claude Desktop, Cursor, Antigravity, and Windsurf.
Your library data lives safely in %LOCALAPPDATA%\Quartermaster, so upgrades are simple folder replacements with zero data loss.
From source — needs Python 3.10+.
git clone https://github.com/Tanshaydar/Quartermaster.git
cd Quartermaster
pip install -r requirements.txtSeed your library:
1. Sign in. The one step that needs you. A normal browser window opens; 2FA and captchas behave exactly as they always do. Close it when you're done and the session persists locally.
python -m src.store_client login unity
python -m src.store_client login fab
python -m src.store_client login gumroad # optional
python -m src.store_client login cosmos # optional — Leartes Cosmos2. Harvest and enrich. Long-running, resumable, safe to re-run — each picks up where it stopped.
python -m src.store_client fetch unity
python -m src.store_client fetch fab
python -m src.store_client fetch gumroad # if you signed in above
python -m src.store_client fetch cosmos # if you signed in above
python -m src.store_client sync-quixel # Megascans/Megaplants catalog — no login needed
python -m src.store_client enrich # descriptions and cover art, politely batched
python -m src.store_client enrich-quixel # Megascans scan specs
python -m src.store_client fab-deep-media # Fab only: plain HTTP is 403'd, galleries need the authed browser3. Build the local indexes, then scan your disk.
python -m src.semantic build # text embeddings
python -m src.vision build # screenshot embeddings + concept tagging
python -m src.local_scan # which of them are already downloaded heresemantic build and vision build are what make "concrete structures for holding back water" and visual concept queries find your assets. Skip them and search still works, but only on exact keywords.
Run local_scan after you have a catalog, not before. Scanned against an empty vault it has nothing to match filenames against, so it files every cached package as its own bare entry. Harmless — the next scan reconciles them against the real catalog — but you'll see doubles until then.
Already have CSV exports from the stores? Skip the browser entirely:
python -m src.ingest # eats any CSVs in data/seed/
python -m src.semantic build # still needed — see the note above
python -m src.local_scan # then find what's already on diskConnect your agents:
Option A: Auto-registration (one command)
# Standalone binary users:
Quartermaster-mcp.exe --register --all
# Source users:
python -m src.register --all # Claude Desktop, Cursor, Windsurf, Antigravity
python -m src.register --all --dry-run # look before you leapRegistration merges into existing client configs and creates a .quartermaster-backup first. It won't clobber your other servers.
Option B: Manual config Paste the server block into your client configuration:
Standalone binary:
{
"mcpServers": {
"quartermaster": {
"command": "C:/path/to/Quartermaster/Quartermaster-mcp.exe",
"args": []
}
}
}From source:
{
"mcpServers": {
"quartermaster": {
"command": "python",
"args": ["-m", "src.mcp_server"],
"cwd": "C:/path/to/Quartermaster"
}
}
}Claude Desktop reads %APPDATA%/Claude/claude_desktop_config.json, Cursor ~/.cursor/mcp.json, Windsurf ~/.codeium/windsurf/mcp_config.json.
First-run model warm-up: On the very first natural language or vision search, the embedding models (BAAI/bge-small-en-v1.5 and clip-ViT-B-32) are downloaded and cached locally by ONNX Runtime (~150 MB). The first query may take 3–5 seconds while loading into memory; every subsequent query executes in ~100 ms.
Tool | Answers |
| What do I own that fits this? Hybrid keyword + semantic. |
| Full metadata, usage notes, gallery, store URL. |
| Maps a feature brief onto owned packs. |
| Will these fight each other? Role conflicts, missing prerequisites. |
| Curated production stacks resolved against your library. |
| Engine, version, render pipeline of a target project. |
| Unpack a local package into |
| Category breakdown and counts. |
| Totals by source and category, local vs cloud. |
Two files let you teach Quartermaster your own vocabulary, no code changes needed:
data/recipes.json — roles, prerequisites, and curated stacks. This is what the conflict linter reasons with: which assets compete for the same job, what needs what, and which combinations you consider a known-good stack.
data/concepts.json — the visual vocabulary CLIP scores your screenshots against. The shipped list is game-shaped; if you do archviz or previs, replace it and rebuild.
Both are plain JSON read at runtime, and both have a reference page under docs/.
Desktop app (run_desktop.bat) — PySide6 spotlight search with tray icon; press Win+Alt+V anywhere in Windows. Runs alongside your agent without getting in its way — the database runs in WAL mode, so the GUI writing while your agent searches never blocks either of them.
It is more than the search bar, though that is the part you will use most:
Hit space on any result for a full-size preview, the way Finder does it. Detail panes carry up to 24 gallery shots, decoded and cached in the background.
Megascans rows show their scan specs inline — texel density, physical dimensions, PBR map list — so you can tell a 5785 px/m cliff from a 1 m tiling surface without opening the store page.
Reveal in Explorer, Unpack to Unity (same sandbox and demo-stripping as the MCP tool), and Copy Context, which dumps an asset's title, publisher, pipelines, formats, specs and disk path as a plain-text block you can paste straight into a chat.
Filter by source (Unity, Fab, Quixel, Gumroad, Cosmos), by pipeline (HDRP, URP, Built-in), or to what is already on disk.
Logins, harvests and the Quixel sync all run from here with live progress and a running ETA, and every one of them is resumable.
Web UI (run_ui.bat) — dark-mode dashboard at http://localhost:7890.
In Unity — import editor_bridge/Quartermaster-Bridge.unitypackage, then Window > Quartermaster. Search and import without leaving the editor. Small aside: that bridge package is generated by src/build_bridge.py, which writes the same tar format unpacker.py reads. Dogfooding on purpose.
This thing holds store sessions and writes into your projects, so it takes the local API seriously:
Every state-changing endpoint requires a token (generated on first run, stored in data/.auth_token, mirrored for the Unity bridge). Send it as X-Quartermaster-Token or Authorization: Bearer; the web UI gets a SameSite=Strict cookie automatically.
Cross-origin requests are rejected even with a valid token.
The unpacker sandbox collapses .. segments, strips drive letters and control characters, relocates anything outside Assets/ under Assets/_Quartermaster_Imported/, and asserts the final path lands inside the project — enforced by tests, not vibes (python run_tests.py -v).
The image proxy is domain-allowlisted, blocks private ranges and metadata endpoints, re-validates every redirect hop, caps sizes, and prunes the oldest entries once the cache passes its file cap.
Nothing phones home. Your library, embeddings, disk paths, and store sessions stay on this machine.
Optional keys in config.json (created on first run):
Key | Default | Purpose |
|
| Web UI / API port. |
|
| Any fastembed-compatible model. Change it and rebuild the index. |
| auto-detected | Override Fab VaultCache locations. |
| demos, docs, PDFs | What the unpacker discards. |
|
| Politeness throttle for enrichment. |
|
| Disk cache for proxied cover art. |
Windows-first, Linux-capable. Windows is the tested platform, and the Win+Alt+V hotkey is Windows-only. A linux-x64 build ships and disk scanning knows the Linux and macOS cache roots, but they see far less mileage than the Windows paths do. There is no macOS build.
One machine, one user. No sync, no server mode. Deliberate.
Harvesting is scraping. Unity and Fab change their internals whenever they feel like it, and have — the chunk sizes, endpoints, and GraphQL shapes in here are correct as of the day I shipped, not forever. When a fetch comes back empty, data/store_harvest.log records every JSON response seen; that's where to start digging.
Taxonomy is heuristic. Categories are inferred via a multimodal blend of word-boundary tokens, store tags, and zero-shot CLIP visual concept mining from screenshots. Highly stylized titles without screenshots default to Tools & Utilities, though semantic vector search and hybrid search always cover the entire vault regardless of assigned category. Tuning the visual vocabulary is documented in docs/concepts.md.
Indexing stops at the package boundary & store metadata is noisy. Search operates across titles, descriptions, tags, and whole-image CLIP embeddings of gallery screenshots. It faces two structural limits:
No internal asset indexing: It does not unpack archive contents to index individual sub-meshes, prefabs, or internal filenames (e.g. searching for a specific architectural sub-element like a "pantile" or "curved concrete riser" inside a modular environment pack won't hit unless declared in the listing text or prominent in gallery renders).
Vacuous store boilerplate: A noticeable fraction of store listings (particularly Unity's templated og:description) contain pure marketing boilerplate ("Elevate your workflow with...") that carries zero technical information. The visual CLIP embeddings exist precisely to bridge this gap, but whole-image vectors cannot always resolve fine-grained sub-elements.
Unpacking is Unity-only. Fab assets are indexed and searchable, but .unitypackage extraction obviously doesn't apply.
Open an issue. It's a solo project, so I can't promise a response time, but I do read them.
What helps, by symptom:
A fetch came back empty or short. This is the most likely thing to break, because the stores change their
internals without notice. data/store_harvest.log records every JSON response the harvest saw — the tail of
that file is the whole diagnosis. Include it.
Search returns nothing sensible. Check python -m src.vision status first. An unbuilt index degrades to
keyword-only silently, and that accounts for most "search is broken" reports.
Wrong categories, or a conflict that isn't real. That's usually the knowledge base rather than the code —
docs/recipes.md and docs/concepts.md cover how to fix it yourself,
and a PR to data/recipes.json with a rule I don't own the assets to test is genuinely welcome.
The standalone won't start. It's --windowed, so it fails silently. %LOCALAPPDATA%\Quartermaster\data\crash.log
is where it lands.
If you build something cool with this, I'd genuinely like to hear about it.
Quartermaster reads your own account, from your own machine, in a browser you signed into yourself. It holds no credentials, ships nothing to any server of mine, and has no telemetry — the session lives in a local browser profile and the library in a local SQLite file. There is no shared backend to leak.
It is not affiliated with, endorsed by, or connected to Unity Technologies, Epic Games, Gumroad or Leartes Studios. Unity, the Unity Asset Store, Fab, Unreal Engine, Quixel, Megascans, Gumroad, Leartes and Cosmos are trademarks of their respective owners. Automating access to any service is your call to make against that service's terms, and this tool doesn't make it for you.
MIT. See LICENSE.
Detect the engine, version and render pipeline of a game project (Unity: from ProjectVersion.txt / manifest.json; Unreal: .uproject / DefaultEngine.ini). Call this BEFORE recommending or importing assets so pipeline mismatches (e.g. URP-only shader into an HDRP project) are caught.
| Name | Required | Description | Default |
|---|---|---|---|
| project_dir | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Detect' strongly implies a read-only operation; however, it does not explicitly state that no modifications or side effects occur. The description gives sufficient functional context but stops short of stating non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that deliver purpose and usage without fluff. The parenthetical examples add useful specificity without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the essential context: what it detects, when to use it, and why it matters (avoiding pipeline mismatches). It does not describe the return format, but that is not critical for a detection tool and the output schema exists separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, project_dir, is not elaborated in the description at all. While the name suggests a file path, there is no mention of expected format, whether it should point to a root folder or a specific file, or any related constraints. With 0% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Detect') and resource ('engine, version and render pipeline of a game project'). It distinguishes itself from sibling tools by focusing on detection rather than mutation or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use the tool: 'Call this BEFORE recommending or importing assets.' This provides a direct usage trigger and sets expectations for preconditions, leaving no ambiguity about when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details for one owned asset: summary, usage notes, gallery/video links, store URL.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It conveys a read-only lookup and previews the output fields, but it does not disclose failure modes, authorization/ownership consequences, or any limitations. It is minimally adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every phrase contributes either scope ('one owned asset') or expected content. Exemplary concision for a simple lookup.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return-value structure, so the description doesn't need to restate it, and the one-parameter tool is simple. However, the description omits when to use the tool versus its siblings and leaves parameter semantics underspecified, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the lone asset_id parameter is never defined, formatted, or tied to the description beyond the phrase 'one owned asset.' The description does not compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('one owned asset') and enumerates the returned content ('summary, usage notes, gallery/video links, store URL'). It does not use an explicit verb beyond the tool name, and the contrast with siblings like search_owned_assets is only implicit, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'One owned asset' implies this is for retrieving details on a specific already-known asset rather than searching across assets, but the description never explicitly says when to prefer it over search_owned_assets or other siblings. Usage context is implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a game/feature description (e.g. 'third-person fantasy open world with magic combat and a village'), sweep the vault using 3-way hybrid search (FTS + BGE + CLIP) and recommend which owned packages fit which aspect of the problem.
| Name | Required | Description | Default |
|---|---|---|---|
| limit_per_category | No | ||
| problem_description | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden and does disclose meaningful behavior: it performs a 3-way hybrid search (FTS + BGE + CLIP) and returns recommendations mapped to aspects of the problem. It does not explicitly mention side effects, permissions, or non-mutation, but 'recommend' strongly implies a read-only sweep.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense, well-structured sentence. It front-loads the input and purpose, includes a useful example, and adds meaningful algorithmic detail without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main input, the search approach, and the intent of the output, and the output schema can explain return values. However, it omits the semantics of limit_per_category and provides no guidance on how this tool compares to sibling search/recommendation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives clear semantics for problem_description, including a concrete example, but says nothing about limit_per_category. With schema description coverage at 0%, the optional parameter's meaning is left entirely to inference from its title and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it sweeps the vault via hybrid search and recommends owned packages for a given game/feature description. It is distinct in behavior from siblings like search_owned_assets, though it does not explicitly name or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: provide a game/feature description to get package recommendations. However, it does not state when to prefer this tool over search_owned_assets or other sibling tools, nor does it provide any exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Overall vault stats: total assets per engine, per category, and how many are already downloaded locally vs cloud-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral disclosure burden. It discloses the nature of the output in useful detail: totals per engine, per category, and download status breakdown. Being a read-only stats endpoint, this is sufficient transparency, though it does not explicitly state that no mutation occurs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase adds concrete information about the aggregation dimensions and the local-versus-cloud distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter aggregate stats tool with an output schema present, the description tells the agent exactly what dimensions the stats cover. Nothing crucial is missing for selecting or invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are inherently non-issue. The baseline of 4 applies, and the description correctly implies that the tool operates over the entire vault without requiring arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific resource (vault) and the kind of output (overall stats), listing concrete aggregation dimensions: assets per engine, per category, and local vs cloud-only counts. It implies a broad overview role among the siblings, though it does not explicitly name an alternative to distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Overall vault stats' signals that this tool is for high-level aggregate information rather than per-asset or per-category detail, so usage context is implied. However, there is no explicit statement of when to use this tool versus siblings like get_asset_details or list_asset_categories, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unpack a locally-downloaded Unity Asset Store package (.unitypackage) directly into a Unity project's Assets/ folder. Only works for assets tagged local=true (check with search first). project_dir must be the Unity project root (the folder containing Assets/).
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | ||
| project_dir | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates the local-only restriction and the project_dir root requirement, but it does not state whether existing files in Assets/ will be overwritten, merged, or left untouched if a conflict occurs. For a mutating operation that unpacks into a project filesystem, that is a notable omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences with no filler. The primary action is front-loaded, followed by the eligibility precondition and the critical project_dir requirement. Every sentence adds operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description covers the core action, the target location, the eligibility requirement, and the directory root expectation. The main missing context is conflict/overwrite behavior, but the definition is otherwise sufficient for an agent to invoke the tool correctly in the common case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% property description coverage, so the description must compensate. It explains project_dir clearly, but asset_id is left implicit as 'the package to unpack' with no guidance on its format, source, or relationship to search results. This leaves one of two required parameters essentially undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Unpack') and a clear resource/goal: importing a locally-downloaded .unitypackage into a Unity project's Assets/ folder. This clearly differentiates it from the sibling search, audit, and recommendation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the precondition 'Only works for assets tagged local=true (check with search first)', directing the agent to verify eligibility using a sibling search tool. This provides clear when-to-use guidance and implies the alternative when the condition is not met.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all categories and how many owned assets fall into each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. The verb 'List' implies a read-only operation and the description states the output shape, but it does not disclose potential nuances such as whether categories with zero assets are included, ordering, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with the action and resource, containing no redundant or filler information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema present, the description fully covers what an agent needs to invoke the tool correctly. There is no need to explain return values because the output schema already exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no semantic ambiguity to clarify. The baseline of 4 applies because there are no parameters at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('categories'), and clearly states the output: how many owned assets fall into each category. This distinguishes it from siblings like search_owned_assets or get_vault_stats, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of scenarios that favor a sibling, and no exclusions or prerequisites. An agent must infer usage solely from the name and the literal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Curated production stacks ('asset recipes') resolved against the user's OWN library. Each recipe lists which owned assets fill each slot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the tool is personalized by resolving against the user's OWN library and explains the output shape: each recipe lists which owned assets fill each slot. This gives meaningful behavioral context beyond the tool name, though it does not explicitly state side-effect absence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the core purpose and immediately clarifies the key distinguishing behavior and return format, making every sentence informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and an existing output schema, the description is complete enough for an agent to invoke the tool correctly. It defines the resource, the personalization scope, and what each returned recipe contains, so no critical operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds value by indicating that the user context is implicit and that results are scoped to the user's own library, which is the relevant semantic context despite the empty parameter list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and a clear resource ('curated production stacks' / 'asset recipes'), then clarifies the differentiating scope: they are resolved against the user's OWN library. This distinguishes it from siblings like get_stack_recommendations and search_owned_assets by emphasizing curated, owned-asset-specific recipes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the user wants curated recipes resolved against their own library rather than generic recommendations or raw asset search. However, it does not explicitly state when-not-to-use it or name any sibling alternative, so usage guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the user's asset vault across Unity, Fab, Quixel Megascans, Gumroad, and Cosmos. Hybrid: keyword (FTS5) fused with BGE text embeddings and CLIP visual vectors via 3-way RRF. Results include 'match' attribution ('keyword+semantic+vision') and 'ownership' ('vault_owned' vs 'catalog_grant').
engine: target game engine compatibility (all|unity|unreal|godot). Engine-agnostic sources (Quixel FBX/textures, Cosmos) match both unity and unreal.
source: filter by marketplace provider (all|unity|fab|quixel|gumroad|cosmos).
pipeline: render pipeline (all|HDRP|URP|Built-in).
local_only: only assets already downloaded to disk.
limit: max results to return.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| engine | No | all | |
| source | No | all | |
| category | No | all | |
| pipeline | No | all | |
| local_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden and delivers substantive traits: the 3-way RRF fusion of FTS5/BGE/CLIP, result 'match' attribution ('keyword+semantic+vision'), and the ownership distinction ('vault_owned' vs 'catalog_grant'). It also discloses engine-agnostic matching behavior for Quixel and Cosmos sources. It stops short of pagination, rate limits, and error behavior, but the core result-interpretation behaviors are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose line is front-loaded, followed by two compact behavioral notes, then a terse parameter block where each line earns its place with inline enums. No filler, no repetition of schema defaults. The structure is scannable and information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return structure, so the description rightly focuses on filtering semantics and result interpretation. For a 7-parameter hybrid-search tool with zero annotations, it covers the essentials: marketplaces, engine-agnostic matching, render pipeline, and ownership/match attribution. Remaining gaps—query syntax, pagination beyond limit, and empty-result behavior—are modest for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does for 5 of 7 parameters: engine, source, pipeline, local_only, and limit all receive meaningful semantics with inline enum values (e.g., 'all|unity|fab|quixel|gumroad|cosmos'). The engine note adds genuine nuance ('Engine-agnostic sources... match both unity and unreal'). query and category remain unexplained, with query—the only required parameter—lacking any guidance on accepted query syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: 'Search the user's asset vault across Unity, Fab, Quixel Megascans, Gumroad, and Cosmos.' The enumerated marketplaces and the vault scope clearly distinguish it from siblings like get_asset_details, list_asset_categories, and get_vault_stats. The hybrid-search detail ('keyword (FTS5) fused with BGE text embeddings and CLIP visual vectors') reinforces that this is the vault search operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than explicit: the name and first line mark this as the vault search tool, and filters like local_only ('only assets already downloaded to disk') hint at concrete use cases. However, the description never states when to prefer this over siblings (e.g., get_asset_details for a known asset, list_asset_categories for taxonomy) or any exclusion conditions. An agent must infer the division of labor from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lint a set of owned assets that are planned for one project/stack. Detects role conflicts (two weather systems, two vegetation renderers, …), same-product family notes, and missing prerequisites (e.g. MicroSplat module without core MicroSplat). Call before importing multiple assets together.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Lint' and 'detects' imply a non-mutating validation pass, and the specific detection categories explain what the tool does. It does not explicitly state side-effect freedom or permission requirements, but the language strongly signals read-only analysis for a pre-import check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: purpose, concrete detection examples, and a single usage directive. The most important information is front-loaded, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single input parameter, no annotations, and an existing output schema, the description covers purpose, input semantics, and when to call it. It could explicitly confirm that no changes are made or name sibling alternatives, but it leaves no major workflow ambiguity for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter, asset_ids, has an empty items schema. The description compensates by clarifying that these are 'owned assets planned for one project/stack,' and the plural usage plus 'importing multiple assets' conveys that all intended assets should be passed together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Lint a set of owned assets that are planned for one project/stack.' It also enumerates concrete outputs (role conflicts, family notes, missing prerequisites), which makes it clearly distinct from siblings like get_stack_recommendations or audit_project without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit invocation context: 'Call before importing multiple assets together.' It does not name alternative tools or exclusion conditions, but the workflow placement is clear enough for an agent to choose this over search, recommendation, or import tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.3.0audit_projectget_asset_detailsget_stack_recommendationsget_vault_statsimport_asset_to_projectlist_asset_categorieslist_stack_recipessearch_owned_assetsvalidate_stackScored across 9 tools
Most tools map to distinct workflows, but list_asset_categories and get_vault_stats both report per-category counts, and get_stack_recommendations with list_stack_recipes can be confused as recommendation surfaces. The detailed descriptions disambiguate most cases, but some boundary overlap remains.
All tool names follow a consistent snake_case verb_noun pattern: search_, get_, list_, audit_, import_, validate_. There are no mixed naming conventions or vague verbs, and even related stack tools use predictable get/list distinctions.
Nine tools is a reasonable size for this server's scope and covers search, details, stats, project auditing, import, and stack validation. The count would be a 5 if list_asset_categories and get_vault_stats did not duplicate category-count reporting.
The vault search, details, stats, and stack recommendation/validation surface is strong, but there is a notable workflow gap: audit_project is engine-aware for Unity and Unreal, while import_asset_to_project only supports Unity .unitypackage files. There is also no download or asset lifecycle management operation, leaving some workflows unable to proceed.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
shared AI-context layer for teams — persistent memory your agents search and update over MCP
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
