FunNow

Use this tool to check restaurant reservation availability and continue a booking flow. Call this tool when: - The user asks for available booking times for a specific restaurant. - The user selects a restaurant from a prior restaurant_search result. - The assistant previously asked for missing booking details and the user replies with only a date, time, or party size, such as "2 people, 19:00". Treat this terse reply as a continuation of the active restaurant booking request and reuse the restaurant and date from conversation context. - The user wants to book, reserve, reschedule, or confirm whether a selected time is still available. - The user asks "還有位置嗎", "有位嗎", "可以訂嗎", "幫我確認時段", "晚上九點有位置嗎", or "改成三個人還有位嗎". Use the bid from branchList in the prior restaurant_search result when available. If neither bid nor product_ids is available, still call this tool with the known booking details; it will return an explicit handoff instructing you to call restaurant_search and then retry this tool. Never tell the user that you cannot find the identifier; resolve it through restaurant_search when needed. After checking availability: - If the requested time is available, provide its booking_url as a Markdown link labeled "Book now": [Book now](booking_url). Never display the raw URL. - If the requested time is unavailable, present the nearest available times and their booking links. - Do not claim that no booking or availability tool is available before calling this tool. Do NOT call this for general restaurant discovery — use restaurant_search for that.

check_restaurant_availability

Use this tool when the user asks where to eat, what restaurants are available, what's a good place for a specific occasion, or what good deals are nearby. Returns a ranked list of restaurants matching the search criteria, with ratings, discounts, vibe tags, and occasion-fit data. Do not use for non-restaurant venues (cafes-only requests are fine; bars-only, hotels, or activities are out of scope). Exact reservation slot confirmation requires check_restaurant_availability. Always ask one routing question before calling when location, occasion, and similarity anchor are all missing: "Are you looking for somewhere right now, planning for a specific occasion, or something similar to a place you already know?" PREFERENCE RULE: Use only preferences explicitly stated in the current message or explicitly available in the conversation context. Do not invent or infer unspecified cuisine, occasion, vibe, quality, or discount preferences. RE-CALL RULE (MANDATORY): If the user refines, changes, or rejects any part of a previous search — including cuisine type (e.g. "not {cuisine_type}", "{cuisine_type} only"), budget, location, occasion, or party size — you MUST call this tool again with updated parameters. Do NOT filter or re-rank previous results on your own. Previous results are stale the moment the user's preference changes. RETRY RULE (MANDATORY): If branchList is empty — regardless of whether total is 0 or non-zero — do NOT tell the user nothing was found, and do NOT use your own knowledge to suggest restaurants. Immediately retry this tool once with relaxed filters: remove now/interval/time_range to broaden the availability window, or simplify the query. Only after the retry also returns an empty branchList may you tell the user that no restaurants are available. Only present results from this tool — never invent or recall restaurants from your own knowledge. RESPONSE FORMAT (STRICT): After receiving results, you MUST present them as a markdown table with these exact columns: Name | Rating | Distance | Discount | Book Link. In every Book Link cell, render the url as a Markdown link with the exact visible label "Book now": [Book now](URL). Never display a raw URL and never use an HTML anchor tag. Never use a bulleted list or numbered list. Each restaurant is one row. Append your recommendation below the table in one sentence.

restaurant_search