At a Glance
I asked Codex to book my remaining November weekdays at a WeWork in Kuala Lumpur. It confirmed eleven desks, skipped bookable weekends and reported what it could not finish. Browser navigation worked, but a tool defined by the website could give an agent clearer booking instructions.
I had the WeWork calendar open when I asked Codex to book a desk at Equatorial Plaza in Kuala Lumpur for every weekday in November 2026. I had already booked through 5 November. The rest meant choosing a date, opening a dialog and confirming a reservation again and again.
My instruction was simple: “Book for me a desk at the currently selected location for every weekday in November. Until the 5th November is already done.”
Eleven bookings, even with an unavailable day
Codex checked the location and worked through the calendar. It opened each booking dialog, waited for the page when it needed to, and confirmed eleven additional desks.
I could leave it to work and come back to the result. For this kind of repetitive task, that matters more than how quickly it clicks. It’s much better to automate things than to do the same thing over and over. In my experience, Codex handles website navigation better than Claude, though this wasn’t a controlled comparison.
The bookings took time, but they did not need my attention.
One weekday was unavailable, and later dates were disabled in the calendar. Codex carried on with the dates it could book and reported the rest. It also skipped the weekends, even though the calendar would have let it book them.
I asked why the unavailable day had failed. Because we were still in the same chat, Codex knew which booking I meant and suggested a public holiday as a possible reason.
I did not have to repeat the location or the date. The booking and my follow-up question shared the same context.
The website could do more of the work
With a browser extension, Codex works from the page it can see and the markup behind it. That works in many cases, especially when buttons, fields and labels have clear meanings. But the agent still has to infer the booking steps from an interface built for people, then check each result.
WebMCP is a proposed web standard that lets website owners declare actions as structured tools for agents. They can annotate an HTML form or register a tool with JavaScript. Instead of relying on labels and layout alone, an agent could receive a defined booking action with clear inputs.
I built six WebMCP tools for this site, mostly to answer questions about my travels. Then I called 3’842 tools on other sites to find out how well they work. Neither experiment booked a desk, but both made me think harder about what a website should tell an agent before it acts.
A booking tool could return the confirmed dates and the exceptions directly.
A tool that accepts several dates could take a location and a list of weekdays, then return the reservations it made. The website would still enforce existing bookings, unavailable days and the booking window. Codex would still need to understand my request, but it would no longer need to work out each click.
That might be faster and use fewer tokens. I did not measure either here, and WebMCP alone would not turn individual bookings into one operation. The site would have to build that tool.
For now, eleven fewer calendar bookings are enough for me. But the more often I hand over a task like this, the more I want the website to offer an action the agent can call instead of a page it has to navigate.
Conclusion
I got eleven reservations and a possible explanation for the date that failed without starting another conversation. A booking tool defined by the website could make that workflow less dependent on how its calendar happens to be built.