← Back to blog
mcpmcp serverunofficial apiai agentsapi integration

MCP for Software Without a Public API

A lot of business software ships no public API, a partner-gated one, or a thin read-only slice. An MCP server, built by reverse-engineering the web app, is how AI agents work with it anyway. What that takes, and where it's worth doing.

Published by Alex Klarfeld · May 12, 2026
MCP for software without a public API

You want an AI agent to do something inside a piece of business software. The software has a web app. It doesn't have an API you can actually use.

Maybe there's no public API at all. Maybe there's one, but it's gated behind a partner program with a contract and a per-call fee. Maybe it exists and it's a thin read-only slice that doesn't cover the thing you need to do.

That's the situation for a huge chunk of vertical and legacy SaaS, and it's the gap an MCP server fills.

When the API doesn't cut it

3 flavors of "no usable API," and they land in the same place:

  • No public API. The vendor never shipped one. Everything happens in the web app. SimplePractice and TherapyNotes are textbook cases in behavioral health; plenty of property-management and POS tools too.
  • Partner-gated. There's an API, but you need a partnership agreement, certification, sometimes a per-door or per-call fee. Yardi, Entrata, RealPage, and a long list of healthcare clearinghouses work this way.
  • Thin or read-only. AppFolio's REST API is export-only. Some EHRs expose FHIR for a handful of resources and nothing for the rest. You can read; you can't act.

An agent that can read but can't write, or can't touch the system at all, is stuck narrating the work instead of doing it.

Why an MCP server is the right shape here

An MCP server is a connector that exposes a set of tools an AI model can call. (New to that? Start here.) For software with no usable API, the MCP server gets built the way unofficial APIs get built: by reverse-engineering the authenticated flows behind the web app and wrapping them as clean, callable tools.

Why this beats the alternatives:

  • Versus waiting for the vendor. You wait forever. Most of these vendors will never ship an MCP server, and a lot of them won't ship a real API either.
  • Versus driving the UI with a bot. Browser automation and "computer use" agents work without an API, but they're slow, brittle, token-expensive, and trip MFA and CAPTCHAs. (More on that trade-off.) An MCP server hits the same underlying endpoints the app's front-end uses, as a normal API call: deterministic, fast, structured.
  • Versus building it yourself. Months of reverse-engineering per system, then perpetual maintenance every time the vendor moves a button. The reverse-engineering you can do; the maintenance is what burns teams out.

What "production-grade" means here

A reverse-engineered MCP server is only useful if you can lean on it. That takes:

  • Auth handled. A dedicated account, managed MFA, automatic session refresh. The connection stays live without anyone babysitting it.
  • Normalized data. Consistent JSON shapes across modules, not the raw shape the front-end happens to return.
  • Monitoring and adaptation. When the vendor changes its UI, monitoring catches it and the connector gets patched, ideally before it reaches you.
  • Real-time. Live reads and writes against the vendor's system, not a stale nightly export.

Examples

Supergood maintains MCP servers for vendors across the categories where this gap is widest:

If yours isn't on the list, the same approach applies.

Supergood builds and maintains MCP servers, and the REST APIs underneath them, for the software that doesn't offer one, using automated reverse-engineering and human-in-the-loop code review, with observability so the integration keeps working when the vendor changes things.

If there's a system your agents need to touch and it doesn't have an API worth using, that's the problem we solve. Request an MCP server for it.

Ready to get a real API?