Restaurant reservations

Book, search, cancel, and schedule future bookings ("snipes") across multiple reservation platforms behind a single pluggable surface. Every provider (Resy, OpenTable, and future peers) is implemented as an independent module plugged into the same interface — the tools and CLI dispatch through a shared registry.

Pick an execution path

Choose based on the tools available in the current session:

1. restaurant_* tools present (OpenClaw host) — call the tools directly. Parameters documented under OpenClaw tools below.
2. No restaurant_* tools (Claude Code host or plain shell) — shell out to the restaurant CLI via Bash. For complex or ambiguous requests, delegate to the restaurant-router agent rather than executing directly.

Both paths share one backend, so results are identical — only the calling convention differs. Never invoke a provider's API directly; the plugin's safety invariants (e.g. OpenTable: never auto-submit a booking) live in the CLI and tools.

Provider capabilities (2026-04)

OpenTable cannot complete bookings via API; the bookUrl capability returns a deep link for the user to confirm in their own browser. Always verify capabilities via restaurant doctor (CLI) or the tool's own error handling (OpenClaw) rather than assuming from this table.

Opt-in gates (off by default)

Two higher-risk capability groups are disabled unless the user explicitly opts in via an env var. If a command errors with "off by default", relay the reason and the env var to the user — do not set it yourself:

Resy (documented-token API) and OpenTable bookUrl hand-off are not gated. snipe --dry-run previews without the flag.

CLI quick reference

One-time auth per provider:

restaurant setup resy              # env-first: prints an export line to add to your env
restaurant setup resy-openclaw     # also writes an env SecretRef into ~/.openclaw/openclaw.json
restaurant doctor                  # verify config, auth, scheduler health

Search, check availability, book:

restaurant search "le bernardin"                    # default provider
restaurant search "carbone" --provider opentable    # cross-provider
restaurant availability --venue 1387 --date 2026-05-15 --party 2
restaurant book --venue 1387 --date 2026-05-15 --time 19:30 --party 2

List and cancel:

restaurant list --upcoming
restaurant cancel <reservation-id>

Snipe — queue a booking for a specific future release time:

restaurant snipe --venue 1387 --date 2026-05-15 --time 19:30 --party 2 \
                 --release-at 2026-04-30T10:00-07:00
restaurant jobs list
restaurant jobs cancel <job-id>
restaurant jobs logs <job-id>

All destructive commands (book, cancel, snipe, jobs cancel) prompt y/N unless --yes is passed.

OpenClaw tools

Six provider-agnostic tools. All accept an optional provider string; when omitted the configured default applies.

Format conventions:

• Dates: YYYY-MM-DD
• Times: HH:mm (24-hour)
• releaseAt: ISO-8601 with offset, e.g. 2026-04-30T10:00-07:00
• slotToken: provider-specific token returned by a prior restaurant_availability call; omit to re-lookup at book time

Tool results are text-only (JSON stringified in the text content). Parse before acting.

Routing in Claude Code

For multi-venue searches, ambiguous provider intent, or any multi-step booking flow, invoke the restaurant-router agent via the Task tool rather than executing directly. The router inspects restaurant doctor output to pick the right provider agent (resy-agent, opentable-agent) based on the capabilities that are actually live.

Slash commands auto-route through the router:

• /restaurant <request> — generic entry point
• /restaurant-book <args> — immediate booking intent
• /restaurant-snipe <args> — schedule a future booking
• /restaurant-setup <provider> — interactive provider auth
• /restaurant-jobs list|cancel|logs — inspect scheduled snipes

Config and secrets

• CLI config: ~/.config/restaurant-cli/config.yaml (holds an env tokenRef, never the token value)
• Secrets: env-first — the tool writes no secret file. setup/auth login print an export KEY=... line; you add it to your own env (e.g. ~/.secrets.env, never macOS Keychain). The token is read from the environment at runtime.
• OpenClaw plugin config: ~/.openclaw/openclaw.json → plugins.entries.restaurant-cli.config

Append -openclaw to any restaurant setup <provider> invocation to mirror the resulting credentials into the OpenClaw plugin config in addition to the CLI store — the plugin reads only from pluginConfig, so this bridge step is required for the OpenClaw tools to find credentials.

Run restaurant config path to print the CLI config location without parsing help output.

Provider-specific notes

• Resy: restaurant setup resy[-openclaw] prompts for email/password, exchanges credentials for an auth token, and persists it. The public RESY_API_KEY has a built-in default; provide a custom one only when overriding.
• OpenTable: anonymous — no auth flow. Requires the patchright peer dep for browser-driven search:

  pnpm add patchright
  npx playwright install chromium

  Bookings are deep-link hand-offs: the CLI returns a URL, the user confirms in their own browser.
• Tock / SevenRooms: not yet implemented. Attempts surface a CapabilityError.

Safety invariants

• Never auto-submit an OpenTable booking — always hand off to the user's browser.
• Confirm venue identity before booking when the user gave a name: run restaurant search "<name>" first and verify the matching venueId with the user.
• Treat scheduled snipes as commitments: when the user says "snipe this", the releaseAt defaults to the venue's reservation-window opening; verify the time with the user when ambiguous.