blinkit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HEADLESS | No | Set to 'true' to run browser in headless mode, 'false' to see the browser action |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_loginA | Check if the current session is logged in. Returns 'Logged In' or 'Not Logged In'. |
| set_locationA | Manually set the delivery location via search. Pass 'detect' to click 'Detect my location'. The flow should be: login -> set_location('detect') -> add items -> check_cart -> if address not same, use get_addresses and select_address. Do not use this tool to fix address after adding items. |
| loginA | Log in to Blinkit. Returns status or prompts for OTP (which will be sent to your phone). |
| enter_otpC | Enter the OTP received on your phone to complete authentication. |
| searchB | Search for a product on Blinkit. Returns a list of items with their IDs. |
| add_to_cartB | Add an item to the cart. Optional: specify quantity (default 1). |
| remove_from_cartC | Remove a specific quantity of an item from the cart. |
| check_cartA | Check the current cart products, total value, and the delivery address. If the delivery address is not the intended one, use get_addresses and select_address to change it. |
| checkoutA | Proceed to checkout (clicks Proceed / Pay button). DO NOT call this if you need to change the delivery address. To change address, use get_addresses and select_address BEFORE checkout! Do not use set_location to fix address here. |
| get_addressesA | Get the list of saved addresses. Use this and select_address to change address on the cart page, if the address in check_cart is incorrect. |
| select_addressB | Select a delivery address by its index. Only use this BEFORE checkout. |
| proceed_to_payA | Proceed to payment (clicks Proceed button again). Use after selecting address. |
| select_payment_methodA | Select a payment method. Automatically chooses Cash on Delivery if available. If not, it opens UPI and generates a QR code to be scanned by the customer. |
| pay_nowB | Click the 'Pay Now' button to complete the transaction. |
| get_order_historyA | Fetch recent Blinkit order history in an LLM-friendly format: for each
order, its date, total, status, and the items bought (name, variant,
quantity, price). Use this to see what the user has ordered before and infer
recurring purchases when building an order. |
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 15 tools
Several tools overlap around the checkout/payment flow (checkout, proceed_to_pay, select_payment_method, pay_now all 'click the proceed/pay button'), and address handling is split across set_location, get_addresses, and select_address. The descriptions repeatedly warn 'do not use X here, use Y instead,' which signals real ambiguity an agent could misstep on, though the warnings do mitigate it.
All names use snake_case and mostly follow a verb_noun or verb_verb pattern (get_order_history, add_to_cart, select_address). A few single-word/verb-only names (login, search, checkout) deviate slightly but remain readable and predictable.
15 tools is reasonable for a full e-commerce ordering lifecycle (auth, search, cart, address, checkout, payment). The multi-step checkout/payment segment is somewhat heavy with four separate tools, but each maps to a distinct UI action.
The surface covers the core ordering lifecycle: login/OTP, search, add/remove cart, address selection, checkout, and payment. Minor gaps like order tracking or quantity-update beyond add/remove exist, but the essential flow is complete.