For thirty years the interface to your business has been a website: pages for people to read, forms for people to fill in, buttons for people to press.
That assumption is now partially wrong. A growing share of the people who want to buy from you are delegating the transaction to software. And the software cannot fill in your form.
The standard that settled this is the Model Context Protocol. Anthropic released it in November 2024, and by December 2025 donated it to the Linux Foundation's Agentic AI Foundation, backed by AWS, Google, Microsoft, OpenAI, Bloomberg and Cloudflare. As of mid-2026, reported enterprise figures put 78% of enterprise AI teams running MCP-backed agents in production and 28% of the Fortune 500 operating MCP servers — with SDK downloads around 97 million a month. ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor and VS Code all speak it.
Almost every article about this is written for engineers. Here is the version for the person paying.
Being findable by an assistant gets you mentioned. Being actionable by one gets you the order. Those are different investments, and only one of them has a queue.
The gap between mentioned and bookable
Imagine two barbershops in the same street. Both are on the same directory. An assistant asked to find a haircut tomorrow at six can name either.
For the first, the answer ends with a phone number. For the second, the assistant checks real availability, holds a slot and completes the booking inside the conversation.
The second shop did not win because its marketing was better. It won because it was transactable at the exact moment of intent, and the first one required the customer to start again in a different application.
That is the whole thesis. Search visibility competes on attention. Agent visibility competes on friction to completion, and the gap between "here is their number" and "booked, you will get a confirmation" is the largest remaining source of drop-off in a lot of service businesses.
What we actually built
We run Bronjoy, an appointment booking marketplace for Uzbekistan. In September 2026 it listed 23,727 venues. We built two MCP servers into the same Laravel backend that serves the website, so the tools call exactly the same search, availability and booking services a browser does.
A public marketplace server. No account, no token. Six tools, in the order a booking actually happens: search-venues, get-venue, reveal-phone, check-availability, request-booking-code, book-appointment. It works as a connector in Claude and as a Streamable HTTP endpoint for anything else.
A private organisation server. A business issues a token from its dashboard, scoped by middleware to that one organisation. Booking-only tools. A single organization://profile resource describes services, staff, branches, timezone and currency, so an assistant gets the whole context in one read instead of six calls.
Four design decisions did most of the work, and they generalise to almost any business.
Declare what you cannot do, on every record
Most of Bronjoy's catalogue is directory data — real businesses with real hours and a phone number and no online booking. An assistant that assumes every venue is bookable will promise a customer something that cannot happen.
So every result carries an is_bookable flag, and the server's own instructions tell the assistant to say plainly when a venue can only be phoned.
This is the opposite of the marketing instinct. The instinct is to maximise apparent capability. The correct move is to be explicit about limits, because an agent that knows your boundary routes around it politely, while an agent that discovers it at checkout produces a failed order and a bad answer about you next time.
Never let the agent hold the key
request-booking-code sends six digits to the customer's own phone or email. The assistant never sees them. The user reads them back. The code lasts five minutes and books one appointment.
The assistant is a helper, not an identity. That distinction is what makes the whole thing safe to expose publicly.
Rate limits replace the checks your front end was doing
On the website, the code endpoint sat behind Cloudflare Turnstile. An MCP client cannot solve a Turnstile. So the server enforces its own ceilings: 30 requests a minute per caller, 10 phone reveals a minute, 10 code sends an hour, on top of the existing per-recipient limit. Phone numbers are masked in search results and only revealed through a deliberate, separate call.
Organisation tokens are Sanctum tokens bound to one organisation, 90-day default expiry, 365 maximum, 60 requests a minute per token and 120 per organisation, with every operation logged for audit.
The agent path and the human path must enforce the same rules
This is the finding that will cost other companies the most money, so read it twice.
Bronjoy's public server shipped together with a fix to the website's own guest booking flow. The old flow created the appointment first and sent the verification code afterwards — which meant a name and any phone number could put a real booking on a partner's calendar. Verification now happens before anything is written, and the MCP tools call that same service.
An assistant cannot book on terms a browser could not.
Most companies will discover the same thing: their real business rules live in the front end. A disabled button, a multi-step wizard, a hidden field, a session that had to be built up over five page views. None of that exists in an agent channel. Exposing an API does not create that vulnerability — it reveals one you already had.
What it costs and where to start
This is not a twelve-month programme. For most businesses it is a focused build on top of an API you already have.
Step 1 — pick one action, not a catalogue. The right first tool is the single thing customers most want to do and most often abandon. Book, check availability, order a repeat, get a quote, check a claim's status. One.
Step 2 — write down the business rules that currently live in your interface. Who is allowed to do this, how do we know it is really them, what must be true before it is written, what happens on failure. If those rules are not already on the server, that is the project.
Step 3 — decide your honesty flags. What is the is_bookable of your business? Which records can be acted on and which are read-only? Put it in the data.
Step 4 — set limits before you launch, not after. Per caller, per recipient, per account. Assume the caller is a script, because sometimes it will be.
Step 5 — annotate your tools. MCP lets each tool declare whether it is read-only, idempotent or destructive. A client that knows the difference behaves better.
Our AI integration and automation work starts at $299 with a 1–3 week delivery, and this shape of build sits inside it: a workflow audit, the integration, then evaluation against real conversations. The same service covers the other end of the spectrum — assistants trained on your own documents with a human handoff path, as in the Bronjoy help bot, which answers in three languages from imported product docs, holds no write tools at all, and escalates to a person on request, after repeated unhelpful answers, or on error.
Who should not build this yet
We would talk three kinds of business out of it, and it is worth being specific so you can place yourself.
Your availability data is not true. If your calendar, your stock levels or your service list disagree with reality by more than a few hours, an agent interface will broadcast that inaccuracy faster and more confidently than your website ever did. A customer who is told "booked" and arrives to find nothing is a worse outcome than a customer who had to phone. Fix the data first; the integration is the easy half.
Your business rules live in your front end. Covered above, and it is a prerequisite rather than a nice-to-have. If skipping the website would let someone do things they should not, exposing an agent interface converts a latent bug into a live one. That work has to happen anyway — it just has to happen first.
Nobody is asking for you by category. If your customers arrive by referral, by tender, or through a relationship, an assistant is not in the path and this is a solution looking for a problem. The test from our piece on AI search applies: write the twenty questions a buyer asks before they buy. If none of them could be answered by "find me one and book it", stop here.
There is also a fourth case worth naming: if your product's value is the interface itself — a design tool, a game, anything where the experience is the point — an agent channel is beside the point, and time spent on it is time not spent on the thing people are paying for.
The part that turns into revenue
One detail from our own product is worth copying: MCP access for a business is a paid plan feature.
Agent access is not a marketing channel to be given away. For a marketplace, a SaaS product or a supplier, it is a distribution capability, and capabilities can be priced. The organisation server exists precisely so a business can point its own assistant at its own calendar — that is a product, not a brochure.
If you run a platform with business customers, the question is not whether to build an agent interface. It is whether it is a feature of your paid tiers.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
How to judge whether it worked
Agent channels fail at measurement more often than they fail technically, because the instinct is to count calls.
Calls are not the metric. Completions are, and so is the ratio between them.
Three numbers, all of which your own server can produce:
| Metric | What it tells you | What a bad value means |
|---|---|---|
| Search → completion rate | How often a session that started with a search ended in a booking or an order | Your data is not rich enough for the agent to narrow down a good match |
| Failed writes / attempted writes | How often the agent tried something your rules rejected | Your tool descriptions are promising capability you do not have |
| Verification drop-off | How many people requested a code and never entered it | The friction is in the wrong place, or the agent is reaching people with no real intent |
That middle row is the one to watch in the first month. A high rejection rate is not the agent misbehaving; it is a mismatch between what your tools say they do and what your business actually permits. Every rejection is a sentence to fix in your tool description.
And one qualitative check that beats all three: once a week, use it yourself, as a customer, on your phone. Ask an assistant to do the thing your customers do. You will find the gap between what your data says and what a stranger would conclude from it faster than any dashboard will show you.
Frequently asked questions
Is MCP going to be replaced by something else next year?
Unlikely in the short term. Its governance moved to a neutral foundation with the major model vendors and cloud providers behind it, and competing protocols in commerce have converged on interoperating rather than displacing it. More to the point, the expensive part of this work — moving your business rules out of your front end — is protocol-independent and would survive a switch.
Do I need to expose my whole system?
No, and you should not. Expose the smallest set of actions that completes one valuable job. Our public server exposes six tools and nothing that is not already on the public website.
What if an assistant misrepresents my business?
That is a real risk and it is mostly addressable in the data and the server instructions. Flags like is_bookable, masked fields, explicit instruction text and tool annotations all constrain what an assistant can reasonably say. The alternative — being described by an assistant that has only scraped your marketing copy — is strictly worse.
Is this only for marketplaces and SaaS?
No. Any business where a customer has to check something and then commit benefits: clinics, salons, repair services, logistics, wholesale ordering, education enrolment. The pattern is availability plus a verified write.
How do I know if my business rules are in the wrong place?
Ask your developer one question: if someone posted directly to our API, skipping the website entirely, what could they do? If the answer takes more than a minute or involves the word "probably", you have found your first project.
