Skip to main content
Glama
chrischall

opentable-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

opentable_find_slots

Read-only

Find available OpenTable reservation slots for a restaurant by date and party size, returning bookable tokens for each open time.

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

TableJSON 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. 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"
  2. 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"
+}
  3. First observedv0.14.3

TDQS

A4.4/5.0
Behavior5/5

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

Annotations provide readOnlyHint=true reporters, and the description adds substantial behavior: tokens expire quickly, slot_hash can bypass a get_restaurant call, the dining-area id is resolved at book time, and the exact 'operation ... not yet observed on this tab' error workaround. This is rich behavioral disclosure well beyond the annotations.

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

Conciseness5/5

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

Every sentence in the description carries distinct operational information: core purpose, token expiration, slot attributes/types, booking shortcut, and error recovery. It is front-loaded with the main purpose, and the length is justified by the complexity of the integration.

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

Completeness4/5

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

Given there is no output schema, the description does a good job explaining the key return value (reservation_token), slot_attributes, type, and slot_hash as an input to opentable_book. It also covers a known failure mode glitch. Minor gaps remain: it doesn't describe the full output shape or explicitly mention the required 'time' parameter in the prose, so it is very good but not fully complete.

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?

The input schema already documents date, time, view, and database_region in detail. The description reinforces 'date + party size' and restaurant specificity, but it doesn't add significant meaning for restaurant_id, party_size, or time beyond what the schema already says. With 67% schema coverage, this is adequate but not exemplary.

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?

The description opens with a specific action and resource: 'List available reservation slots at a specific OpenTable restaurant for a date + party size.' It clearly differentiates from siblings like opentable_list_reservations by focusing on availability rather than existing reservations, and it names the downstream integration with opentable_book.

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?

It gives explicit usage context: returned reservation_token and slot_hash should be passed directly to opentable_book, and opentable_get_restaurant is unnecessary for that flow. It also provides a concrete retry condition. It doesn't explicitly contrast with opentable_list_reservations or state when not to use this tool, so it stops short of a 5.

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