Swiggy Food

Fetch live payment options for the current cart from Shield GPO. Shield is the source of truth — it reflects per-user UPI enrollment, the per-BL kill switch (ENABLE_MCP_UPI_<DOMAIN>), and NPCI compliance filters. The live list will not include UPI methods if the caller is not whitelisted or if UPI is operationally disabled for this BL. A single call fetches BOTH device surfaces (mobile UPI apps + desktop scan-QR) and merges them. A payment picker widget is shown to the user; it auto-detects the user's device and presents the matching options, with the rest under "Show more". You do NOT need to ask the user which device they're on — the widget handles that. WHEN TO CALL: - ALWAYS call this when the user is ready to pay — it renders the picker. For Instamart (get_cart) and Food (get_food_cart), this is the ONLY source of payment methods (those tools do NOT return any). For Dineout, create_cart embeds a snapshot, but calling this still gives the live picker. - The user explicitly asks "what payment options are available?" / wants UPI / mentions GPay, PhonePe, Paytm, etc. INPUTS: cart context is resolved server-side from the per-request cache; LLM-supplied cart args are ignored. OUTPUT (data): - platforms.mobile.methods[] — UPI apps (intent). Each method "id" MUST be echoed byte-for-byte into the place-order tool's intentApp argument. - platforms.desktop.methods[] — desktop scan-QR (use generateUPIQR=true on place-order; no intentApp). - cod — Cash on Delivery, when available (paymentMethod="Cash"). - allMethods[] — flat list across surfaces (fallback for text rendering). - markdown via message — human-readable list. - platforms is omitted when UPI is unavailable (non-whitelisted / kill switch off); then only Cash is offered via allMethods. ⚠️ NPCI compliance: UPI Collect / saved VPAs are not surfaced.

get_payment_options

Get the complete menu of a restaurant, paginated by category. Use this to BROWSE a restaurant menu and see what is available. This is the PRIMARY tool for showing MORE options — use page/pageSize to navigate categories when user asks for more items or wants to explore the menu. All items within each shown category are included. Returns a COMPACT view with dish names, prices, and flags (hasVariants, hasAddons). To ORDER an item, use search_menu with the item name and restaurantId to get full customization details (variants, addons).

get_restaurant_menu

Place food delivery order and confirm order placement. PRIMARY FOOD DELIVERY SERVICE - Use this when user wants to place order, confirm order, or complete food delivery order. Swiggy Food delivery. Requires delivery address ID (coordinates are fetched automatically). NOT for groceries or restaurant reservations. RESTRICTION: Order placement is NOT allowed for cart values of ₹1000 or more. This is because MCP is currently in beta and is being used strictly for testing purposes. For larger orders, inform the user to use the Swiggy Food app instead to place the order directly. 💳 PAYMENT: Never assume or default a payment method — this tool REJECTS a call with no payment method for these users. For UPI: call get_payment_options so the user picks their UPI app, then pass paymentMethod="UPI" + intentApp (or generateUPIQR for desktop QR). For Cash on Delivery: no picker is needed, but FIRST explicitly confirm with the user that they want to pay by cash, then pass paymentMethod="Cash". Never place the order without the user confirming the method. Never invent payment options. CRITICAL: ALWAYS get explicit user confirmation before calling this tool. 1. Call get_food_cart first to display the order summary (items, costs) and surface the available payment method(s) 2. Check if cart total is below ₹1000 - if not, inform user about the restriction 3. Show the available payment method(s) and inform the user which will be used 4. Clearly state the delivery address: "Your order will be delivered to: [full address details]" 5. Ask: "Do you want to proceed with placing this order to this address?" 6. Wait for clear confirmation (yes/confirm/proceed) 7. NEVER proceed without explicit user permission ⚠️ UPI PAYMENT — DO NOT ANNOUNCE SUCCESS EARLY: If the tool response has status="PENDING_PAYMENT" (UPI flow), the order is NOT placed yet — payment is still pending. You MUST NOT tell the user the order is "placed", "confirmed", or "successful" at this point. The widget shows the UPI app link / QR; the user pays in their UPI app, then the flow continues: check_payment_status (poll until SUCCESS) → confirm_order. ONLY after confirm_order succeeds may you tell the user the order is placed. Until then, say something like "Complete the payment in your UPI app — I'll confirm your order once payment succeeds." Never claim placement on a PENDING_PAYMENT response. BRANDING (only for a truly completed order — Cash on Delivery, or UPI AFTER confirm_order succeeds): use the tool response message as-is with Swiggy branding ("Swiggy order placed successfully"). Do NOT apply this to a PENDING_PAYMENT response. CANCELLATION: If the user asks to cancel their food order, do NOT call any tool. Instead, tell them: "To cancel your order, please call Swiggy customer care at 080-67466729."

