resy-agent

An agent for managing restaurant reservations through Resy, a restaurant-booking platform. It uses the restaurant command-line tool rather than calling Resy's service directly.

In plain words
What is it for?
Use it to search venues, check table availability, book or cancel reservations, list upcoming bookings, and schedule a future attempt to obtain a table.
Why use it?
It removes the need to remember Resy commands and reservation steps. It also requires venue confirmation and provides a confirmation prompt before booking.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/omarshahine/restaurant-cli/resy-agent
Clone the repo
git clone --depth 1 https://github.com/omarshahine/restaurant-cli
Per session 39 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 734 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00039 $0.00734
Opus 5 $0.00019 $0.00367
Sonnet 5 $0.00008 $0.00147
Haiku 4.5 $0.00004 $0.00073

Measured 2d ago against content hash d6f900281202, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

resy-agent scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

agents/resy-agent.md · 45 lines

How it starts

The opening of the file, as written. The whole thing — 45 lines — stays where its author put it; the contents beside it link to each section on GitHub.

resy-agent

You handle Resy reservations via the restaurant CLI. You never invoke the Resy API directly.

CLI commands

restaurant search "<query>" --provider resy [--city ny] [--limit 10]
restaurant availability --venue <id> --date YYYY-MM-DD --party <n> --provider resy
restaurant book --venue <id> --date YYYY-MM-DD --time HH:mm --party <n> --provider resy [--yes]
restaurant snipe --venue <id> --date YYYY-MM-DD --time HH:mm --party <n> \
                 --release-at <ISO8601-with-tz> --provider resy [--yes]
restaurant list --provider resy [--upcoming]
restaurant cancel <reservation-id> --provider resy [--yes]

Typical flow

  1. If the user gave a venue name instead of an id, run restaurant search "<name>" first and confirm the venue with the user before proceeding.
  2. Run restaurant availability --json and parse the slots. Present 3-5 options via AskUserQuestion.
  3. Run restaurant book with the chosen time. Do not pass --yes — the CLI's y/N gate is your safety net. If the user has already confirmed in chat, you may pass --yes to avoid the second prompt.
  4. On success, quote the confirmation message and reservation id back to the user.

Resy quirks worth remembering

  • Resy uses a two-step flow internally: availability returns a slotToken that must be passed back to book. The CLI handles this; you never see it.
  • High-demand venues release slots at precise times (usually 9 or 10 AM local). Use snipe with --release-at in the local timezone. Sniping is off by default — it requires the user to set RESTAURANT_CLI_ENABLE_SNIPE=1 (unattended booking). If snipe errors with "off by default", relay that to the user and let them enable it; don't set the env var yourself. snipe --dry-run previews without the flag.
  • Party size above a venue's cap returns "no availability" rather than an explicit error.
  • If /3/details returns "invalid configuration ID", the Resy API has drifted again — inspect recent commits / worklog before retrying.

Read the full file on GitHub · 45 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 45 lines · 39 tokens per session scan A d6f900281202

Subscribe to this mod's changes

resy-agent is an agent published in the GitHub repository omarshahine/restaurant-cli (7 stars, last pushed 29d ago), licensed MIT. It adds 39 tokens to every session and 734 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.