Build with Trove

Trove is built around a symmetric pair of authoring patterns. Both are “user code Trove runs on your behalf” — pointed in opposite directions:

• Toolkits serve tools out. A toolkit answers live questions against a system of record (an internal API, a SaaS, a public data feed) by exposing tools Claude can call. Every toolkit runs as a full MCP server on Trove’s cloud (that’s the one bit of protocol trivia worth knowing — after this page we’ll say MCP server freely in the developer docs). Toolkits run server-side (on Trove’s Cloudflare Workers infrastructure) and are written against @ontrove/mcp with defineMcpServer({ tools }). This is the path that ships today — see the catalog of toolkits already running.
• Sources collect data in. A source adapter pulls content from an upstream system (an API, an RSS feed, your bookmarks) and feeds it into your knowledge base, where it becomes semantically searchable next to everything else. Source adapters run client-side (the Mac app runs them on a schedule) and are written against @ontrove/sdk with a sync(ctx) function that returns documents.

A source feeds your knowledge base; a toolkit answers live questions. A developer who has written one can write the other in minutes — the SDKs are deliberately symmetric.

Sources are coming soon

The source-adapter runtime ships with the Trove Mac app, which is still in private beta. You can already author and run source adapters locally with the Trove CLI (trove source dev / sync), but scheduled background sync isn’t generally available yet. Toolkits, by contrast, are live now — if you’re starting today, start there.

Which one do I want?

• “I want my saved articles / podcasts / bookmarks / notes to be searchable in Trove.” → Source. It ingests documents that the trove_search core tool then finds.
• “I want Claude to call a live tool that hits my API / database / a public feed and returns a fresh answer.” → Toolkit. It exposes a tool that runs on demand.
• “I want a scheduled job that writes into my knowledge base from a sanctioned API.” → Either: a source (client-side, the established path) or a toolkit with the trove:ingest scope and onSchedule (cloud-side, planned).
• “I want a live tool that touches my own machine — scans my home network, edits my todo list in Things / Reminders, reads files on my Mac.” → Neither. A toolkit runs in Trove’s cloud and cannot reach your laptop (no localhost, LAN, local files, or Mac apps), and a source only collects data in. Run a local stdio MCP server yourself (desktop-only). Trove deliberately doesn’t host this, because the cloud has no network path back to your Mac.

Side by side

	Sources	Toolkits
Direction	Collect data in (batch)	Serve tools out (live)
SDK	@ontrove/sdk	@ontrove/mcp
Entry point	export default { sync(ctx) } → documents	defineMcpServer({ tools }) → results
Artifact	manifest.json + index.ts	manifest.json + server.ts
Where it runs	Client-side (Mac app)	Server-side (Trove cloud)
Credentials	macOS Keychain	Trove Secrets Vault (ctx.secret)
Egress control	manifest.egress + ctx.fetch	manifest.egress + ctx.fetch
Can reach	Local + private data on your Mac (it runs there) and the public internet	The public internet only (egress allowlist) — never localhost, your LAN, local files, or Mac apps
Output	Stored & indexed documents	Live tool results read by Claude
Deploy	Add in the Mac app	trove mcp deploy
Output reach	Indexed content reachable everywhere	Live tools reachable on every Claude surface
Build it	Sources series	Toolkit quickstart

The shared shape

Both SDKs hand your code a small ctx capability object — no ambient authority. The members line up:

• ctx.fetch(url, init?) — the only egress path, enforced against the manifest allowlist, in both worlds.
• ctx.log(...) — structured logs, redacted against known secret values.
• A toolkit also gets ctx.secret(name) (vault access), ctx.userId (the caller), and ctx.trove (a scoped client over the caller’s knowledge base) when the manifest grants the scope.

If you’ve internalized one ctx, the other is familiar immediately.

Start here

Toolkits — serve tools out (available today)

• catalog — the official toolkits that ship today, by category
• Toolkits overview — why build on Trove, and how tools appear in Claude
• Quickstart — build and deploy your first toolkit in ~5 minutes
• SDK Reference — defineMcpServer, the ctx object, ToolError, annotations, structured output
• manifest.json · Secrets & Auth · Deploying

Sources — collect data in (coming soon)

• Sources Overview — the ingest contract, pagination, and dedup
• Sources concept — how sources, feeds, and documents fit together
• Hacker News example — a complete sync(ctx) source adapter

Examples cookbook

• USGS Earthquakes — a no-auth toolkit over a public feed
• NASA APOD — an authed toolkit (secrets + ctx.secret)
• Knowledge-base tool — a toolkit that reads & writes the user’s Trove
• Hacker News source adapter — a source adapter built on @ontrove/sdk

The CLI

Both paths share the trove command-line tool — it scaffolds, runs, and deploys sources and toolkits from one place. See the CLI docs for installing and authenticating.