resy-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RESY_EMAIL | No | Email for password login. | |
| RESY_API_KEY | No | Override the public Resy API key. | |
| RESY_PASSWORD | No | Password for password login. | |
| RESY_AUTH_TOKEN | No | Pre-obtained x-resy-auth-token. Overrides everything. | |
| RESY_DISABLE_FETCHPROXY | No | Set to 1 to disable fetchproxy fallback. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| resy_get_profileA | Get the authenticated Resy user's profile (name, email, phone, booking count, member-since date). Payment method IDs are not exposed. |
| resy_list_payment_methodsA | List the user's saved payment methods on Resy. Returns id, brand, last four digits, expiry, and is_default. The id can be passed as payment_method_id to resy_book. |
| resy_healthcheckA | Resolves the credential the way real tools do, then makes one authenticated request to api.resy.com. Reports which source supplied the credential, whether api.resy.com accepted it, the round-trip time, and a plain-English hint distinguishing 'no credential' from 'credential rejected' from 'a api.resy.com-side problem'. Read-only; never returns the credential itself. Call this when a real tool fails and you want to know which hop broke. |
| resy_search_venuesA | Search Resy for restaurants with availability. Returns venues including any bookable slot tokens for the requested date + party size. Defaults to NYC geo if lat/lng omitted. |
| resy_find_slotsA | List available reservation slots at a specific venue for a date + party size. Returns slot config_tokens suitable for booking. Tokens expire quickly; book soon after fetching. |
| resy_get_venueB | Get full details for a single Resy venue by id. |
| resy_list_reservationsA | List the user's Resy reservations. Defaults to upcoming; pass scope="past" or "all" to broaden. Each result includes the resy_token needed for cancellation, plus occasion/special_request/cancellability. |
| resy_cancelA | Cancel a Resy reservation by its resy_token (the rr://... identifier returned from resy_book or resy_list_reservations). The confirmation preview shows the venue, date, time, party size, and any cancellation fee. 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). |
| resy_bookA | 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 (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. |
| resy_list_favoritesA | List the user's favorited Resy venues ("hit list"). |
| resy_add_favoriteA | Add a venue to the user's favorites by venue_id. |
| resy_remove_favoriteA | Remove a venue from the user's favorites by venue_id. |
| resy_list_notifyA | List Priority Notify subscriptions — tables you are waiting for when reservations open up. |
| resy_add_notifyA | Subscribe to Priority Notify for a venue/date/party size. Resy emails you when a matching slot opens. time_start / time_end bound the window you're willing to accept (HH:MM, 24h). Resy's notify booking window only accepts near-term dates (~30 days out). |
| resy_remove_notifyA | Cancel a Priority Notify subscription by notify_id. The tool looks up the full spec from resy_list_notify internally — no other input needed. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools target clearly distinct resources/actions (venue details vs search vs slots, favorites CRUD, notify CRUD). The only mild overlap is between resy_search_venues (returns venues with slot tokens) and resy_find_slots (lists slots at a specific venue), but the descriptions make the boundary clear enough.
All 15 tools share the resy_ prefix and follow a predictable verb_noun or action pattern (list_x, add_x, remove_x, get_x). Minor deviations are resy_book, resy_cancel (verb-only) and resy_healthcheck (noun-only), but these remain readable and consistent in spirit.
15 tools sits at the top of the ideal 3-15 range and each one maps to a real capability (venue lookup, slot finding, booking, cancelling, favorites, notify, payment, profile, health). No filler tools.
Favorites and Priority Notify have full list/add/remove coverage, and reservations cover book/list/cancel plus discovery. The main gap is that an existing reservation cannot be modified/updated, and payment methods are read-only, but these are reasonable limitations users can work around.