Back to browse
We wrapped US healthcare API in MCP and it became surprisingly usable

We wrapped US healthcare API in MCP and it became surprisingly usable

by endurant_dev·Feb 23, 2026·2 points·1 comment

AI Analysis

●●SolidSolve My ProblemSlick

MCP bridge turns messy healthtech API into conversational interface; real healthcare friction.

Strengths
  • MCP pattern reduces integration friction from 'learn 50+ endpoints' to 'talk to Claude'
  • Genuine healthcare pain point: API surface area, partner onboarding, multi-language queries all addressed
  • Conversational queries ('Does this plan cover X?') are genuinely more accessible than REST pagination
Weaknesses
  • Still early-stage with 'two clients' — no evidence of product-market fit or scale
  • Cloudflare blocking suggests bot/spam issues; security posture unclear for healthcare data
Category
Target Audience

Healthcare engineers, healthtech startups integrating US provider/plan data, AI-driven healthcare tools

Similar To

Stripe's MCP usage patterns · Zapier/Make healthcare automations

Post Description

Hi HN,

I’m building HealthPorta — an API layer for the US healthcare data (providers, plans, coverage, costs). Like most healthtech APIs, it started small… and then it didn’t. The surface area grew fast, integrations took longer than they should, and every new partner ended up needing a mini “tour guide” to use it correctly.

So, since the last post here, something changed. We’ve built an MCP server as a boring integration helper to provide a smaller, friendlier interface for engineers of our "two clients" who didn’t want to learn the entire API on day one and just wanted to ask Codex or Claude to "integrate".

Then something unexpected happened.

Once it was hooked into MCP clients, it stopped feeling like "API integration tooling" and started feeling like something you can talk to:

- Find a pcp doctor near me - Does this plan cover this medication? - What’s the cost signal for this procedure/provider? - Any quality or cost indicators for this provider?

Under the hood, it’s still structured tool calls — but the interaction flips from reading the docs & mapping endpoints to "ask a question + inspect the returned structure." Frankly speaking, it was a good stress test for the API layer, as, by common consensus, the MCP tested the APIs quite well, from the structure of calls to usage limits also.

What it can help with (today):

- provider lookup (specialty/location) - plan & issuer lookup - medication details, including restrictions, etc. - coverage/formulary-style checks (where available) - cost-related signals + basic comparisons (doctors, plans) - provider metadata + quality-related signals (where available)

What we’re working on now: We’re going deeper on transparency data from insurers and hospitals to improve cost/coverage accuracy and make outputs more explainable (and less "trust me, bro").

There’s a free per-user cap, so you can test it without paying or adding a card. Use it from your favorite MCP-capable console or IDE (anything that supports MCP and auth).

I’d love feedback on it.

Happy to answer questions / share implementation details.

Similar Projects

HealthPass

US Healthcare API and MCP server: the first step to price transparency

The idea—putting standardized pricing and an MCP server behind a programmatic API—actually matters if it normalizes the mess of payer rates and CPT mappings. I couldn't get past a Cloudflare verification page to inspect endpoints or sample data, so the promise is there but I need to see the OpenAPI surface, sample responses, and data sources to judge whether it's transformative or just a thin wrapper around public datasets.

Niche GemShip It
endurant_dev
204mo ago