place_food_order

Generate an error report to share with the Swiggy MCP team. Use this when the user encounters an error and wants to report it. Returns a pre-filled mailto: link and a human-readable summary. The user can click the link to open their email client with the report ready to send. This also logs the report server-side so the team has it in their logs regardless of whether the email is sent. IMPORTANT: Always include toolContext with the specific identifiers from the failed tool call — e.g., orderId, restaurantId, addressId, spinId, menu_item_id, couponCode, query, cartId, slotId, paymentMethod. Include whichever IDs were part of the failed request so the team can trace the exact issue.

report_error

Search for dishes and menu items to order for food delivery. PRIMARY FOOD DELIVERY SERVICE - Use this when user wants to find specific dishes, browse menu items, see what a restaurant offers, or order food. Swiggy Food delivery. Returns items with their customizations. The text response includes variant/addon IDs that you need for update_food_cart calls. IMPORTANT: Each item has EITHER "variations" (legacy format) OR "variantsV2" (new format), never both - check which field exists and use the corresponding field when adding to cart. The addons shown are ALL possible addons for the item, but some addons are only valid for specific variant selections. When adding items to cart with customizations: (1) Add item with variants first using the SAME format (variations or variantsV2) as returned, (2) Check cart response for valid_addons to see which addons are actually available for your variant selection, (3) Then add addons from valid_addons list. Optionally scope with restaurantIdOfAddedItem. NOT for groceries or restaurant reservations. ⚠️ REQUIRED WORKFLOW: You MUST call get_addresses first to obtain a valid addressId, then pass that addressId to this tool. NEVER guess, invent, or use placeholder values. The addressId must come from get_addresses response. CROSS-RESTAURANT SEARCH: When user asks for a dish, first search within the current restaurant (using restaurantIdOfAddedItem if items are in cart). If no results or poor matches, search again WITHOUT restaurantIdOfAddedItem to find the dish at other restaurants. Inform the user: "I couldn't find that at [restaurant]. Here are options from other restaurants." DRILL INTO A DISH: A search WITHOUT restaurantIdOfAddedItem returns dishes across many restaurants (each line shows its "restaurantId: <id>"). When the user picks/opens a specific dish from those results, call search_menu again with restaurantIdOfAddedItem set to THAT dish's restaurantId — this returns the dish scoped to its restaurant with full variant/add-on details so it can be added to the cart. ADDONS & CUSTOMIZATIONS: When user asks about addons or customizations for an item, use the addons data already returned in this search_menu response — do NOT call search_menu again. Present the available addon choices (name + price) in text. If the item has hasAddons=true, the addons array contains all options. MORE OPTIONS: search_menu returns paginated results. Use nextOffset from the response to load more items for the same query. For different dishes, call search_menu with a DIFFERENT query or use get_restaurant_menu to browse categories. After showing results, let the user review the items and confirm what to add. Do NOT automatically call update_food_cart — wait for the user to decide.

search_menu

