For agents
Book me without a browser.
Every public booking page has a machine-readable twin at a stable URL. An agent can fetch it, read real availability, and complete a booking — with no key, no account, and no scraping.
This adds no capability, and that is the point
A booking link has always been a strange, under-appreciated object: it grants an unauthenticated stranger exactly one right— write a single event into someone's calendar — with no account, no key, and no visibility into anything else. That is already the shape of a scoped, single-purpose tool endpoint. It has simply been speaking HTML. Both endpoints below were public long before the descriptor existed; what was missing was any way to find them, or to know what a given event type requires — so a caller that guessed would fail on a missing required question with no way to learn why.
One request, and you know everything.
Run this against any live booking link on this site. Nothing is signed, nothing expires.
curl -s https://meet.neos.network/api/book/<handle>/<slug>{
"kind": "neos-meet/booking-descriptor",
"version": 1,
"event": {
"handle": "...", "slug": "...", "title": "30 Minute Meeting",
"host": "Miko Matsumura",
"durationMinutes": [30], "durationMode": "fixed",
"locationType": "google_meet",
"minNoticeMinutes": 240, "maxDaysAhead": 60,
"questions": []
},
"endpoints": {
"availability": { "method": "GET", "url": ".../api/availability/by-handle", ... },
"book": { "method": "POST", "url": ".../api/bookings", ... }
},
"humanUrl": "https://meet.neos.network/book/<handle>/<slug>"
}The booking page advertises this from its own <head> as <link rel="alternate" type="application/json">, which is how an agent that already has the HTML discovers it without being told. That is deliberate, and it is why we did not content-negotiate on Accept: Accept: */* is what every crawler and most fetch tools send, and that must keep returning the human page forever. Negotiation would have served almost nobody and broken link previews for everyone.
Two things it will never tell you.
The descriptor is built from a handle lookup that never loads the host's address, so there is nothing available to leak. A descriptor is more invitee-facing than the page, not less — it is built to be read by software that will keep a copy.
The durations it advertises come from the same function the booking endpoint validates against, so the set an agent is told about cannot drift from the set that will be accepted. Publishing a length the booking path rejects would be the shown-but-not-bookable failure, exported to a new audience.
What this is not.
There is no MCP server.Calendly and Cal.com both ship one and we do not. Theirs are host-side and authenticated — they automate the account holder's own scheduling, which is a real thing to want and a real gap on our side.
There is no host-side API.Nothing here lets you list your own bookings, create or edit event types, or receive a webhook when something changes. Everything on this page is the invitee's side of the transaction. A documented API and webhooks so you can build on top of Neos Meet. We want it; we haven't committed a shape or a version yet, so we're calling it exploring rather than promising it.
And these are rate-limited on purpose. The descriptor publishes each endpoint's budget rather than making you find it by being refused. Booking is the tighter of the two, because it writes a row, sends mail and calls a calendar API — a public endpoint a stranger can loop is exactly the category that needs a ceiling, not just a polite retry.
Questions a builder actually has.
No, and there is nowhere to get one. A booking link already grants an unauthenticated stranger exactly one right — write a single event into someone's calendar, with no visibility into anything else — and these endpoints are that same right, in JSON. Adding a key would restrict what is deliberately open.
Treat it as a stable read of the public booking surface, not a product API. The descriptor carries a version, and that version only moves when a field is removed or changes meaning — additive fields do not move it, so a consumer that ignores unknown keys keeps working. What does not exist is a host-side API: nothing here lets you list your own bookings, create event types, or receive webhooks. That is on the roadmap as exploring, which in our vocabulary means wanted with no committed shape and no date.
No. Calendly and Cal.com both ship one and we do not. Theirs are host-side and authenticated — they automate the account holder's own scheduling. What is unclaimed, and what these endpoints cover, is the other side: an agent acting for the person doing the booking, who has no account with us and never will.
It has a published budget rather than a surprise. The descriptor states the ceiling for each endpoint — availability is the more generous one because it is two indexed reads, booking is tighter because it writes a row, sends mail and touches a calendar API. A ceiling you can read is one you can respect; a ceiling you discover by being 429'd is an outage you have to guess your way out of.
No to both, and neither is a policy we are asking you to trust. The descriptor is built from a handle lookup that never loads the host's address, so there is nothing to leak. Availability returns start and end instants for slots that are free — never an event, never a title, never who else is on the calendar. On Google that narrowness is enforced by the scope we hold rather than by our restraint.
It gets a 409 and should re-read availability. The slot is defended by a database constraint rather than by a check-then-write, so two agents racing for the last slot on a Tuesday cannot both win it.
A booking may carry up to 10 extra attendees. Part of the writing index. See also what we can and cannot read, embedding, and the covenant.