opentable-mcp

by chrischall

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.16.5
Disambiguation5/5
Each tool has a clearly distinct purpose: booking flows (book, book_preview, cancel, modify, modify_preview), data retrieval (find_slots, get_restaurant, get_profile, list_reservations, search_restaurants), and favorites management (add_favorite, remove_favorite, list_favorites). No two tools could be confused.
Naming Consistency5/5
All tools follow the consistent pattern 'opentable_verb_noun' (e.g., opentable_add_favorite, opentable_book_preview). The naming is uniform and predictable across the entire set.
Tool Count5/5
13 tools cover the full scope of an OpenTable integration without unnecessary bloat. Each tool serves a necessary function in the reservation workflow, from search to booking to modification.
Completeness5/5
The tool set covers the entire lifecycle: search restaurants, view details, check availability, preview and book, list/modify/cancel reservations, and manage favorites. Notable gaps like updating user profile or viewing menus are beyond the core domain and not expected.
Average 4.3/5 across 13 of 13 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 6 community issues answered or closed in the last 6 months
- 79 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose idempotency, error behavior for duplicates, authentication needs, or side effects. Only states the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it is too sparse to be maximally helpful, lacking details that could be included without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple add operation, the description minimally covers the purpose. But without output schema or behavioral details, it is incomplete for an agent to invoke correctly, especially regarding duplicates or success confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. However, it adds no meaning beyond the schema's 'restaurant_id' parameter, which is already defined as an integer with constraints.
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 'Add a restaurant to the user's Saved Restaurants list' clearly states the action (add) and the resource (restaurant to Saved Restaurants list). It distinguishes itself from siblings like 'opentable_remove_favorite'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives. Usage is implied by the name, but no when-not or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It indicates a mutation (remove), but fails to disclose important behavioral traits such as whether the operation fails if the restaurant is not a favorite, authentication requirements, or rate limits. Transparency is minimal.
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 a single concise sentence of 11 words, front-loading the action and resource with no extraneous information. It is efficient and fits within the MCP context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides a basic functional understanding. However, it lacks guidance on usage and behavioral details that would make it fully complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter. While the parameter name 'restaurant_id' is self-explanatory, the description adds no additional meaning or context (e.g., where to find the ID, or acceptable formats). The tool description does not compensate for the lack of schema documentation.
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 clearly states the action ('Remove') and the resource ('a restaurant from the user's Saved Restaurants list'). It effectively distinguishes from sibling tools like opentable_add_favorite and opentable_list_favorites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a restaurant should be removed from favorites, but it does not provide explicit guidance on prerequisites (e.g., the restaurant must already be a favorite) or when to avoid using it. Sibling tool names provide context, but the description itself lacks explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the dry-run behavior (no action without confirm:true) and the prerequisites. It does not cover all potential behaviors (e.g., error handling, reversibility), but the key behavioral trait is disclosed.
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?
Two sentences, front-loaded with purpose, no unnecessary words. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the required workflow but omits return value information and does not discuss edge cases or error handling. The database_region parameter is important but not mentioned in the description, although it is in the schema.
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 description adds meaning for three parameters (restaurant_id, confirmation_number, security_token) by noting their source. It does not mention the database_region parameter, which is well-described in the schema. Overall, it partially compensates for the 40% schema coverage.
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 clearly states 'Cancel an OpenTable reservation,' using a specific verb and resource. The action is unambiguous and distinct from sibling tools like opentable_book or opentable_modify.
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?
The description tells the agent where to obtain required parameters (from opentable_list_reservations or opentable_book) and explains the dry-run vs. cancellation workflow. However, it does not explicitly contrast with opentable_modify (for changes instead of cancellation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, indicating a safe read operation. The description adds context about returned data (cuisine, neighborhood, etc.) and explicitly states what is not included (bookable slot tokens), going beyond the annotation to set expectations fully.
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 two sentences long, front-loads the purpose, and contains no superfluous information. Every clause adds value by specifying either what is returned or what is not, achieving maximal efficiency.
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?
The description clearly defines input (search query) and output (list of restaurants with key fields) and flags the absence of slot tokens. However, it omits details like pagination, result limits, or sorting, which are relevant for a search tool. Nonetheless, the core functionality is adequately covered given the tool's simplicity.
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 schema covers 75% of parameters with descriptions (6 of 8). The overall description does not add further meaning beyond the schema; for the two undocumented parameters (latitude, longitude), no additional context is provided. Thus, the description meets the baseline but does not compensate for missing schema descriptions.
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 clearly states the action ('Search OpenTable for restaurants') and lists returned fields (cuisine, neighborhood, price band, rating, description, URL). It explicitly distinguishes from the sibling 'opentable_find_slots' by noting that slots are not included, making the tool's scope unambiguous.
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?
The description explicitly tells when to use this tool (search) and when not (to get slots, use opentable_find_slots). However, it does not mention other sibling tools like opentable_get_restaurant for detailed information on a specific venue, which could provide additional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating safety. The description adds significant behavioral context: token expiration, direct use of slot_hash in booking, the limitation regarding database_region, and the browser tab workaround. This goes well beyond the annotation.
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?
The description is packed with useful information but is slightly lengthy. It front-loads the core purpose and is well-structured with parenthetical clarifications. Could be trimmed slightly without losing key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema), the description covers behavioral and error-handling aspects well. However, it does not fully specify the response structure beyond mentioning reservation_token, attributes, and type. More detail on the return format would improve completeness.
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?
The description adds meaning for the database_region parameter, explaining its necessity and limitation. For other parameters, the schema already provides descriptions, but the description clarifies that 'time' is an anchor time and slots are relative to it, adding value.
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 clearly states the tool lists available reservation slots for a specific restaurant, date, and party size. It differentiates from siblings by explicitly mentioning the returned reservation_token and its use with opentable_book, as well as slot attributes and types.
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?
The description provides explicit guidance on when to use the tool (before booking), mentions token expiration, and gives a workaround for a specific error. However, it does not explicitly contrast with alternatives like opentable_book_preview or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds the list of returned fields (id, name, cuisine, etc.), providing useful context beyond annotations. However, it doesn't mention potential limitations like pagination or ordering.
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 a single concise sentence that front-loads the action and avoids wasted words.
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?
The description adequately explains what the tool returns given no output schema. It covers the key fields but could mention if there are any limits or pagination.
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?
No parameters exist, and schema coverage is 100%. Baseline score of 4 applies as no parameter information is needed.
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 clearly states the tool lists the user's saved restaurants from OpenTable, specifying the resource and verb. It is distinct from sibling tools like opentable_add_favorite or opentable_search_restaurants.
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?
The description implicitly indicates when to use this tool (to list saved restaurants) given the sibling names. No explicit exclusions or comparisons, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds value by explicitly noting that payment and credit-card details are never exposed, which is important behavioral context. No contradictions.
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?
Two sentences, no redundant words. The first sentence immediately states the purpose and lists key data fields; the second adds a boundary condition. Highly concise and front-loaded.
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 the tool's simplicity (zero parameters, read-only), the description is complete: it explains the return values and explicitly states what is not included (payment details). No output schema is needed.
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?
The tool has no parameters, and schema coverage is 100% (0 params). The description adds meaning by explaining what data is returned (profile fields), which is valuable beyond the empty 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?
Description clearly states the tool retrieves the authenticated user's profile and lists specific data fields like name, email, phones, loyalty points. It is distinct from sibling tools that deal with restaurants, bookings, or favorites.
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?
The description implies usage for retrieving profile info, but does not explicitly state when to use this tool versus alternatives or provide exclusions. However, given the tool's specificity, the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds value by revealing that each entry contains a security_token needed for cancellation or modification, which is critical for subsequent actions. No contradictions.
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?
Two sentences, no waste. The critical information is front-loaded: purpose, default behavior, options, and output content. Every sentence earns its place.
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 simple list endpoint with one optional parameter, the description is complete. It covers usage, scope options, and the return value's key feature (security_token). No output schema needed given this clarity.
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?
The schema has 0% description coverage, but the description fully explains the single optional parameter: defaults to 'upcoming', with 'past' and 'all' options. This compensates for the lack of schema descriptions, providing clear guidance on parameter usage.
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 clearly states the tool lists the authenticated user's OpenTable reservations, distinguishing it from sibling tools like opentable_book or opentable_cancel. It specifies the default scope (upcoming) and that entries include security_token for modifying/canceling, uniquely positioning it among 13 siblings.
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?
The description explicitly explains the default scope and how to retrieve past or all reservations via the scope parameter. While it doesn't list alternative tools, the context is clear: this is for viewing reservations, not modifying them. Implicit guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses API endpoint, internal parameters, effect on confirmation_number and security_token, return shape including was_modified, and dry-run vs confirm behavior. Transparent about the need for modify_token due to differing cancellation policies.
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?
Slightly long but every sentence adds value. Well-structured: starts with purpose, then requirements, then workflow details, then return, then special cases, then confirm behavior. Could be trimmed slightly but not wasteful.
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 12 parameters (9 required) and no output schema, the description is thorough. Explains the modification process, preview dependency, confirmation handling, and a special case. Minor missing details about error handling or rate limits, but overall complete for agent usage.
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?
Adds meaning beyond schema: explains purpose of modify_token, experience_id as optional tamper-check, reservation_token from opentable_find_slots, and confirms that confirm must be true to proceed. Covers key parameters despite 58% schema coverage.
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?
Clearly states it modifies an existing OpenTable reservation, specifying the needed identity elements and the mandatory modify_token from preview. Distinguishes from sibling tools like opentable_book and opentable_modify_preview.
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?
Explicitly states when to use (modify existing reservation) and that preview is mandatory. Mentions special case for Listing-type restaurants. Does not explicitly state when not to use, but implied context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint:true, consistent with description. Description adds behavioral details: supports three input formats (slug, path, URL), handles legacy /{slug} venues, and explains that numeric ids are unsupported. No contradictions.
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?
Single, well-structured sentence with colon separating summary from specifics. Every clause adds distinct value: purpose, input format guidance, and note about legacy venues. No unnecessary words.
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?
No output schema, but description enumerates the returned fields: cuisine, price band, description, address, hours, phone, payment options, features, rating/review count, and availability_token (with usage note). Sufficient for an agent to understand what details are retrieved.
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 100% with detailed parameter description. The description adds value beyond schema by explaining that passing the search result's 'url' verbatim always resolves and mentions legacy venue paths. Baseline 3, plus extra context gives 4.
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 specifies the verb 'Get' and resource 'full details for a single OpenTable restaurant', listing key fields (cuisine, price band, etc.). It clearly distinguishes from sibling tools like opentable_search_restaurants (which returns list) and others.
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?
Explicitly states it accepts slug, path, or URL from opentable_search_restaurants, advising to pass the search result's 'url' verbatim. Warns that numeric IDs result in 404. Provides context for use before booking. Does not explicitly mention when not to use, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses token expiry, dry-run mode, CC-required slot behavior, auto-fetching of user profile, return values, and limitations like database_region not being auto-derived.
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?
The description is long but well-structured, front-loaded with the main action, and each sentence adds useful information. Slightly verbose but not unnecessarily.
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 12 parameters and no output schema, the description is fully adequate, covering prerequisites, side effects, return values, error conditions, and alternatives.
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 83% (high), baseline 3. The description adds significant value by explaining token expiry, optionality of dining_area_id, dry-run with confirm, booking_token requirement, and database_region limitation.
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 clearly states 'Book an OpenTable reservation' and distinguishes from siblings by specifying prerequisites (slot_hash, reservation_token from opentable_find_slots) and noting that Listing-type restaurants should use alternative flows.
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 provides explicit guidance on when to use this tool, including token expiry, optional parameters, required preview step for CC-required slots, dry-run behavior, and conditions for Listing-type restaurants. It also references sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details the internal mechanics: URL includes confirmationNumber + securityToken + isModify=true, returns modify_token for the next step. It also warns about Listing-type restaurants blocking modification. This adds significant behavioral context.
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?
The description is relatively long but well-organized: purpose first, then inputs/outputs, then comparison with sibling, then requirement, then limitation. Front-loaded and efficient, though could be slightly more concise.
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 tool with 12 parameters and no output schema, the description provides comprehensive context: what inputs are needed, their sources, what outputs to expect, and a critical limitation. It clearly fits into the workflow with opentable_modify.
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?
The description groups parameters into existing identity and new slot args, explaining their origin (from opentable_list_reservations or opentable_find_slots). With 58% schema coverage, this complements the missing param descriptions effectively, though not every param is individually detailed.
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 clearly states the tool previews a modification to an existing reservation, specifying inputs (existing identity + new slot args) and outputs (cancellation policy, CC details, modify_token). It explicitly distinguishes from opentable_book_preview and notes the limitation for Listing-type restaurants.
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 states this tool is REQUIRED before opentable_modify with no shortcut. It also mentions when it might not work (Listing-type restaurants, requiring check of opentable_get_restaurant.bookable). Context for when to use vs. siblings is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms read-only preview behavior. It adds timing context (holds slot ~60-90s) and notes skipping redundant re-lock in book, going beyond 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?
Front-loaded with main purpose, all sentences add value (purpose, required scenarios, alternatives, timing, edge cases). No redundancy despite length.
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?
Covers all critical context: what it surfaces, when mandatory, special cases (Listing, Experience-mandatory), timing, and database region handling. Adequate given no output schema.
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 80%, so baseline is 3. The description adds extra context for experience_id, database_region (with limitation), and auto-resolve for dining_area_id, justifying above baseline.
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 clearly states it previews a booking before committing, distinguishes from sibling opentable_book, and specifies the resources surfaced (cancellation policy, payment card, booking_token).
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 says when to use (required for CC-required slots, safe for standard slots) and when not (Listing-type restaurants cannot fetch slot; check bookable first). Also provides guidance for Experience-mandatory slots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![opentable-mcp MCP server](https://glama.ai/mcp/servers/chrischall/opentable-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/opentable-mcp)

Score Badge

Copy to your README.md:

[![opentable-mcp MCP server](https://glama.ai/mcp/servers/chrischall/opentable-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/opentable-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/opentable-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server