Community-proposed · no official UCP services spec yet

UCP for Services

Appointments, classes, reservations and rentals sell time, not stock. UCP has no services namespace yet — but a Governing Council working group is being explored, and scheduling capabilities are already turning up in real UCP manifests.

StatusCommunity

Namespacenone in UCP — the USP draft uses dev.usp-protocol.services.*

SpecNot scoped — Services working group in exploratory talks (Governing Council, 10 Jul 2026); issue #303 open; USP draft v2026-08-20 registers in /.well-known/ucp

UCP was built for things that ship. A large part of commerce sells time instead: a haircut at 3pm, a spot in Tuesday's yoga class, a table for four, a boiler service at the customer's home. The inventory is a slot that exists once and then expires, so two agents can race for the same one, and the lifecycle runs booked, rescheduled, attended or no-show rather than purchased, shipped, delivered. Requests for it have run through most of 2026. Discussions #93 and #163 set out use cases beyond retail and the case for holding a slot before checkout; issue #303 (25 March) asks the Technical Council to scope a Services vertical; issue #317 (28 March) proposes a three-step search-availability, hold-slot, book-appointment flow, prototyped under its own io.github.ligament-oss.scheduling namespace; and issue #479 (26 May) asks for a booking-availability query for timed tickets and busy restaurants. All three are still open. On governance, the UCP Governing Council discussed a Services Domain Working Group on 10 July 2026. There was interest, but no agent-platform participant, and the council wants any charter to come from both sides of the market — service providers and platforms — so it agreed to exploratory conversations rather than a charter. Its most recent published minutes, from 7 August, approved a working group for feeds; services has not returned to the agenda since, and the roadmap names Food and Lodging as the industries in development. A fuller draft now exists outside the protocol body. The Universal Scheduling Protocol (USP), maintained in Wix's GitHub organisation and published under Apache-2.0, defines a service catalog, availability with slot holds, and a full booking lifecycle. Its UCP-Native Mode lets a business register those capabilities in its existing /.well-known/ucp and take paid bookings through UCP checkout. It sits under its own dev.usp-protocol.* namespace rather than dev.ucp.*, which is what UCP's namespace rules ask of anyone building ahead of a council. And it already appears in the wild: our census sees one service business declaring the USP catalog, availability, bookings and paid-bookings capabilities in its UCP manifest, alongside Appointedd's UCP demo endpoint declaring booking, intent and schedule capabilities under com.appointedd.*.

What it looks like

A homeowner tells an assistant: "get someone out to service the boiler next Tuesday morning, under $150." The agent finds a provider, checks real availability, holds a slot so no other agent can take it, confirms the booking at the customer's address and takes a deposit — with the business still the merchant of record.

There is no UCP services spec to validate against yet. What we can measure is what service businesses actually declare: the capability names, who defines them, and whether their schema URLs sit on the namespace owner's domain. That is on the capability and vendor pages linked below.

Who is building it

Wix — Universal Scheduling Protocol (draft) Appointedd — com.appointedd.* ligament-oss — #317 prototype Community — issues #303 and #479

What services need that shopping doesn't

Time is the inventory

A slot exists once and expires. Shopping inventory can be read freely and locked at checkout; a booking needs a hold with a time limit before the buyer commits, or two agents book the same 3pm. Issue #317 and USP both put the hold first.

Availability before the cart

An agent has to resolve party size and dates against real capacity before it starts a checkout. Issue #479 proposes a day view and a slot view; USP makes availability a capability of its own.

A booking lifecycle, not an order lifecycle

Reschedule, cancel, waitlist and no-show have no equivalent in dev.ucp.shopping.*. USP requires a reschedule to take the new slot before releasing the old one, so the customer is never left with no booking at all.

Five kinds of service

USP's core verticals are appointments (one client, one provider), group sessions, reservations of a shared resource, rentals, and field service at the customer's location. Events, courses, healthcare and tours are listed as candidates.

Pay now, pay a deposit, or pay on the day

A deposit with the balance due later is already expressible through dev.ucp.common.payment.terms, shipped in v2026-08-25. Paying in cash at the appointment is not; the USP draft adds its own extension for that.

What to do now

