OpenTable Reservations

Find and book restaurant reservations via OpenTable with date, time, party size, location, cuisine filters, or direct booking links for named restaurants.

Security Scan

The skill's requests, code, and runtime instructions align with its stated purpose (finding restaurants and producing OpenTable deep links); it requires an attached browser session and never asks for unrelated credentials or installs arbitrary code.

Purpose & Capability

Name/description match the code and instructions: scripts search OpenTable via the user's attached browser and build booking deep links. No unrelated env vars, binaries, or external services are requested.

Instruction Scope

SKILL.md constrains the agent to only use the included scripts and the OpenClaw browser primitives and explicitly forbids raw CDP scripting, web_fetch on opentable.com, and auto-completing bookings. The scripts run JS inside the user's attached browser to extract restaurant cards (expected behavior). Note: the evaluate JS runs in the user's browser context — if that browser session has unrelated sensitive tabs open, data exposure risk exists in principle, though the script itself targets OpenTable DOM selectors.

Install Mechanism

Instruction-only install (no remote download/install steps). Code is bundled with the skill (Python scripts). No network-based installers or archive extraction from untrusted URLs are used.

Credentials

No credentials, secret env vars, or config paths are requested. The only required runtime capability is access to an 'attached' browser profile and python3, which is appropriate for a skill that reads the user's OpenTable session and builds links.

Persistence & Privilege

always:false and the skill does not request permanent/automatic inclusion or modify other skills. It invokes the browser plugin at runtime; that is expected and proportionate to its function.

Assessment

This skill appears internally consistent: it uses your attached Chrome session to read OpenTable pages and then returns booking deep links (it explicitly stops before filling or submitting reservations). Before installing, confirm you are comfortable with the agent opening and evaluating pages in your existing browser profile (the skill requires an 'attached' profile and a logged-in OpenTable session). If you keep other sensitive tabs open in that browser, consider closing them first — the evaluate() JS is scoped to OpenTable selectors, but it runs inside your browser context. Because the skill's source/owner is 'unknown', review the bundled Python scripts if you want extra assurance (they are short and readable). Finally: the skill will not ask for credentials or perform network installs; in environments without the OpenClaw browser primitives it will fail rather than attempt forbidden fallbacks.

OpenTable

READ THIS FIRST (before any tool call)

There are two entry points. Pick ONE based on what the user gave you:

Entry A — user is discovering ("find me...", "what's available...")

The user has NOT named a specific restaurant. Your first tool call MUST be:

python3 ~/.openclaw/skills/opentable/scripts/list_restaurants.py \
  --location "<city>" --date-time "<YYYY-MM-DDTHH:MM>" \
  --party <N> --query "<cuisine>" --limit 5

Entry B — user already named a restaurant ("book Park Rose...", "reserve Carbone...")

The user HAS named a specific restaurant by name or slug. SKIP Phase 2 entirely and go straight to Phase 4. Call book.py directly — do NOT search to "verify" first:

python3 ~/.openclaw/skills/opentable/scripts/book.py \
  --rid "<slug-or-name>" \
  --date-time "<YYYY-MM-DDTHH:MM>" \
  --party <N> \
  --name "<display name>" \
  --url-path "<slug if known, else guess from name: lowercase+hyphenate+append -new-york>"

book.py is pure URL construction — it does not fetch OpenTable, does not verify the slot is still open, does not guarantee the restaurant exists. It builds a deep link. The user completes the reservation in OpenTable and sees any errors there. Do NOT call list_restaurants.py to "verify" before calling book.py when the user has named a specific restaurant — you will waste tokens and block on OpenTable rate limits.

---

For both entry points: Do not read any HTML. Do not write any CDP script. Do not call web_fetch on opentable.com. This is enforced by the skill's hard rules below.

You are NOT allowed to:

• Write /tmp/cdp_*.js or any JS file that talks to Chrome DevTools Protocol
• Run exec node ... or exec python ... where the command drives a browser
• Call web_fetch on any opentable.com URL
• Call openclaw browser snapshot / click / fill / navigate / evaluate directly — the skill's primitives already wrap these
• Read SKILL.md scripts via read — the CLI contracts in this file are authoritative

If you hit any error from list_restaurants.py, stop and tell the user the error. Do not invent a workaround.

---

Context (one-shot OpenTable reservation workflow)

Three Python scripts do all the work; you glue them together with short user-facing messages and stop early and often.

Non-negotiable definition

When the user says "book it for me", "make the reservation", "reserve it", or any variant, it means:

Produce a booking deep link that the user taps in OpenTable to complete the reservation with their account and card.

It does NOT mean:

• ❌ Click the "Reserve" / "Confirm" / "Complete Reservation" button on OpenTable
• ❌ Fill out the diner name, phone, country code form
• ❌ Select a Standard Reservation vs Experience option
• ❌ Navigate past the search results page on the user's behalf
• ❌ Write JS / CDP scripts that drive Chrome through the booking flow

Your job ends at book.py's output. The user takes it from there.

