Swiggy Syndicate
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SWIGGY_TOKEN | No | OAuth 2.1 PKCE bearer token for live Swiggy MCP access. Optional; if absent or empty, the server uses a local sandbox fallback. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| plan_and_optimize_group_mealC | 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. |
| execute_group_cart_and_splitB | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.