The Genome of Games publishes the same 1,180 records four different ways, and one command writes all four: node build.js, 0.39 seconds, zero npm dependencies.
Out come 1,245 static HTML pages for crawlers, an interactive canvas graph for humans, a 129,037-byte search index for the site's own search box, and a Model Context Protocol server exposing 8 tools to agents.
The decision worth copying is the one that sounds like a downgrade. The MCP server does not query the site and does not read the source data. It statically imports a 1.9 MB index that the build wrote. There is exactly one place where slugs, lineage, and adoption edges get joined, so an agent and a crawler cannot come back with different answers.
The dataset is an ontology of video game mechanics — 168 mechanics, 618 games, 394 companies, 4,366 recorded links, 1962 to 2025. What the records are about does not matter here. The shape of the problem shows up anywhere a structured knowledge base has to serve both a search engine and a model.
Six hand-edited JSON files under data/ are the source of truth: the feature ontology, the graph, the prose, the company registry, the site copy, and the verified outbound links. Together they are 1,312,577 bytes.
The build turns that into 16,644,215 bytes of generated read surface. A 12.7× expansion, and every byte of it is disposable.
| Surface | Consumer | Bytes | Per entity | |---|---|---|---| | 1,245 static HTML pages | Crawlers, humans | 14,613,203 | 11,728 / page | | mcp-index.json → MCP server | Agents | 1,901,975 | 1,612 | | search-index.json | The site's own search box | 129,037 | 109 | | /graph/ canvas | Humans exploring lineage | data injected at build | — |
The build also emits sitemap.xml with 1,245 entries, llms.txt, robots.txt, and a 404 page. The same run reports 96,843 internal links across those pages.
Nothing in that list is authored. Delete the whole output directory and the next build restores it in under half a second.
The obvious way to serve an agent is to put an API in front of the data and let the MCP server call it. That is the version that rots.
An API layer has to re-derive the same things the page renderer derives — how a name becomes a slug, which parents count as ancestors, which adoption edges are shown. Two implementations of one join is two implementations that will disagree, and the disagreement surfaces as an agent confidently citing a URL that renders something else.
So build.js writes data/mcp-index.json as a build step, and api/mcp.mjs opens with a static import of it. The serverless function holds no derivation logic at all. Its first line of real work is const { meta, families, eras, entities } = INDEX.
The protocol itself is spoken by hand — JSON-RPC over POST, no MCP SDK, for the same reason there is no Stripe or Supabase SDK anywhere in the repo. initialize, tools/list, tools/call, ping, and two notifications is the entire surface area. The whole server is 21,508 bytes.
Eight tools come back: overview, search, getmechanic, getgame, getstudio, tracelineage, listfamily, byyear.
Same 1,180 entities, two indexes, wildly different budgets. The search index spends 109 bytes per entity. The MCP index spends 1,612. That ratio is 14.7×, and it is the most useful number in the build.
The search box only needs enough to rank a substring match and hand over a URL: name, type, year, path. Everything else is one navigation away, and the human doing the navigating is the retrieval system.
An agent has no second hop it can afford. If genomegetmechanic returns a stub, the model either guesses or makes four more tool calls, and both outcomes are worse than a fat payload. So the MCP record carries the credited origin game and its developer, the full prose essay, parents, children, everything downstream, and the later adopters — pre-joined.
The generic version of this: size a machine-readable surface by how many round trips the consumer can tolerate, not by what looks tidy. Humans tolerate many. Agents tolerate roughly one.