Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@easytable-mcp list available time slots for restaurant 123, 2 people, tomorrow"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for easyTable restaurant reservations. easyTable is a
restaurant table-booking system with a public per-restaurant widget at
https://book.easytable.com/book/?id=<restaurantId>.
Every request rides the user's own signed-in, Cloudflare-cleared
book.easytable.com browser tab via the
@fetchproxy/server bridge — the
site blocks server-side requests, and there is no login (the restaurant is
identified by its id).
This project was developed and is maintained by AI (Claude Code). Use at your own discretion.
Tool | Kind |
| read — bookable areas/types for a restaurant |
| read — bookable dates for an area + party size |
| read — available time slots |
| read — look up bookings by phone number |
| write (confirm-gated) — make a reservation |
| write (confirm-gated) — change a reservation |
| write (confirm-gated) — cancel a reservation |
| read — bridge connection status |
Writes are confirm-gated: without confirm: true they return a dry-run
preview and make no network call.
Related MCP server: eventin-mcp-server
Install the fetchproxy browser extension.
Open a booking widget in Chrome: https://book.easytable.com/book/?id=<id>
and let it finish loading.
The first tool call prints a one-time pair code to approve in the extension.
create and modify additionally read the widget's Cloudflare Turnstile token
from the loaded confirm step, so a booking-widget tab must be open when you
confirm one.
npm install
npm run build
npm testSee docs/EASYTABLE-API.md for the reverse-engineered request/response shapes
and CLAUDE.md for architecture notes.
MIT
Cancel an existing booking. Look up the booking id first with easytable_find_bookings (it needs the mobile the booking was made with). Without confirm: true it returns a dry-run preview and makes NO network call; with confirm: true it cancels.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Restaurant id — the `id` in a book.easytable.com/book/?id=<id> link. | |
| mobile | Yes | Mobile the booking was made with, E.164 (e.g. +46701234567). | |
| confirm | No | Must be true to proceed. Without this, the tool returns a preview. | |
| bookingId | Yes | Booking id from easytable_find_bookings. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and idempotentHint=true. The description adds that without confirm, no network call is made (dry-run), and with confirm, cancellation happens. It also clarifies the need for the mobile number. This provides useful behavioral context beyond annotations, though it does not elaborate on potential side effects like emailed confirmations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states purpose and prerequisite, second details the confirm parameter's effect. No extraneous information, front-loaded with the core action. Every sentence serves a distinct purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, full schema coverage, and no output schema, the description adequately covers what the tool does, how to use it, and the critical confirm behavior. It could optionally describe what the dry-run preview looks like, but overall it is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all four parameters. The description adds value by explaining the functional difference when confirm is true vs false (dry-run vs actual cancellation) and by emphasizing the need for the mobile used during booking. This enriches the schema's static descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel an existing booking' and instructs to look up the booking id using a sibling tool. It distinguishes itself from other tools like create, modify, and list by specifying cancellation as its sole function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (to cancel), what prerequisite is needed (booking id from find_bookings), and how the confirm parameter controls behavior: without it, a dry-run preview is returned; with confirm: true, actual cancellation occurs. This provides 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.
Create a restaurant booking. Reads the Cloudflare Turnstile token from your signed-in booking-widget tab (via the bridge) and submits it with the reservation — so a book.easytable.com/book/?id= tab must be open and loaded. Without confirm: true it returns a dry-run preview and makes NO network call; with confirm: true it books.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Restaurant id — the `id` in a book.easytable.com/book/?id=<id> link. | |
| date | Yes | Booking date, ISO YYYY-MM-DD (from easytable_list_dates). | |
| lang | No | Widget language code (en, se, da, …). Defaults to en. | en |
| name | Yes | Guest name on the booking. | |
| time | Yes | Time slot HH:MM (from easytable_list_times). | |
| type | Yes | Booking area/type id from easytable_list_types. | |
| No | Guest email. | ||
| event | No | Optional event id. | |
| mobile | Yes | Guest mobile in E.164 (e.g. +46701234567). | |
| comment | No | Free-text note / special requests. | |
| company | No | Optional company name. | |
| confirm | No | Must be true to proceed. Without this, the tool returns a preview. | |
| persons | Yes | Party size. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the exact behavioral difference between confirm false (dry-run, no network call) and confirm true (actual booking). It also discloses the prerequisite of the booking-widget tab, adding significant transparency about side effects and required state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 sentences) with front-loaded key information: purpose, prerequisite, and confirm behavior. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the key workflow and prerequisites well, but lacks details on return values and error handling. Since there is no output schema, more information on what the tool returns (especially the preview format) would be helpful. The description is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all 13 parameters (100% coverage). The tool description adds high-level context but does not enhance individual parameter meaning. A score of 3 is appropriate given the schema already handles this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Create a restaurant booking') and distinguishes it from siblings by detailing the workflow (Turnstile token, dry-run vs confirm). This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context about prerequisites (open tab with booking widget) and explains when to use confirm:true vs confirm:false. While it does not explicitly compare to sibling tools, the guidance is clear enough for an AI agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a restaurant's existing bookings made with a given mobile number. Returns each booking's id (for easytable_cancel_booking) plus a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Restaurant id — the `id` in a book.easytable.com/book/?id=<id> link. | |
| lang | No | Widget language code (e.g. en, se, da, de, fr). Defaults to en. | en |
| mobile | Yes | Mobile number the booking was made with, in E.164 (e.g. +46701234567). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds that it returns booking ids and a summary, providing output context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, focused sentences with no redundant information. Efficiently conveys the essential purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description mentions the return includes booking ids and a summary, it lacks detail on the summary structure, potential multiple results, or error handling. Could be more complete given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). The description adds no additional meaning beyond what is already in the schema, so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (look up), resource (restaurant's existing bookings), and filter (mobile number). It also mentions the returned id is for use with easytable_cancel_booking, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (by mobile number) and connects to cancellation, but doesn't explicitly state when not to use or provide alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Round-trips a small public book.easytable.com URL (/robots.txt) through the fetchproxy bridge and returns diagnostics: the bridge's role (host/peer/null), port, version, the extension link (linked / pair pending / not attached / never answered), the elapsed round-trip time, and a plain-English hint distinguishing 'bridge never came up' from 'extension not connected' from 'real book.easytable.com-side problem'. Call this when a real tool fails and you want to know which hop broke. Read-only, no auth required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing that no auth is required, that the operation is read-only, and exactly what diagnostics are returned, including role, port, version, extension link state, elapsed time, and failure-mode hints. This gives an agent a full behavioral picture without opening a schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense sentence plus a crisp usage directive. Every element earns its place: what is round-tripped, what diagnostics are returned, failure-mode differentiation, and when to call. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description thoroughly enumerates the return diagnostics and explains the intended troubleshooting use case. The tool has no parameters, so the only missing context would be around edge-case behavior, which is already addressed by the plain-English hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, there is nothing for the description to explain. The baseline of 4 applies, and the description appropriately includes no misleading parameter information, even confirming that no auth is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: round-trips a known URL through the fetchproxy bridge and returns diagnostics. It is clearly distinct from the sibling booking/list tools, which all relate to Easytable data operations rather than bridge health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to call: 'Call this when a real tool fails and you want to know which hop broke.' This gives the agent a clear trigger condition and differentiates it from normal business operations, making the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bookable dates for a restaurant area and party size. Each entry has an ISO date and whether it is available.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Restaurant id — the `id` in a book.easytable.com/book/?id=<id> link. | |
| lang | No | Widget language code (e.g. en, se, da, de, fr). Defaults to en. | en |
| type | Yes | Booking area/type id from easytable_list_types. | |
| persons | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, and the description does not contradict this. It adds that results include ISO dates and availability, providing some behavioral context beyond the annotation, but does not elaborate on other behaviors like pagination or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that convey the core purpose and result format with no unnecessary words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward listing tool with readOnly annotations and a simple response (dates with availability), the description is largely sufficient. It lacks output format details but the response is adequately implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema coverage, the description adds no additional meaning to the parameters beyond what is in the schema. The baseline of 3 is appropriate as the schema already documents most parameters, but the description does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists bookable dates for a specific restaurant area and party size, and mentions each result includes ISO date and availability. This distinguishes it from sibling tools like list_times or list_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives. While the context suggests it's used after obtaining area IDs from easytable_list_types, the description does not state this or provide any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available time slots for a restaurant area, date, and party size. Times are returned as HH:MM.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Restaurant id — the `id` in a book.easytable.com/book/?id=<id> link. | |
| date | Yes | Date to check, ISO YYYY-MM-DD (from easytable_list_dates). | |
| lang | No | Widget language code (e.g. en, se, da, de, fr). Defaults to en. | en |
| type | Yes | Booking area/type id from easytable_list_types. | |
| persons | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation, confirming a read-only operation. It adds the return format (HH:MM) but does not disclose other behavioral traits like error handling or rate limits. With annotations already covering safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. It front-loads the action and essential information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description usefully states the return format (HH:MM). It does not cover edge cases like no available slots or error responses, but for a simple listing tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema documents most parameters. The description summarizes key parameters (restaurant area, date, party size) but does not add meaning for the 'persons' field (which lacks a schema description) or the 'lang' parameter. It compensates slightly by mentioning party size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'time slots' with specific parameters (area, date, party size). It distinguishes from sibling tools like easytable_list_dates and easytable_list_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after obtaining dates and types, but does not explicitly state when to use or when not to use this tool versus alternatives. No exclusion criteria or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the bookable areas/types for a restaurant (e.g. "Boka Inne", "Boka baren"). Returns each area's type id for use in the other availability tools.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Restaurant id — the `id` in a book.easytable.com/book/?id=<id> link. | |
| lang | No | Widget language code (e.g. en, se, da, de, fr). Defaults to en. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by specifying that the tool returns type IDs for use elsewhere. However, it does not disclose potential limitations like pagination or additional behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'List' and concisely conveys the purpose and output usage without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no output schema), the description provides a clear statement of what is returned (type IDs) and how they are used. It could be more detailed about the return structure, but it's sufficient for a basic list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already described. The description does not add any new semantic information about the parameters beyond what is in the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists bookable areas/types for a restaurant, specifying the verb 'list' and the resource 'bookable areas/types'. It distinguishes from sibling tools like easytable_list_dates and easytable_list_times by focusing on area types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the output is 'for use in the other availability tools', indicating it's a prerequisite. However, it does not explicitly state when not to use it or provide alternatives, though the siblings imply different list functionalities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify an existing booking (date/time/party size/details). Like create, it reads the Turnstile token from your signed-in widget tab. Get the existing booking id from easytable_find_bookings. Without confirm: true it returns a dry-run preview and makes NO network call; with confirm: true it applies the change.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Restaurant id — the `id` in a book.easytable.com/book/?id=<id> link. | |
| date | Yes | Booking date, ISO YYYY-MM-DD (from easytable_list_dates). | |
| lang | No | Widget language code (en, se, da, …). Defaults to en. | en |
| name | Yes | Guest name on the booking. | |
| time | Yes | Time slot HH:MM (from easytable_list_times). | |
| type | Yes | Booking area/type id from easytable_list_types. | |
| No | Guest email. | ||
| event | No | Optional event id. | |
| mobile | Yes | Guest mobile in E.164 (e.g. +46701234567). | |
| comment | No | Free-text note / special requests. | |
| company | No | Optional company name. | |
| confirm | No | Must be true to proceed. Without this, the tool returns a preview. | |
| persons | Yes | Party size. | |
| existing | Yes | Id of the existing booking to modify (from easytable_find_bookings). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, open-world, non-idempotent. The description adds critical behavioral details: the dry-run preview mode without confirm:true (no network call) and the need for a Turnstile token from the signed-in widget tab. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences plus a brief clause. Every sentence provides essential information without fluff, and the structure is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters and no output schema, the description covers the key behavioral aspects (dry-run, token requirement) but does not specify the output format or semantics. This is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds context beyond the schema for 'confirm' (dry-run) and 'existing' (source from easytable_find_bookings), improving understanding without repeating all parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies an existing booking, specifying the modifiable fields (date/time/party size/details). It is distinct from sibling tools like easytable_cancel_booking and easytable_create_booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to get the booking ID from easytable_find_bookings and the dry-run vs confirm behavior. It provides clear when-to-use guidance, though it does not explicitly discuss when not to use or alternatives beyond the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.0.0easytable_cancel_bookingeasytable_create_bookingeasytable_find_bookingseasytable_healthcheckeasytable_list_dateseasytable_list_timeseasytable_list_typeseasytable_modify_bookingEach tool targets a distinct stage of the booking workflow: discovery (types/dates/times), lookup (find_bookings), mutations (create/modify/cancel), and diagnostics (healthcheck). There is no real overlap or ambiguity between tools.
All tools use the easytable_ prefix and mostly follow verb_noun naming (list_types, create_booking, cancel_booking). The only minor deviation is healthcheck, which is a noun rather than a verb_noun pattern like check_health.
Eight tools is well-scoped for a restaurant booking server: availability discovery, booking lookup, booking create/modify/cancel, and health diagnostics. Each tool has a clear role and none feel redundant or excessive.
The toolset covers the full booking lifecycle: browse areas/types, check dates, check times, find bookings, create bookings, modify bookings, and cancel bookings. The healthcheck tool also addresses operational diagnostics, which is a thoughtful addition for a bridge-dependent workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Meitre restaurant reservations.
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
REST-to-MCP for UK hospitality. Safety proxy: circuit-breakers, rate limits, whitelists. Apache 2.0.
An MCP server that exposes functionalities to use Zomato's services.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/easytable-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
