resy-mcp CLAUDE.md

resy-mcp

MCP server for Resy. Wraps Resy's private web-app API and exposes 14 resy_* tools over stdio: search venues, find slots, book/cancel reservations, manage favorites, and Priority Notify subscriptions.

Resy has no official public API. This server calls the same endpoints the resy.com web app calls. Use at your own discretion.

Auth (three paths, in priority order)

The client picks an auth path on demand:

1. RESY_AUTH_TOKEN — direct x-resy-auth-token override. Power users / CI. Skips everything else.
2. RESY_EMAIL + RESY_PASSWORD — POSTs /3/auth/password (form-encoded), caches the returned token.
3. fetchproxy bootstrap (Pattern B) — when neither of the above is set, calls POST https://api.resy.com/3/auth/refresh through the user's signed-in resy.com tab via @fetchproxy/server's FetchproxyServer.postJson. The browser auto-attaches the HttpOnly session cookies; the response body returns { token: "..." } which we use as both x-resy-auth-token and x-resy-universal-auth. After that, all API calls remain direct Node fetch — fetchproxy is invoked once per session bootstrap, never in the hot path. Opt-out with RESY_DISABLE_FETCHPROXY=1.

Why Pattern B (one bootstrap call, then direct fetch) instead of Pattern A (every call through fetchproxy)? Resy's session lives in HttpOnly cookies (localStorage / sessionStorage / IndexedDB are auth-empty). The page's only authenticated endpoint that returns a usable token in its response body is /3/auth/refresh — so we bridge that one call and run everything else directly.

Commands

npm run build          # tsc → dist/ + esbuild bundle → dist/bundle.js
npm test               # vitest, mocked fetch, no network
npm run test:watch     # watch mode
npm run test:coverage  # v8 coverage (text + html, no thresholds)
npm run smoke          # live read-only probe of /2/user, /3/user/reservations,
                       #   /3/user/favorites, /3/notify — needs real .env
npx tsc --noEmit       # typecheck only