Most MCP content stops at the demo: connect Claude to a to-do list, applaud, publish. This is what it looks like when the Model Context Protocol runs a real business — a Caribbean car-rental company whose entire operational backend, from reservations to fleet telematics to payments, is now callable by AI agents through a 114-tool MCP server we built and operate. It runs in daily use. It touches money. And the interesting engineering was never the MCP part.
The hard problem isn't giving an AI tools. It's deciding which tools it gets, in which context, with which blast radius — and encoding that decision in code instead of hope.
The setting: an island fleet and a quirky API
The client rents cars across a Caribbean island and runs their operation on a rental-management SaaS — reservations, fleet, customers, payments, vehicle telematics, all in one vendor platform. The platform has an API, which is where the optimism ends. It expects POST parameters in the query string. Field identifiers are tenant-specific, so the field that means "pickup location" in one account means something else in another. And at least one endpoint mutates state on a GET request, which is the kind of thing you discover exactly once.
Day to day, that meant manual everything: staff clicking through the vendor UI for lookups a sentence could describe, quotes assembled by hand, and no way to ask the system a question it didn't already have a report for. The goal wasn't a chatbot. It was to make the backend AI-operable — so that an agent, properly constrained, could do the clicking.
Architecture: the SDK is the foundation, MCP is the roof
The build is a three-package TypeScript stack, and the layering is the whole point:
- SDK core (~3,700 lines). A typed client that makes the vendor API behave like one designed this decade: Stripe-shaped resource classes, retry with backoff, and a seven-class typed error hierarchy so a rate limit, an auth failure, and a validation error are different types — not one string a model has to squint at.
- MCP server: 114 tools across 54 tool files. Reservations, quoting, customers, fleet, payments, damages, telematics, agreements — each tool a thin, documented wrapper over the SDK with schemas the model can actually plan against.
- A public ChatGPT app (~1,300 lines). A deliberately tiny consumer surface, covered below.
The discipline that pays off daily: no tool calls the vendor API directly. Every quirk — query-string POSTs, tenant field mapping, the mutating GET — is absorbed once, in the SDK, and tested there. The MCP layer stays boring, and boring is what you want in the layer an AI improvises against. It's the same separation we argue for in our AI architecture guide: connection, action, and governance are different layers, and collapsing them is how demos stay demos.
Designing an API surface a model can't misread
An AI agent is a fast, tireless junior operator with no institutional memory. The schema is the only training it gets, so we made the schemas opinionated:
- Discriminated-union reservation states. A reservation isn't a bag of nullable fields; it's one of a set of explicit states, each carrying only the fields valid in that state. The model can't reason about a pickup time that can't exist yet, because the type won't let it see one.
- Integer minor-unit money. Every amount is an integer in minor units with an explicit currency. Floating-point money in an LLM pipeline is how a quote drifts by a cent and an invoice dispute is born.
- Zero-diff schema snapshots. Every rebuild regenerates tool schemas and diffs them against committed snapshots. The v2.0.0 release shipped with byte-identical schema parity — meaning we can refactor internals aggressively while proving the model-facing contract didn't move.
None of this is exotic. It's the same contract discipline good integration engineering has always demanded — the model just punishes sloppiness faster than a human integrator would, because it takes your schema at its word every single call.
The safety story: two-key launch controls
Here is the section that matters if the phrase "AI agent with payment access" made you flinch. It should. Our answer is a 204-line write-gating proxy that annotates all 114 tools into three tiers:
| Tier | Examples | Default | To enable |
|---|---|---|---|
| Read | Search reservations, check availability, daily manifest | On | Nothing — this is the baseline |
| Write | Create reservation, update customer, assign vehicle | Off | Explicit opt-in flag per deployment |
| High-risk | Charge card, refund, security-deposit release | Off | Write flag and a second, separate high-risk flag |
We call it two-key launch controls: money moves only when two independent switches have been deliberately turned, in configuration the client owns, enforced by the proxy before any tool executes. The model never sees an ungated tool it hasn't been granted; a prompt-injection attempt against a read-only deployment has nothing to inject into. This is the operational version of the argument in our MCP security guide: permissions live in the connector layer, not in the prompt.
Equally important is what we did not automate. Gating is in the proxy, but judgment stays with staff: the AI drafts, checks, and assembles; a human owns anything a customer will feel.
Carving a public surface: the three-tool ChatGPT app
The same backend also powers a public, consumer-facing ChatGPT app — and the design move is subtraction. Of 114 tools, the public app exposes exactly three: locations, vehicle options, and quotes. A traveler planning an island trip can ask ChatGPT what's available and what it costs, and get answers straight from the live rental system.
Every public response passes through a field allowlist. Not a blocklist — an allowlist. The vendor API returns rich operational payloads with internal identifiers, cost fields, and configuration detail that has no business in a consumer chat; only fields explicitly approved for public consumption survive the trip out. The app is ~1,300 lines with unit tests plus in-protocol tests — tests that speak MCP to the running server and assert on what a model would actually receive — and CI secret scanning on the repository, because a public AI surface is a public attack surface.
That's the pattern we'd hand any company asking for "a ChatGPT app for our business": same SDK, separate server, minimum tools, allowlisted fields, zero shared authority with the staff connector.
What daily operations actually look like
With the connector live, the vendor UI stops being the only door into the business. Staff work conversationally against the same tools: pull the daily manifest and walk through today's pickups; find a customer across bookings without remembering which spelling of their name is on file; check availability and assemble a quote in one exchange instead of a form-filling session; ask fleet questions — which vehicles are due back, what the telematics history shows — that previously meant a report request. The write-gated deployment lets trusted staff take the next step and create the reservation from the same conversation.
The honest version of the limits, because a case study without them is an ad: the model occasionally plans a clumsy tool sequence and needs a nudge; tenant-specific field mapping means onboarding a new account of the same SaaS is configuration work, not copy-paste; and the vendor API remains the ceiling — when it's down or slow, the AI is too, which is why the SDK's retry, backoff, and typed errors exist. An AI-operable backend doesn't remove operational ownership. It changes what your best people spend it on.
The numbers, from the code audit
- 114 MCP tools across 54 tool files
- ~3,700 lines of SDK core with a 7-class typed error hierarchy
- 204-line write-gating proxy annotating all 114 tools
- ~1,300-line public ChatGPT app with unit and in-protocol tests, plus CI secret scanning
- v2.0.0 frozen with byte-identical schema parity against committed snapshots
- In live daily use at the client
Every figure comes from auditing our own repositories, not from marketing rounding. Where a number is approximate, we say so.
Scoping your own AI-operability project
If you're considering the same move — letting AI agents operate the systems your business already runs on — the sequence that worked here generalizes:
- Audit the API before promising anything. The vendor's API quality sets your budget. Quirks aren't blockers, but they belong in an SDK layer, priced and tested, not discovered in production.
- Ship read-only first. Most of the daily value — lookups, manifests, cross-record questions — needs no write access at all, and read-only usage is how you learn where the model stumbles while it can't break anything.
- Gate writes in code, tier the risk. Separate "can create a booking" from "can move money," and make each an explicit switch someone accountable turns on.
- Treat any public surface as its own product. Minimum tools, allowlisted fields, its own tests and secret scanning.
This is the core of our AI setup service: we audit the system, build the connector and its guardrails, and leave you with an operating model — not a demo. If the system in question is Salesforce, the same architecture ships through our Salesforce MCP consulting practice, and the consumer-surface pattern is exactly what we build in ChatGPT + Salesforce solutions.
Frequently asked questions
What is an MCP server, in business terms?
MCP (Model Context Protocol) is the open standard that lets AI assistants like Claude and ChatGPT call your software's functions as tools. An MCP server is the piece you build: it translates 'find this reservation' from the model into an authenticated API call against your real system, and returns structured data the model can reason over. It's how AI stops being a chat window and starts being an operator.
How long does it take to build a custom MCP server for a business system?
The MCP layer itself is fast; the work is everything under it. If your vendor API is clean and documented, a useful read-only server is weeks, not months. If the API has quirks — ours had endpoints that mutate on GET — budget for an SDK layer that normalizes behavior first. Write access and payment operations should come later, behind explicit gating, after read-only usage has proven the model behaves.
Is it safe to let AI agents touch payments and refunds?
Not by default, and we don't. In this build every tool starts read-only, write tools sit behind an explicit opt-in flag, and payment and refund tools sit behind a second, separate high-risk flag. Both switches have to be deliberately enabled per deployment. The model never decides its own permissions — the proxy layer does, in code the client controls.
Can we expose part of our backend to customers through ChatGPT?
Yes, but expose a surface, not the system. Our public ChatGPT app carves exactly three tools out of the 114 — locations, vehicle options, and quotes — and every response passes through a field allowlist so raw operational payloads never reach a consumer conversation. The public app shares the SDK with the staff connector but none of its authority.
Does this only work for car rental?
No. The pattern — SDK that normalizes a quirky vendor API, MCP tools on top, tiered write gating, a narrow public surface — applies to any operational SaaS: practice management, property management, logistics, booking systems. Car rental just happens to exercise everything at once: inventory, scheduling, customers, payments, and telematics.
Bring us the backend
GAT Solutions builds revenue-generating systems for healthcare, accounting, and SaaS companies — fast, flawlessly, and powered by AI. The premium choice for teams who can't afford to re-do the work.
If your team is swivel-chairing between a vendor UI and everything else, bring the system to a working session. We'll audit the API, map the tool surface worth building, and show you the gating architecture before you spend a dollar.