Fantuan

Find restaurants with or without login. This tool already supplies restaurant UI cards; do not call show_restaurants to render the same search again. Default to delivery unless the user explicitly requests pickup. Nearby, distance sorting, and a landmark do not imply pickup. Preserve the user's chosen fulfillment on follow-ups; change it only on an explicit user request and search again. An explicitly provided address or selected location reference takes priority over saved addresses. Reuse confirmed location references for follow-ups. Without a location, ask for an address; when the user explicitly requests their saved delivery address, pass use_saved_address=true and a known country, even before login. On an authentication challenge let the host authorize address:read and restaurant:read, then retry the same arguments. Never set use_saved_address merely because location is missing. Country alone never authorizes saved-address lookup, even after login. Login does not change the search location or enable additional tools. Never infer country from language. A missing or ambiguous saved address requires user input. Only personal address or legacy account cursor inputs require login; public address search remains available without login. For another batch, copy next_page_arguments exactly. This supplies next_discovery_cursor as discovery_cursor and discovery_session; do not append other fields. It preserves all search conditions. Never change sorting or restart page one to imitate pagination after an error; if the client cannot accept discovery_cursor, explain in plain language that the Fantuan connection needs refreshing to load more results. Stop when has_more=false. To change keyword, location, fulfillment, locale, sort or limit, start a new search without the cursor. Legacy market_context_handle, cursor and fulfillment_type remain accepted for existing clients. Do not silently change location after login. For NEEDS_CONFIRMATION ask the user to choose a candidate; confirm only candidates with can_confirm=true. References require their original discovery_session. Handle location questions briefly in conversation. MORE_DETAIL_REQUIRED means ask for a city, neighborhood, landmark or street address; restaurant search has not run. A city, neighborhood or landmark is sufficient for discovery when uniquely resolved. Do not insist on a door number or ask again when the tool returns RESULTS. Use location_guidance to describe the search center; approximate searches do not guarantee delivery to the user's eventual address. A confirmed landmark is a search center, not a verified delivery address or live device location. Never invent an address or claim no nearby stores from a location failure. When the user changes location, discard the old location reference and resolve the new location. Preserve keyword and fulfillment while asking for location. For a new search pass locale from the requested or conversation language; use en for unsupported languages. Mention relevant notes briefly when useful, without repeating them on every unchanged follow-up. Missing ratings and prices are unknown. After a successful search, answer from the returned result and cards; do not repeat the same search to confirm, read, or render it. Empty results, closed restaurants, missing optional fields, or has_more=true are not retry signals. Search again when the user requests a refresh, changes conditions, or asks for another page; retry a failed call at most once only for a retryable error or after its required authentication/location correction. Speak naturally in the user's language, focusing on restaurants, dishes and useful choices. Identify restaurants by name and branch, not technical labels such as card 4 or display_position. Use unnumbered bullets for selected recommendations; keep original positions internally to resolve 'the second restaurant'. Mention a displayed position only when needed to disambiguate, in the user's language (for example 上面第2家), together with its name. For more results say 再看看其他店 or 换一批 in Chinese, or a natural equivalent, rather than explaining pagination. Do not narrate checking plugin capabilities, tools, schemas, cursors, references or internal workflows. If location is missing, simply ask for a city, neighborhood or landmark. Briefly acknowledge a changed location or delivery/pickup preference when useful. Keep recommendations concise; do not repeat the full cards or caveats for every restaurant or turn. Explain actual limitations honestly in plain language. Only mention refreshing the Fantuan connection when a client-definition mismatch blocks a retry; do not hide errors or claim a failed action succeeded. Search with the user's dish or restaurant words in their original language. Do not append translations, synonyms, or alternate spellings to keyword: it is one literal search query, not an OR list. For example, a request for 抹茶奶茶 uses keyword=抹茶奶茶, never 抹茶奶茶 matcha milk tea. Preserve mixed-language names when the user supplied them. Keep the keyword on location confirmation or fulfillment changes; change it when the user requests a different dish or agrees to an alternative. candidate_reference and location_reference identify addresses (lctx_), never restaurants (drst_ or rst_). For a specific returned restaurant or card ordinal, answer prices from its existing matched_items when sufficient; use get_restaurant for fresh branch details only if that tool is available; otherwise offer the returned menu link. This search has no single-restaurant filter; do not rerun a broad search to answer a same-restaurant question. Do not promise cart changes when asked only for prices or delivery, or when no cart write tool is available. After a failed tool or web read, do not claim fresh verification. Label reused results as earlier search results and offer the exact menu link when more detail is unavailable. Copy returned web_url and search_web_url verbatim into links, including every query parameter (shippingType, lat, lng, f_channel, rTraceId). Never shorten or reconstruct URLs, even when the UI fails to load. display_position is the 1-based card position in this result, including closed or less suitable restaurants. Keep display_position as internal context; do not prefix every recommendation with it. Never assign new ordinal numbers to a filtered recommendation list. A card ordinal counts all returned cards, not only open restaurants or the shops you recommended. Use the latest relevant result; if the user explicitly refers to your text list, use that list. When a bare ordinal could refer to different shops in the cards and your text, ask which named shop they mean instead of choosing silently. Preserve the returned restaurant order. Sorting includes business grouping; When search_web_url is returned, offer it to continue the same keyword search in Fantuan. It carries location and fulfillment, not all recommendation constraints or sorting. Resolve card ordinal references against that result order; clarify when the user might mean a different result batch or your recommendation list. For cheaper alternatives or comparisons, use returned item base prices in the same currency and price basis. per_person_price is average spend, not an item price or an all-in budget. Fees and required options may change the total. There is no price, spiciness, or exclusion filter in this tool; do not invent arguments or claim these constraints were applied. For another restaurant, preserve location and fulfillment, distinguish a different returned branch using its reference or exact link, and say when no alternative is available. Missing price or taste data is unknown, not proof a constraint is satisfied. For follow-ups asking for multiple dishes together at the same restaurant, retain all requested dishes and the same-store constraint. Keyword search does not guarantee an intersection of dishes. Confirm a same-store match only from returned facts for that exact restaurant. An empty restaurant list means this query returned no matches, not that no such restaurant exists. Missing matched_items do not prove a dish is absent. Do not automatically drop a dish or other explicit condition and search again; ask before broadening. If the user accepts partial alternatives, state which condition the new search covers before calling the tool, and do not present its cards as satisfying all conditions. distance is not guaranteed to be globally ascending. distance_bucket is an approximate range, not an exact distance. Restaurant names are display labels, not verified street addresses or city identifiers. Do not infer a location mismatch or declare a service/data anomaly from a city name in a restaurant name, missing optional fields, or an environment label alone. If returned facts explicitly conflict, describe the specific uncertainty without declaring an unverified cause or service failure. can_order is a legacy permission signal and does not establish immediate availability or preorder support. Use availability and can_order_now together; final order eligibility must be confirmed in Fantuan.

search_restaurants

Receives observations from the Fantuan UI only. Do not call from the assistant.