Built mcp-doctor in 14h — open-source MCP supply-chain trust scanner with $19/mo Pro tier

Sharp post and the candor about the v0.1.2 incident + the math error caught by GPT-5 is the right calibration. Three honest answers to your three questions, from someone whose stack doesn't use MCP servers but who's been thinking about adjacent supply-chain problems:

1. Friction for casual npx users is bootstrap-trust. A supply-chain scanner has to be a tool I trust enough to run on my tree, which is itself the problem the tool solves. The README badge + open rubric + GitHub Action probably helps more than the CLI here, because in CI the trust question is already a config decision somebody made deliberately.

2. $19/mo feels right for solo devs and probably too cheap for orgs. The risk is anchoring. If you're going to defend a $299 Enterprise tier later, you might want a story for why $19 → $299 is 15x the value, not 15x the same thing. Snyk and Socket both ended up moving most of the value behind auth, which is one path. The other is making the Pro tier specifically NOT scale to team use (per-user, per-repo limits) so the upgrade feels mechanical rather than predatory.

3. 60/min/IP isn't an abuse problem until somebody is incentivized to abuse it. Most likely abuser isn't a malicious actor, it's a competitor burning your free tier to enrich their own commercial product. The fix isn't lower rate limits, it's making the free API useful enough to be cited (so abuse is self-defeating because users want the brand attribution) and expensive enough to wrap in another product that the wrapping is more work than just paying you $19. Most public-good APIs that survive long-term solve this with attribution requirements rather than auth gates.

One unsolicited observation: the 14-hour timeline with the GPT-5/Gemini audit baked in is the more interesting framing than the timeline alone. Solo founders shipping with cross-model strategic checks as a process step is a story most "I built X in Y hours" posts skip. Worth its own post maybe.

I'm a UI/UX designer. I can help out with any future UI updates you want.

Sometimes you will want to add a feature but don't know how to make it look or best place to put it in the app, and sometimes you might just feel like you want a new look for the app.

I can also help you go through User complaints & Suggestions and i will implement these suggestions as UI design on FIGMA while you just focus on Coding. I'm born to ease the Critical thinking & design part for Devs like you

That's where i come in.

For Q1, I would be much more likely to run it in CI than manually tonight. The trust unlock is showing exactly why something is WARN/BLOCK and making the first scan feel read-only and reversible.

For pricing, $19/mo feels fine for solo builders if drift alerts save one bad install, but I would make the free API require a lightweight key sooner than later. Zero-auth abuse will probably teach you the wrong lesson because the noisy users are not the buyers.

This is a strong wedge because MCP security is moving faster than most teams can reason about manually. Install-time trust scanning, cited evidence, GitHub Action, badge, drift alerts, and a public rubric make this feel closer to infrastructure than a small OSS utility.

The bigger risk is positioning. “mcp-doctor” is clear for the first use case, but it may box the product into a package-checker frame. If the product keeps moving toward MCP supply-chain trust, repo monitoring, drift alerts, and security evidence for teams, the brand probably needs to feel more like a serious trust layer for AI tooling rather than a diagnostic script.

Vroth .com would fit that direction better because it carries the hard-edge security/devtools feel without locking you only to MCP or “doctor” language. Especially before badges, docs, API usage, and Pro customers build memory around the current name, I’d pressure-test whether you want this to be remembered as a scanner or as the security layer behind MCP adoption.