Scopes

Every tool declares the scope it needs. A credential (an API key, or an approved OAuth grant) is only allowed the scopes you granted it — a call outside them is rejected before the tool runs.

Read and write are always separate scopes, so you can grant a key read-only access to a domain.

Scope	Grants
bookings.read	Read reservations, availability, and the booking projection
bookings.write	Create / update / cancel reservations, seat and notify guests
floor-plan.read	Read the dining room — plans, areas, tables, combinations
floor-plan.write	Add / edit / remove tables, areas, and combinations
guests.read	Read the guest book and guest history
guests.write	Edit guest records
waitlist.read	Read the waitlist / queue
waitlist.write	Add, quote, promote, and remove waitlist entries
schedule.read	Read service hours, shifts, and special days
schedule.write	Add / remove shifts and set special days
menu.read	Read the menu — categories, items, availability
menu.write	Set availability / price / image, add items
knowledge.read	Read the knowledge base (FAQs)
knowledge.write	Add / activate / delete FAQ entries
settings.read	Read feature settings
settings.write	Toggle features and configuration
brand.write	Edit the brand profile and images
comms.read	Read guest message threads
comms.send	Send an SMS to a guest (costs money)
reports.read	Read reporting / analytics

No scope required

A few tools are open to any authenticated caller because they carry no tenant data of their own:

• list_brands — the discovery entry point. Always call this first.
• list_capabilities — the static catalogue of what can be configured and run.

How scoping composes with brands

Scopes say what a credential may do; brand access says which restaurants it may do it to. Both are enforced:

• an API key is limited to the brand list and scopes chosen at issuance;
• an OAuth grant carries the scopes the user approved, for the brands they belong to.

A tool call must clear both gates.