Click on "Deploy 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 discloses substantial non-obvious behavior beyond annotations: reading the Cloudflare Turnstile token via the bridge, requiring an open tab, making NO network call without confirm: true, and booking only with confirm: true. This aligns with readOnlyHint=false and idempotentHint=false, with no contradiction.
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?
Three sentences with the core action front-loaded: each sentence earns its place by covering the tab prerequisite, the dry-run behavior, and the confirm gating. There is no filler or redundant detail.
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?
It covers the critical operational details needed to call the tool safely: the required tab, the Turnstile mechanism, and the confirm gate. It omits success/error behavior and return expectations, which is more noticeable given there is no output schema, but the essential prerequisites are fully specified.
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%, and the schema already documents every parameter clearly, including the confirm preview behavior. The description's mention of the dry-run mirrors the schema's confirm description and adds no new semantic meaning beyond what the schema provides.
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 opens with the specific action 'Create a restaurant booking' and then differentiates the operation from its siblings by explaining the dry-run vs confirmed booking behavior. It is unmistakably distinct from cancel/modify/list tools and 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?
It gives clear, concrete usage context: a book.easytable.com tab must be open and loaded, and confirm: true is required to actually book rather than preview. However, it does not explicitly name sibling alternatives or state when to prefer them, so it falls just short of full routing guidance.
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'. Read-only, no auth required. Call this when a real tool fails and you want to know which hop broke.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it states no auth is required, explains that it distinguishes 'bridge never came up' from 'extension not connected' from 'real book.easytable.com-side problem,' and lists the returned diagnostic fields. This gives an agent a rich behavioral picture without conflicting 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 compact sentences carry the operation, outputs, read-only/no-auth facts, and the exact failure-directed use case. No filler or repeated schema details.
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?
With no output schema, the description supplies the return semantics in plain language and disambiguates failure categories. For a zero-parameter healthcheck tool, an agent has everything needed to invoke and interpret it correctly.
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?
There are zero parameterschers, so the schema needs no explanation. The baseline of 4 applies; the description adds context about what the tool probes, which compensates for the absence of any input contract.
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 names a specific verb ('round-trips'), a concrete resource ('/robots.txt'), and the exact diagnostic outputs (role, port, version, link state, timing, hint). It clearly distinguishes this diagnostic tool from the booking/list siblings.
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?
It explicitly says when to call it: 'when a real tool fails and you want to know which hop broke.' It does not name a non-diagnostic alternative, but none of the siblings serve this purpose, so the guidance is clear enough.
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 declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, so the agent knows this is a mutating, non-idempotent operation. The description adds valuable behavioral context beyond annotations: the dry-run preview behavior, the fact that no network call is made without confirm:true, and the Turnstile token requirement. It doesn't detail side effects or error behavior, but the preview/confirm distinction is a significant behavioral disclosure.
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?
Three sentences with zero waste. The core action is front-loaded, the workflow dependency (find_bookings) is stated, and the critical confirm behavior is explained. Every sentence earns its place.
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 14-parameter mutation tool with no output schema, the description covers the essential workflow: where to get the id, the token requirement, and the confirm gate. It doesn't describe the return value or error cases, but the schema covers parameters and the description covers the critical behavioral gate. Slightly more detail on what the preview returns would push this to 5.
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 100%, so the schema already documents all 14 parameters. The description adds meaning for the key parameters (existing, confirm) by explaining their roles in the workflow, but it doesn't add much beyond the schema for the rest. Baseline 3 is appropriate when the schema carries the heavy lifting.
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 ('Modify') and resource ('existing booking'), and enumerates the modifiable fields (date/time/party size/details). It also distinguishes itself from create and find_bookings by referencing them explicitly, so an agent can tell it apart from siblings without opening the schema.
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 gives explicit when-to-use guidance: get the existing booking id from easytable_find_bookings, and it explains the confirm flag semantics (dry-run preview without confirm, applies change with confirm). It also references the Turnstile token requirement, which is a clear prerequisite. This is strong usage guidance.
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.
v0.4.1easytable_create_booking1 field changedInput schema / properties / email / patternPrevious value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"easytable_modify_booking1 field changedInput schema / properties / email / patternPrevious value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"v0.0.0easytable_cancel_bookingeasytable_create_bookingeasytable_find_bookingseasytable_healthcheckeasytable_list_dateseasytable_list_timeseasytable_list_typeseasytable_modify_bookingScored across 8 tools
Each tool has a clearly distinct purpose: availability lookup (list_dates/list_times/list_types), booking lifecycle (create/find/modify/cancel), and diagnostics (healthcheck). No two tools overlap in function.
Most tools follow a consistent verb_noun pattern (list_dates, create_booking, cancel_booking, find_bookings, modify_booking). The single-word healthcheck deviates slightly but is still understandable and not confusing.
Eight tools is well-scoped for a restaurant booking MCP server. The count covers the core booking lifecycle, availability checks, and a useful diagnostic without bloat.
The tool surface covers the full booking workflow: discover types/dates/times, create bookings, look up existing bookings by mobile, modify, and cancel. The healthcheck tool also fills the obvious debugging gap for bridge-related failures.
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.
