An MCP server that browses and manages easyTable restaurant reservations by riding your signed-in book.easytable.com browser tab through the ContextMint Bridge (no login needed — the restaurant is identified by its id).
Discover availability (read): easytable_list_types for bookable areas/types, easytable_list_dates for dates by area + party size, and easytable_list_times for open HH:MM slots.
Find bookings (read): easytable_find_bookings looks up existing reservations by mobile number and returns booking ids and summaries.
Create a booking (write): easytable_create_booking reserves a table with name, mobile, date, time, party size and optional email/comment/company/event — reading the Cloudflare Turnstile token from an open widget tab.
Modify a booking (write): easytable_modify_booking replaces a booking's date/time/party size/details (email, comment and company must be passed explicitly; opt-in is reset).
Cancel a booking (write): easytable_cancel_booking cancels by booking id + mobile.
Diagnose connectivity (read): easytable_healthcheck round-trips a public URL to report bridge role/port/version, link state and where a failure occurred.
Safety: every write requires confirmation — an elicitation prompt where supported, otherwise a two-step preview + single-use confirmToken (MCP_CONFIRM_MODE of ask-user, auto or refuse), with token TTL and signing key configurable.
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 (confirmed) — make a reservation |
| write (confirmed) — change a reservation |
| write (confirmed) — cancel a reservation |
| read — bridge connection status |
Related MCP server: Rizerve MCP Server
Every write asks you to confirm it first. A client that can show a
confirmation prompt (Claude Code) shows one. Elsewhere the first call makes no
network call and returns a preview plus a confirmToken; only a repeat call
with the same arguments and that token books, changes or cancels. The token is
single-use, and a changed argument invalidates it.
variable | default | |
|
| What a write does on a client that cannot show a confirmation prompt (claude.ai, Claude Desktop). |
|
|
|
|
| How long a token stays valid. |
| random per process | Signing key; set it only if tokens must survive a server restart. |
Install the ContextMint Bridge browser extension from its
releases:
in Chrome, unzip the contextmint-bridge-chrome-*.zip asset and load it
unpacked (chrome://extensions → Developer mode → Load unpacked); in
Safari, it ships inside the ContextMint app, which has no public download
link yet, so use Chrome for now. ContextMint Bridge is the fetchproxy browser extension under its
new name, from the same maintainer — fetchproxy's own
README points to it.
Its source is public at
nullnet-app/contextmint-bridge:
build it yourself, or check a release zip against the .sha256 file
published beside it
(shasum -a 256 -c contextmint-bridge-chrome-<version>.zip.sha256).
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 ContextMint Bridge.
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). Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). The first call makes NO network call.
| 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). | |
| bookingId | Yes | Booking id from easytable_find_bookings. | |
| confirmToken | No | ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (destructive, idempotent, open-world); the description adds the critical behavioral detail that the first call makes NO network call, that a confirmation prompt or a preview+confirmToken round-trip gates the actual cancellation, and that the token must never be invented or reused.
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?
Front-loads the action, then the prerequisite lookup, then the confirmation mechanics. Four tight sentences with no filler, every one carrying load.
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 destructive mutation with no output schema and a non-trivial two-phase confirmation protocol, the description covers the gating behavior thoroughly. It stops short of describing the success/error response shape, but the key operational hazards are addressed.
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%, so the baseline is 3, but the description adds real meaning by explaining that id/mobile come from the booking lookup and by narrating exactly when confirmToken is passed (only after explicit user approval on the repeat call).
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?
Opens with a specific verb+resource ('Cancel an existing booking'), which cleanly distinguishes it from the sibling create/modify booking tools. The scope is unambiguous even 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?
Explicitly routes the agent through easytable_find_bookings to obtain the bookingId, noting it needs the mobile the booking was made with. It also spells out the confirmation precondition and the fallback path when no elicitation client is present.
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. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). The first call makes NO network call.
| 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. | |
| persons | Yes | Party size. | |
| confirmToken | No | ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: reads a Cloudflare Turnstile token via a bridge, requires a signed-in widget tab, prompts for confirmation, and critically discloses that the first call makes no network call and returns a preview + confirmToken. This is exactly the non-obvious operational detail the annotations do not carry.
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?
Front-loads the core purpose, then layers prerequisites and the confirmation protocol. It is dense and every sentence is load-bearing, though the confirm-flow explanation is lengthy relative to a single-tool description.
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 13-parameter mutation with no output schema, the description covers prerequisites, confirmation, and the no-network first call. It does not describe failure modes (e.g., unavailable slot, missing/mismatched token beyond the outline) or the eventual success response, leaving a small gap.
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 parameters are already well documented (id, date, time, type, confirmToken, etc.). The description adds linkage context (id as the widget link id, confirmToken as the phase-1 token) but no syntax or format detail 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Create a restaurant booking') and clearly distinguishes itself from siblings like easytable_modify_booking and easytable_cancel_booking. An agent immediately knows this is the booking-creation tool.
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?
Gives concrete prerequisites (a loaded book.easytable.com/book/?id=<id> tab must be open) and explains the confirmation flow, including the MCP_CONFIRM_MODE fallback. It does not explicitly state when to prefer this over siblings (e.g., availability-check tools), but the operational context is strong.
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 already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context about what is returned (booking id and summary) and connects it to cancellation, but it does not disclose things like ordering, pagination, or match behavior. This is adequate but not rich.
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 compact sentence that front-loads the core action, includes the key parameter, and states the return value. No filler or repetition exists.
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 read-only lookup tool with 3 fully documented parameters, the description covers the purpose, the key input, and the return value. It omits exact response structure, but the summary of 'booking id plus a summary' is enough for an agent to decide to call it, especially with no output schema and straightforward behavior.
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 fully documents all three parameters. The description reinforces the 'mobile' parameter's purpose but does not add meaning 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') and resource ('restaurant's existing bookings made with a given mobile number'), clearly distinguishing this tool from sibling tools like create, modify, cancel, and list date/type/time tools. It also states what is returned (booking id and summary), giving the agent an actionable purpose.
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 the tool: when you need to find existing bookings by mobile numberware, and it explains the id is 'for easytable_cancel_booking', which hints at a downstream use case. However, it does not explicitly state when not to use it or how it compares against other lookup siblings like easytable_list_types or easytable_list_dates.
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 ContextMint Bridge (your signed-in browser tab) 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 'this browser can't serve a capability' 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?
Annotations only cover safety/read/idempotency, but the description goes well beyond them: it discloses the exact diagnostic fields returned, the four distinguishable failure states, and that the call is read-only with no auth required. That is exactly the kind of behavioral context annotations cannot carry.
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?
Front-loads the core action, then the returned data, then the trigger condition. The middle enumeration sentence is comma-heavy but every clause adds distinct diagnostic value, so it is dense rather than padded.
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 parameters and no output schema, the description fully carries the burden by describing both the invocation and the return payload, including how to interpret failure modes. Nothing an agent needs in order to call or interpret this tool is missing.
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 tool takes zero parameters, so there are no parameter semantics to explain and the baseline of 4 applies. Nothing in the description is needed here, and nothing is missing.
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?
States a specific action (round-trip /robots.txt through ContextMint Bridge) and enumerates exactly what it produces (role, port, version, extension link state, elapsed time, hints). It is unmistakably a diagnostics tool and trivially distinguishable from the booking-oriented 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?
Explicitly tells the agent when to call it: 'when a real tool fails and you want to know which hop broke.' That trigger is clear and actionable. It stops short of naming exclusions or alternatives (e.g., when NOT to reach for it), so it lands just below the full 5.
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?
The readOnlyHint annotation already communicates that this is a safe read operation, and the description adds useful behavioral detail by stating that each entry contains an ISO date and an availability flag. This goes beyond the annotation by describing the return shape.
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 only two sentences long, with no redundant wording. The primary action is front-loaded, and the output format is explained efficiently.
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 read-only list operation, the description is complete enough: it states the required context, output shape, and availability semantics. The schema handles the remaining parameter documentation, and no output schema means the explicit return description is sufficient.
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 documents id, lang, and type, and the description loosely maps 'restaurant area' to type and 'party size' to persons. However, it does not add detail about the persons parameter's meaning or constraints 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 clearly states a specific action and resource: 'List bookable dates for a restaurant area and party size.' It also describes the output, which helps distinguish it from sibling tools like list_types and list_times, though it does not explicitly name those alternatives.
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 the tool is used when date availability is needed for a given area and party size, but it does not explicitly explain when to use this rather than easytable_list_times or other sibling tools. No exclusions or alternative routing are provided.
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 is consistent with the readOnlyHint annotation by describing a read-only listing operation. It also adds useful behavioral detail beyond the annotation: times are returned as HH:MM. No destructive or hidden behavior is suggested.
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 redundant phrasing. The core purpose is front-loaded, and the output format detail is placed directly after the main action.
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 tool's inputs and the time format, and the read-only annotation covers safety. Since there is no output schema, mentioning 'Times are returned as HH:MM' partially fills the return-value gap, though it does not describe the exact response container or empty-result behavior.
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 schema already documents most parameters well (id, date, lang, type), and the description adds meaning to the otherwise undocumented persons parameter by calling it 'party size'. It also clarifies that 'type' refers to a restaurant area. With 80% schema coverage, this is a meaningful but not critical addition.
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 ('List') and a clear resource: available time slots for a restaurant area, date, and party size. It also adds the output format (HH:MM), which disambiguates this from sibling tools like easytable_list_types and easytable_list_dates.
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 makes the tool's purpose clear: use it when you need available time slots given area, date, and party size. It does not explicitly explain when not to use it or name an alternative like easytable_find_bookings, but the context is strong enough for an agent to infer the appropriate usage.
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 include readOnlyHint=true, which the description does not explicitly restate but does not contradict. The description says it returns type ids but does not mention whether the output is sorted, paginated, or includes area names, which could be useful. Given the annotation covers read-only nature, a 2 is appropriate as it adds minimal behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, and it front-loads the essential purpose and the key return value (type ids). It is concise and well-structured, though it could mention the lang parameter's effect but not necessary.
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 only 2 parameters with full schema coverage and readOnlyHint annotation, the description is mostly complete. It clearly states the purpose and return type usage. Missing details like whether the output is sorted or includes area names are minor for a listing tool, but it could be more 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 100%, so parameters are already well-documented. The description adds value by explaining that the id parameter is the restaurant id and that lang is optional, which aligns with schema. No extra semantics beyond schema are provided, so baseline 3 is appropriate.
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 and that it returns type ids for use in other availability tools. It distinguishes itself from siblings like list_dates and list_times, which are about dates and times respectively.
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 states the tool is for listing bookable areas/types and that the returned type ids are used by other availability tools, implying usage context. However, it does not explicitly state when not to use it or name alternatives, though siblings like list_dates and list_times are obvious alternatives.
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. The change replaces the whole booking: email, comment and company are required — pass the booking's current values to keep them (ask the user if unknown), or '' to clear them; the newsletter opt-in is reset. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). The first call makes NO network call.
| 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. | |
| Yes | Guest email. REQUIRED — the booking's current email, or '' to remove it (also drops the confirmation mail). | ||
| event | No | Optional event id. | |
| mobile | Yes | Guest mobile in E.164 (e.g. +46701234567). | |
| comment | Yes | Free-text note / special requests. REQUIRED — the booking's current comment (e.g. allergy notes), or '' to remove it. | |
| company | Yes | Company name. REQUIRED — the booking's current company, or '' for none. | |
| persons | Yes | Party size. | |
| existing | Yes | Id of the existing booking to modify (from easytable_find_bookings). | |
| confirmToken | No | ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the destructive/idempotent/write profile; the description adds substantial behavior beyond them — whole-booking replacement semantics, required-field retention rules, that '' clears a field, that a blank email drops the confirmation mail, that the newsletter opt-in resets, and that phase 1 makes no network call. This is exactly the extra context a mutation tool needs.
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?
Front-loads what the tool does, then the id source, then the replace semantics, then the confirmation flow. It is long and parenthetically dense, but nearly every clause carries operational information rather than filler.
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, 11-required destructive mutation with no output schema, the description covers the auth/token path, the id source, the full-replace hazard, and the two-phase confirmation return contract (preview + confirmToken), so an agent can complete a correct call sequence.
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%, so the schema already documents each field; the description nonetheless adds cross-parameter meaning the schema cannot convey — that email/comment/company are required in full-replace mode and must carry current values, and that confirmToken is a phase-2-only argument tied to a preview. Above the 3 baseline for genuine added semantics.
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?
Opens with a precise verb+resource ('Modify an existing booking') and enumerates the mutable scope (date/time/party size/details), which cleanly separates it from easytable_create_booking and easytable_cancel_booking. An agent can identify the tool 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?
Explicitly routes the agent to easytable_find_bookings for the booking id, states that create-like Turnstile token handling applies, and spells out the when/when-not rules for confirmToken ('never on the first call, never invented, never reused', ignored when elicitation exists). Nothing is left to inference.
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.
v1.2.0easytable_cancel_booking2 fields changedInput schema / properties / confirmRemoved value: -{
- "description": "Must be true to proceed. Without this, the tool returns a preview.",
- "type": "boolean"
-}Input schema / properties / confirmTokenAdded value: +{
+ "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+ "type": "string"
+}easytable_create_booking2 fields changedInput schema / properties / confirmRemoved value: -{
- "description": "Must be true to proceed. Without this, the tool returns a preview.",
- "type": "boolean"
-}Input schema / properties / confirmTokenAdded value: +{
+ "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+ "type": "string"
+}easytable_modify_booking2 fields changedInput schema / properties / confirmRemoved value: -{
- "description": "Must be true to proceed. Without this, the tool returns a preview.",
- "type": "boolean"
-}Input schema / properties / confirmTokenAdded value: +{
+ "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+ "type": "string"
+}v1.1.3easytable_modify_booking8 fields changedInput schema / properties / comment / descriptionPrevious value: -"Free-text note / special requests."New value: +"Free-text note / special requests. REQUIRED — the booking's current comment (e.g. allergy notes), or '' to remove it."Input schema / properties / company / descriptionPrevious value: -"Optional company name."New value: +"Company name. REQUIRED — the booking's current company, or '' for none."Input schema / properties / email / anyOfAdded value: +[
+ {
+ "format": "email",
+ "pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+ "type": "string"
+ },
+ {
+ "const": "",
+ "type": "string"
+ }
+]Input schema / properties / email / descriptionPrevious value: -"Guest email."New value: +"Guest email. REQUIRED — the booking's current email, or '' to remove it (also drops the confirmation mail)."Input schema / properties / email / formatRemoved value: -"email"Input schema / properties / email / patternRemoved 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,}$"Input schema / properties / email / typeRemoved value: -"string"Input schema / requiredPrevious value: -[
- "id",
- "type",
- "date",
- "time",
- "persons",
- "name",
- "mobile",
- "existing"
-]New value: +[
+ "id",
+ "type",
+ "date",
+ "time",
+ "persons",
+ "name",
+ "mobile",
+ "email",
+ "comment",
+ "company",
+ "existing"
+]v1.0.0easytable_cancel_booking1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"easytable_create_booking1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"easytable_find_bookings1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"easytable_healthcheck1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"easytable_list_dates1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"easytable_list_times1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"easytable_list_types1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"easytable_modify_booking1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"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 targets a distinct booking lifecycle action or availability query; create/modify/cancel/find are clearly differentiated, and list_dates/list_times/list_types have separate resource scopes. healthcheck is a diagnostic outlier but clearly separate from booking operations.
All tools use the easytable_ prefix and snake_case; booking actions follow verb_noun (cancel_booking, create_booking, etc.) and availability tools follow list_noun. healthcheck is a minor deviation as a single compound noun rather than verb_noun.
8 tools is well-scoped for a restaurant booking integration, covering booking lifecycle, availability lookups, and diagnostics without bloat. Each tool has a clear role and earns its place.
Covers create, modify, cancel, find bookings, and availability listing (types/dates/times) plus healthcheck. Minor gap: no get_booking tool to fetch full booking details (email/comment/company) needed by modify, though find_bookings summary plus user prompting may suffice.
MCP server for Meitre restaurant reservations.
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
Official MCP server for MAQAMI, a hotel and flight booking platform with 3M+ hotels. Search live hotel rates and flights, look up places, airports and hotel details, then prebook and book. Remote Streamable HTTP endpoint, no API key required.
REST-to-MCP for UK hospitality. Safety proxy: circuit-breakers, rate limits, whitelists. Apache 2.0.
