Upsalt Booking

Create Booking

create-booking

Create a booking for a company as a guest. Requires a date (YYYY/MM/DD), an hour and shift_id obtained from list-available-slots, and the guest contact details. On success, returns the reservation details including a token that can be used with get-booking-info and cancel-booking.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No	Guest city.
`date`	Yes	Booking date in YYYY/MM/DD format (e.g. 2026/07/20). Note the slashes.
`hour`	Yes	Booking hour in HH:MM format, taken from list-available-slots.
`name`	Yes	Guest first name.
`pets`	No	Number of pets.
`email`	Yes	Guest email address. The booking confirmation and management token are sent here.
`optin`	No	Marketing opt-in flag (1 or 0).
`phone`	Yes	Guest phone number.
`vegan`	No	Whether the party includes vegan guests.
`adults`	Yes	Number of adults.
`babies`	No	Number of babies.
`country`	No	Guest country.
`message`	No	Optional message for the business.
`surname`	Yes	Guest last name.
`children`	No	Number of children.
`latitude`	No	Guest latitude, if known.
`shift_id`	Yes	The shift id, taken from list-available-slots.
`highchair`	No	Number of highchairs.
`longitude`	No	Guest longitude, if known.
`pushchair`	No	Number of pushchairs.
`company_id`	Yes	The company id, as returned by the find-company tool.
`vegetarian`	No	Whether the party includes vegetarian guests.
`wheelchair`	No	Number of wheelchairs.
`gluten_free`	No	Whether the party needs gluten-free options.
`guest_token`	No	Existing guest token, if the guest has booked before.
`nuts_allergy`	No	Whether the party has a nut allergy.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only include destructiveHint=false, so the description carries the transparency burden. It discloses the return behavior (reservation details with a token) and its downstream use. It doesn't mention failure modes or email side effects, but the core behavior is clearer than typical for a create operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first states the purpose, the second covers requirements and return behavior. No filler, front-loaded, and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 26-parameter tool with no output schema, the description provides a concise overview of the workflow, prerequisites, and return token. It doesn't mention side effects like confirmation email, but that's covered in the schema. The description is sufficient for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description mostly repeats key schema facts (date format, shift_id source) without adding new meaning. It groups contact details but doesn't explain optional parameters. Baseline 3 is appropriate since the schema already documents all parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Create') and resource ('a booking'), with clear context ('for a company as a guest'). It distinguishes from sibling tools like cancel-booking and get-booking-info by explicitly focusing on creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states prerequisites: requires a date (YYYY/MM/DD), an hour, shift_id from list-available-slots, and guest contact details. It also explains how the returned token is used with get-booking-info and cancel-booking, providing workflow context. It doesn't explicitly state when not to use, but the sibling differentiation is implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Upsalt Booking tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clear, distinct role: find-company for lookup, list-available-slots for availability, create-booking for reservations, get-booking-info for retrieval, and cancel-booking for cancellation. No overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb-noun pattern with lowercase hyphenated style (cancel-booking, create-booking, find-company, get-booking-info, list-available-slots). Perfectly predictable.

Tool Count5/5

Five tools are well-scoped for a booking system, covering the essential guest-facing operations without unnecessary additions. The count feels appropriate and focused.

Completeness4/5

The core booking lifecycle (create, read, cancel) is covered, along with prerequisites like company lookup and slot listing. An update/modify booking operation is missing, which is a minor gap but not critical for the primary use case.

Resources

Need Help?