All servers · Scraping & browsing · Images & design
com.cordering/whitelabel-ordering
com.cordering/whitelabel-ordering · v0.0.1
Has write/delete tools
Measured by MCP Station
| Last check | Reachable |
|---|---|
| Checked at | — |
| Check success 7 / 30 days | — |
| First-try success 30 days | — |
| Median response | — |
| Lookups 30 days | — |
| Authentication | No auth |
| MCP version | 2025-06-18 |
| Rank score | — |
| Declared risk | Has destructive tools (destructiveHint) |
| Capabilities declared | completions, prompts, resources, tools |
| Tool definitions | 10 tools · with description 100% · input schema is an object 100% · read/destructive hints 100% |
Description written by the publisher, not verified
Order food from Cordering white-label restaurants: browse menus, confirm, then place an order.
Connect
streamable-http · https://wl-mcp.cordering.com/mcp
claude mcp add --transport http whitelabel-ordering https://wl-mcp.cordering.com/mcp{
"mcpServers": {
"whitelabel-ordering": {
"url": "https://wl-mcp.cordering.com/mcp"
}
}
}Tools as reported by the server
list_menuShow the restaurant's menu to the user as a visual HTML document — a horizontally-scrollable category strip with item photos, names and prices. Present the returned HTML by opening it as an HTML artifact; do NOT paste the markup into the chat as text. (Ordering does not require this — prepare_orderprepare_orderResolve a natural-language food order (one or more items) to concrete menu items and return a summary plus a confirmation token. Does NOT place the order. Call place_order with the returned token to actually place it. Delivery is as soon as possible by default; pass 'date' to ask for a later time inplace_orderwrite/deletePlace an order previously staged by prepare_order. Requires the confirmationToken returned by prepare_order. This causes a real order to be sent to the vendor.check_orderCheck the current status of an order the user has already placed, using the order number returned by place_order. Reports whether the restaurant has accepted it, whether it is on its way, and whether it has finished (delivered or declined). There is no background tracking and no notification: call tlist_vendorsFind restaurants (vendors) available for ordering. This is the discovery entry point: each card shows the clientId and vendorId that list_menu and prepare_order need. Call it with no arguments to list every restaurant — that is the normal case. Returns a complete, self-contained HTML document of venlogoutwrite/deleteSign the user out. By default signs out of every restaurant; pass a clientId to sign out of one, and an account label to sign out just that account.loginStart signing the user in to a restaurant so they can place orders. Browsing the menu never needs this — only ordering and saving an address do. Returns a URL the user must open in a browser to sign in with Google or Apple; afterwards they copy the 'code' value from the address bar and you call submsubmit_login_codeComplete a sign-in started by login, using the 'code' value the user copied from the browser address bar. On success the user can place orders from that restaurant.list_accountsShow which accounts are signed in, per restaurant, and which one is active. Useful when the user keeps separate work and personal accounts.switch_accountChoose which signed-in account to order with at a restaurant, e.g. to switch between work and personal. The account must already be signed in via login.
Repository · JSON · Text for agents · Registry updated 2026-08-28