Why we built OpenSlot
A business can have a perfectly good website and still be difficult for an AI agent to use. A customer might ask for an appointment, but the agent still has to work through forms, guess how a booking page works, or tell the customer to call the office.
WebMCP gives websites a way to offer clear, structured actions to agents. But the next question is adoption: how does a small business put that into practice without building and maintaining its own agent integration?
OpenSlot is our answer to that question: a shared service and a drop-in script, built around the website the business already has.
What OpenSlot does
The business registers with OpenSlot, enters its services, chooses its preferred appointment setup, and receives a script to add to its website. In a compatible browser, that script exposes WebMCP tools the customer's agent can discover and use. The site can continue looking and working like a normal business website.
Our demo makes this concrete with Bright Smile Dental, a fictional business. The agent can list services, search sample appointment times, hold a selected slot, and complete a dummy confirmation. It can also request a simulated phone callback, check the request's status, and confirm one of the returned dummy options.
Dentistry is the example, not the product boundary. We want the same onboarding pattern to work for salons, repair shops, fitness studios, and other businesses where customers need to arrange a service.
Start simple, add more when needed
The intended setup supports different starting points. A business without online scheduling could use an OpenSlot-hosted calendar and define its availability. A business with an existing calendar or booking system could connect a supported integration and keep using that system. Businesses could also opt into a phone workflow for requests that still need a conversation.
The script is the small part the business installs; the shared service would handle those connections behind it. Businesses would not need to build a separate MCP server or redesign their website to get started.
Those integration paths are a roadmap, not a claim that the demo can access private calendars or place calls. Today, registration saves the choices, while scheduling and phone results use sample data.
Why WebMCP matters here
WebMCP lets the business expose the actions it understands instead of making an agent reverse-engineer its interface. The person can ask for help, compare the returned options, choose a time, and ask the agent to carry out the next step using explicit functions and returned IDs.
This gives the human and agent different roles: the person makes the decision; the agent handles the repetitive steps. Our intended interaction asks for approval before confirmation, although the prototype does not yet enforce approval on the server.
The opportunity is bigger than one booking flow. If businesses can adopt WebMCP through a familiar setup-and-script process, more of the everyday web can become useful to people working with agents.
How we built it
OpenSlot uses a JavaScript SDK that registers seven tools through document.modelContext.registerTool. Each tool defines its inputs and calls the shared backend when executed. A Cloudflare Worker serves the SDK, registration page, sample business website, and API. Cloudflare D1 stores business profiles and simulated callback state.
The business ID connects the snippet to the registered profile. Ordinary appointment slots, holds, and confirmations use in-memory demo state. The source code, setup instructions, and MIT license are public.
What is real, and what is simulated
Business registration, generated IDs, WebMCP registration, backend requests, and stored callback state are implemented. The hosted example exercises the SDK and API on the same domain.
All availability and booking results are simulated. No external calendar is connected, no real call is placed, and no real appointment is booked. The deployed SDK's full dummy workflow was tested from a separate website origin. The demo uses a permissive cross-origin policy; phone opt-in is a saved preference rather than an enforced permission, and production authentication and durable booking guarantees are not implemented.
Challenges and lessons
The hardest part was making the reusable setup flow match the promise of one script per business. We fixed business-scoped service filtering, consistent callback request IDs, expired-hold release, and validation of submitted details. Testing a second business and the SDK from a separate website helped catch gaps that a single polished demo could hide.
The main lesson was that exposing a function is only the beginning. A real integration also needs reliable state, explicit permissions, and honest handling of missing availability. We kept external scheduling and telephony simulated rather than presenting those unfinished connections as working features.
What's next
Our next step is to make the tools business-neutral and connect one real scheduling path. Then we can add other supported systems and optional telephony, with verified business ownership, origin restrictions, approval checks, durable booking state, and reliable retries in place before handling real customers.
The aim stays simple: make adding WebMCP practical for the businesses people already use.
Log in or sign up for Devpost to join the conversation.