Who this is for
An owner who keeps hearing “MCP” and “connector” and wants a plain account of what they are before deciding how to connect an AI to the software they run.
The short version
- MCP (Model Context Protocol) is an open standard, published in late 2024, for how an AI model asks software for things. Claude, ChatGPT, and most coding assistants speak it.
- An MCP server is the program on the software side that answers. It publishes a list of tools — named actions with defined inputs, like
list_repairs_past_dueorlookup_customer— and runs them when the AI calls one. - An MCP connector is the same thing seen from the assistant’s side: the entry in your AI app’s settings that points at one server. “Add a connector” means “let my AI reach this one thing.”
- The AI never touches your software directly. It calls a tool by name; the connector does the work and returns the result as text the model can read.
- What a connector can do is fixed when it is built. A connector with only read tools cannot write, no matter how the question is phrased.
What it can and cannot do
An MCP connector can:
- Carry a specific person’s permissions, so the AI sees what that person may see.
It cannot:
- Reach a system it was not built for. One connector points at one thing.
- Write, if it was built with only read tools. A write exists only if someone deliberately adds a write tool.
Why this is harder than it looks
The idea is simple; the constraints are where the work is.
The AI has no access of its own. A chat assistant starts each conversation knowing nothing about your business. Anything it “knows” arrives through a connector, in the moment, as the result of a tool call. If there is no connector for a system, the AI cannot see it, and will sometimes guess instead of saying so.
Most small-business software was not built to be asked questions. A jewelry point of sale, a florist’s proposal tool, a recruiting ATS, a liquor store’s inventory system — many have no public API, or an API that was designed for a vendor’s own integrations rather than for outside programs. Some run only on a machine in the back office. A connector has to be written for each of these, and the writing is different every time.
A connector carries whoever’s permissions it was given. If it signs in with the owner’s login, every person whose AI uses it sees what the owner sees. Shared logins that were tolerable for people become a problem the moment an AI can ask a thousand questions a minute. Getting permissions right is most of the design.
Connectors multiply. Each system is its own connector, with its own settings, its own sign-in, its own set of decisions about what the AI may touch. Three systems is three sets of those decisions; ten is ten.
The approaches, honestly compared
| Approach | What it is | When it fits | What it costs you |
|---|---|---|---|
| Vendor-supplied connector | Your software vendor publishes an MCP server for their product; you add it in your AI app’s settings. | The vendor offers one and its permissions match how your staff actually work. Check first — the list is growing. | Little. You are limited to the tools the vendor chose to expose and the permissions their connector understands. |
| Copy and paste | Export a report, paste it into the chat. No connector. | One-off questions, small data, a single person. Honestly the right answer for many businesses today. | Someone’s time on every question; the answer is only as current as the last export; nothing is enforced about what leaves the building. |
| Build your own connector | A developer writes an MCP server against your system’s API, database, or export. | You have a system without a vendor connector and a developer (in-house or hired) who can own it over time. | A build, then upkeep whenever the system changes. Permissions, logging, and hosting are yours to get right. |
| Connector behind a gateway | Each person’s AI reaches your systems through one gateway that knows who they are; tools are filtered per person before the AI sees them. | Several people, several systems, and a need for “the associate’s AI cannot see payroll.” | A running service between your AI and your tools — someone has to operate it. Overkill for one person and one system. |
A vendor connector, if it exists and its permissions fit, is usually the cheapest path. Copy and paste is not embarrassing; it is the honest baseline every other option has to beat.
What we do and why
We build and run connectors for the tools an owner-operated business already has, behind a gateway that gives each person’s AI that person’s permissions — every tool is a read until the business decides otherwise. We make nothing on your AI bill.
Worked example
The connector we run in front of The Edge, a jewelry point of sale that runs on a machine in the store. The AI never reaches that machine. A nightly read-only export lands in a copy we host, and every tool on the connector reads from the copy. The store’s owner, managers, and associates each get their own AI with their own list of tools. It is in production, and we last verified it running on August 27, 2026. It is the worked example behind this explainer: one connector, pointed at one system, read-only as we run it. How The Edge and Claude connect → · Read-only first: why we sequence access this way → · Can I connect AI to software with no API? → · Should I use a connector, an export, or a managed service? → · How do I connect The Edge jewelry POS to Claude? →