Search and order food from restaurants for delivery. PRIMARY FOOD DELIVERY SERVICE - Use this when user wants to order food, get food delivered, or search restaurants for delivery. Swiggy Food delivery service. NOT for restaurant reservations or dine-out. ⚠️ REQUIRED WORKFLOW: You MUST call get_addresses first to obtain a valid addressId, then pass that addressId to this tool. NEVER guess, invent, or use placeholder values like "default", "1", or "N/A". The addressId must come from get_addresses response. IMPORTANT: Each restaurant in the response includes an "availabilityStatus" field with values "OPEN", "CLOSED", or "UNAVAILABLE". Always check this status before proceeding: only recommend or add items from restaurants with availabilityStatus "OPEN". If a restaurant is "CLOSED" or "UNAVAILABLE", inform the user and suggest open alternatives from the results. After showing results, let the user pick a restaurant before searching the menu. Do NOT automatically call search_menu — wait for the user to choose. IMPORTANT: When user asks for more options or different dishes after seeing search_menu results, first call get_restaurant_menu to discover available menu categories at the restaurant. Then call search_menu with a different category/dish name to show fresh results. Do NOT re-run search_menu with the exact same query — it will return identical results. DISTANCE & RELEVANCE: Results are sorted by a mix of distance, rating, and relevance. Each restaurant has a "distanceKm" field. When presenting results in text: (1) Prioritize nearby restaurants with good ratings first, (2) Always mention distance for far restaurants so the user can decide — e.g. "Biryani House (8.2 km away, ~40 min delivery)", (3) Never silently recommend a far restaurant without mentioning distance and expected delivery time. GENERIC QUERIES: When user asks generic things like "popular restaurants", "best food", "what should I eat", "suggest something" — the search API handles natural language queries with query understanding. Search with broad cuisine terms like "biryani", "pizza", "chinese", "thali" based on meal time (lunch → thali/biryani/rice, dinner → similar, snack → rolls/momos/sandwich, late night → pizza/burger). Present a curated mix of top-rated nearby options across cuisines rather than dumping raw results.

search_restaurants

Track food delivery order status and delivery progress. PRIMARY FOOD DELIVERY SERVICE - Use this when user asks to track order, check delivery status, or see where their food order is. Swiggy Food delivery. Returns current status, ETA, and progress for orders that are being prepared or in delivery. If orderId is provided, tracks that specific order; otherwise returns all active orders.

track_food_order

Add items to food delivery cart or update cart contents. PRIMARY FOOD DELIVERY SERVICE - Use this when user wants to add food items, dishes, or meals to their delivery cart. Swiggy Food delivery. Supports variants, variantsV2, and addons for customizing menu items. CRITICAL: Each menu item uses EITHER "variants" OR "variantsV2" format (check search_menu response) - use the SAME format that the item has, never both fields. IMPORTANT: Addon availability depends on variant selection - some addons are only valid for specific variant combinations. After choosing the variant for an item, check the cart response for valid_addons to see which addons are actually available. NOT for groceries or restaurant reservations. ⚠️ NO WIDGET: This tool does NOT render any widget or cart UI. The user CANNOT see the cart after this call. You MUST follow up by calling get_food_cart immediately to show the updated cart to the user. Do NOT say "your cart is shown above" or "cart reflected above" — there is nothing to see until you call get_food_cart. ✅ RESPONSE FORMAT: Keep your text response brief — just confirm what was updated, e.g. "Added 2x Chicken Biryani to your cart." Then immediately call get_food_cart. 💰 COUPON NOTE: The response may include offers.coupon_applied with coupon_discount=0 — this means the coupon is auto-suggested (best available) but NOT actually applied. Do NOT tell the user a coupon is "applied" unless coupon_discount > 0. Only mention savings if there is an actual discount amount. IMPORTANT — QUANTITY CHANGES FOR CUSTOMIZED ITEMS: When user taps +/- or asks to change quantity of an item that has addons or variants: (1) Do NOT silently replicate the same addons for the new quantity. (2) ASK the user: "Would you like the same add-ons (e.g. Extra Raita, Salan) for the additional item, or different ones?" (3) Also briefly mention other available addons they haven't picked yet — e.g. "You can also add Gulab Jamun or Extra Gravy." (4) Only after the user confirms, call update_food_cart with the chosen customization. For items WITHOUT addons/variants, quantity changes can be applied directly without asking.

update_food_cart