Skip to content
OSBP

Open Service Booking Protocol

A small, open protocol that lets an AI agent book a service appointment only inside a user-approved booking mandate. It works through existing booking platforms and authorizes the booking, not the payment.
Read the specification View examples See the manifesto

The missing layer for appointment commitments

Booking a service is not simply making a purchase. It is a provider-bound timeslot: one named person's time, from one organization, at one place, in person or online, for one duration, under one cancellation policy, that cannot be double-sold. OSBP models that object directly and gives agents and booking platforms a narrow shared contract for committing to it.

OSBP authorizes the booking, not the payment. An AI agent can search, compare, and prepare freely. It can only create a booking inside a BookingMandate the user has already approved. Payment authority remains a separate layer.

Where OSBP fits

The protocol gap is deliberately small. OSBP is a domain protocol for service booking that rides on the Model Context Protocol (MCP) for transport: MCP carries the bytes, and OSBP defines what booking-related tool calls mean and the guardrails that wrap them. The booking platform stays the system of record. OSBP validates authority, translates tool calls, and records an audit trail.

An agent reaches a booking platform through MCP transport and the OSBP booking-authority layer, while payment authority remains a separate sibling layer. agent MCP transport OSBP booking authority booking platform payment authority An agent reaches a booking platform through MCP transport and the OSBP booking-authority layer. Payment authority remains outside OSBP. agent MCP transport OSBP booking authority booking platform payment authority outside OSBP
Composable layers: transport below the agent, booking authority in OSBP, payment authority outside OSBP.

The trust boundary is nested

A BookingMandate is the cell the user approves: service, provider, place, time window, price ceiling, and policy visibility. The agent can search, compare, and prepare outside it. Only a booking that fits inside it can reach booking.create.

The agent's possible requests sit outside the user-approved BookingMandate. The provider-bound appointment is the innermost cell, and only it may become a booking.create call. agent preparation and possible requests BookingMandate service, window, ceiling, policy booking.create The agent's possible requests sit outside the user-approved BookingMandate. Only a booking.create call inside the mandate may create the appointment. agent preparation possible requests BookingMandate service, window ceiling, policy booking.create
Nested mandates: the user-approved cell bounds the only mutation v0.1.0 allows.

The eight tools

v0.1.0 keeps the surface intentionally small. Every mutation requires a BookingMandate and an idempotency_key, and the server fails closed or returns a structured handoff when something cannot be handled safely.

Read and prepare

service.describe, availability.find, and policy.explain let an agent explain a service, find candidate slots, and read payment and cancellation policy before any mutation.

Verify and book

verification.send and verification.verify handle agent-mediated customer verification. booking.create creates the appointment after user approval and mandate validation.

Read status and hand off

booking.status reads the current appointment state. handoff.request returns a structured result for the agent to relay when the adapter cannot safely complete the request.

What v0.1.0 proves

v0.1.0 is a usable proof and a formative contract, not a stability promise. It proves the smallest useful loop:

The user approves a BookingMandate, the agent reads service information, policy, and availability, booking.create creates the appointment, and status plus receipt close the loop. Booking Mandate lookup and policy readback booking.create status receipt The user approves a BookingMandate, the agent reads service information, policy, and availability, booking.create creates the appointment, and status plus receipt close the loop. Booking Mandate lookup and policy readback booking.create status receipt
The loop is intentionally narrower than a full appointment lifecycle.

Slot holds, modification, cancellation, reconfirmation, payment collection, and production mandate signing are out of scope for this first proof. They are roadmap, named so the booking safety boundary stays small enough to inspect.

Design principles

Mandated action

The agent can search and prepare freely. It can only create a booking inside a mandate the user approved. Authorization is enforced server-side on every mutation, never left to the agent to self-limit.

Platform of record

The booking platform remains authoritative for availability, policy, verification, and receipts. OSBP never holds booking truth of its own.

Canonical values

OSBP carries machine-readable money, time, contact, and country values, then lets the agent or host localize the presentation for the user. It fails closed when it would have to invent booking truth.

Small surface

The protocol stays narrow enough for a booking platform or adapter to implement without a new backend: eight public tools, backed by a seven-method adapter interface.

Start with the spec

The v0.1.0 specification is the complete contract: the participants, the mandate, the eight tools and their wire shapes, the result envelope and error codes, the enforcement rules, and the audit trail. The reference implementation is a TypeScript monorepo with the protocol core, the local stdio MCP server package, a credential-free synthetic reference backend, a conformance kit, an adapter starter, and the Openings adapter/integration kit for Openings' booking platform. Questions and discussion live in the issue tracker.