Hard forbid list (read this first)

These are disqualifying — if you're about to do any of them, stop and re-read this file.

1. Do not exec node, python, curl, or any other shell command to drive Chrome or talk to the Chrome DevTools Protocol. OpenClaw has a native browser plugin (openclaw browser …). Use it. If it errors, report the error to the user — do not hand-roll a workaround.
2. Do not write temporary JS files to /tmp/ for browser automation. The only scripts allowed in this flow are the three in ~/.openclaw/skills/opentable/scripts/. No others.
3. Do not WebFetch any opentable.com URL. Akamai blocks it and burns your context on failure.
4. Do not Read the skill's Python scripts. The CLI contracts below are authoritative; reading the scripts wastes tokens.
5. Do not call openclaw browser click, openclaw browser fill, openclaw browser press, or any other mutating browser subcommand. Only open, navigate, and evaluate (the read-only ones, used by the primitive) are allowed in this skill.
6. Do not openclaw browser navigate to any page under opentable.com/booking/, /restref/, or /restaurant/profile/. Those are booking-flow pages. The user opens them by tapping the link book.py produces.
7. Cap: max 3 openclaw browser … subcommand invocations per user request. If you hit that limit and still don't have what you need, stop and report.

If the agent's reasoning ever says "let me try this a different way using CDP / exec / a JS file", stop. The rule is: one primitive, or a clear error back to the user. No fallbacks.

Critical: the right profile

Always pass --browser-profile attached as a top-level flag on openclaw browser, before the subcommand.

Profile	Driver	State	Use it?
attached	existing-session (chrome-mcp)	running with user tabs	✅ yes
openclaw	cdp launcher port 18800	flaky	❌
manual	default launcher	stopped	❌
user	existing-session	stopped	❌

Correct: openclaw browser --browser-profile attached open <url> Wrong: openclaw browser open --browser-profile attached <url> (CLI syntax error)

browser.defaultProfile = "attached" is set in ~/.openclaw/openclaw.json, but still pass the flag explicitly as insurance.

Workflow — four phases, strict

Phase 1 — Gather requirements (one question max)

Field	Format	Default
location	city / neighborhood / ZIP	required
date_time	YYYY-MM-DDTHH:MM local	required — you parse natural language
party	integer	2
query	cuisine / vibe keywords	""

Parse "tonight 8pm" / "tomorrow 7:30" / "Friday dinner" yourself. Do not ask a separate date vs. time question — combine them.

If location is missing, ask one combined question: "Where should I look and any cuisine preference? (Defaults: 2 people, tonight if you said 'tonight', otherwise tomorrow 7:30pm)"

Stop asking questions after one clarification round. Pick reasonable defaults and move on.

Phase 2 — Get the restaurant list (SINGLE primitive call)

Run one command. This navigates OpenClaw's attached browser, queries the OpenTable DOM via evaluate, and returns structured JSON.

python3 ~/.openclaw/skills/opentable/scripts/list_restaurants.py \
  --location "<city or neighborhood>" \
  --date-time "<YYYY-MM-DDTHH:MM>" \
  --party <N> \
  --query "<cuisine keyword, or empty>" \
  --limit 5

Typical latency: ~8 seconds (navigate + evaluate). Typical output size: <1 KB of JSON.

If you already opened the search page in Phase 2 and just need to re-extract (e.g., the user changed filters in their tab), call it with no navigation flags and it will use the current tab:

python3 ~/.openclaw/skills/opentable/scripts/list_restaurants.py --limit 5

Never orchestrate this by hand with separate search.py → openclaw browser open → openclaw browser snapshot calls. The primitive does it correctly in one shot; the hand-rolled path is where the old skill burned 233 messages.

list_restaurants.py returns a single-line JSON:

{
  "restaurants": [
    {
      "name": "Little Alley",
      "cuisine": "Chinese",
      "neighborhood": "Midtown East",
      "price": "$$$$",
      "reviews": 43,
      "slots": ["7:45 PM", "8:00 PM", "8:15 PM"],
      "url_path": "little-alley-new-york"
    },
    ...
  ],
  "count": 3
}

On {"error": "...", "restaurants": [], "count": 0}: tell the user the error and suggest adjusting criteria. Do not retry with different params automatically — ask first.

Show the user a compact numbered list, summarized to at most 5 lines total:

1. Little Alley — Chinese · Midtown East · $$$$ · 43 reviews
   Slots: 7:45, 8:00, 8:15
2. Hutong — Chinese · Midtown East · $$$$ · 312 reviews
   Slots: 7:45, 8:00, 8:15
3. Jaba — Taiwanese · Midtown East · $$$$ · 36 reviews
   Slots: 7:30, 8:00, 8:30

Ask exactly one question: "Which one and what time?" Do not recommend a pick unless the user asked. Do not describe the restaurants beyond the compact row — the user can look at OpenTable for more.

This is a hard STOP point. You have now used one openclaw browser … open and one openclaw browser … evaluate. That is 2 of your 3 allowed calls. Do not make further browser calls until the user replies.

