Oneshot MCP server

oneshot-mcp

An MCP server that lets your coding agent query the OneShot catalog of receipt-verified build packs without you leaving your editor. Mid-build, your agent can ask "is there a verified pack for this?" instead of you having to remember to check the storefront.

Why you'd add this (honestly)

This is a vendor catalog: it lets your agent query OneShot's own paid build packs, plus their verification data, from inside your normal workflow. It's worth adding because it's useful independent of whether you ever buy anything -- searchpacks and listpacks tell you plainly whether a receipt-verified pack exists for what you're building, with real "M of N runs passed" numbers, not marketing copy. get_pack puts the price, refund terms, and exact receipt facts in front of you before you decide anything. But be clear-eyed about what it is: this is OneShot listing its own products to your agent, not an independent recommendation engine. It never calls a pack "best" or invents a verification a receipt doesn't support, and every result carries the price and refund pointer -- but the catalog is ours, and every entry in it is something we sell.

Tools

niche) over the catalog. Returns matching packs: title, one-liner, price, verification status stated exactly as the receipt supports (e.g. "3 of 3 clean-room runs passed", or "unverified" if no receipt exists yet), a receipt summary, the refund-policy pointer, and the storefront URL. Never ranks or calls a result "best" -- describes each match and leaves the decision to the caller.

• searchpacks({ query, limit? })** -- keyword search (stack, problem, or

architecture-decision highlights, scale envelope, FAQ, exact receipt facts (per-check pass/fail, model, token/wall-time cost) when verified, price, refund pointer, and the buy URL.

• getpack({ slug })** -- full detail for one pack: what you get,

niche, price, and verification status per pack, plus the refund-policy summary once.

• listpacks()** -- the whole catalog, compact: slug, title, one-liner,

Data source: fetch-with-fallback (not a bundled catalog)

Two options were on the table: read packs/*/pack.yaml + receipt/receipt.json

the npm package. Chosen: live reads, preferring the storefront's /catalog.json over a local checkout, in that order:

• LISTING.md live at runtime, or ship a generated catalog.json baked into

3s timeout). Accepts either a bare array of pack objects or { "packs": [...] }.

1. Try GET $ONESHOTCATALOGURL (default https://oneshotpacks.com/catalog.json,

shape -- fall back to reading packs//pack.yaml + LISTING.md + receipt/receipt.json directly off disk under $PACKSDIR (default ../packs, resolved from the current working directory -- matches storefront/lib/packs.ts's own convention when both this package and packs/ sit at the repo root).

1. If that fails for any reason -- network error, non-2xx, not JSON, wrong

(catalog_source: "none" + an explanatory note) instead of serving stale bundled data. This server never fabricates catalog contents.

1. If neither source has anything, listpacks/searchpacks say so plainly

A baked-in catalog.json was rejected because it goes stale the moment a pack is re-verified or newly listed, and every server update would then require a new npm release just to refresh data the storefront already has live. Live reads cost one fetch + a YAML parse -- the same low cost the storefront's own loader pays -- and stay fresh without a redeploy of this server, which is the whole point per docs/03-marketing-distribution.md Lever 2.

Shortened. The full README is on GitHub.