swiggy-mcp

Three independent MCP servers over Streamable HTTP. Carts, orders and tools are per server; the login is shared.

Every tool's exact parameters: references/tools.md. Journeys: swiggy-mcp-food, swiggy-mcp-instamart, swiggy-mcp-dineout; payments: swiggy-mcp-payments; docs lookup for coding agents: swiggy-mcp-docs.

Non-negotiable rules

1. Never invent a tool name, parameter or id. Parameters are camelCase (addressId, restaurantId, orderId, spinId) and are listed in the reference; ids come only from a previous tool response in this conversation. A guessed addressId fails silently in dev and load-bearing in prod.
2. Get explicit user confirmation before place_food_order, checkout, book_table, cancel_booking, flush_food_cart, clear_cart, delete_address. Show items + total + delivery address, ask "proceed?", wait for a clear yes. These spend money or destroy state and orders cannot be cancelled via the API.
3. Never blind-retry an order-placing tool. On a network error or 5xx, call get_food_orders / get_orders / get_booking_status first; if the order exists, treat the failure as success. Reads and cart mutations are safe to retry (cart updates are idempotent for the same args).
4. Read the cart at the start of any turn that touches it and again before placing. Cart state is server-side and the user may have changed it in the app; prices and stock move between turns. Never rely on what you remember.
5. Session credentials are never tool arguments. Auth is the bearer token on the connection.