prototype demo
SWIGGY MCP · FOOD + DINEOUT

Your evening, planned
in one conversation

An AI agent that coordinates dining-out and food delivery across Swiggy's MCP stack — with live availability checks, staged confirmations, and graceful fallbacks when things don't go perfectly.

Food MCP
Dineout MCP
14 tools · OAuth 2.1 PKCE
occasion-copilot — interactive prototype
MCP v1.0
🌆
Hi! Tell me what you're planning tonight — a dinner out, food delivered home, or both. I'll coordinate across Swiggy Food and Dineout and confirm each step separately before acting.
Date night — Italian in Indiranagar, 2 people, 8pm, gelato after
Rooftop for 4 tonight, biryani delivered home around 10
Show me what happens when a slot isn't available
Agent flow
💬
Parse intent
LLM extracts
constraints &
occasion type
→
🔍
Find table
search_restaurants
_dineout
get_available_slots
→
📋
Confirm · book
book_table
get_booking
_status ✓
→
🛵
Build cart
search_restaurants
get_restaurant
_menu · update_cart
→
✅
Confirm · order
get_food_cart
place_food_order
track_food_order

Each server confirmation is independent. Partial success is surfaced explicitly — a failed food order never silently cancels a Dineout booking.

Edge case handling
graceful degradation
Slot unavailable at chosen time
Agent re-fetches 7-day availability window, surfaces the 3 closest alternatives with times and party-size fit. Never dead-ends.
safe retry
book_table returns 5xx
Calls get_booking_status before retrying — non-idempotent endpoint, so check-then-retry prevents double bookings.
staged confirm
Dineout books, food order fails
Each action confirms separately. If food placement fails, booking remains intact. Agent offers: retry delivery, prepare cart for later, or skip.
cart safety
User edits cart in Swiggy app mid-chat
get_food_cart is called right before every place_food_order — never trusts what was added earlier in the conversation.
auth recovery
401 mid-session on either server
Re-runs OAuth 2.1 PKCE flow once, updates the shared bearer token across both MCP clients, then retries the failed call.
coupon safety
Coupon requires online payment
v1 is COD-only. fetch_food_coupons is filtered at the agent layer — requiresOnlinePayment coupons are never surfaced to the user.
Technical implementation
LLM
Claude Sonnet
Multi-tool orchestration, constraint extraction, occasion-type classification
FRAMEWORK
Next.js 14
Server-side MCP calls via API routes, streaming responses, Vercel deploy
MCP CLIENT
Streamable HTTP
Parallel clients to /food and /dineout — single OAuth 2.1 PKCE token across both
RESILIENCE
Retry + fallback
Exponential backoff (500ms→8s), check-then-retry on placement, 30s wall-clock cap
STATE
Server-authoritative
No client-side cart caching — always re-fetches before mutations or confirmations
OBSERVABILITY
Session ID logging
Every tool call logs session ID for Swiggy-side trace correlation on failures