Skip to main content
Glama
chrischall

opentable-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

opentable_modify

Modify an existing OpenTable reservation to a new date, time, or party size. Preview the new slot's policy first, then confirm to submit the change.

Instructions

Modify an existing OpenTable reservation in place. Requires the existing reservation's identity (restaurant_id + confirmation_number + security_token) plus a fresh modify_token from opentable_modify_preview — preview is mandatory because the new slot's cancellation policy / CC re-hold can differ from the original. Submits /dapi/booking/make-reservation with isModify: true + the existing confirmation_number + security_token; OpenTable preserves confirmation_number across modifies but may regenerate reservation_id and security_token. dining_area_id is OPTIONAL — the modify_token already carries the area opentable_modify_preview resolved; pass it only to restate it (mismatch is refused). Returns the same shape as opentable_book plus was_modified: true so the agent can phrase the user confirmation accurately. For Listing-type restaurants there's no slot to lock — agents should check opentable_get_restaurant.bookable first. Without confirm:true this returns a dry-run and makes NO change to the reservation; re-run with confirm:true to submit the modification.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesYYYY-MM-DD (the NEW date)
timeYesHH:MM (24h) — the NEW time
confirmNoMust be true to proceed. Without this, the tool returns a preview.
slot_hashYesslot_hash from opentable_find_slots for the NEW slot
party_sizeYes
modify_tokenNoREQUIRED. From opentable_modify_preview. No no-token path — the new slot's policy + CC re-hold can differ from the original.
experience_idNoOptional tamper-check signal. When set, must match the experienceId baked into modify_token.
restaurant_idYes
dining_area_idNoOptional. The modify_token carries the dining area preview resolved; when restated here it must match the token.
security_tokenYes
reservation_tokenYesslot_availability_token from opentable_find_slots for the NEW slot
confirmation_numberYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.18.2
    • addedInput schema / properties / dining_area_id / description
      Added value: +"Optional. The modify_token carries the dining area preview resolved; when restated here it must match the token."
    • changedInput schema / required
      Previous value: -[
-  "restaurant_id",
-  "confirmation_number",
-  "security_token",
-  "date",
-  "time",
-  "party_size",
-  "reservation_token",
-  "slot_hash",
-  "dining_area_id"
-]New value: +[
+  "restaurant_id",
+  "confirmation_number",
+  "security_token",
+  "date",
+  "time",
+  "party_size",
+  "reservation_token",
+  "slot_hash"
+]
  2. First observedv0.14.3

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that without confirm:true the tool is a dry-run, that confirmation_number is preserved, that reservation_id and security_token may be regenerated, and that mismatched dining_area_id is refused. It also states the return shape (same as opentable_book plus was_modified:true).

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?

The description is dense but every sentence earns its place: prerequisites, side effects, optional parameters, return shape, and dry-run flow are all covered without fluff. The structure front-loads the mandatory identity and preview requirement before optional details, which is appropriate for a complex mutation tool.

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?

Given no annotations and no output schema, the description is notably complete: it specifies return shape via opentable_book plus was_modified, explains the reservation-identity and confirmation flow, warns about Listing-type restaurants, and describes the dry-run-to-confirm invocation protocol. An agent has everything needed to invoke this tool correctly.

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

Parameters4/5

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

Schema coverage is 67%, so the description must add meaning, and it does: it identifies restaurant_id + confirmation_number + security_token as the reservation identity, marks modify_token as mandatory and sourced from opentable_modify_preview, and explains that dining_area_id and experience_id are optional/tamper-check values. It also ties reservation_token and slot_hash to opentable_find_slots, adding provenance beyond the schema.

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 states 'Modify an existing OpenTable reservation in place' with a specific verb and resource, and clearly distinguishes this from sibling tools like opentable_book (new reservations) and opentable_modify_preview (required preview step). It also names the endpoint and core semantics, so an agent can understand exactly what this tool does.

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

Usage Guidelines5/5

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

The description explicitly requires a fresh modify_token from opentable_modify_preview and explains why the preview is mandatory. It also tells agents to check opentable_get_restaurant.bookable for Listing-type restaurants and to re-run with confirm:true to submit, including the dry-run behavior. This is clear when-to-use and when-not-to-use guidance.

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