MCP Servers for Software Without a Public API: The Complete Guide
Scraping MCP servers, browser-automation MCP servers, and private-API MCP servers all promise agent access to software without a public API. How the three approaches differ on latency, reliability, and writes, and which one holds up in production on enterprise portals.
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. This guide covers the full picture as of July 2026. The three ways to build MCP tools for software without an API: scraping, browser automation, and private APIs. How they compare in production, and where each is the right call.
TL;DR
- There are three ways to give an agent MCP tools for software without a usable API: scraping MCP servers, browser-automation MCP servers, and private-API MCP servers.
- Scraping is for public, read-only content. Browser automation works on anything a human can see, but pays for it in latency, brittleness, and MFA friction. Private-API servers behave like a normal API: deterministic, fast, and writable. That's what production workflows need.
- Enterprises now have real deployment and governance rails for MCP; the missing piece is servers for the software that never shipped an API.
- Supergood builds managed MCP servers on request, scoped to the customer's own account, across the verticals where the API gap is widest, from property management to healthcare RCM to hospitality.
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.
Three ways to build an MCP server when there's no API
An MCP server is a connector that exposes a set of tools an AI model can call. (New to that? Start here.) When the underlying software has no usable API, there are three ways to put working tools behind that interface. They are not interchangeable.
1. Scraping MCP servers
Servers in the Firecrawl, Bright Data, and ZenRows mold expose tools that fetch a page and hand back clean markdown or structured data. Point them at a URL, get content.
They're the right tool for public web data: research, competitive monitoring, content pipelines, feeding pages into a search index. They're the wrong tool for enterprise portals. Scraping is read-only by design, fragile behind logins and MFA, and returns page content rather than business objects. You can't post a payment or update a work order by scraping.
2. Browser-automation MCP servers
Playwright MCP and Puppeteer MCP drive a real browser with scripted selectors; computer-use tools like Skyvern add vision models that look at the page and decide what to click. The agent's tools are, effectively, hands on a keyboard and mouse.
The appeal is universality: if a human can do it in a browser, an agent can attempt it, with no integration work up front. That makes browser automation genuinely useful for one-off tasks, long-tail systems you'll touch once, and prototyping.
The costs show up in production. Every step is a page load, often a screenshot and a model call too, so a multi-step workflow takes minutes where an API call would take seconds. Selector-based flows break when the vendor moves a button; vision-based flows trade that brittleness for nondeterminism. And enterprise portals actively resist automation: MFA prompts, CAPTCHAs, bot detection, and session timeouts all land on you. (More on that trade-off.)
3. Private-API MCP servers
The third approach skips the rendered page entirely. Every web app is a client of its own private API: the JSON endpoints its front-end calls. A private-API MCP server is built from the platform's own network requests, the same way unofficial APIs are built: by mapping the authenticated endpoints and wrapping them as clean, callable tools.
The result behaves like the API the vendor never shipped. Calls are deterministic HTTP requests that return structured JSON, writes are first-class, and there's no browser in the loop: nothing renders, nothing gets clicked, no selector drifts. The catch is the work: months of endpoint mapping per system, then perpetual maintenance as the vendor changes things. That's why this is a managed-service category rather than a weekend project, and it's the approach Supergood productizes.
Browser-based vs. API-based vs. building your own
The practical differences, dimension by dimension:
| Browser-based | API-based | Build your own | |
|---|---|---|---|
| Latency | A session per call: navigate, render, act, wait, repeat. Vision-driven flows add a screenshot and a model inference per step. Minutes per workflow. | A single HTTP round trip against the same endpoint the vendor's front-end uses. Seconds per workflow. | Same single-round-trip profile, once the integration exists. |
| Reliability | Fails in browser-shaped ways: selector drift, layout changes, MFA prompts, CAPTCHAs, sessions expiring mid-run. | Fails in API-shaped ways: an endpoint changed, a session needs refreshing. Detectable, retryable, and fixed once for everyone. | Same failure modes as API-based, but you catch and fix every break yourself. |
| Writes | Possible, but it's a nondeterministic click-path posting payments. | Explicit tools with validated inputs and inspectable results. | Explicit, but you build and validate every write path. |
| Auth | Borrows a human's session and inherits the human's MFA prompts. | A dedicated account with managed MFA and automatic session refresh; the connection stays live without babysitting. | You own credential handling, MFA, and session refresh. |
| Token cost | Model tokens spent on every screenshot and every decision. | Tokens spent on arguments in and JSON out. | Same lean token profile; the cost is engineering time instead. |
| Maintenance | Re-teaching flows as UIs change. | A managed server makes maintenance somebody else's full-time job. | Owning endpoint drift forever. |
When to choose which:
- Public content at scale → a scraping MCP server.
- A system you'll touch once, or a workflow nobody has mapped yet → browser automation.
- An enterprise portal your business runs on, where agents read and write every day → a private-API MCP server.
What "production-grade" means here
A private-API 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, Supergood's 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.
- Observability. Every tool call logged with latency and outcome, so degradation surfaces as an alert to fix, not a mystery your agents trip over.
The 2026 MCP ecosystem made this deployable
Two things changed recently that matter specifically for enterprise portals.
The spec grew up. The November 2025 revision of the MCP specification was the protocol's biggest since launch: a stateless core that scales on ordinary HTTP infrastructure, a Tasks extension for long-running work, MCP Apps for tool-rendered UI, and authorization aligned with OAuth and OpenID Connect, including an Enterprise-Managed Authorization extension adopted by Anthropic, Microsoft, and Okta. Anthropic also donated MCP to the Agentic AI Foundation, which makes betting on the protocol a safer long-term call.
Enterprises got governance rails. Cloudflare's MCP Server Portals put every MCP connection behind Zero Trust access control: one gateway to centralize, secure, and observe MCP traffic, with service tokens for autonomous agents, Gateway routing with DLP scanning, and context optimization so tool definitions stay cheap.
The upshot: platform teams now have standard ways to deploy, authorize, and monitor MCP servers. What they still don't have is an MCP server for Yardi, or Availity, or Toast, because those vendors never shipped the API underneath. That's the layer this guide is about.
The verticals Supergood covers
Supergood builds managed MCP servers on request, scoped to the customer's own account, across the verticals where the API gap is widest. Recent work spans property management (systems like Yardi and AppFolio), healthcare and RCM (clearinghouses like Availity and Waystar), and hospitality (systems like Toast).
Example documentation exists for platforms including:
- Property management: AppFolio, Entrata, RealPage, ResMan, Yardi.
- Healthcare / EHR: AdvancedMD, eClinicalWorks, Kipu Health, Netsmart, TheraNest, WellSky.
- Behavioral health / ABA: CareLogic, CentralReach, SimplePractice, TherapyNotes.
- Healthcare RCM and clearinghouses: Availity, Change Healthcare, CoverMyMeds, InstaMed, Office Ally, Optum, Waystar.
- Restaurant and hospitality: NCR Aloha, Oracle Hospitality, Toast.
- Construction: Buildertrend.
The documentation catalog is much bigger: 700+ platforms, including auto dealer software and legal practice management, plus insurance, logistics, fitness, and more. If your agents need a system that isn't listed, the same approach applies.
FAQ
Can an MCP server work with software that has no public API?
Yes. That's the point of the three approaches above. Scraping servers extract content from pages, browser-automation servers drive the UI, and private-API servers call the private endpoints behind the web app. Which one fits depends on whether you need reads or writes, public pages or an authenticated portal, and a one-off task or a daily workflow.
Are browser-automation MCP servers reliable enough for production?
For demos, one-offs, and long-tail systems, yes. For daily enterprise workflows, the failure modes compound: MFA and CAPTCHAs interrupt runs, UI changes break flows, and per-step latency turns a five-second job into a five-minute one. Teams that start with browser automation for a core workflow usually end up wanting API semantics underneath it.
What's the difference between a scraping MCP server and a private-API MCP server?
A scraping server returns what a page says; a private-API server returns what the system knows, as structured business objects, and it can write back. Scraping is a read-only view of rendered HTML. A private-API server speaks to the same private endpoints the vendor's front-end uses, so an agent can fetch a resident ledger or post a claim, not just read about them.
How does a private-API MCP server keep working when the vendor changes their app?
Observability. Supergood monitors every call to every endpoint, so when a vendor ships a change that alters a response shape or breaks a flow, it's detected and the connector is patched centrally, usually before customers notice. That maintenance loop is most of the value of a managed server over a DIY integration.
Which MCP spec changes matter most for enterprise deployments?
Three from the November 2025 revision: the stateless core (servers scale behind ordinary load balancers), the Tasks extension (long-running work like report generation fits the protocol), and enterprise-managed authorization (your identity provider controls what agents can reach). Combined with gateway products like Cloudflare's MCP portals, MCP now passes standard enterprise security review.
Supergood builds and maintains MCP servers, and the REST APIs underneath them, for the software that doesn't offer one, generated from the platform's own network requests with 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.