• 

• 

• 

About the project

Booksy Reloaded is our answer to a simple question: if a customer already knows who they like, what they normally book, how they pay, and how much they are comfortable spending, why should booking the next appointment still take so many steps?

We built an original two-sided marketplace where a customer can ask an AI to find or rebook an appointment through WebMCP. The customer can set practical limits once, such as using the usual provider and service, paying in person, and staying at or below $50. If the appointment fits those rules, the AI can complete the repetitive work. If the provider is unavailable, the service changes, the requested time changes, or the price goes above the limit, the system comes back and asks the customer what to do.

The project also shows the provider side. Once an appointment is created, the exact same appointment appears in the provider's calendar and activity feed. That makes this more than an AI filling out a booking form. It demonstrates how a customer, an agent, and a provider can share one visible workflow.

Inspiration

I am an avid Booksy user, especially when I want to get a haircut. That made it a good starting point for thinking about WebMCP because it is a real consumer habit I already understand. Even when I know the barber I want, I still have to open the app, find the provider, check availability, and repeat a decision I have made before.

I wanted to see what this experience could look like if I could simply ask AI to handle it. The goal was not just to make booking faster. It was to let the website give the AI structured, reliable information while the customer stays in control of the rules that actually matter.

What we built

Booksy Reloaded is an original bilingual marketplace for six fictional beauty and wellness professionals in Tampa, Florida. Three customer profiles see the same provider pool ranked differently. Returning customers can ask for their usual service in natural language without starting over. An AI agent can use fifteen WebMCP tools to inspect authenticated relationship history, find rebooking options, weigh goals, specialties, proximity, budget, review themes, language, accessibility, promotions, and availability, explain every score and tradeoff, and prepare an appointment.

The customer sets a practical policy: use the usual provider and service, pay in person, and stay at or below $50. Exact matches can be booked when the customer asks. A different provider, service, requested window, or higher price returns a structured exception and requires a new customer choice. The final tool creates one idempotent sandbox appointment. Switching to the provider account shows that same appointment on the professional's calendar and activity feed.

Why WebMCP

The website owns provider facts, services, prices, availability, and booking policy. The person owns intent, preset limits, and exception choices. The agent handles the tedious comparison across those constraints. WebMCP lets all three responsibilities meet in one shared visible state without making the agent rediscover cards, buttons, and calendars through visual browser automation.

This is not a generic booking form. It is a two-sided marketplace demonstration. The agent's completed action becomes visible to both the customer and the fictional provider, while any material change invalidates stale availability, review, approval, and booking state.

How we built it

Booksy Reloaded registers fifteen top-level imperative tools through document.modelContext.registerTool(...). Human controls and agent tools call the same deterministic marketplace engine. The recommendation score is inspectable and has no paid placement. A new med spa can compete through price, specialty fit, and availability while its shorter review history remains visible. Returning-customer history is explicit site data, not invisible model memory. Closed JSON schemas limit every input. Read-only actions are annotated, customer history is unavailable before the site-owned demo session is established, and the final booking tool requires confirmed: true plus either an exact policy match or explicit exception approval.

The English and Spanish interface uses the same provider and appointment state. All marketplace records and generated portraits are original fictional demo assets. A small browser-local database keeps the public project credentialless and lets a booking created in the customer account appear in the provider calendar without exposing a public production backend.

Challenges

The first challenge was getting the entire project up to spec while still making it visually appealing and easy to understand. It needed to feel like a real consumer marketplace, not a technical screen built only to show tool calls. We also needed to show what happens after the booking, so we built the customer account, the provider workspace, the provider calendar, and the activity feed around the same appointment state.

The biggest design challenge was security. While building this second project, the AI kept returning to security and confirmation. That was useful, but asking the customer to approve every familiar appointment would defeat much of the reason for using an agent. We wanted something secure but also smart.

Our answer was parameter locking. The customer can approve a reusable policy for an exact match and change the price ceiling from the account. The workflow fails closed if a provider, service, time window, or price changes. We considered building a real passkey server for exception approval, but this public demo is hosted as a static site. A real passkey requires server-generated challenges and server-side signature verification, so we decided not to fake that security step. Instead, the demo clearly shows the secure boundary we could connect to a production authentication service later.

What we learned

We learned that security does not have to mean asking the same question every single time. A customer can define clear limits in advance, and the agent can act inside those limits while still pausing for the decisions that are actually different. That is a much more useful version of customer control.

We also learned that WebMCP is strongest when tools describe the customer's goal instead of browser mechanics. search_providers, compare_providers, find_rebooking_options, and request_booking are more reliable and understandable than asking an agent to repeatedly scan cards and click through calendars.

Finally, we learned that the provider side matters. The agent should not stop after making a recommendation in chat. The completed action should become visible to both sides of the marketplace. Seeing the same confirmed appointment in the customer account and provider calendar made the project feel much closer to a real-world workflow.

Results

The current policy-aware benchmark uses ten engine calls through final booking status. Across 25 reproducible runs, all 25 completed successfully. The latest artifact measured approximately 84 input plus 1,968 output JSON I/O tokens, for an estimated serialized payload footprint of 2,052 tokens. These are transparent JSON-size estimates, not provider-billed model tokens, and the benchmark excludes rendering, networking, native WebMCP transport, and model inference.

Booksy Reloaded is a sandbox. It contacts no real provider, collects no payment, sends no notification, and consumes no production inventory.

What was built during the challenge

The Booksy Reloaded application, original interface, fictional marketplace data, generated provider portraits, bilingual experience, personalized and returning-customer flows, customer and provider views, browser-local persistence, fifteen WebMCP tools, tests, native browser verifier, benchmark, and submission materials were created during the challenge.

Built With

• chrome
• css
• github
• github-actions
• html
• hyperframes
• javascript
• leaflet.js
• node.js
• openstreetmap
• playwright
• vite
• vitest
• webmcp-imperative-api