Connecting an AI assistant to an enterprise platform's API

A capable language model sitting beside an enterprise system is not much use until it can query that system. The moment it can, a set of previously hypothetical questions become concrete. Which operations is it allowed to call? How does it learn what data exists without a developer describing every entity to it in advance? And what prevents a request phrased in plain English from becoming a write against a system of record that thousands of people depend on?

These questions came up in our own work connecting assistants to OpenText AppWorks, a platform whose process-automation tenants expose several hundred API endpoints. The answers generalize well beyond that one product, and the bridge we built to settle them is now open source. What follows is the reasoning, with the OpenText connector as the worked example.

The cost of wiring one endpoint at a time

The obvious way to give an assistant access to an API is to write a dedicated tool for each operation: one to list cases, one to fetch a case, one to search by status, and so on down a list that, for a large platform, runs into the hundreds. Every one of those tools has to be defined, described to the model, tested, and then maintained as the underlying API moves.

Two things go wrong. The first is arithmetic. Nobody writes and maintains three hundred tool definitions, so a developer picks the ten or twenty operations that look useful today and the assistant stays permanently blind to the rest. The second is timing. The selection has to be made before anyone knows which questions users will actually bring, which is precisely when the information required to choose well does not yet exist.

Discovering the surface rather than enumerating it

A better approach uses something these platforms already provide: they describe themselves. An AppWorks tenant knows which entities it holds and which fields each one carries, and it will report that structure on request. A bridge can read that description when it starts and learn the shape of the system it sits in front of, with nobody transcribing any of it by hand.

Above that description sits a small set of generic tools in place of one tool per endpoint. The assistant can ask what kinds of record exist, ask for the structure of a particular one, and retrieve the records that match a condition. Three general operations, composed by the model, reach the ground that hundreds of specific ones would have covered, and they keep working when a tenant's own configuration changes because they were never bound to it.

Read-only until there is a reason not to be

A generic bridge to a system of record is powerful, and pointing that power at production data through a component that is fluent whether or not it is correct is a liability. So the bridge reads; it does not write. An assistant can answer questions about what the system holds. It cannot alter what the system holds.

That is a deliberate boundary rather than a missing feature. Read access covers most of what makes an assistant useful over an enterprise platform, which is finding, explaining and summarizing what is already there, while carrying a small fraction of the risk. Write access is a separate decision, taken one operation at a time, with its own approval and its own audit trail, rather than something that arrives by accident because a general query tool happened to be able to reach it.

Where it runs

The bridge speaks the Model Context Protocol, the interface a growing number of assistants use to reach external tools, so it is not tied to a single vendor's model. It runs in either of two modes. One is a local process that a desktop assistant such as Claude starts directly, which suits an engineer working against a tenant from their own machine. The other is an HTTP service that a hosted assistant calls over the network, which suits a team that wants the bridge to run centrally under its own controls. It supports the OpenText Directory Services front end and recent AppWorks and Process Automation releases today, and it is an early release rather than a finished product.

Why we published it

A read-only bridge between an assistant and an enterprise API is plumbing. It is the sort of component every team that attempts this ends up rebuilding, and there is nothing to be gained by each of us doing so privately. We released it under a permissive licence for that reason. It installs with a single command, pip install opentext-pa-mcp, the source is public, and it is free to use and to fork.

It is one small, specific tool, and it stands for a general position. In applied enterprise AI the interesting engineering is rarely the model. It is the boundary drawn around it: what it may see, what it may do, and how a person stays in a position to check its work.