Book tables at restaurants on the Loyalist network. No login; read availability, then book.
Scored across 5 tools
Each tool targets a distinct step in the reservation lifecycle: discovery (find_venues), availability lookup (get_availability), booking (book), read-back (get_reservation), and waitlist (join_waitlist). The descriptions explicitly draw the line between book and join_waitlist (a waitlist request 'is not a reservation'), so an agent is unlikely to misselect.
Four of five names follow a clear verb_noun pattern (find_venues, get_availability, get_reservation, join_waitlist). The lone bare verb 'book' is a minor deviation but is unambiguous and readable in context.
Five tools is well-scoped for a restaurant booking domain, with one tool per lifecycle stage and no redundant or filler operations. Each tool earns its place.
Discovery, availability, booking, read-back, and waitlist are covered, but there is no cancel or modify tool — the description admits a mistaken booking must be undone by the guest phoning the restaurant, which is a real dead end for an agent. The absence of any update/cancel path leaves a notable lifecycle gap.
Book a table. This takes a real table at a real restaurant.
Pass a `slot_id` from get_availability. Confirm the venue, date, time and party size
with the person before calling this, and do not call it speculatively: there is no
cancel tool, so a booking made by mistake has to be undone by the guest phoning the
restaurant.
Calling it twice with identical arguments is safe and returns the same reservation
rather than taking a second table. Changing the slot or the guest makes it a
different booking, so re-read availability rather than editing the arguments to
"retry".
`phone` is optional here but required by some venues; omitting it can come back as
`guest_field_required`. `note` reaches the restaurant as the reservation's note.
`source` is where you found this venue: if the restaurant's own website told you a
value to pass (in its markup or llms.txt), send it here so the restaurant can see its
own site drove the booking. Leave it out if you did not arrive through one.
`reservation_id` is for your own use, to read the booking back with get_reservation.
It is not a confirmation number the venue knows, so do not read it out to the guest:
tell them the restaurant, date, time and party size instead.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| Yes | |||
| phone | No | ||
| source | No | ||
| slot_id | Yes | ||
| last_name | Yes | ||
| first_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial real behavioral context beyond the annotations: there is no cancel tool, a mistaken booking must be undone by the guest phoning the venue, `phone` can fail with `guest_field_required`, and `reservation_id` is not a venue-known confirmation number. However, it states that 'calling it twice with identical arguments is safe and returns the same reservation rather than taking a second table', which asserts idempotent behavior while the annotation declares idempotentHint=false. That is a direct conflict with one hint, though the remaining hints (readOnlyHint=false, openWorldHint=true, destructiveHint=false) are consistent with the text.
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-loaded with purpose, then paragraph-per-concern (preconditions, idempotency, optional fields, identifier usage) with no filler sentences. It is on the long side for a tool description, but the length is justified by 7 parameters at 0% schema coverage and by genuinely non-obvious constraints.
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?
No output schema exists, yet the description still tells the agent what it gets back conceptually (a reservation, readable via get_reservation) and what to tell the guest instead of the reservation_id. Preconditions, failure modes, irreversibility and retry behavior are all covered, so an agent has what it needs to call this 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?
Schema description coverage is 0%, so the description carries the full burden, and it does: `phone` (optional here, required by some venues, error guest_field_required), `note` (reaches the restaurant as the reservation note), `source` (attribution back to the venue's own site/llms.txt, with an explicit omit condition), and `reservation_id` (for get_reservation read-back, explicitly not guest-facing). Only first/last/email are left implicit, and they are self-evident.
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 ('Book a table') and immediately scopes it ('takes a real table at a real restaurant'), which cleanly separates it from find_venues, get_availability and get_reservation. It even names the upstream dependency (slot_id from get_availability), so an agent can place it in the flow without opening a 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?
Gives explicit preconditions ('Confirm the venue, date, time and party size with the person before calling'), an explicit prohibition ('do not call it speculatively'), and the correct recovery path when arguments need to change ('re-read availability rather than editing the arguments to "retry"'). The when-not guidance is tied to a concrete consequence (no cancel tool).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restaurants bookable through this network, and what each one's system supports.
Returns every venue that has opted in, across restaurant groups. Two optional filters
narrow it, never widen it: `signup_form_id` to one website's venues when you found an
Orion signup embed on a restaurant's page, and `venue_id` to a single venue when
you already have its loyalist-venue-id (off a page's markup or a ReserveAction entry
point) and want just that one rather than listing them all and matching yourself.
Neither can reach a venue that has not opted in.
A venue with `bookable: false` has no reservation system connected and will return
no availability.
| Name | Required | Description | Default |
|---|---|---|---|
| venue_id | No | ||
| signup_form_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful non-obvious behavior: opted-in-only coverage across groups, filters can never reach non-opted-in venues, and bookable=false means no reservation system and no availability.
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 qualifies filters and the bookable caveat. The multi-line indented formatting is slightly heavier than needed, but every sentence contributes information about scope or semantics.
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 and no param descriptions in the schema, the description compensates well by describing what a result set contains, that it spans restaurant groups, and what bookable=false implies. It stops short of describing the full returned fields, but an agent has enough to call and interpret it.
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 0%, so the description carries the full burden. It defines both parameters precisely, explains the narrowing scope of each, and even tells the agent where the venue_id value comes from (page markup or a ReserveAction entry point).
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 and resource: returns every venue that has opted in across restaurant groups, with the bookable-network scope made explicit. It is immediately distinguishable from siblings like book, get_availability, and get_reservation, which are transactional rather than discovery 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?
Gives concrete when-to-use conditions for each filter: signup_form_id when you found an Orion signup embed, venue_id when you already have a loyalist-venue-id from markup or a ReserveAction entry point. It also states the filters only narrow, never widen. It does not explicitly name when to prefer a sibling tool over this one, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bookable times at one venue, on one date, for one party size.
`date` is the venue's own local calendar date, `YYYY-MM-DD`. Each slot carries a
`slot_id` to pass to book and a `starts_at` that is a full venue-local datetime, so
a service running past midnight is unambiguous without you having to infer the day.
An empty `slots` list means nothing is open on those terms, not that the venue is
closed. Try a different time, party size or date before telling someone it is full.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| venue_id | Yes | ||
| party_size | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, so the description wisely spends its budget on semantics: `date` is venue-local, `starts_at` is a full venue-local datetime to disambiguate post-midnight services, and an empty `slots` list means no availability rather than a closed venue. That last point materially changes how an agent reports results and is not derivable from any structured field.
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-loaded with the one-line purpose, then two tight paragraphs on date/slot semantics and empty-result handling. Every sentence adds value; slightly more prose than strictly needed, but no 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?
With no output schema, the description steps in to document the return shape (`slots`, `slot_id`, `starts_at`) and its empty-state meaning. Combined with annotation coverage of the safety profile, an agent has everything needed to call and interpret this 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 0%, so the description carries the burden. It fully specifies `date` (venue-local, YYYY-MM-DD) but says nothing about `venue_id` format/source or any constraint on `party_size` (bounds, minimum). Partial compensation, so a mid score.
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 opening line states a specific verb (bookable times) and its exact scope: one venue, one date, one party size. It also names the sibling tool `book` as the consumer of the returned `slot_id`, so an agent can place it in the workflow without opening other schemas.
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 context (call this before booking, pass `slot_id` to book) and an explicit interpretation rule for empty results, including a retry instruction. It stops short of naming alternative siblings (e.g. `join_waitlist`) for the empty case, leaving that inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one booking this credential made back from the venue.
Use it to confirm a booking landed. A `status` of `pending` means the venue has not
answered yet, not that it failed; treat anything you do not recognise as
non-terminal rather than reporting a failure.
| Name | Required | Description | Default |
|---|---|---|---|
| reservation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful semantics beyond that: 'pending' means unanswered, not failed, and unrecognized statuses should be treated as non-terminal. That prevents a real agent error.
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, front-loaded sentences; the core purpose leads and the status caveat follows. No filler, 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?
With no output schema, the description wisely pre-explains the ambiguous status field, which is the main thing an agent needs. The gap is the undocumented reservation_id argument, but otherwise the definition is complete for a simple read 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 description coverage is 0%, so the description carries the full burden for the single required parameter, yet it never mentions reservation_id, where it comes from, or its expected format. The agent must infer provenance from the sibling 'book' tool.
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 ('Read one booking') and scopes it to bookings made by this credential. Clearly distinct from siblings like book and get_availability, though the phrase 'back from the venue' is slightly informal rather than precise.
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 gives the use case ('Use it to confirm a booking landed') and adds interpretation guidance for status values. It does not name alternatives or state when not to use it, but the sibling set makes the intent unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask to be told if a table opens at a time the guest actually wants.
This is not a reservation and never becomes one by itself. The venue contacts the
guest if something frees up, so say that plainly rather than implying a table is
held.
Offer it whenever the guest cannot get a time that suits them, which is far more
often than a venue being completely full: someone who wants 7:30 and is offered
5:00 or 9:45 may well prefer to wait for 7:30. An empty get_availability is only
the most obvious case. Try other times, party sizes and dates first, then ask
whether they would rather wait than take a time that does not work. Record what
they wanted in `time_range`, not the time you found.
`date` is the venue's own local calendar date, `YYYY-MM-DD`. `time_range` is
required and is the window in the guest's words, like "7:00 PM - 9:00 PM" or
"7:00 PM"; ask the guest for it rather than guessing, because the venue works the
list by when people wanted to come. The email address is where the confirmation
goes, so it must be the guest's own.
Not every venue accepts these. One that does not refuses with a message saying so,
which is an answer, not an error to retry.
There is no reference number to give the guest, so the response is the only record
either of you gets. Confirm it back to them by the restaurant, date and time.
Mention the confirmation email only when `confirmation_sent` is true. When it is
false the request is still on the venue's list, the note simply did not go out, so
say they are on the list and that no email is coming rather than promising one.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| Yes | |||
| notes | No | ||
| phone | No | ||
| venue_id | Yes | ||
| last_name | Yes | ||
| first_name | Yes | ||
| party_size | Yes | ||
| time_range | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false; the description adds substantive context beyond that: no reference number is issued, the response is the only record, venue refusal is a valid answer rather than a retryable error, and it explains the confirmation_sent=true/false outcomes and what to tell the guest in each case. This is exactly the behavioural disclosure 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?
The purpose and the 'not a reservation' caveat are front-loaded, and most sentences carry operational guidance that earns its place. It is nonetheless long for the payload, with some repetition around the reservation framing ('not a reservation', 'rather than implying a table is held') that could be tightened.
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 does the work of explaining the return semantics (confirmation_sent, absence of a reference number) and the failure mode (venue refuses). For a mutating, non-idempotent tool it omits any warning about duplicate join attempts and says nothing about notes/phone, but overall an agent has enough to call and report 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?
Schema description coverage is 0%, so the description carries the full burden. It does cover date format ('venue's own local calendar date, YYYY-MM-DD'), time_range requiredness, sourcing and syntax examples, and that email must be the guest's own, but venue_id, party_size, first_name, last_name, notes and phone receive no explanation at all. Useful but clearly incomplete compensation for a 9-parameter schema.
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 opening states a specific verb and resource (ask to be told if a table opens) and the second sentence explicitly negates the nearest sibling behaviour: 'This is not a reservation and never becomes one by itself.' An agent can distinguish this from book and get_availability without opening either 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?
It gives explicit when-to-use guidance ('Offer it whenever the guest cannot get a time that suits them'), names the obvious trigger (an empty get_availability) and immediately widens it, and prescribes an ordering of alternatives: try other times, party sizes and dates first. It also states what to record and what to ask the guest, which is more than any sibling description would supply.
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.
bookfind_venuesget_availabilityget_reservationjoin_waitlistBook hard-to-get restaurant reservations on your own Resy, SevenRooms, or OpenTable account.
Request a restaurant table by automated phone call; charged only when the restaurant says yes.
Book a table, appointment or class at a real local business. Instant confirmation, no API key.
Read availability, reservations, guests; create, change, cancel bookings; add notes in GoTable.
Add one secure layer between your agents and this server.