com.cordering/whitelabel-ordering
REMOTE · WL-MCP.CORDERING.COM · SCANNED SEP 24
Order food from Cordering white-label restaurants: browse menus, confirm, then place an order.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security57
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not fully verified: no authorisation is required to call this server, and 10 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. See how to fix → View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability74
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 1450 tokens (~145/item across 10 items; 10 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management90
- Stability observed for 27 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 10 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 11 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the com.cordering/whitelabel-ordering MCP server?
com.cordering/whitelabel-ordering is a hosted endpoint at https://wl-mcp.cordering.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · wl-mcp.cordering.com
claude mcp add --transport http com-cordering-whitelabel-ordering 'https://wl-mcp.cordering.com/mcp'
{
"mcpServers": {
"com-cordering-whitelabel-ordering": {
"url": "https://wl-mcp.cordering.com/mcp"
}
}
} {
"servers": {
"com-cordering-whitelabel-ordering": {
"type": "http",
"url": "https://wl-mcp.cordering.com/mcp"
}
}
} [mcp_servers.com-cordering-whitelabel-ordering] url = "https://wl-mcp.cordering.com/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-cordering-whitelabel-ordering": {
"type": "remote",
"url": "https://wl-mcp.cordering.com/mcp",
"enabled": true
}
}
} openclaw mcp add com-cordering-whitelabel-ordering --url 'https://wl-mcp.cordering.com/mcp' --transport streamable-http
mcp_servers:
com-cordering-whitelabel-ordering:
url: "https://wl-mcp.cordering.com/mcp" {
"McpServers": {
"com-cordering-whitelabel-ordering": {
"Transport": "http",
"Url": "https://wl-mcp.cordering.com/mcp"
}
}
} assistant mcp add com-cordering-whitelabel-ordering -t streamable-http -u 'https://wl-mcp.cordering.com/mcp'
{
"mcpServers": {
"com-cordering-whitelabel-ordering": {
"type": "http",
"url": "https://wl-mcp.cordering.com/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 24 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 22 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 20 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.
- 17 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.
- 15 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.
- 13 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 50 to 53. That category is still filling its 30-day observation window: 15 days of observed history at the previous scan, 16 at this one. The score rises as the window fills, whether or not the server changes.
- 11 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.
- 9 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 24 Sept 2026 · Probed https://wl-mcp.cordering.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=wl-mcp-dev.cordering.com | CN=WR3,O=Google Trust Services,C=US | 19 Aug 2026 | 17 Nov 2026 | RSA 2048 | SHA256-RSA | 53430388d305d51e09db5c59e9b1f3ac |
| SANs: wl-mcp-dev.cordering.com, wl-mcp.cordering.com | ||||||
| CN=WR3,O=Google Trust Services,C=US (CA) | CN=GTS Root R1,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | RSA 2048 | SHA256-RSA | 7ff005a91568d63abc22861684aa4b5a |
| CN=GTS Root R1,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 19 Jun 2020 | 28 Jan 2028 | RSA 4096 | SHA256-RSA | 77bd0d6cdb36f91aea210fc4f058d30d |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of wl-mcp.cordering.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| cordering.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| x-content-type-options | nosniff |
| x-frame-options | DENY |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://wl-mcp.cordering.com/mcp | Verified | 200 | |
| http (plaintext) | http://wl-mcp.cordering.com/mcp | HTTPS enforced |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
check_order ~136
Check 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 this again when the user asks, and only until the order is reported as finished.
| Name | Type | Req | Description |
|---|---|---|---|
| clientId | integer | – | clientId of the restaurant the order was placed with, from the list_vendors result. Omit only when the server is configured for a single restaurant. |
| orderId | integer | yes | The order number returned by place_order. |
No output schema declared.
No examples provided.
list_accounts ~35
Show which accounts are signed in, per restaurant, and which one is active. Useful when the user keeps separate work and personal accounts.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_menu ~141
Show 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_order resolves item names on its own.)
| Name | Type | Req | Description |
|---|---|---|---|
| clientId | integer | – | clientId of the restaurant, from a list_vendors result. Omit only when the server is configured for a single restaurant. |
| vendorId | integer | – | vendorId of the restaurant, from a list_vendors result. Omit only when the server is configured for a single restaurant. |
No output schema declared.
No examples provided.
list_vendors ~164
Find 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 vendor cards (logo, address, phone, delivery fee) — restaurants open today first in colour, those closed today greyed out at the bottom. Present the returned HTML to the user by opening it as an HTML artifact; do not paste the markup into the chat.
| Name | Type | Req | Description |
|---|---|---|---|
| city | string | – | City to filter by. Pass this ONLY when the user named a city themselves; never guess one from context, because a filter that matches nothing hides restaurants the user could have ordered from. |
No output schema declared.
No examples provided.
login ~126
Start 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 submit_login_code. Each restaurant has its own login, so this must be done per restaurant.
| Name | Type | Req | Description |
|---|---|---|---|
| clientId | integer | – | clientId of the restaurant to sign in to, from a list_vendors result. Omit only when the server is configured for a single restaurant. |
No output schema declared.
No examples provided.
logout ~94
Sign 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.
| Name | Type | Req | Description |
|---|---|---|---|
| clientId | integer | – | clientId of the restaurant to sign out of. Omit to sign out everywhere. |
| label | string | – | Account label to sign out, e.g. 'work'. Omit to sign out every account at that restaurant. |
No output schema declared.
No examples provided.
place_order ~53
Place 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.
| Name | Type | Req | Description |
|---|---|---|---|
| confirmationToken | string | yes | The confirmationToken returned by prepare_order. |
No output schema declared.
No examples provided.
prepare_order ~380
Resolve 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.
| Name | Type | Req | Description |
|---|---|---|---|
| bringTerminal | boolean | – | Whether the courier should bring a card terminal so the order can be paid by card on delivery. Pass true when the user wants to pay by card, false for cash; omit when they do not say. Ignored (with a… |
| clientId | integer | – | clientId of the restaurant, from a list_vendors result. Omit only when the server is configured for a single restaurant. |
| cutlery | boolean | – | Whether to ask the restaurant to include disposable cutlery. Only pass this when the user says either way; omit to leave it to the restaurant's default. Ignored (with a note) by vendors that do not o… |
| date | string | – | Delivery date-time as an ISO-8601 UTC instant, e.g. '2026-07-25T12:00:00Z'. Must be in the future. Defaults to 5 minutes from now (as soon as possible) — only pass this when the user asks for a speci… |
| deliveryAddress | string | yes | Delivery address text, e.g. 'Orlovica Pavla 26'. |
| items | array | yes | The item(s) to order — one or more lines, each with an item name, an optional quantity (default 1), an optional size, and optional extra ingredients by name. |
| notes | string | – | Optional notes for the vendor. |
| vendorId | integer | – | vendorId of the restaurant, from a list_vendors result. Omit only when the server is configured for a single restaurant. |
No output schema declared.
No examples provided.
submit_login_code ~120
Complete 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.
| Name | Type | Req | Description |
|---|---|---|---|
| clientId | integer | – | clientId of the restaurant being signed in to. Omit if only one sign-in is in progress. |
| code | string | yes | The code value copied from the redirect URL after signing in. |
| label | string | – | Optional label for this account, e.g. 'work' or 'personal'. Defaults to the email address on the account. |
No output schema declared.
No examples provided.
switch_account ~84
Choose 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.
| Name | Type | Req | Description |
|---|---|---|---|
| clientId | integer | – | clientId of the restaurant. Omit only when the server is configured for a single restaurant. |
| label | string | yes | Account label to make active, e.g. 'work'. |
No output schema declared.
No examples provided.
What is the com.cordering/whitelabel-ordering MCP server?
com.cordering/whitelabel-ordering is an MCP server listed in the public MCP registry as com.cordering/whitelabel-ordering. Order food from Cordering white-label restaurants: browse menus, confirm, then place an order. This page covers its hosted endpoint (https://wl-mcp.cordering.com/mcp).
Is the com.cordering/whitelabel-ordering MCP server safe to use?
com.cordering/whitelabel-ordering scores 77 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the com.cordering/whitelabel-ordering MCP server expose?
com.cordering/whitelabel-ordering exposes 10 tools: logout, check_order, submit_login_code, list_menu, prepare_order, and 5 more. Their descriptions and schemas cost roughly 1,333 tokens of context every time the server is loaded.
Does the com.cordering/whitelabel-ordering MCP server require authentication?
No. We connected to com.cordering/whitelabel-ordering without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the com.cordering/whitelabel-ordering MCP server still maintained?
com.cordering/whitelabel-ordering is still listed as active in the MCP registry. We last reached this channel on 24 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.