@striderlabs/mcp-opentable

Server Quality Checklist

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

Latest release: v0.1.5
Disambiguation5/5
Each tool targets a distinct concern: auth status/login/logout, restaurant search/details, availability checking, and reservation create/list/cancel. No two tools overlap in purpose, so an agent can easily select the right one.
Naming Consistency5/5
All tools use a consistent opentable_ prefix followed by clear verb_noun names (search, get_restaurant, check_availability, make_reservation, get_reservations, cancel_reservation). Even the auth tools (status, login, logout) follow the same verb style. The pattern is predictable and uniform.
Tool Count5/5
With 9 tools, the server is well-scoped for an OpenTable integration. Each tool serves a necessary function in the core workflow (auth, search, details, availability, reservation management), and none feel redundant or superficial.
Completeness4/5
The toolset covers the full reservation lifecycle: search, view details, check availability, book, list, and cancel. A minor gap is the lack of a modify/update reservation tool, but agents can work around this by canceling and rebooking. Overall, the surface is complete for the main domain.
Average 4/5 across 9 of 9 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- 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 the full burden. It only states the action (search) and filter criteria but does not disclose whether authentication is required, what the response looks like, pagination, rate limits, or any side effects. The behavioral traits are not adequately 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?
The description is a single, front-loaded sentence that clearly states the action and key filters. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description should provide more context about return values, expected result structure, or how to use results with sibling tools. It lacks any guidance on response format or integration, making it incomplete for a tool of this complexity.
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 100%, so the schema already explains all parameters. The description merely lists the same parameter names without adding format, defaults (other than partySize default), or usage nuances beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for restaurants on OpenTable with specific filter dimensions (location, cuisine, party size, date, time). While it distinguishes from siblings by being the only 'search' tool, it doesn't explicitly contrast with check_availability or get_restaurant.
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 usage for finding restaurants, but provides no explicit guidance on when to use this tool versus alternatives like check_availability or make_reservation. No exclusions or alternative tool names are mentioned.
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 are provided, so the description carries the full burden. It only states the basic function and adds no behavioral details such as whether it is read-only, requires authentication, or returns nearby time slots. The schema does mention 'Availability is shown for nearby times,' but the description itself provides no transparency beyond the core purpose.
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 core purpose. It contains no filler or repetition, every word contributes to understanding the tool's function.
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 tool is moderately simple with four parameters, but there is no output schema and no annotations. The description implies the output (available time slots) but does not explicitly state the return format or any edge-case behavior. It is adequate for basic understanding but could benefit from mentioning what the response contains or typical use scenarios.
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 provides full descriptions (100% coverage) for all four parameters, so the description does not need to add much. It redundantly mentions date and party size but omits time and restaurantId. Since the schema already documents the parameters clearly, the description adds no significant semantic value, but the schema coverage keeps this at baseline 3.
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 ('Check'), the resource ('available reservation time slots'), and the context ('for a restaurant on a specific date and party size'). This distinguishes it from sibling tools like opentable_make_reservation or opentable_search, making the purpose unambiguous.
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 intended use case (checking availability before booking) is implied by the description and the sibling tool set, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. The context makes it fairly obvious, but the description itself offers no direct instruction.
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?
With no annotations provided, the description must disclose behavioral traits but only says 'Get', which implies read-only. It does not mention authentication requirements, error behavior, or that it makes no state changes. The verb alone is insufficient for full transparency.
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 is front-loaded with the key action and resource, then lists the main data categories. There is no redundant or filler content.
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?
There is no output schema, so the description must explain what is returned. It mentions several fields but uses vague terms like 'features' and omits possibly important details (ratings, reviews, contact info). For a simple get tool, it is adequate but not fully comprehensive.
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 100% (restaurantId is described as 'The restaurant ID or profile URL (from search results)'). The tool description adds no additional parameter guidance, so it meets the baseline but does not exceed it.
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 uses a specific verb ('Get') and a specific resource ('detailed information about a specific restaurant'), and it enumerates the content (description, address, hours, features). This clearly distinguishes it from siblings like search, availability, and reservation tools.
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?
There is no explicit when-to-use or alternative guidance in the description. The need to have a restaurant ID is implied by 'specific restaurant' and clarified in the schema ('from search results'), but the description itself does not state a preferred workflow or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions 'requires authentication' and 'for the logged-in user', which are useful behavioral traits. However, it does not state whether the operation is read-only, what happens if the user is not authenticated, or what the response format contains, leaving significant gaps.
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 one concise sentence with an additional clause about authentication. Every word contributes to the meaning, and it is front-loaded with the core action. There is no redundancy or filler.
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?
For a simple, zero-parameter read tool with no output schema, the description is largely complete: it states the operation, the actor, and a key prerequisite (authentication). Minor details like the exact scope of 'upcoming' (e.g., today or future) are unspecified, but the description provides enough context for basic use.
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 zero parameters, so the description need not add parameter details. Per the rubric, 0 parameters provides a baseline of 4, and the description adds no unnecessary parameter information. The schema is trivially fully covered with an empty properties object.
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 uses a specific verb and resource: 'List all upcoming reservations for the logged-in user.' This clearly distinguishes it from sibling tools like opentable_make_reservation or opentable_cancel_reservation, and it explicitly scopes the action to the user's own upcoming reservations.
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 for viewing a user's own upcoming reservations and requires authentication, hinting at the need to log in first. However, it does not explicitly tell when to use this tool versus alternatives such as searching for restaurants or checking availability, so usage guidance is only implicit.
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 carries the burden of disclosing behavior. It transparently explains the confirmed booking vs preview distinction and explicitly requires the user to be logged in. However, it does not mention potential failure modes (e.g., unavailability) or the nature of the response after booking, leaving some behavioral aspects undisclosed.
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 three short sentences, each carrying essential information: the core action, the preview/booking toggle, and the login requirement. There is no redundant or extraneous text, making it efficient and well-structured.
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 lack of an output schema and the tool's side-effectful nature, the description could be more complete by explaining what the tool returns on success or failure. It covers the main workflow and login prerequisite but leaves the agent uncertain about response formats and exceptional cases.
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 provides complete descriptions for all six parameters, including formats and semantics for date, time, partySize, restaurantId, confirm, and specialRequests. The description does not add new parameter details beyond what the schema already states; it only repeats the confirm flag's behavior, so it adds minimal value above 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 uses the specific verb 'Book' and identifies the resource as 'restaurant reservation on OpenTable', making the tool's purpose unmistakable. It also clarifies the confirm parameter's role in preview vs actual booking, which distinguishes it from related tools like availability checking or cancellation.
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 gives clear context that this tool is for booking or previewing a reservation, and notes the login requirement as a prerequisite. However, it does not explicitly state when to prefer this tool over alternatives such as opentable_check_availability or opentable_cancel_reservation, so it falls short of explicit when/when-not guidance.
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 provided, the description carries full responsibility for disclosing behavior. It clearly states the irreversible nature ('This action cannot be undone.') and explains the preview vs. execute mechanism. However, it omits potential error conditions or side effects, which would have pushed the score to 5.
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 three concise sentences, each with a distinct purpose: state the action, explain parameter usage, and warn about irreversibility. There is no filler or redundancy, and the most critical information is front-loaded.
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?
For a cancellation tool with two required parameters and no output schema, the description covers essential context: what it does, how to use the confirm flag for preview, and the permanence of the action. It does not mention prerequisites like authentication or post-cancellation behavior, but these are less critical for invoking the tool 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?
The input schema already comprehensively describes both parameters (100% coverage), including the preview/cancel semantics for 'confirm' and the source of 'reservationId'. The description's mention of 'confirm=false to preview' adds no new information beyond the schema, meeting the baseline for high 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 starts with a clear verb ('Cancel') and specific resource ('existing reservation'), unambiguously defining the tool's function. It also distinguishes itself from sibling tools like opentable_make_reservation and opentable_get_reservations by its unique cancellation purpose.
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 usage context by explaining the two-step process: 'Set confirm=false to preview, confirm=true to actually cancel.' This guides the user on how to use the confirm parameter. It does not mention alternative tools, but cancellation has no direct sibling, making the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it returns login status and instructions if not authenticated, which conveys the tool's behavior. However, it does not explicitly state that it is read-only or has no side effects, which is a minor gap for a status/check tool.
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, front-loaded with the main purpose, and includes a useful usage instruction without unnecessary filler. Every word earns its place.
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?
For a simple status check with no parameters and no output schema, the description provides the essential information: what it does, what it returns, and when to call it. It could add more detail about the exact return format or next steps, but it adequately covers the tool's operation.
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 input schema is empty (0 parameters) and schema coverage is 100%, so the description is not required to explain parameters. The baseline for 0 parameters is 4, and the description does not miss any parameter info.
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 'Check if the user is logged in to OpenTable,' which clearly identifies a specific verb and resource. This distinguishes it from sibling tools like opentable_login and opentable_logout, which perform different actions.
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 explicitly instructs 'Call this before any other OpenTable operations,' providing clear when-to-use guidance. It does not discuss when not to use it or explicitly name alternatives, but the context is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses the core behavior (returns URL and instructions) and user authentication, but does not mention side effects, state changes, or how the URL is consumed. This is adequate but not highly transparent.
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 concise sentences, front-loaded with purpose, then condition. No filler or redundant details.
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?
For a zero-parameter tool with no output schema, the description is reasonably complete: it states what is returned (URL and instructions) and when to use it. Could specify return format more explicitly, but the essential context is present.
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 zero parameters, so the empty schema covers everything. Baseline for 0 parameters is 4, and the description implies no input required. It does not introduce any separate parameter semantics, which 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?
The description clearly states a specific action ('Get the OpenTable login URL and instructions') and the resource (OpenTable authentication). It distinguishes from siblings by specifying the trigger condition 'when opentable_status returns not logged in.'
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 provides a usage condition referencing opentable_status, and the alternative (when already logged in) is implicitly clear. This is actionable guidance for when to invoke the tool.
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 provided, the description carries the full burden of behavioral disclosure. It transparently states that it clears stored session cookies, which implies a mutation of local state. It could add more detail about idempotency or behavior when no cookies exist, but the primary effect is clearly 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?
The description is exceptionally concise, consisting of two short sentences. The action is front-loaded in the first sentence, and the usage context is in the second. There is no wasted text or repetition of schema 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?
Given the tool's simplicity—no parameters, no output schema, and no annotations—the description is fully complete. It explains what the tool does, when to use it, and the effect on authentication state. No additional context seems necessary for an agent to invoke it 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?
The tool has zero parameters, and the input schema is an empty object. According to the rubric, a baseline of 4 applies for zero-parameter tools. The description adds no parameter information, which is appropriate since there is nothing to explain.
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 with a specific verb and resource: 'Clear the stored OpenTable session cookies.' It also explicitly states the purpose: 'Use this to log out or reset the authentication state,' which distinguishes it from sibling tools like opentable_login and opentable_status.
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 clear guidance on when to use the tool: 'Use this to log out or reset the authentication state.' It gives a direct usage context, though it does not explicitly mention alternatives or when not to use it. Given the tool's simplicity, this is adequate.
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:

[![mcp_opentable MCP server](https://glama.ai/mcp/servers/noahelson208-prog/mcp_opentable/badges/card.svg)](https://glama.ai/mcp/servers/noahelson208-prog/mcp_opentable)

Score Badge

Copy to your README.md:

[![mcp_opentable MCP server](https://glama.ai/mcp/servers/noahelson208-prog/mcp_opentable/badges/score.svg)](https://glama.ai/mcp/servers/noahelson208-prog/mcp_opentable)

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/noahelson208-prog/mcp_opentable'

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