Hosted remote MCP server (zero-install via "Add custom connector" URL)

[prPMDev]

Summary

Offer jd-intel as a hosted remote MCP server so users can add it by URL via Claude Desktop / Claude.ai "Add custom connector" — no download, no Node, no terminal. The zero-install rung above the one-click .mcpb extension.

Why

Adoption's binding constraint is install friction. Current paths:

• npx config — needs Node 18+ and a terminal/config edit.
• .mcpb extension — no terminal/Node, but a per-user download + manual install, and it doesn't auto-update.

A hosted server removes the last friction: paste a URL once; works across Claude Desktop, Claude.ai web, and any remote-MCP-capable client; the registry stays fresh automatically.

Approach

• Reuse the existing server logic (mcp/tools.js, mcp/resources.js, the jd-intel library) unchanged. Only the transport changes: swap StdioServerTransport for Streamable HTTP (the MCP SDK supports both).
• Host it (Cloudflare Workers per the roadmap, or a Node host like Fly/Render). On Workers there's no filesystem, so the registry's disk reads (src/registry.js) would need to become bundled JSON / KV — the loader is already network-first with a disk fallback.
• Expose a stable URL; users add it under "Add custom connector".

Tradeoffs / open questions

• Operator burden: uptime (our downtime = everyone's jd-intel down), monitoring, deploys.
• ATS-traffic concentration: all queries hit ATS APIs from one server IP (vs. distributed local calls). Needs caching + rate limiting to stay a good citizen and keep the "public APIs, not scraping" posture honest (related: Retry logic and rate limit handling for all ATS APIs #7).
• Privacy posture flips: queries flow through our server. Needs a stated policy (collect the catalog, never the queries).
• Cost (compute/bandwidth) and possible auth/abuse gating on a shared URL.
• Client support for remote MCP varies; "zero install" only holds where the client supports custom connectors.

Notes

Deferred intentionally — .mcpb + npx cover local install today; this is the heaviest rung (we go from shipping code that runs on the user's machine to running a service). Distinct from #22 (ATS coverage) and #18/#19 (MCP best-practices).