Toolkits

A toolkit is a bundle of live tools for Claude. Every toolkit runs as a full MCP server on Trove’s cloud — authenticated, always-on, multi-tenant, and reachable from every Claude surface: desktop, web, and mobile. (That’s the one-time protocol gloss; the rest of this developer series says MCP and server freely.) Trove already runs the hard parts of a remote MCP server; toolkits let you extend that connection with your own tools.

You author a small server — manifest.json + server.ts — and deploy it with one command. Trove runs it for you and surfaces your tools inside the same Trove connection Claude already has, right next to trove_search and the other core tools.

Official toolkits ship with Trove today — browse the catalog of toolkits over public APIs (arXiv, Wikipedia, SEC EDGAR, FRED, the Met, and more).

Sources and toolkits: two sides of the same idea

Trove is built around a symmetric pair of authoring patterns:

	Sources	Toolkits
Direction	Pull data in (batch)	Serve tools out (live)
Entry point	sync(ctx) → documents	defineMcpServer({ tools }) → results
SDK	@ontrove/sdk	@ontrove/mcp
Executes	Trove cloud by default; Mac app for browser/local sources	Trove cloud
Deploy	Add from the catalog	trove mcp deploy

A source feeds your knowledge base; a toolkit answers live questions against systems of record. A developer who has written one can write the other in minutes. See Build with Trove for the full picture, or jump to the examples.

Sources run in Trove’s cloud

Most sources run in Trove’s cloud — Trove schedules and syncs them for you, no app required. Sources that need a real browser, local files, or your own network run on the Trove Mac app (still in private beta), and you can switch any cloud-capable source to run there too. Toolkits — this page — run in the cloud and are available today.

What toolkits can and can’t reach

A toolkit runs in Trove’s cloud, not on your computer. It can reach the public internet — and only the hosts you list in your manifest’s egress allowlist. It cannot reach your local machine: no localhost, no LAN or home network, no local files, no Mac apps. The same network controls that block exfiltration to undeclared hosts also block private and reserved address ranges entirely (an SSRF defense — see the security model).

That boundary decides which of three tools fits your problem:

What you want to reach	Reachable from Trove’s cloud?	Build this
A cloud / SaaS / open-data / your-company’s-internet API (anything you could hit from a server, or from your phone)	Yes — public internet	Toolkit — e.g. the USGS earthquake API OK
Local or private data you want searchable in your KB (Apple Notes, a folder of local files)	No, but you can collect it in	A source — it syncs on your Mac via the app and pushes documents into Trove
A live tool that must touch your machine (scan your home network, edit your todo list in Things / Reminders on your Mac)	No — the cloud can’t reach your Mac	A local stdio MCP server you run yourself (desktop-only). Trove deliberately doesn’t host this NO

If your problem lands in the third row, a toolkit is the wrong tool — there is no network path from Trove’s cloud back to your laptop, by design.

When to build a toolkit

Build a toolkit when you need live, interactive access to a system that has no official toolkit yet:

• Your company’s internal orders, support, or metrics API
• A read replica of a production database you’re allowed to query
• A vertical SaaS with a REST endpoint — a logistics provider, a government data portal, a niche tool
• A personal automation: “summarize my Whoop recovery this week,” “what’s the status of PR #42 across all three repos”

Why not just run a local MCP server?

A local stdio server running on your laptop is desktop-only by construction. Your phone cannot reach localhost:3000, and the process is dead while your laptop sleeps.

Standing up your own remote MCP server is the right answer in principle, but the accidental complexity is disproportionate: OAuth 2.1 with PKCE, dynamic client registration, TLS, a domain, multi-device session management. Trove has already paid that cost — it is already the authenticated, always-on endpoint on your phone and in your browser.

Deploying your toolkit on Trove means it inherits all of that for free:

• Zero new client config. Your tools appear in the Trove connection Claude already has. The user authorized Trove once; the new tools just show up.
• Works on mobile and web. Because the toolkit runs on Trove’s infrastructure (Cloudflare Workers), not your laptop.
• Always on. No process to manage, no laptop that needs to be awake.
• Strong isolation. Your toolkit runs in its own V8 isolate with hard CPU/memory limits, controlled egress, and no access to other users’ data.

How your tools appear in Claude

When you deploy a toolkit with id acme-orders containing a tool named lookup_order, Claude sees:

acme-orders__lookup_order

The toolkitId__toolName namespace prefix makes provenance legible and prevents collisions. The Core tools (trove_search, etc.) are unaffected — they appear as normal. Your tools appear alongside them.

There are two ways to access a deployed toolkit:

• Aggregated (default). Your tools appear automatically in the existing https://api.ontrove.sh/mcp connection. No new connection required.
• Standalone. Each toolkit is also reachable at https://api.ontrove.sh/mcp/s/{serverId} for targeted use or sharing.

Next steps

• catalog — every official toolkit that ships today, by category
• Quickstart — build and deploy your first toolkit in about 5 minutes
• SDK Reference — the @ontrove/mcp API in full
• manifest.json Reference — every manifest field explained
• Secrets and Auth — setting secrets, egress allowlisting, OAuth connections
• Deploying — versioning, rollback, lifecycle, and teardown
• Examples — complete, copy-pasteable toolkits (USGS earthquakes, NASA APOD, knowledge-base tool)