Skip to main content
Glama
chrischall

opentable-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

opentable_modify

Destructive

Modify an existing OpenTable reservation to a new date, time, or party size after a required preview; use the original confirmation/security tokens and the preview's modify token.

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. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds; the prompt names the restaurant, the current and new slot, and the card re-hold (see MCP_CONFIRM_MODE).

Input Schema

NameRequiredDescriptionDefault
dateYesYYYY-MM-DD (the NEW date)
timeYesHH:MM (24h) — the NEW time
slot_hashYesslot_hash from opentable_find_slots for the NEW slot
party_sizeYes
confirmTokenNoONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.
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 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. Changed2 schema fields changedv1.2.1
    • removedInput schema / properties / confirm
      Removed value: -{
-  "description": "Must be true to proceed. Without this, the tool returns a preview.",
-  "type": "boolean"
-}
    • addedInput schema / properties / confirmToken
      Added value: +{
+  "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+  "type": "string"
+}
  3. 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"
  4. 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"
+]
  5. First observedv0.14.3

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this as non-idempotent and destructive, but the description adds substantial context beyond them: the confirmation prompt flow, the two-step confirmToken fallback for non-elicitation clients, the CC re-hold, cancellation-policy drift, and that confirmation_number is preserved while reservation_id/security_token may be regenerated.

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-loaded with purpose and requirements, and nearly every sentence carries actionable detail. However it is a single dense paragraph mixing API internals ('Submits /dapi/booking/make-reservation') with agent-facing guidance, which costs some readability.

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 12-param mutation tool with no output schema, the description covers the return contract (same shape as opentable_book plus was_modified: true), the confirmation semantics, and the preview prerequisite. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 67%, and the description supplements it by grouping the identity triad (restaurant_id + confirmation_number + security_token), reinforcing modify_token as required with no no-token path, and explaining that dining_area_id is optional and refused on mismatch. It adds little for the still-undocumented restaurant_id/party_size fields, so not a full 5.

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 ('Modify an existing OpenTable reservation in place') and immediately distinguishes it from the preview step and the other siblings. An agent can tell this apart from opentable_book / opentable_modify_preview without opening any schema.

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?

Explicitly declares the precondition (a fresh modify_token from opentable_modify_preview is mandatory, with the reason) and routes the agent via named siblings. It also flags the Listing-type restaurant edge case and points at opentable_get_restaurant.bookable as the check.

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