How it works

Quartermaster works in four stages: it discovers agent-context artifacts by crawling the roots you point it at, normalizes each one into a canonical manifest, indexes everything in one local SQLite database (keyword + semantic search, fully offline), and serves it back over MCP so agents can search, convert, and install capabilities on demand. Your agent talks to Quartermaster over MCP (Streamable HTTP); behind that surface sits a single pipeline:

   your agent ──(MCP over Streamable HTTP)──▶  Quartermaster
                                                  │
   discover ◀──────────────────────────────────┤  crawl drives/projects, classify
   ~/.claude, ~/.codex, ~/.gemini, .cursor,     │  (type × tool), redact secrets
   .hermes, C:/, E:/, project dirs …            │
                                                  │
   normalize ──────────────────────────────────▶ canonical manifest + snapshot
                                                  │  (tree-hash, per-file class)
   index ──────────────────────────────────────▶ SQLite: FTS5 (BM25) + sqlite-vec
                                                  │  embeddings: all-MiniLM-L6-v2 (384-d)
   serve ──────────────────────────────────────▶ search · fetch · convert · hydrate
                                                  │  · scan-risk · drift · packs
   browse ─────────────────────────────────────▶ web console at GET / + JSON /api

Discover

The crawler walks your scan roots (whole drives if you want), classifying every artifact by type × tool using the discovery map. Config files (MCP servers, settings, hooks) are read surgically and redacted — key names are kept, secret values dropped — and credential stores are hard-skipped.

The crawl is non-blocking: the server answers MCP calls immediately, yields to the event loop every 1,000 files, and indexes per batch, so results appear while the scan is still running. Re-scans are incremental by content hash.

Normalize

Every artifact becomes a canonical capability manifest plus a snapshot (tree hash + per-file classification) — the same shape regardless of which tool it came from. See Canonical model & snapshots.

Index

One SQLite database holds everything: an items table (one row per artifact, path-unique), an FTS5 table for BM25 keyword search, and a sqlite-vec table for 384-d cosine vector search. Embeddings come from all-MiniLM-L6-v2 running locally via Transformers.js — baked into the build, fully offline.

Serve

Search is hybrid: BM25 and vector kNN results are fused with reciprocal-rank fusion, and cross-tool duplicates are collapsed (one result, all locations noted). On top of search sit conversion, hydration, packs, trust/risk, and provenance/drift — all exposed as MCP tools and a JSON API behind the web console.

Produce/sink split

Internally the scan pipeline is split in two:

• Produce (scanner.ts) — crawl + classify + parse + redact + snapshot. Filesystem-only; no SQLite, no embeddings.
• Sink (ingest.ts) — embed + upsert the produced items.

That seam is what makes the thin collector possible: the produce half runs standalone on any machine (no model, no database) and pushes wire-format items to a hub, which runs the same sink as a local crawl.