We Made Our Website Agent-Operable. Here's What That Actually Took.

This week OpenAI announced that ChatGPT's browser and ChatGPT Sites consume WebMCP — a standard where a website publishes a structured list of actions an agent can call, instead of the agent squinting at your UI and guessing which button books the meeting. Chrome, Cloudflare, Shopify, and Vercel are behind it.

We build agent APIs and MCP servers for clients. So instead of writing a think-piece, we spent a day making our own site agent-operable and kept notes. If you run a business website, this is what the work actually looks like.

What an agent can now do here

An AI agent acting for a person — in their browser or from a remote service — can call seven tools on aslaninteractive.com:

• get_services and get_case_studies — what we do and whom we've done it for, as structured data rather than marketing paragraphs.
• check_fit — a deterministic assessment, with reasons, of whether a project suits us. No model call, no black box. An agent can read the reasoning and decide whether a call is worth its user's time.
• check_availability and book_call — open 20-minute slots with a founder, and the booking itself.
• request_quote — a project brief that starts our quote-everything process. A founder replies with a written quote; nothing is billed until the client approves it.
• get_client_portal_access — for existing clients, how their agent connects to our client portal's own MCP server.

The same seven tools are exposed three ways: an MCP server for remote agents, WebMCP registration on every page for agents co-browsing with their user, and a plain REST API for everything else. One tool layer, three transports. There's a page for agents that explains all of it.

Lesson 1: your bot protection is now your biggest bug

Every business website has spent a decade learning to hate automation. Ours had the standard kit documented: CAPTCHAs, honeypot fields, "you submitted that form too fast" timing checks, and a user-agent blocklist that rejects anything matching bot, curl, or python.

Every one of those treats a legitimate agent — one acting with a real person's authority — as an attacker. An agent fills a form in two hundred milliseconds with a non-browser user-agent, and the site drops it silently.

So the first thing we built wasn't a tool. It was an agent lane: a set of endpoints that deliberately never apply user-agent blocking, CAPTCHAs, or timing analysis. What they do instead is stricter in the ways that matter: per-IP rate limits (generous for reads, tight for writes), schema validation on every input, and identity capture — we log the Signature-Agent header that Web Bot Auth platforms send, so every submission is attributable. Verifying those signatures cryptographically is the natural next step.

The design principle: agents aren't bots. Bots are automation acting for nobody. Agents are automation acting for someone. Your defenses have to tell the difference, and today most can't.

Lesson 2: exposing a tool isn't a customer journey

The sharpest observation in the coverage of OpenAI's announcement was that publishing tools doesn't automatically produce a useful experience. A tool has to land the person somewhere coherent.

For us the coherent landing was already built: we quote everything. Every piece of work gets a written quote the client approves before we begin. So request_quote isn't a contact form with a JSON face — it's the front door to a process that already exists. The brief goes to the same Slack channel and CRM as a human-submitted lead, tagged as agent-submitted, and can optionally create a Submitted request in our client portal so the quote lands where the client will eventually approve it. The agent's user gets a reference number and a plain-language explanation of what happens next.

If your site has no equivalent — if "contact us" goes into a void — WebMCP won't fix that. Fix the journey first.

Lesson 3: consequential actions need a human, and the transport decides how

Booking a meeting and sending a brief with someone's contact details are consequential. We never let an agent do either silently.

How the confirmation happens depends on where the agent is. In the browser, the human is right there, so WebMCP tools pop a native confirmation dialog showing exactly what's about to happen — the agent proposes, the person disposes. Remotely, there's no dialog to pop, so the schema itself requires a userConfirmed: true flag, and the tool description instructs the agent to show the user the exact details and obtain their yes before setting it. That's a contract with the agent, not a technical guarantee — but it's enforced at the schema layer, described in the OpenAPI document, and logged.

Lesson 4: it's small, if you already have the backends

Total new surface: a shared content module, a fit heuristic, seven REST routes, one MCP route, one client component that registers WebMCP tools, llms.txt, a .well-known discovery document, structured data, and a documentation page. The Calendly, HubSpot, and Slack integrations already existed for our chatbot; the agent lane just calls them. The OpenAPI document is generated from the same validation schemas the endpoints use, so it can't drift.

One honest caveat: WebMCP is early. It's a W3C community-group proposal with initial browser support, and the API shape will move. We feature-detect and fail silently where navigator.modelContext doesn't exist. Expect to revisit it.

Lesson 5: for existing clients, the portal is the product

The marketing site is for prospects. Our clients live in the client portal, which has had its own MCP server, OAuth flow, and scoped tokens for months — their agents already read project status, file requests, and comment on their behalf. What they can't do is approve or decline a quote, set an estimate, or change status. We built the service layer without those functions on purpose.

So the marketing site's job for clients is simply to hand off: get_client_portal_access tells an agent where the portal's MCP server is and how to authenticate. Discovery, not duplication.

If you want this for your business

The pattern generalizes: find the two or three actions a customer's agent would actually want to take, build them on the backends you already have, put them behind an agent lane instead of your bot wall, and make consequential actions ask the human. It's a few days of work for a shop that's done it before — and it's exactly the kind of AI feature we build. Our agent can tell yours how to reach us.