Connect the AI you use to the software your business relies on.
A custom MCP connector can give an AI tool a defined way to work with an existing system, including software without a ready-made integration.
Illustrative example using an invented order-management workflow.
The starting point
The team uses AI, but answers about orders still require someone to open an older system, find the record and copy information between tools.
The proposed workflow
A proposed connector lets the AI request the information it is allowed to access and return an answer with the record behind it. Changes are separate actions with their own permissions.
Start with a question people ask every day.
For this example, a customer asks when an order will arrive. The account manager needs the current status from an existing order system before replying.
I would first check what access the system supports and what the AI tool can connect to. An API, database view or supported export may provide a route. If the system cannot offer reliable access, we need to solve that before promising an integration.
Let the connector return a bounded answer.
| Input or action | Example | What the connector permits |
|---|---|---|
| Team request | What is happening with order 1042? | Look up an order the signed-in user may access. |
| Order record | Awaiting stock. Dispatch date not confirmed. | Return the status, record reference and last update. |
| Proposed reply | The order is awaiting stock; a dispatch date has not been confirmed. | Prepare an answer without inventing a delivery promise. |
| Request to change delivery date | Set delivery to Friday. | Keep this outside the initial read-only connector. |
MCP, the Model Context Protocol, is the interface between the AI tool and the connector. The connector handles the system-specific work and enforces access rules. A prompt asking the model to be careful is not an access control.
Define access in the software.
I would build a small set of explicit operations for the work you need. The underlying system and connector would enforce who can use them and which records they can access.
For a first version, that might mean read-only lookups. If the team later needs to make changes, we would add narrowly scoped write operations and agree where a person must review them.
Test what happens when the answer is missing.
We would test missing records, restricted accounts, stale information and an unavailable source system. The result should make those limits visible rather than fill the gaps with a plausible answer.
The handover would cover how to use the connector, who maintains it, how access is removed and what happens when either system changes. The useful result is less copying and switching between tools, with access you can control.
Bring your existing software into your AI workflow.
Tell me where the work gets stuck. We’ll look at what a useful first step could be for your team.