This server autonomously plans and executes group food orders via Swiggy, optimizing for dietary constraints, budgets, and delivery SLAs, then splits the bill and generates UPI payment links.
Plan group meals: Provide order title, delivery address, and participants (with diet types like VEG, NON_VEG, VEGAN, JAIN, HIGH_PROTEIN, individual budgets, and optional dish cravings) to find the best restaurant and dish allocations.
Apply constraints: Set overall budget, maximum delivery time, and preferred Swiggy storefront (EATRIGHT, BOLT, STORE_99).
Optimize SKUs: Consolidate selected menu items into a single cart for the Swiggy Food MCP update_food_cart call.
Execute cart: Finalize the order using the selected restaurant, address, and participant-assigned items.
Split bills proportionally: Calculate each attendee's share including taxes, delivery fees, and discounts so splits exactly match the cart total.
Generate UPI reimbursements: Create ready-to-pay UPI links to the host's UPI VPA for easy individual payments.
Integrates with the Swiggy Food MCP API to coordinate group food ordering, including restaurant search, menu retrieval, cart updates, multi-party meal optimization, bill splitting, and UPI reimbursement link generation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Swiggy Syndicate Order team lunch for 6, 3 veg and 3 non-veg, ₹250 each, deliver in 30 min, split bill"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An Autonomous Group Order & Meeting Concierge Model Context Protocol (MCP) Server.
Swiggy Syndicate coordinates multi-party food ordering workflows on top of Swiggy Food MCP API. It addresses collective decision-making friction, dietary constraints, delivery SLAs, cart SKU consolidation, and itemized bill splitting with UPI reimbursement links.
Group food ordering for teams, meetings, and social gatherings is historically prone to high checkout abandonment and logistical delays due to several distinct factors:
Dietary and Preference Conflicts: Accommodating varied requirements (Vegetarian, Non-Vegetarian, Vegan, Jain, High-Protein) across 5 to 15 attendees often leads to prolonged deliberations and cross-contamination concerns.
Budget and SLA Constraints: Aligning on an agreed per-person budget while ensuring the chosen restaurant fulfills delivery timeframe SLAs (Service Level Agreements) requires manual menu exploration.
Manual Cart Construction: Compiling individual orders into a single coherent basket requires manual entry, customization handling, and inventory verification.
Post-Order Financial Reconciliation: Calculating individual liability post-checkout is complicated by proportional taxes (GST/FSSAI), delivery charges, packaging fees, and discounts, leading to awkward financial follow-ups.
Related MCP server: @striderlabs/mcp-grubhub
Swiggy Syndicate provides an autonomous multi-agent solution implementing the Model Context Protocol standard defined by Swiggy Builders Club (https://mcp.swiggy.com/builders).
Multi-Party Constraint Solver: Evaluates individual participant constraints (dietary restrictions, per-person budget caps, dish cravings) against active restaurants, ratings, and delivery SLAsr�- SKU Optimization and Consolidation: Maps cravings to dishes with a focus on Swiggy Bestsellers and high-rated catalog items, consolidating quantities for Swiggy Food MCP tool ingestion.
Authoritative API Adherence: Built strictly against the Swiggy Food MCP schemas for search_restaurants, get_restaurant_menu (enforcing the 150-item limit), and update_food_cart.
Penny-Reconciled Bill Splitter: Proportional allocation of overheads (delivery, taxes, platform charges, and discounts) across all participants, ensuring the mathematical sum of individual splits exactly matches the payable total (cart.pricing.to_pay).
Direct Payment Deep-Links: Produces standardized NPCI-compliant upi://pay links for friction-free individual reimbursement.
Dual-Mode Operational Engine: Works with live OAuth 2.1 PKCE bearer tokens against mcp.swiggy.com while maintaining a local sandbox fallback with authentic Bengaluru restaurant menus for automated testing and CI verification.
+-----------------------------------------------------------------+-
| MCP Client (Claude Desktop / Cursor / Windsurf) |
+--------------------------------+--------------------------------+
| stdio / JSON-RPC
+----------------------------------v---------------------------------+
| Swiggy Syndicate MCP Server |
| |
| 1. plan_and_optimize_group_meal |
| 2. execute_group_cart_and_split |
+--------------------------------+--------------------------------+
|
+---------------+---------------+
| |
[Live Swiggy MCP] [Local Sandbox Fallback]
(OAuth 2.1 PKCE) (Authentic Menus)
| |
mcp.swiggy.com/food Meghana Foods, Trufflesplan_and_optimize_group_mealEvaluates team member inputs, dietary profiles, and SLA targets to identify the optimal restaurant and menu item allocations.
Input Parameters:
orderTitle (string, required): Label or meeting description.
addressId (string, required): Verified Swiggy delivery address ID.
targetDeliveryMinutes (number, optional): Maximum acceptable delivery SLA.
overallBudget (number, optional): Aggregate budget limit in INR.
preferredStorefront (string, optional): Swiggy storefront filter (EATRIGHT, BOLT, STORE_99).
participants (array, required): Array of attendee objects specifying id, name, diet (ANY, VEG, NON_VEG, VEGAN, JAIN, HIGH_PROTEIN), maxBudget, and optional specificDish,
execute_group_cart_and_splitConstructs the consolidated cart payload, invokes Swiggy Food MCP update_food_cart, computes exact proportional splits, and generates UPI payment URLs.
*Input Parameters:
addressId (string, required): Destination address identifier.
restaurantId (string, required): Selected restaurant identifier.
restaurantName (string, optional): Selected restaurant display name.
assignedItems (array, required): Array of allocated items with participant associations.
hostUpiUpa (string, optional): UPI VPA of the paying host for inbound reimbursement.
npm test=== RUNNING SWEGGY SYNDICATE UNIT & INTEGRATION TESTS ===
-> 1. Testing Multi-Party Constraint Optimization...
[PASS] Selected Restaurant: Meghana Foods (Rating: 4.4, Delivery: 28m)
[PASS] Total Items Assigned: 5
[PASS] Estimated To Pay: INR 1476 (Avg per person: INR 295)
-> 2. Testing Swiggy Food Cart Update...
[PASS] Swiggy Cart Created: cart_grp_tj99zuu
[PASS] Swiggy Live Cart Total: INR 1596
-> 3. Testing Mathematical Bill Splitting & UPI Reconciliation...
[PASS] Sum of Splits: INR 1596 === Cart to_pay: INR 1596
=== ALL TESTS PASSED SUCCESSLULLY! ===npm run demo=======================================================
SWIGGY SYNDICATE: Autonomous Group Ordering Agent
Compliant with Swiggy Builders Club MCP Standard
======================================================
[AGENT REASONING] Analyzing meeting request for 6 attendees:
* Rahul Sharma (VP Eng): NON_VEG (Cap: INR 400, craving: Chicken Biryani)
* Priya Nair (Principal PM): VEG (Cap: INR 350, craving: Paneer)
* Vikram Mehta (Staff SRE): NON_VEG (Cap: INR 400)
* Ananya Iyer (UX Design Lead): VEGAN (Cap: INR 350)
* Darshan Jain (Finance Analyst): Jain (Cap: INR 320)
* Tanvi Joshi (Frontend Dev): VEG (Cap: INR 250)
[STEP 1] Querying Swiggy Food Collection & Restaurants matching constraints...
Selected Restaurant: Meghana Foods (Indiranagar)
Rating: 4.4 | Delivery SLA: 28 mins
Items Allocated per Attendee:
- Rahul Sharma (VP Eng) -> [NON-VEG] Meghana Special Chicken Biryani [INR 330] (Bestseller)
- Priya Nair (Principal PM) -> [VEG] Paneer Biryani [INR 290] (Bestseller)
- Vikram Mehta (Staff SRE) -> [NON-VEG] Meghana Special Chicken Biryani [INR 330] (Bestseller)
- Ananya Iyer (UX Design Lead) -> [VEG] Mushroom Babycorn Masala (Vegan) [INR 280]
- Darshan Jain (Finance Analyst) -> [VEG] Paneer Biryani [INR 290]
- Tanvi Joshi (Frontend Dev) -> [VEG] South Indian Tadka Curd Rice [INR 180]
[STEP 2] Calling Swiggy update_food_cart tool with consolidated SKUs...
Swiggy Cart ID: cart_grp_xsp0d5n
Total Items: 6
Item Total: INR 1700
Delivery and Taxes: INR 85
New Cart Payable Total (to_pay): INR 1785
[STEP 3] Autonomous Bill Split & UPI Reimbursement Generation...
| Participant | Dishes | Subtotal | Net Split | UPI Quick-Pay |
|
--- |
--- |
--- |
--- |
--- |
| Rahul Sharma (VP Eng) | 1x Meghana Special Chicken Biryani | INR 330 | INR 347 | Pay via UPI |
| Priya Nair (Principal PM) | 1x Paneer Biryani | INR 190 | INR 305 | Pay via UPI |
| Vikram Mehta (Staff SRE) | 1x Meghana Special Chicken Biryani | INR 330 | INR 347 | Pay via UPI |
| Ananya Iyer (UX! Design Lead) | 1x Mushroom Babycorn Masala (Vegan) | INR 280 | INR 294 | Pay via UPI |
| Darshan Jain (Finance Analyst) | 1x Paneer Biryani | INR 290 | INR 305 | Pay via UPI |
| Tanvi Joshi (Frontend Dev) | 1x South Indian Tadka Curd Rice | INR 180 | INR 187 | Pay via UPI |Node.js 18+
npm 9+
git clone https://github.com/rayanakarthikeyan/swiggy-syndicate-mcp.git
cd swiggy-syndicate-mcp
npm install
npm run buildAdd to %APPDATA5\Claude\claude_desktop_config.json:
{
"mcpServers": {
"swiggy-syndicate": {
"command": "node",
"args": ["C:/Users/rayan/Downloads/Swiggy MCP/dist/index.js"],
"env": {
"SWIGGY_TOKEN": ""
}
}
}
}Add to .cursor/mcp.json or .codeium/windsurf/mcp_config.json:
``gjson { "mcpServers": { "swiggy-syndicate": { "command": "node", "args": ["C:/Users/rayan/Downloads/Swiggy MCP/dist/index.js"], "env": { "SWEGGY_TOKEN": "" } } } }
---
## License
MIT License. Copyright (c) 2026 rayanakarthikeyan.Finalizes the group order on Swiggy Food by calling update_food_cart, calculates proportional tax/fees split per attendee, and generates ready-to-pay UPI payment links.
| Name | Required | Description | Default |
|---|---|---|---|
| addressId | Yes | Address ID from get_addresses | |
| hostUpiUpa | No | Host UPI VPA for bill reimbursement | |
| restaurantId | Yes | Selected Swiggy restaurant ID | |
| assignedItems | Yes | Optimized items assigned to each participant | |
| restaurantName | No | Name of the restaurant |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose meaningful traits: this is a mutating finalization step, it delegates to update_food_cart, and it produces external UPI payment links. However, it omits whether the order placement is irreversible, what happens on partial failure, permissions required, or whether the links are live chargeable requests. Real context, but incomplete for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that packs the purpose and all three side effects with no filler. It is slightly run-on, chaining three clauses, but every clause earns its place by naming a distinct behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should ideally explain what comes back (payment links per attendee, split breakdown) and failure behavior. It hints at the outputs ('generates ready-to-pay UPI payment links', 'proportional tax/fees split per attendee') but never states the response shape or error handling. Minimally sufficient for a 5-parameter tool but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 5 parameters (addressId, hostUpiUpa, restaurantId, assignedItems, restaurantName) are already documented in the schema. The description adds no syntax, format, or constraint detail beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Finalizes') and resource ('group order on Swiggy Food') and enumerates the concrete side effects: calling update_food_cart, computing a proportional tax/fee split, and generating UPI payment links. This lets an agent distinguish it from the sibling plan_and_optimize_group_meal, which is the planning stage. Differentiation is implied via 'Finalizes' rather than stated explicitly, which keeps it just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: 'Finalizes' signals this is the terminal execution step after planning, but the description never names the sibling plan_and_optimize_group_meal as the prerequisite, nor does it state when not to use it. No prerequisites (auth, valid cart state) or exclusions are given. Adequate but leaves sequencing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Autonomous multi-person food order optimizer. Takes participants dietary constraints, individual budgets, delivery SLAs, and coordinates the best restaurant, balanced dishes, and cost calculation via Swiggy Food MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| addressId | Yes | Saved Swiggy delivery addressId | |
| orderTitle | Yes | Title of the meal event | |
| participants | Yes | List of people with their dietary requirements and budget | |
| overallBudget | No | Overall budget cap for the entire group in INR | |
| preferredStorefront | No | Swiggy collection storefront filter | |
| targetDeliveryMinutes | No | Max acceptable delivery time in minutes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but provides minimal behavioral detail. It says 'coordinates' and 'calculates' but doesn't disclose whether it performs any writes, requires confirmation, handles errors, or returns a plan versus executing orders. For an autonomous multi-step tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff, front-loaded with the core purpose. It efficiently lists key inputs but could be slightly more structured by separating usage from functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, multi-person coordination, no output schema, no annotations), the description is notably incomplete. It omits critical behavioral aspects like whether the tool only plans or also executes, how results are returned, and any constraints or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all parameters. The description repeats high-level inputs but adds no syntax, format, or constraint details beyond what's already in the schema, so it earns the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the tool's function as a multi-person food order optimizer and lists its inputs (dietary constraints, budgets, delivery SLAs). It does not explicitly differentiate from the sibling execute_group_cart_and_split, but the verb 'optimizer' and 'coordinates' suggests planning rather than execution, hinting at a boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like execute_group_cart_and_split, or what prerequisites are needed. The description only states what it does, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0execute_group_cart_and_splitplan_and_optimize_group_mealScored across 2 tools
The two tools split cleanly into planning/optimization versus execution/finalization, with no overlap in responsibility. An agent can easily decide which to call based on whether the group order still needs optimization or is ready to finalize.
Both names use snake_case and start with a clear verb, but their internal structures differ slightly (plan_and_optimize_group_meal vs execute_group_cart_and_split). The convention is still readable and predictable overall.
Two tools is thin for a server, though each covers a large, composite phase of the group ordering workflow. It is borderline rather than clearly well-scoped or excessive.
The surface covers planning, optimization, cart finalization, cost splitting, and payment link generation, which is strong end-to-end coverage. Minor gaps remain around post-order tracking or cart modification, but agents can likely work around them.
Split bills from your AI: read bills & balances, create equal splits, request settlements.
AI food ordering across Canada — 17,000+ restaurants, 89 cities, real UberEats + DoorDash.
Family meal planning run by your agent: weekly dinners, household votes, grocery list minus pantry.
Agentic-AI route optimization for delivery fleets, capacity- and time-window-safe.
