resy-mcp
# resy-mcp
[](https://github.com/chrischall/resy-mcp/actions/workflows/ci.yml)
[](https://www.npmjs.com/package/resy-mcp)
[](LICENSE)
Resy reservation management as an MCP server for Claude — search restaurants, book tables, manage reservations, favorites, and Priority Notify via natural language.
> ⚠️ Resy does not publish an official API. This server uses the same private endpoints the Resy web app calls, with the public web-app `api_key` and one of three user-level auth paths (token override, email + password, or a fetchproxy browser bridge). Use at your own discretion.
## Tools
| Tool | Purpose |
| --- | --- |
| `resy_get_profile` | Current user profile (name, email, booking count) |
| `resy_search_venues` | Search venues with availability for a date + party size |
| `resy_find_slots` | List bookable slots at a venue |
| `resy_get_venue` | Full venue details |
| `resy_book` | Book a reservation (composite: find → details → book) |
| `resy_list_reservations` | Upcoming / past reservations |
| `resy_cancel` | Cancel by `resy_token` |
| `resy_list_favorites` | Favorited venues |
| `resy_add_favorite` / `resy_remove_favorite` | Manage favorites |
| `resy_list_notify` | Priority Notify subscriptions |
| `resy_add_notify` / `resy_remove_notify` | Manage Priority Notify |
## Acknowledgement of Terms
By using this MCP server, you acknowledge and agree to the following:
**1. This server accesses your own Resy account.** Auth happens via your own credentials (email/password) or your own signed-in browser session through the ContextMint Bridge extension. It does not — and cannot — access anyone else's reservations.
**2. [Resy's Terms of Service](https://resy.com/terms) govern your use of this server**, just as they govern your direct use of resy.com. Resy's ToS prohibits the use of bots and automated booking, enforces rate limits, deploys CAPTCHA, and states that automated booking bots can result in account bans. Reservations are not transferable and may not be resold.
You are agreeing to those terms — read by the maintainer 2026-05-23 — every time you invoke a tool in this server.
**3. Personal, non-commercial use only.** This project is not affiliated with, endorsed by, sponsored by, or in partnership with Resy or American Express. It is a personal automation tool intended only to help one user manage one person's reservations from the command line. Specifically: **do not use it to mass-book**, snipe slot-tokens the moment they open, resell tables, or compete with Resy. The booking tools exist so you can book the table you would have booked anyway, faster.
**4. Stability is not guaranteed.** This server calls the same `api.resy.com` endpoints the Resy mobile app and web app call, with the same public web-app api_key. Resy may change endpoint shapes, rotate keys, or add new bot detection at any time. It may break.
**5. You accept full responsibility** for any consequences of using this server in connection with your Resy account — rate limiting, slot-lock rejections, account warnings, suspension, or bans. If Resy objects to your use, stop using this server.
This section is the maintainer's good-faith summary of the terms — it is not legal advice and does not modify or supersede Resy's actual ToS.
## Install
```bash
npm install
npm run build
```
## Configure
Pick one of three auth paths. The client tries them in this priority order:
1. **`RESY_AUTH_TOKEN`** — pre-obtained `x-resy-auth-token`. Overrides everything; useful for CI or power users who already have a token.
2. **`RESY_EMAIL` + `RESY_PASSWORD`** — the classic flow. POSTs `/3/auth/password` and caches the returned token.
3. **fetchproxy fallback** — when no env vars are set, the server uses the [fetchproxy](https://github.com/chrischall/fetchproxy) browser bridge to call `/3/auth/refresh` through your signed-in resy.com tab. Install the ContextMint Bridge extension once from its [releases page](https://github.com/nullnet-app/contextmint-bridge/releases) (unzip the Chrome build and load it unpacked at `chrome://extensions`; Safari isn't available yet — it will ship inside the ContextMint app, which has no public download — so use Chrome for now), sign into resy.com, and that's it — no credentials in env.
ContextMint Bridge is the fetchproxy browser extension under its new name, from the same maintainer — fetchproxy's own [README](https://github.com/chrischall/fetchproxy#extension) points to it. Its source is public at [nullnet-app/contextmint-bridge](https://github.com/nullnet-app/contextmint-bridge): build it yourself, or check a release zip against the `.sha256` file published beside it (`shasum -a 256 -c contextmint-bridge-chrome-<version>.zip.sha256`).
Copy `.env.example` to `.env` and fill in whichever path you want:
```
# Path 2: password login (classic)
RESY_EMAIL=you@example.com
RESY_PASSWORD=changeme
# Path 1: direct token (overrides everything)
RESY_AUTH_TOKEN=...
# Opt-out of the fetchproxy fallback (forces 1 or 2)
RESY_DISABLE_FETCHPROXY=1
```
For MCPB / Claude Desktop install, the packaged manifest prompts for all three optional inputs — leave them blank to route through ContextMint Bridge instead.
## Confirmations
`resy_book` and `resy_cancel` ask you to confirm before they change anything. A client that can show a confirmation prompt (Claude Code) shows one. On a client that cannot, the first call returns a preview and a `confirmToken`, and only a repeat call with that token goes ahead:
| variable | default | |
|---|---|---|
| `MCP_CONFIRM_MODE` | `ask-user` | What a write does on a client that cannot show a confirmation prompt (claude.ai, Claude Desktop). `ask-user`: two steps — the first call does nothing and returns a preview plus a token, and the model must get your approval in chat before calling again with it. `auto`: the same two steps, but the model may use the token after reviewing the preview itself. `refuse`: writes are refused on such clients. A client that can show prompts (Claude Code) always gets the real prompt. An unrecognised value is treated as `refuse`. |
| `MCP_CONFIRM_TTL_SECONDS` | `600` | How long a token stays valid. |
| `MCP_CONFIRM_SECRET` | random per process | Signing key; set it only if tokens must survive a server restart. On mcp-host the host supplies a stable per-child key (`MCP_HOST_CONFIRM_SECRET`) and spent tokens are recorded under `MCP_DATA_DIR`, so an approval survives an idle restart. |
`resy_book` additionally books only the exact slot a preview showed. On a client without prompts the preview itself carries the `confirmToken`, bound to that slot's time, seating type and terms; once you approve, the model repeats the call with the preview's time as `desired_time` plus the token. On a client with prompts the call must name the slot (`desired_time` + `slot_type` + `terms_token`) before you are asked. If the slot or its terms changed in between, nothing is booked and a fresh preview is returned.
## Run (local stdio)
```bash
node dist/bundle.js
```
## Test
```bash
npm test # tsc typecheck + unit tests (mocked fetch)
npm run smoke # live endpoint probe — requires real .env
```
## Notes
- The api key is the public one baked into resy.com's JS bundle. It is captured from your signed-in tab and cached, so a rotation is picked up on its own — `RESY_API_KEY` pins a specific key instead, and is only needed when you want to override that.
- Favorites and Priority Notify endpoint paths are reverse-engineered; if live endpoints differ, run `npm run smoke` and adjust.
---
This project was developed and is maintained by AI (Claude Opus 4.7).
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.