resy-mcp

resy_book

Destructive

Book a Resy reservation for a venue, date, and party size by previewing available slots and confirming the exact time, with duplicate and payment checks.

Instructions

Book a reservation. Composite tool: internally runs find-slots → get booking details → book. It books ONLY the exact slot a preview showed. The first call returns a preview (the Resy account, venue, date, party size, the exact slot time that would be booked, its slot_type, the payment card last-4, and the slot's cancellation_policy / payment_terms — any no-show fee or deposit) and books nothing. Pass desired_time (HH:MM, 24-hour) to target a specific slot. If your exact desired_time is not available the tool does NOT auto-book a different time — it returns the available times so you can pick, unless you pass allow_closest_time:true (which previews the nearest slot). Omit desired_time to preview the first available slot. Resy can list several slots at one time with different seating types (Dining Room / Bar / Patio) and different fees; pass slot_type to target one. To book: on a client without a confirmation prompt the preview comes back with a confirmToken bound to that exact slot and its terms — after the user approves, call again with the same arguments plus the preview's time as desired_time and the confirmToken. On a client that can prompt, call again with the preview's time as desired_time, its slot_type and its terms_token, and the user is asked to confirm. If that slot is gone, or its seating type or cancellation/payment terms changed since the preview, nothing is booked and a fresh preview is returned. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Before booking, it checks your existing reservations and refuses if you already hold one at this venue on this date (e.g. an earlier call that timed out but went through); pass allow_duplicate:true to book another anyway. Uses the user's default payment method unless payment_method_id is supplied (it must be one of the saved cards from resy_list_payment_methods; the preview names the card by brand and last-4).

Input Schema

Name	Required	Description
`lat`	No
`lng`	No
`date`	Yes	YYYY-MM-DD
`venue_id`	Yes
`slot_type`	No	Seating type (e.g. 'Dining Room', 'Bar', 'Patio'), matched case-insensitively. Only slots of this type are considered. On a client that can prompt it is required to book — pass the preview's slot_type. With a confirmToken it is optional: the token already binds the seating type.
`party_size`	Yes
`terms_token`	No	The preview's terms_token. It fingerprints the slot's seating type and cancellation/payment terms; if they changed since the preview, the call re-previews instead of booking. Required to book on a client that can prompt; with a confirmToken it is optional, because the token already binds the terms (a change is refused as DRAFT_CHANGED).
`confirmToken`	No	ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.
`desired_time`	No	HH:MM (24h)
`allow_duplicate`	No	When true, book even if you already hold a reservation at this venue on this date. Default false: the booking refuses and lists the existing reservation, so a retry after a timed-out booking cannot book twice.
`payment_method_id`	No
`allow_closest_time`	No	When true, if your exact desired_time is unavailable the preview selects the closest slot instead of returning the available times to pick from. It never books on its own: book with that slot's time as desired_time. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.3.0Oct 3, 2026

changedInput schema / properties / slot_type / description

Previous value: -"Seating type (e.g. 'Dining Room', 'Bar', 'Patio'), matched case-insensitively. Only slots of this type are considered. Required to book — pass the preview's slot_type."New value: +"Seating type (e.g. 'Dining Room', 'Bar', 'Patio'), matched case-insensitively. Only slots of this type are considered. On a client that can prompt it is required to book — pass the preview's slot_type. With a confirmToken it is optional: the token already binds the seating type."

changedInput schema / properties / terms_token / description

Previous value: -"The preview's terms_token, required to book. It fingerprints the slot's seating type and cancellation/payment terms; if they changed since the preview, the call re-previews instead of booking."New value: +"The preview's terms_token. It fingerprints the slot's seating type and cancellation/payment terms; if they changed since the preview, the call re-previews instead of booking. Required to book on a client that can prompt; with a confirmToken it is optional, because the token already binds the terms (a change is refused as DRAFT_CHANGED)."

Changed6 schema fields changedv1.2.1Sep 25, 2026

changedInput schema / properties / allow_closest_time / description

Previous value: -"When true, if your exact desired_time is unavailable the preview selects the closest slot instead of returning the available times to pick from. It never books on its own: confirm with that slot's time as desired_time. Default false."New value: +"When true, if your exact desired_time is unavailable the preview selects the closest slot instead of returning the available times to pick from. It never books on its own: book with that slot's time as desired_time. Default false."

changedInput schema / properties / allow_duplicate / description

Previous value: -"When true, book even if you already hold a reservation at this venue on this date. Default false: a confirm refuses and lists the existing reservation, so a retry after a timed-out booking cannot book twice."New value: +"When true, book even if you already hold a reservation at this venue on this date. Default false: the booking refuses and lists the existing reservation, so a retry after a timed-out booking cannot book twice."

removedInput schema / properties / confirm

Removed value: -{
-  "description": "Must be true to proceed. Without this, the tool returns a preview.",
-  "type": "boolean"
-}

addedInput schema / properties / confirmToken

Added value: +{
+  "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+  "type": "string"
+}

changedInput schema / properties / slot_type / description

Previous value: -"Seating type (e.g. 'Dining Room', 'Bar', 'Patio'), matched case-insensitively. Only slots of this type are considered. Required with confirm:true — pass the preview's slot_type."New value: +"Seating type (e.g. 'Dining Room', 'Bar', 'Patio'), matched case-insensitively. Only slots of this type are considered. Required to book — pass the preview's slot_type."

changedInput schema / properties / terms_token / description

Previous value: -"The preview's terms_token, required with confirm:true. It fingerprints the slot's seating type and cancellation/payment terms; if they changed since the preview, the confirm re-previews instead of booking."New value: +"The preview's terms_token, required to book. It fingerprints the slot's seating type and cancellation/payment terms; if they changed since the preview, the call re-previews instead of booking."

Changed4 schema fields changedv1.1.3Sep 24, 2026

changedInput schema / properties / allow_closest_time / description

Previous value: -"When true, if your exact desired_time is unavailable the closest slot is booked instead of returning the available times to pick from. Default false: an unavailable desired_time never silently books a different time."New value: +"When true, if your exact desired_time is unavailable the preview selects the closest slot instead of returning the available times to pick from. It never books on its own: confirm with that slot's time as desired_time. Default false."

addedInput schema / properties / allow_duplicate

Added value: +{
+  "description": "When true, book even if you already hold a reservation at this venue on this date. Default false: a confirm refuses and lists the existing reservation, so a retry after a timed-out booking cannot book twice.",
+  "type": "boolean"
+}

addedInput schema / properties / slot_type

Added value: +{
+  "description": "Seating type (e.g. 'Dining Room', 'Bar', 'Patio'), matched case-insensitively. Only slots of this type are considered. Required with confirm:true — pass the preview's slot_type.",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / terms_token

Added value: +{
+  "description": "The preview's terms_token, required with confirm:true. It fingerprints the slot's seating type and cancellation/payment terms; if they changed since the preview, the confirm re-previews instead of booking.",
+  "minLength": 1,
+  "type": "string"
+}

Changed1 schema field changedv1.0.0Sep 19, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed2 schema fields changedv0.5.4Jul 12, 2026

addedInput schema / properties / allow_closest_time

Added value: +{
+  "description": "When true, if your exact desired_time is unavailable the closest slot is booked instead of returning the available times to pick from. Default false: an unavailable desired_time never silently books a different time.",
+  "type": "boolean"
+}

addedInput schema / properties / confirm

Added value: +{
+  "description": "Must be true to proceed. Without this, the tool returns a preview.",
+  "type": "boolean"
+}

First observedv0.5.1Jun 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description goes well beyond them: it enumerates exactly what the phase-1 preview returns (account, venue, date, slot time, slot_type, card last-4, cancellation/payment terms), states that a changed slot_type or terms causes a refusal/re-preview (DRAFT_CHANGED), and warns that confirmToken must never be invented or reused.

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

Conciseness4/5

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

Front-loaded with the core action and the preview-first invariant before the mechanics. It is long and somewhat repetitive about the confirmation flow (described once narratively and again via confirmToken), but given 12 parameters and a multi-phase protocol, most sentences carry necessary information.

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

Completeness5/5

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

With no output schema, the description carries the full burden and discharges it: it specifies what the preview response contains, when booking proceeds, when it is refused (slot gone, terms changed, duplicate reservation), and how each confirmation mode resolves. Nothing an agent needs to invoke it correctly is missing.

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

Parameters5/5

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

Schema coverage is only 58%, but the description compensates richly: it defines desired_time as HH:MM 24-hour targeting, explains slot_type's role across seating types and its optionality when a confirmToken is present, and clarifies that payment_method_id must reference a saved card from resy_list_payment_methods, previewed by brand and last-4.

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?

Opens with a specific verb+resource ('Book a reservation') and immediately clarifies it is a composite tool that internally runs find-slots → booking details → book. It distinguishes itself from sibling resy_find_slots by stressing that it 'books ONLY the exact slot a preview showed,' so an agent can tell booking apart from searching.

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

Usage Guidelines5/5

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

Explicitly states when it books vs when it only previews, names the alternative branch (omit desired_time, use allow_closest_time) for unavailable times, and spells out the two distinct confirmation paths (confirmToken fallback vs elicitation client). It also documents the duplicate-refusal rule and how to override it with allow_duplicate:true.

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

Deploy Server

resy_book

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools