api-mirror
Skill0 starsChanged 6 months agoApache-2.0View on GitHub
Stand up a persistent, self-refreshing local mirror of a bulk upstream dataset with the MirrorService (@cyanheads/mcp-ts-core/mirror). Use when a server wraps a large or slow API and should query a synced local index (embedded SQLite + FTS5) instead of paginating the live API per request.
In this repository31 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- add-app-toolSkill
- add-promptSkill
- add-resourceSkill
- add-serviceSkill
- add-testSkill
- add-toolSkill
- api-authSkill
- api-canvasSkill
- api-configSkill
- api-contextSkill
- api-errorsSkill
- api-linterSkill
- api-servicesSkill
- api-telemetrySkill
- api-testingSkill
- api-utilsSkill
- api-workersSkill
- code-simplifierSkill
- design-mcp-serverSkill
- field-testSkill
- git-wrapupSkill
- maintenanceSkill
- polish-docs-metaSkill
- release-and-publishSkill
- report-issue-frameworkSkill
- report-issue-localSkill
- security-passSkill
- setupSkill
- tool-defs-analysisSkill
The file
Files
Context
The MirrorService owns the source-agnostic half of a local mirror — the embedded store, the sync-state machine, the runner — so a server supplies only the two parts that are irreducibly per-source: the ingester (a sync generator) and the schema. It targets the embedded-SQLite tier (~10⁴–10⁷ rows). Node/Bun only: bun:sqlite is built-in on Bun, better-sqlite3 is an optional peer dependency on Node; the store is unavailable on Workers (no SQLite, no persistent filesystem).
Import from @cyanheads/mcp-ts-core/mirror.
The shape
import { defineMirror, sqliteMirrorStore } from '@cyanheads/mcp-ts-core/mirror';
const papers = defineMirror({
name: 'arxiv-papers',
store: sqliteMirrorStore({
path: config.mirrorPath,
primaryKey: 'id',
columns: { id: 'TEXT', title: 'TEXT', authors: 'TEXT', abstract: 'TEXT', updated: 'TEXT' },
fts: ['title', 'authors', 'abstract'], // opt-in FTS5 external-content index
indexes: [{ columns: ['updated'] }],
}),
// The ingester — the one part that is always server-specific.
async *sync({ mode, cursor, checkpoint, signal }) {
for await (const page of harvestPages({ resumeFrom: cursor, since: checkpoint, signal })) {
yield {
records: page.rows, // objects keyed by declared column
tombstones: page.deletedIds, // primary-key values to delete
cursor: page.token, // volatile resume position (see below)
checkpoint: page.maxStamp, // durable high-water mark (see below)
};
}
},
});
await papers.runSync({ mode: 'init', signal: AbortSignal.timeout(3_600_000) }); // full; resumes on interrupt
await papers.runSync({ mode: 'refresh' }); // incremental
const { rows, total } = await papers.query({ match: 'transformers', limit: 10, offset: 0 });
const status = await papers.status(); // { status, ready, checkpoint, total, ... }cursor vs. checkpoint — the core distinction
Two resume dimensions, deliberately separate. Conflating them silently corrupts resume for token-paged sources.
cursor | checkpoint | |
| Meaning | Volatile intra-run resume position (e.g. an OAI-PMH resumption token, a page token) | Durable incremental high-water mark (e.g. the max record datestamp) |
| Lifetime | One run; may expire; cleared on completion | Persists; advances monotonically, only on success |
| Used for | Resuming an interrupted init | Seeding the next refresh |
Why they can't merge: during a from-scratch init the records aren't ordered by the high-water field, so the max-so-far is not a valid resume position — only the cursor is. After a completed init the cursor is meaningless, but the high-water mark is the correct refresh seed. The framework persists both per page and threads the right one back into sync() per mode. The checkpoint must be lexicographically monotonic (ISO 8601 works); the runner advances the stored checkpoint only when a page's value compares greater.
What you own vs. what the framework owns
| Framework | Server |
Cross-runtime SQLite handle, WAL + busy_timeout | The sync generator (the ingester) |
mirror_sync_state + cursor/checkpoint state machine | Translating your query syntax → FTS5 match |
runSync({ init | refresh }), per-page persist, resume | Mapping upstream records → row objects |
| Schema gen (columns + FTS + tokenizer + triggers) | Migration content (the up functions) |
schema_version + migration runner | Scheduling + init/refresh bootstrap (see below) |
Generic query() + the raw-handle escape hatch | Server-specific access paths via the raw handle |
Querying
query({ match?, filters?, sort?, limit, offset }) covers the common case:
match— an FTS5MATCHexpression (only when the store declaresftscolumns). Translate your own query grammar to FTS5 before calling.filters—[{ column, op, value }], AND-combined, over declared columns.op∈eq|ne|gt|gte|lt|lte|in(intakes an array).sort—{ column, direction }or'relevance'(FTS bm25; requiresmatch). Defaults to insertion order.
For access paths the generic query can't express — junction tables for index-backed multi-value filtering, denormalized counters, bespoke bm25 weighting — use the raw handle: const db = await mirror.raw(); then run prepared statements against your own auxiliary tables (declare them via a migration). Add the auxiliary DDL in a migrations step; maintain it from your sync mapping or SQL triggers.
Readiness — key off the completion marker, not live status
status().ready is true once a full sync has ever completed (completedAt != null), not when status === 'complete'. The dataset stays transactionally queryable during a refresh, so a mirror mid-refresh — or one whose last refresh failed — is still ready and should keep serving. Gate the mirror read path on await mirror.ready(); fall back to the live API only when it is false (cold, never-completed init).
Scheduling and bootstrap (server-owned)
The service owns runSync + state; it does not schedule. Wire "self-refreshing" yourself:
- Refresh — register
runSync({ mode: 'refresh' })on a cron viaschedulerServicefrom@cyanheads/mcp-ts-core/utils, insidesetup(). Gate on transport (HTTP) when stdio operators run it out-of-band. - Init — run out-of-band (a CLI script / one-shot), never on startup: a full init can take hours and must not block the server. It is idempotent and resumable — re-running after an interrupt continues from the persisted cursor.
Checklist
defineMirror({ name, store, sync }); the server holds the instance (one per mirror)sqliteMirrorStorespec declaresprimaryKey,columns, and (if searching)ftssyncyields{ records, tombstones?, cursor?, checkpoint? }per page; checkpoint is lexicographically monotonic- Read path gated on
await mirror.ready()with a live fallback when not ready better-sqlite3added as a peer dependency for Node deployments; mirror disabled on Workers- Refresh wired via
schedulerServiceinsetup(); init runs out-of-band bun run devcheckpasses
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

