Why 73 Brand Design Systems? The Real Problem Behind This Case Study
Design teams managing multiple brands face a structural challenge: design systems documentation grows linearly with each brand, but the cost of loading it into an AI context window grows multiplicatively.
The Documentation Explosion
A single well-documented brand design system (colors, typography, spacing, components, icons) typically runs 20–40 KB of structured Markdown. For 73 brands, that becomes 1.5–2.1 MB — far beyond any LLM context window for simultaneous comparison. Traditional approaches force users to load one brand at a time, making cross-brand analysis impractical.
Token Cost Economics
At current LLM pricing ($0.15–$0.30 per million input tokens for Claude, GPT-4o), a full-load query consuming 534K tokens costs $0.08–$0.16 — before any generation. With multi-turn conversations, costs compound. MCPOrb's retrieval approach cuts this to ~500 tokens per query: a 99.9% reduction that changes the economic model from prohibitive to negligible.
Cross-Brand Discovery
The most valuable queries span brands: "Which luxury automotive brands use a black-and-white minimalist palette?" or "Compare button border-radius across all fintech brands." These require simultaneous access to multiple design systems — structurally impossible when each brand must be loaded into a separate session. MCPOrb's cross-brand hybrid search is the first practical solution to this class of problem.
Dataset Profile: awesome-design-md
The source dataset awesome-design-md aggregates design system documentation from 73 globally recognized brands including NVIDIA, BMW, Ferrari, Airbnb, Stripe, Starbucks, and Supabase. Documents range from compact README-style overviews (2–5 KB) to comprehensive design language specifications (40+ KB) covering color systems, typography scales, spacing grids, component libraries, iconography, and motion design tokens. Total corpus: 145 documents, 2.1 MB of raw Markdown.
How Many Tokens Does MCPOrb Save Per Query?
Full-loading 145 documents costs ~534K tokens. One MCPOrb query costs ~500. The difference is structural, not incremental.
Which Search Method Works Best for Your Use Case?
MCPOrb supports BM25, vector, and hybrid retrieval. Each has a sweet spot.
BM25
Vector
Hybrid
What We Searched — and What Came Back
14 queries across English, Japanese, and cross-brand comparisons. Every result includes a [Source: brand/file] prefix so the LLM can instantly identify provenance.
What Makes It Work
Three design decisions that close the gaps in conventional approaches.
[Source: brand/file] Prefix
Every search result chunk is prefixed with its origin — brand name and file type. The LLM can instantly tell nvidia/DESIGN.md from airbnb/README.md and filter noise.
Identifiable resources/list
Unlike v1 which showed generic names like "DESIGN", the Orb now shows airbnb/DESIGN.md — so you know exactly what's inside before reading.
Multilingual Semantic Search
Japanese abstract design concepts ("白を基調としたクリーンなSaaS") correctly match English design documents. The 384-dim MiniLM embedding model handles cross-lingual queries natively — supported by research showing sentence-transformers achieve strong cross-lingual alignment without explicit translation (Feng et al., EMNLP 2020).
How MCPOrb Makes This Possible
Instead of loading all 2.1 MB into the LLM context, MCPOrb retrieves only the relevant ~500 tokens per query.
✕ Without MCPOrb
✓ With MCPOrb
How Does MCPOrb Index and Retrieve 145 Documents at Scale?
The Orb packaging pipeline transforms raw Markdown into a queryable knowledge base in three stages: chunking, embedding, and hybrid retrieval.
Chunking Strategy
Each of the 145 documents is split into semantic chunks of ~200–500 characters using recursive character text splitting with Markdown-aware boundaries. Chunks respect heading structure — no split cuts across an H1 boundary. The result: ~2,400 chunks covering every brand's color specs, typography rules, spacing systems, and component tokens.
Embedding Generation
Every chunk is embedded into a 384-dimensional vector space using all-MiniLM-L6-v2. This compact model balances recall quality with storage efficiency — the full embedding index for 2,400 chunks occupies approximately 3.7 MB, a fraction of the original document corpus. The same model handles Japanese and English queries without separate language detection.
Hybrid Retrieval Fusion
At query time, BM25 exact matching and dense vector cosine similarity run in parallel. Results are fused using reciprocal rank fusion (RRF) with a constant k=60. The hybrid approach compensates for BM25's inability to capture semantics and vector search's occasional drift toward topical but irrelevant chunks. Each result carries a [Source: brand/file] prefix and a hybrid relevance score.
Why Not Just Use a Vector Database?
MCPOrb's key differentiator is portability. A vector database requires a server, network latency, and cloud infrastructure. An Orb is a single file that lives anywhere — local disk, Git repository, content delivery network. The embedding index is embedded directly in the Orb file, eliminating external dependencies. This design is intentional: when knowledge must travel with the user across air-gapped environments, a self-contained file is the only reliable format.
Query Performance
On a standard M3 MacBook Pro, the full retrieval pipeline (BM25 + vector encoding + RRF fusion) completes in under 200 milliseconds per query. The 384-dim MiniLM embedding operates efficiently on CPU — no GPU required. This means the Orb is not only portable but fast: sub-second response times even on resource-constrained machines, making it practical for real-time interactive use in IDE plugins and chat interfaces.
What Are the Current Limitations and What's Coming Next?
Every tool involves tradeoffs. Here are the known limitations of the current approach and our roadmap for addressing them.
README Contamination
Some design repositories include README files with project metadata but minimal design tokens. Vector search occasionally retrieves these README chunks over more substantive design spec chunks. Planned mitigation: add document-level metadata filtering to deprioritize non-design files, and implement per-brand score normalization.
Single Embedding Model
Currently all chunks use the same 384-dim MiniLM embedding. While efficient, this limits differentiation for highly specialized content (e.g., code snippets vs. prose descriptions). Future versions will support per-document-type embedding routing and multi-vector representations for richer retrieval granularity.
Context Window Ceiling
While MCPOrb eliminates the token cost of loading all documents, the retrieved chunks must still fit within the LLM's context window. For queries requiring cross-referencing more than ~50 chunks, users may need to use a model with larger context. The roadmap includes sliding-window retrieval for iterative deep-dive queries.
How to Package Your Knowledge as an Orb
MCPOrb turns product docs, playbooks, and design systems into portable, local, inspectable knowledge packages. One file. Zero cloud. Plug directly into Claude Desktop, Cursor, or VS Code.
Zero cloud dependency. Runs entirely on your machine. Open source runtime.