Every feature launch at a tech company ends the same way. The PM announces the ship. Someone in Slack says "we should celebrate." The team lead volunteers to organize food, then spends 45 minutes DMing 12 people, reconciling "I'm vegetarian," "I'm allergic to peanuts," and "anything is fine" into a single order.
I built the version where an AI agent does that in under a minute.
The idea
- Team lead shares a Google Form: name, dietary restrictions, cuisine preferences, spice level.
- Team fills it in. Export responses as CSV from Google Sheets.
- Run
party-agent --csv responses.csv --event "v2.0 Launch" --address "Office". - The agent finds a restaurant, picks a dish per person, builds the cart.
- CLI prints a per-person breakdown. Team lead confirms.
- Order placed.
The agent never places an order on its own. Cart building and order placement are separate steps.
What makes this possible: Swiggy MCP
Swiggy Builders Club launched in April 2026. Three MCP servers: Food, Instamart, Dineout. 35 tools. OAuth 2.1 with PKCE.
The Food MCP server has the tools this agent needs:
get_addresses → resolve the office delivery address
search_restaurants → find restaurants near the office
search_menu → find dishes by keyword or cuisine
update_food_cart → build the full cart in one call
fetch_food_coupons → get available discounts
apply_food_coupon → apply the best COD-compatible one
get_food_cart → verify cart state before confirming
place_food_order → place the order (COD only in v1)
update_food_cart takes the entire cart as a single call. You don't add items one by one. You send the full array and Swiggy replaces the cart. For a 12-person team, that's one tool call, not twelve.
Swiggy's cart is server-side. The agent builds it, and the team lead can open the Swiggy app and see the same cart. They can edit before confirming. The agent's work is a starting point, not a locked order.
The agent loop
get_addresses
↓
search_restaurants (filtered to OPEN, scored against group preferences)
↓
search_menu (per member, matching cuisine/dish preferences)
↓
update_food_cart (all items in one call)
↓
fetch_food_coupons → apply_food_coupon (COD-compatible only)
↓
get_food_cart (verify final state)
↓
return JSON summary to CLI
The system prompt enforces the constraints. Vegetarian members only get veg items. No-peanuts means no peanut dishes. Cart total stays within the configured cap. A mixed group needs a restaurant with both veg and non-veg options. The agent accounts for that when scoring restaurants.
Dietary restrictions
The CSV parser normalises free-text entries to canonical tags before the agent sees them:
| Input | Tag |
|---|---|
| Vegetarian, Veg | vegetarian |
| Jain | jain |
| Halal | halal |
| No peanuts, Peanut allergy | no-peanuts |
| Gluten free | gluten-free |
Tags flow into the agent prompt as constraints. A member tagged vegetarian only receives items marked veg in Swiggy's menu. The agent doesn't guess.
The cart cap
Swiggy Builders Club v1 sandbox accounts have a ₹1000 cap per order. For a real team, that's too low. The cap is configurable via --cap (defaults to ₹5000). Large teams split into groups automatically. Each group gets its own cart and confirmation prompt.
Order 1 of 3 - Biryani House
─────────────────────────────────────────
Rahul Sharma Chicken Biryani ₹349
Priya Nair Paneer Tikka Masala ₹299
Ankit Gupta Chicken Fried Rice ₹199
Sneha Patel Masala Dosa ₹149
─────────────────────────────────────────
Coupon : LAUNCH20 -₹50
Total : ₹946
? Place order 1/3 from Biryani House (₹946)? (y/N)
y places the order. n skips that group.
It's not just a CLI
The core agent logic in src/agent.ts is surface-agnostic. buildCartForGroup and placeOrder are plain async functions. The CLI is one surface. The same functions work for:
Slack bot: /party-order slash command posts the cart summary as a Block Kit message with Approve / Skip buttons. The agent reads the sheet via Google Sheets API instead of a local CSV.
Web app: Team lead pastes a Google Sheets link, reviews the cart in a table, edits individual items, clicks Place Order.
MCP server: Expose buildPartyCart and placePartyOrder as MCP tools. Any MCP-compatible client (Claude Desktop, Cursor) can trigger a team order from a conversation.
Scheduled cron: Run every Friday at noon. Build the cart, post to Slack for approval. If no one rejects within 30 minutes, place automatically.
What Swiggy got right
I wrote a breakdown of Swiggy's MCP implementation earlier this month.
The idempotency docs alone are better than most MCP implementations I've read. place_food_order is not safe to blind-retry on network failure. If you get a 5xx, call get_food_orders first to check whether the order went through. Agents retry. Swiggy documented the correct pattern. Most MCP server authors don't.
One gap: the v1 scope model is server-level, not tool-level. Any agent with mcp:tools can call place_food_order. There's no protocol-level way to say "this agent can build carts but a human must confirm before checkout." The CLI enforces that boundary here. For enterprise deployments, you'd want a policy layer in front of the MCP server.
The pattern
The Google Form is the input surface. The spreadsheet is structured data. The agent is the layer that turns 12 people's preferences into a confirmed order.
Weekly team lunch. Hackathon dinner. Office birthday. Any time a human would spend 45 minutes in Slack, an agent can do it in under a minute. The tools are there.
The project is open source: github.com/Siddhant-K-code/swiggy-party-agent