Pikelet MCP server

Pikelet

Knowledge that ships as a file.

Pikelet compiles a corpus into one self-contained, queryable artifact.

A model can interrogate a 456,153-record knowledge base whose backend is a static file.

A .pikelet can carry the source text, semantic index, keyword index, query encoder, integrity commitments, retrieval calibration, and evaluation fixtures needed to interrogate that corpus. Put the file on disk, S3, R2, a CDN, or any static HTTP host. A reader can mount it locally or over HTTP Range and search it without a vector database, embedding API, or retrieval server.

Requires Node 20+.

npx pikelet compile --source ./docs --out docs.pikelet

Ingested 3 docs -> 3 chunks
Embedded 3/3 chunks with inline transformer
Built complete .pikelet artifact with 24.5 MB
Compiled docs.pikelet
  24.5 MB, 3 records, identity 8d731a...

First run fetches the ~25 MiB query encoder from a GitHub release and caches it; every .pikelet file is at least that size regardless of corpus, because the encoder ships inside it — a 5-file folder and a 500-file folder both start around 25 MiB.

Then query it from an LLM — Claude Code, Claude Desktop, or any MCP client:

npx pikelet mcp install --client claude-code --pack ./docs.pikelet
# or --client claude-desktop; any other MCP client can run
# `npx pikelet mcp --pack ./docs.pikelet` directly, no install step

Wrote MCP server "knowledge-packs" to ./.mcp.json
Claude Code picks it up on the next session in this project.

Claude now has a search tool over your docs. Or query it directly from code:

import { openPikeletFile } from 'pikelet-wasm/complete';
const pack = await openPikeletFile('docs.pikelet');
const out = await pack.query('how do workers restore snapshots', { k: 5 });
console.log(out.matchQuality, out.results[0]?.title);
// 'strong' 'Snapshot restore'

That's the whole loop. compile also takes a live URL (--source https://docs.example.com) instead of a directory. If you want a deployed search app — a Worker + UI, not a file — use npx pikelet create instead; see pikelet/README.md for the full CLI reference and the tradeoffs between the two. compile never needs the scaffold path's @xenova/transformers dependency; skip its ~140 MB install with npm install -g pikelet --omit=optional if you only need compile/mcp.

Under the hood, the file is one container for everything a reader needs:

documents
    │
    ▼
┌──────────────────┐
│   docs.pikelet   │
│                  │
│ corpus           │
│ semantic index   │
│ lexical index    │
│ query encoder    │
│ integrity        │
│ calibration      │
│ evaluation       │
└──────────────────┘
    │
    ├── local file
    └── static HTTP / object storage
              │
              ▼
        browser / Node / edge / agent

Search is the interface. The file is the knowledge deployment unit.

The shortest demonstration

A real Pikelet pack contains 456,153 Simple English Wikipedia records in a 648.5 MiB artifact.

Try the live browser demo:

https://pikelet-wiki-playground.pages.dev/

The page is static HTML/JS on Cloudflare Pages. It mounts the pack from R2:

https://pub-6da2384a3bca4a44b2b2fa29a94cc811.r2.dev/wikipedia.pikelet

There is no /search, /embed, /query, or /api backend behind the demo. The browser opens the .pikelet file over HTTP Range, verifies the artifact, loads the embedded query encoder, and shows the byte ranges it reads.

That file was served by a deliberately dumb HTTP server whose only relevant capability was:

fs.createReadStream + HTTP Range

There was no vector database, no search service, no embedding service, no application server that understood the pack, no index process on the server.

The pack was mounted by URL and exposed to a real headless Claude process through MCP. Each invocation was restricted with --strict-mcp-config to only:

Shortened. The full README is on GitHub.