COrdering MCP server

• Registry namecom.cordering/whitelabel-orderingverified in the MCP registry

The registry name sits under cordering.com. The registry only lets a publisher use that namespace after proving control of the domain through DNS or HTTP.

• Stateanswerschecked 2026-10-24
• Tools10
• Server calls itselfplate-and-fork
• Server version0.0.1
• Protocol version2025-06-18

On 2026-10-24 the server answered initialize and tools/list without a sign-in. First answer in 509 ms.

• Whether its tools do the product's job has not been judged yet.
• Checked on 1 of the 7 days it takes to judge reliability.

Said by rules from the measurements above. The likely first call is a model's pick from the tool list; read its description before relying on it.

• INITE MCP scoreafter a weeka score needs 7 daily checks: 1 so far
• Answeredmeasuring1 of the 7 daily checks it takes to print a share
• Median first answer506 ms
• Space in an agent's context≈ 2,128 tokensthe definitions of all its tools (10), which an agent carries on every turn
• Tool definitionsA · 100 of 100
• Typed results0 of 10 toolsdeclared outputSchema: results come typed, read once

• Every tool passes all six checks.

A program checks the server once a day: initialize and tools/list, no model. Tokens are the definitions' length at about four characters a token. The grade averages six checks of every tool's name, description, schema and annotations; it says how well the tools are described, not whether they work. The score weighs what was measured and nothing else: answering (30%), doing the product's job (25%), definitions (20%), context (10%) and use (15%). A part that was not measured is left out, and a hidden instruction caps the score at 40. The state of vendors' MCP servers: method and numbers →

• list_menu

  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…

• prepare_order

  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. Delivery is as soon…

• place_order

  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.

• check_order

  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…

• list_vendors

  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…

• logout

  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.

• login

  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…

• submit_login_code

  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.

• list_accounts

  Show which accounts are signed in, per restaurant, and which one is active. Useful when the user keeps separate work and personal accounts.

• switch_account

  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.