Phase 3 — (Skippable) parse a URL the user pasted

If the user picks a restaurant by name/number from the list, skip this phase — you already have the url_path from Phase 2.

If the user pastes a different OpenTable URL instead:

python3 ~/.openclaw/skills/opentable/scripts/extract_rid.py "<url>"

Output: {"rid": "12345"|null, "url_path": "...", "source": "..."}

Phase 4 — Build the booking deep link and stop

python3 ~/.openclaw/skills/opentable/scripts/book.py \
  --rid "<rid-or-slug>" \
  --date-time "<YYYY-MM-DDTHH:MM>" \
  --party <N> \
  --name "<restaurant name>" \
  --url-path "<url_path from Phase 2>"

Output:

{
  "restaurant": "Little Alley",
  "date_time": "2026-04-11T20:00",
  "party": 2,
  "confirm_url": "https://www.opentable.com/booking/details?...",
  "profile_url": "https://www.opentable.com/r/..."
}

Present it to the user under 4 lines:

Little Alley — Saturday, April 11 at 8:00 PM for 2

Tap to confirm on OpenTable: <confirm_url>

Restaurant page: <profile_url>

STOP. Do not navigate the browser to confirm_url. Do not click anything. Do not verify the reservation succeeded. The user's OpenTable app or browser handles the rest.

If you're tempted to "just check if it worked" by snapshotting the page — don't. That's the failure mode that burned 233 messages and accidentally booked a real table last time.

Budget tracker (re-check before every tool call)

Resource	Limit	Why
openclaw browser invocations	3 per user request	Anything more means you're hand-rolling a workaround
Clarification questions	1 per user request	Combine or pick defaults
User-facing message length	≤ 4 lines	Bulleted lists are fine; paragraphs aren't
Total turn latency	< 30 seconds	If slower, stop and report what you have

Troubleshooting — the exact errors you might see

Navigation blocked: strict browser SSRF policy requires an IP-literal URL

www.opentable.com is missing from the SSRF allowlist. One-command fix:

openclaw config set browser.ssrfPolicy.hostnameAllowlist \
  '["opentable.com","*.opentable.com","www.opentable.com"]' --strict-json \
  && openclaw gateway restart

Chrome CDP websocket for profile "openclaw" is not reachable after start

You used --browser-profile openclaw (or no profile flag → it defaulted to openclaw before the fix). Always use --browser-profile attached. If you did and still see this, run:

openclaw browser reset-profile

…but this is a last resort; prefer fixing the command.

browser.request cannot mutate persistent browser profiles

You ran a mutating browser subcommand (click, fill, press, etc.) against a persistent profile. This is forbidden by this skill's hard rules — you should only be using open, navigate, and evaluate. Re-read the hard forbid list.

list_restaurants.py returns {"count": 0}

Either the location string is too narrow, the current tab isn't an OpenTable search results page, or OpenTable is showing an empty result. Common causes ranked:

1. Narrow neighborhood names return empty. OpenTable's search engine is picky: "Lower Manhattan" returned 0, "Manhattan" / "New York" returned 3+ for the same time+query. If count is 0 and the location is a neighborhood, automatically widen to the city once and retry — that's the only auto-retry allowed by this skill.
2. The tab is stuck mid-booking-flow (leftover from a prior session). Fix by re-running list_restaurants.py with --location/--date-time/--party/--query so it re-navigates.
3. The time is outside OpenTable's operating hours window (e.g. 3 AM).

Do not issue more browser commands beyond the single auto-widen retry to "figure out what's on the page". That path leads to runaway.

Multi-page booking flow (for reference only — the skill doesn't automate this)

If the user manually taps the confirm_url from Phase 4, OpenTable routes them through:

1. /r/<slug> — profile page with slot buttons
2. /booking/seating-options — pick Atrium / Lounge / Dining Room (when restaurant has multiple rooms)
3. /booking/details — final form (diner pre-filled for logged-in users, card optional if creditCardRequired=false)
4. /booking/confirmation?confirmationNumber=…&securityToken=… — success page with Modify / Cancel / Add-to-calendar buttons

The URL parameter st=Standard vs st=Experience tells you whether it's a normal reservation or a prepaid menu. Prefer Standard. If the link lands on a seating page with only Experience options, warn the user that a prepaid experience is the only way in at that time.

This is reference information for explaining to the user what they'll see after tapping the link. The skill itself never navigates past /r/<slug>.

What this skill does NOT do

• Complete reservations automatically. Forbidden by design. See the "Non-negotiable definition" at the top.
• Modify or cancel existing reservations. Send the user to OpenTable.
• Handle waitlists / notify-me / prepaid experiences. Skip prepaid experience rows if the user asked for a standard reservation.
• Search beyond OpenTable. Resy, Tock, Yelp Reservations are separate systems.
• Fetch or parse OpenTable pages via WebFetch, curl, urllib, or requests. Akamai blocks them. Use list_restaurants.py exclusively.