Skip to main content
Glama
chrischall

opentable-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

opentable_find_slots

Read-only

Find available reservation slots at a specific OpenTable restaurant by date, time, and party size, returning reservation tokens for booking.

Instructions

List available reservation slots at a specific OpenTable restaurant for a date + party size. Returns each slot's reservation_token (use it with opentable_book — tokens expire quickly, book promptly). Slots may be attributes=['default'|'bar'|'highTop'|'outdoor'] and type=Standard|Experience|POP. You can pass a slot's reservation_token + slot_hash straight to opentable_book without a separate opentable_get_restaurant call — book auto-resolves the dining area. (OpenTable's availability response carries only the seating category, not the numeric dining-area id, so that id is resolved at book time from the booking-details page.) If this errors with "operation ... not yet observed on this tab", open any OpenTable restaurant page in your browser once (the graphql bridge needs to see the page's own availability query fire first), then retry.

Input Schema

NameRequiredDescriptionDefault
dateYesYYYY-MM-DD
timeYesHH:MM (24h) — anchor time; slots come back relative to this
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from the response; "full" returns OpenTable's payload untouched. No field projection: this server has no verified record of which OpenTable fields matter, and inventing one would risk dropping a field a caller needs.
party_sizeYes
restaurant_idYes
database_regionNoOpenTable's sharded-database region for the restaurant. Defaults to 'NA' (North America). Pass the venue's region (e.g. for UK/EU/APAC restaurants) when booking or cancelling outside North America — slot-lock, availability, and cancel route to the wrong database shard, or fail opaquely, when this is wrong. LIMITATION: not auto-derived from restaurant data (OpenTable's availability/booking responses don't surface the shard id), so non-NA bookings must set it explicitly.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.3.4
    • addedInput schema / properties / date / pattern
      Added value: +"^\\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\\d|3[01])$"
    • addedInput schema / properties / time / pattern
      Added value: +"^([01]\\d|2[0-3]):[0-5]\\d$"
  2. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Changed1 schema field changedv0.19.2
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns OpenTable's payload untouched. No field projection: this server has no verified record of which OpenTable fields matter, and inventing one would risk dropping a field a caller needs.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  4. First observedv0.14.3

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnly/openWorld annotations: token expiry pressure, that book auto-resolves the dining area, why the numeric dining-area id isn't in the availability response, and a specific error message with a concrete retry recipe. This is exactly the operational context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then layers workflow and troubleshooting detail. It is dense and on the long side, with a parenthetical about OpenTable internals that borders on tangential, but nearly every sentence carries actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only listing tool with no output schema, it covers the return payload (reservation_token, slot attributes, types), cross-tool handoff, expiry semantics, region caveats via schema, and a known failure mode with recovery steps. An agent has what it needs to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67%, so date, time, view, and database_region are already documented in the schema. The description clarifies output-side vocabulary (slot attributes and type values) and cross-references reservation_token/slot_hash, but adds little about the two undocumented parameters (restaurant_id, party_size) beyond their names. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List available reservation slots') plus scope ('at a specific OpenTable restaurant for a date + party size'). It is clearly distinguishable from siblings like opentable_book and opentable_get_restaurant, and even names the sibling it feeds into.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for the workflow: use the reservation_token with opentable_book, book promptly because tokens expire, and skip a separate opentable_get_restaurant call. It doesn't explicitly frame when to reach for this versus a hypothetical alternate availability tool, but the routing is largely unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools