HeyYumi

Request reservation

request_reservation

Idempotent

LANGUAGE: Answer in the SAME language the user wrote in. The helper sentences attached to results (yumiReservation, influencerContent, keywordMatch, reputation notes, dietary note, aiSummary, ownerIntro, meta notes) are Korean source text: render them in the user's language and never paste raw Korean into a non-Korean answer. 'As-is' / VERBATIM means keep the facts, numbers, venue names, @handles, URLs, link labels, phones and prices exactly. Keep Korean venue names and addresses, adding a romanization when it helps. Send a reservation request (a table, or a beauty or fitness appointment: first ask what yumiBooking.askBefore lists and put the answers in note) to a venue whose result shows yumiBooking.canRequest=true (Yumi partners included). Book by conversation: collect the details in chat (works by voice too) and call this directly; open the restaurant_reservation widget only if the user taps Reserve or asks for a form. REAL side effect: it creates a pending reservation and notifies the venue right away. PRECONDITIONS FIRST: settle a concrete date & time and the venue before asking for any personal details. If the time has already passed or the date is relative ('오늘', '금요일'), confirm the date first and do NOT front-load name/phone/email in that message. reservationTime MUST be in the future (Korea time); on reservation_time_past don't retry — re-confirm the date. Find the id with search_places: for a NAMED VENUE put its name in keyword only and do NOT add a business_category. Confirm venue, date & time, party size, the guest's name and phone. Phone is always required (foreign guests give their own international number). Korean number → phone only, never ask for an email. Non-Korean number → ask for an email in the same step (we can't text abroad; the email has a link to view or cancel the booking). Errors: reservation_requests_closed = nothing was sent; when body.earliestReservation is present, the request can be held overnight for that time or later — offer it. venue_closed_at_requested_time = ask for another time. reservation_too_close_to_closing = times are taken only up to 2 hours before closing; offer body.latestReservation or an earlier time. reservation_not_available = don't retry; say '헤이유미로는 아직 예약이 안 되는 매장이에요', link its placeUrl and offer requestable venues nearby. The result is 'pending', not booked. If it has reviewStartsAt, it was held overnight: relay its yumiNextStep (the venue checks from that time; the result goes to the guest's phone or email) and don't call wait_for_reservation. Otherwise tell the user they'll hear back within 5 minutes, then call wait_for_reservation until it settles: confirmed = booked, cancelled = the venue declined, expired = no answer in time (offer alternatives).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "placeId": "<placeId>",
      "reservationTime": "<reservationTime>",
      "guestCount": "<guestCount>",
      "guestPhone": "<guestPhone>"
    },
    "name": "request_reservation"
  }
}

Input Schema

Name	Required	Description
`note`	No	Note to the venue (seating, occasion, high chair). Required at beauty and fitness venues: the answers to yumiBooking.askBefore, e.g. cut and perm.
`placeId`	Yes	Place id from a search result. Search first; never guess.
`guestName`	No	Guest's name.
`guestCount`	Yes	Party size, at least 1.
`guestEmail`	No	Required only when guestPhone isn't Korean (otherwise guest_email_required); never ask a Korean guest. Ask together with the phone.
`guestPhone`	Yes	Required. The guest's mobile ('010-1234-5678', +82…, or +<country><number> for foreign guests). Korean numbers also get the outcome by text.
`guestLanguage`	No	Language the user is chatting in, ISO 639-1 (e.g. 'en', 'de', 'ja'). The venue's reply is sent back in it.
`idempotencyKey`	No	Optional stable value to retry the same request without duplicates.
`reservationTime`	Yes	ISO 8601 with offset, e.g. "2026-07-23T19:00:00+09:00". Must be in the future.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

changedInput schema / properties / note / description

Previous value: -"Optional note to the venue (seating, occasion, high chair; at a beauty venue the treatment, e.g. cut and perm)."New value: +"Note to the venue (seating, occasion, high chair). Required at beauty and fitness venues: the answers to yumiBooking.askBefore, e.g. cut and perm."

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / note / description

Previous value: -"Optional note to the venue (seating, occasion, high chair)."New value: +"Optional note to the venue (seating, occasion, high chair; at a beauty venue the treatment, e.g. cut and perm)."

First observedNov 3, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already mark this as a non-read-only, open-world, idempotent mutation, and the description adds crucial context: it creates a pending reservation and notifies the venue immediately, the result is not a confirmed booking, and follow-up is asynchronous via wait_for_reservation. It also discloses overnight holds, Korean versus non-Korean phone/email behavior, and error-specific outcomes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a dense wall of text and does not front-load the actual purpose; it begins with language and formatting rules before reaching the reservation action. Much of the content is useful for a complex mutation, but it mixes global output rules, precondition workflow, error handling and post-call behavior without clear structure, making it harder to scan than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and creates a real side effect, the description is highly complete: it covers preconditions, required details, language behavior, error recovery, pending status, overnight holds and the wait_for_reservation follow-up. An agent has enough context to call it and handle the outcome without additional documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already defines all nine parameters, including placeId, reservationTime, guestPhone, guestEmail, note and idempotencyKey. The description mostly repeats those constraints, such as future Korea time and phone/email rules, rather than adding much parameter-specific 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: send a reservation request to a venue showing yumiBooking.canRequest=true. It also distinguishes this tool from restaurant_reservation by saying to call this directly in conversation and only open the widget if the user taps Reserve or asks for a form. It further routes place-id discovery to search_places.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance: collect date/time, venue, party size, name and phone in chat, then call this tool directly. It names the alternative widget flow and the follow-up wait_for_reservation flow, including when not to call wait_for_reservation if reviewStartsAt is present. It also covers retry behavior and alternative actions for each error code.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All HeyYumi tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.