DX finding (from integrating the libraries into a sample). attestomcp.mount(app) requires an Express app — it reads/writes app.locals.attestomcp and is typed ExpressApp. The bundled createStorefront() brings Express, so the storefront path is seamless. But to gate a tool in a non-Express MCP server — the raw @modelcontextprotocol/sdk server, Hono / Fastify / Next.js route handlers / Cloudflare Workers — there's no path today.
Capability for discussion. Framework adapters, or a framework-agnostic mount() that attaches the /attestomcp/* rails + the seam onto any router. Start with the raw MCP SDK server + one of {Hono, Fastify, Next.js}.
Open Qs: a single generic "router" abstraction vs. per-framework adapters? which host first?
Why it matters: this is the #1 blocker to "gate any MCP server" beyond the bundled storefront. Relates to #15 (adoption) and #17 (install skill, which would target whatever host shape we land on).
DX finding (from integrating the libraries into a sample).
attestomcp.mount(app)requires an Express app — it reads/writesapp.locals.attestomcpand is typedExpressApp. The bundledcreateStorefront()brings Express, so the storefront path is seamless. But to gate a tool in a non-Express MCP server — the raw@modelcontextprotocol/sdkserver, Hono / Fastify / Next.js route handlers / Cloudflare Workers — there's no path today.Capability for discussion. Framework adapters, or a framework-agnostic
mount()that attaches the/attestomcp/*rails + the seam onto any router. Start with the raw MCP SDK server + one of {Hono, Fastify, Next.js}.Open Qs: a single generic "router" abstraction vs. per-framework adapters? which host first?
Why it matters: this is the #1 blocker to "gate any MCP server" beyond the bundled storefront. Relates to #15 (adoption) and #17 (install skill, which would target whatever host shape we land on).