Giving AI Access to a Legacy System That Has No API

1. The Copy-Paste Tax Nobody Budgets For

Here is the workflow most firms are quietly running today. A consultant opens the ageing portal that runs the business. They read a case, select the details that matter, and paste them into a chat window. The AI drafts a reply. They copy the reply back into the portal. Repeat, all day, across a team.

It works. It is also slow, error-prone, and — the part that should worry you — a data-governance problem the moment client data leaves the building. Every paste into a public, multi-tenant AI service is a small, undocumented export of information you promised to protect.

The usual excuse is that the system of record “has no API”. Often that is literally true: it predates the API era, or the vendor never shipped one. But “no API” does not mean “no automation”. It means choosing between two legitimate routes instead of one, and choosing deliberately.

2. Route One: Wrap the Portal in an MCP Server

The Model Context Protocol (MCP) is an open, client-agnostic standard for exposing capabilities to AI assistants as structured tools. That last phrase matters, so let me be precise about what it is not.

MCP is not a way to point Claude, or any single vendor’s desktop app, at database endpoints. There need be no database and no API underneath at all. An MCP server is simply a small program you control that advertises a set of named tools — get_case_history, log_time_entry, list_open_workload — and knows how to fulfil each one. How it fulfils them is your business.

For a portal with no API, the honest answer is that the server drives the portal’s own UI behind the scenes. It holds a persistent, authenticated browser session, and each tool call clicks through the same screens a human would — but returns clean, structured data to the assistant instead of a rendered page.

Why this is worth the effort

• Any compatible assistant can use it. Because MCP is a protocol, the same server works with whatever MCP-aware client your firm standardises on, now or later. You are not marrying a vendor.
• Tools are a natural safety boundary. You expose exactly the operations you choose and nothing else. Read-only tools (retrieving cases, workloads, history) can be kept firmly separate from write tools (logging time, editing records), with writes requiring explicit parameters so nothing mutates by accident.
• It scales past one desk. The same server can run as a local process for one person or as a shared endpoint for a team, with each user’s session isolated by identity — no per-person infrastructure.

The honest drawback

• The server ultimately depends on the portal’s UI staying put. If the vendor reshuffles a screen, the affected tool can break until you update the selectors. You are building on sand that occasionally shifts — manageable, but real.
• It is a piece of software someone has to own, host, and maintain. This is an engineering artefact, not a browser plugin you forget about.

3. Route Two: Automate the Browser In Place

The second route keeps everything inside the browser the user already has open. A governed browser extension overlays the portal, reads the live screen, and adds an AI panel and workflow helpers directly on top of the existing UI — with no change to the portal or its backend.

Where the MCP server pulls the user out of the browser and into a chat window, the extension brings the AI to the user, sitting beside the ticket or case they are already looking at.

Why this fits some teams better

• No moving the user. Drafting, summarising, and dictation happen next to the record, grounded on what is on screen. There is no leave-the-portal, rebuild-context, paste-back loop.
• Rollout is gentle and reversible. An extension can ship behind a master switch that defaults to off, so adoption is opt-in and can be pulled per user without touching anyone else.
• It can read the real page structure. A well-built extension reads the underlying form data rather than scraping rendered pixels, which tends to be steadier on a messy multi-frame legacy layout.

The honest drawback

• It lives and dies inside one browser. It does not give a headless assistant or an automated pipeline access the way a server endpoint can.
• Like the MCP route, it is still coupled to the portal’s markup and needs maintenance when the vendor changes things.

4. Keeping the Data Inside the Firm

This is the part that separates a proper build from a liability, and it applies to both routes.

The whole point is to stop client data leaking into public services. So the AI these tools talk to should be your firm’s own endpoint — a private, controlled deployment — not a public, multi-tenant API. Where a task can run on-device, run it on-device: local speech-to-text, for instance, means dictation audio never touches the network at all.

Treat credentials with the same care: hold tokens in session storage, never sync or log them, and purge working data on a sensible schedule. Done this way, the governance win is a property of the architecture — data stays in your environment because there is no path out — rather than a policy you are hoping people follow.

5. How to Choose

A reasonable decision rule:

• Choose the MCP server when you want the portal’s functions available to an assistant across a team, or fed into other automated workflows, independent of any one browser session.
• Choose the browser extension when the work is done by people staring at the portal all day, and the win is bringing safe AI to exactly where they already are.
• Some firms want both, for different jobs. That is fine — they share the same governance spine.

Summary

“No API” is not a dead end; it is a fork in the road. An MCP server wraps the portal’s functions as structured tools for any compatible assistant, which suits team-wide and headless use. A governed browser extension brings AI into the UI itself, which suits people working in the portal all day. Both can be built without a single change to the system of record — and both, done properly, keep client data inside your own environment instead of pasting it into someone else’s.

The one thing not worth doing is the status quo: taxing your team a few minutes at a time while quietly exporting client data one paste at a time. Pick a route, scope it tightly, and keep the data at home.