Name it under a domain you control Until UCP publishes a services namespace, scheduling capabilities belong under your own domain or an existing draft such as dev.usp-protocol.*. A name invented inside the reserved dev.ucp.* space is flagged as unsanctioned.
Validate your manifest →
Declare version, spec and schema List each capability in your /.well-known/ucp with all three fields. UCP requires the schema URL to sit on the namespace owner's domain; the USP draft requires the same of the spec URL.
Run a free check →
See what is already declared Every capability a store declares gets a public page listing the stores behind it, so you can see what service businesses ship before you pick a shape.
USP in the vendor map →

FAQ

Is Services an official UCP vertical?

No. The v2026-08-25 release ships capabilities under dev.ucp.shopping.* and dev.ucp.common.* only, and the UCP roadmap names Food and Lodging as the industries in development. The Governing Council discussed a Services Domain Working Group on 10 July 2026 and agreed to exploratory conversations: there was interest from service providers but no agent platform, and a charter needs both. Issue #303, which asks the Technical Council to scope a Services vertical, is still open.

What is the Universal Scheduling Protocol (USP)?

A draft open standard, version 2026-08-20, maintained in Wix's GitHub organisation and published under Apache-2.0, for discovering, checking the availability of and booking time-based services. It defines service catalog, availability and bookings capabilities, with optional waitlist and discovery-registry modules, over REST, MCP, A2A and an embedded binding. It is not part of UCP and is not governed by a UCP council.

Can a business declare booking capabilities in its UCP manifest today?

Yes, under a namespace it does not borrow from UCP. USP's UCP-Native Mode registers dev.usp-protocol.services.catalog, availability and bookings in /.well-known/ucp next to the shopping capabilities, and routes paid bookings through UCP checkout. Our checker reads those entries as correctly namespaced third-party capabilities; it flags a capability as unsanctioned only when it claims space inside the reserved dev.ucp.* namespace.

Why can't the shopping capabilities handle bookings?

Because a slot is not a SKU. Shopping inventory can be checked freely and reserved at checkout, but a time slot is contended: if two agents see 3pm as free, only one can have it, so a booking flow needs a hold with a time limit before payment. Bookings also carry a lifecycle shopping has no words for — reschedule, waitlist, attended, no-show.

How does Services relate to the Lodging and Food councils?

The edges are not settled. A hotel room is a time-bound reservation, and a restaurant table is one of USP's own reservation examples. Lodging has a seated council and its first capability in review (PR #780); the Food charter covers ordering rather than table booking. Where a general services namespace would stop and those verticals start has not been decided in public.

What should service businesses and booking platforms do now?

Get the shopping-side basics right — a valid manifest, checkout, and payment terms if you take deposits. Keep scheduling capabilities under a namespace you or a published draft control. And if you want a UCP services vertical, the Governing Council has said what it needs: a proposal backed by service providers and agent platforms together.

Sources

Other UCP verticals

UCP is going horizontal — track it across every vertical it's expanding into.

UCP for Retail

Live

The first and largest UCP vertical — agents search catalogs, build carts, and check out across thousands of verified stores.

17,412 verified merchants

UCP for Lodging

Technical Council formed · first capability in review

UCP has a seated Lodging Technical Council and a named phased roadmap — but no lodging namespace and no published schema. Here's what it still has to handle.

UCP for Travel

Announced

Flights, rail and travel distribution are agentic commerce's hardest vertical — perishable inventory and dynamically generated offers, not fixed SKUs.

UCP for Food Ordering

Technical Council formed · spec in progress

UCP has a seated Food Technical Council and a phased roadmap that starts at checkout, not the menu — but no food namespace and no published schema. Here's what it still has to handle.

UCP for B2B

Community-debated · no official UCP B2B spec yet

B2B isn't an officially-named UCP vertical, but it's the most-debated one. Where UCP actually fits B2B today — and the primitives the spec would have to add for the rest.

Explore Protocol Data

Capabilities which commerce features stores support Vendors capabilities & extensions by namespace authority Tools what MCP operations agents can invoke Transports how stores expose their APIs Payment Handlers which payment methods are accepted Spec Versions which protocol versions are in use

Is your store agent-ready?

Whichever vertical you're in, the prerequisite is the same: a valid, machine-readable UCP endpoint an agent can actually transact against.

Run a free check Get notified when Services & Bookings goes live

Weekly UCP Report

Get the agentic commerce digest every Monday

Real adoption data, ecosystem trends, new spec versions, and the stores that broke or recovered this week. Read by founders and engineers building the next generation of commerce.

Free forever No spam Unsubscribe anytime

View a sample report →