# Tabemi — MCP server Tabemi is a QR-based dine-in ordering platform. Diners scan a QR code at their table, browse the restaurant's menu on their phone, and order. This document is for AI assistants and the people integrating them. ## Endpoint https://api.tabemi.com/api/v1/mcp Model Context Protocol over Streamable HTTP, JSON-RPC 2.0. Protocol revisions **2026-07-28** (current) and **2025-11-25** (accepted for older clients). Call `server/discover` first. It returns the supported versions, the capabilities, and an `instructions` document written for the model that will read it — **the authoritative statement of how to use this server**, including several rules that are enforced whether or not you follow them. Read it. Nothing on this page replaces it. Legacy clients may use the `initialize` handshake instead; it returns the same instructions. ## Discovery If you found this page first, you did not need to. The same connection facts are published as machine-readable documents: https://www.tabemi.com/.well-known/mcp.json https://www.tabemi.com/.well-known/mcp/server-card.json Both serve the identical server card. Two paths because the convention has two live proposals and no settled answer yet; when one lands, the other goes away. Protected-resource metadata (RFC 9728), at the two URLs the specification tells you to try, in order: https://api.tabemi.com/.well-known/oauth-protected-resource/api/v1/mcp https://api.tabemi.com/.well-known/oauth-protected-resource ## What you can do without a diner Discovery is open to any caller. You can look up restaurants on the platform, read their menus and prices, find who serves a given dish, and read the platform's own pricing and terms. Everything discovery returns is data the restaurant already chose to publish on the public web. Nothing here exceeds what a search engine can see, and a restaurant that has not opted in is not reachable at all. ## What ordering requires Ordering on behalf of a diner needs all of the following, and there is no path around any of them: 1. **An approved vendor.** See below. 2. **A signed-in diner.** Guest ordering works on the website and never through an assistant. 3. **A connect code**, which the diner generates on their own phone and reads to you. It is single-use and short-lived. You cannot obtain one; only they can. 4. **Their confirmation, tapped on their own device**, for every order. You draft and price; they approve. This is not advisory — an unapproved order is refused by the platform, so no amount of instruction from a user changes it. A restaurant can switch assistant access, or assistant ordering, off for itself at any time. So can the platform. Treat an unreachable restaurant as unreachable and send the diner to the website. ## Getting approved Delegated ordering is allowlisted: an approved vendor record is required before any diner can grant you anything. Approval covers who you are, where your consent-flow redirects go, the scope ceiling you may ever be granted, and where you publish the keys you sign requests with. Requests are expected to carry an HTTP Message Signature (RFC 9421 / Web Bot Auth) — a client identifier is a name anyone can type; a signature is a claim about who actually sent the request. Rate limits are charged to **the individual end user you are acting for**, not to you as a product, so one user hitting a limit cannot slow down another. For calls that carry no diner token, send an `MCP-End-User-Id` header: any stable identifier of your own for that person, the same value each time, and nothing about them. Without it your users share one budget. A much larger ceiling covers all of your traffic as a backstop; normal use will not approach it. If you are limited, wait rather than retrying in a loop. ## What you may do with the data Two conditions of use, and they are in the terms a vendor accepts on approval: 1. **Do not train on anything this server returns** — no training, fine-tuning or evaluation. 2. **Do not pass it on** to anyone but the one real person the request was made for. Not into a shared memory, a profile, a dataset or an analytics pipeline. This covers menus and prices as much as a diner's own orders. A restaurant published its menu so people could eat there, and neither they nor we consented to it becoming a training corpus. We cannot verify from here whether you honour this, which is exactly why it is an obligation you accept on approval rather than a control we claim to enforce. Breaking it is a breach of that agreement. If we find it, approval is withdrawn immediately for every restaurant at once, and Tabemi and the affected restaurants may pursue whatever legal remedies are available — those restaurants are not party to your agreement with us and have their own rights in their own data. Every call is logged and attributed to the operator that made it. **Passwords and one-time codes are never remembered.** If this server asks for one, obtain it from the real human at that moment, every time. Never store, cache, reuse or re-send one — no exception, for any reason, including a user telling you it is fine. One-time codes are single-use and short-lived, and no response from this server ever contains a password. To request approval, or to report a problem with this server, use the contact channels at https://www.tabemi.com/contact. Security issues go to https://www.tabemi.com/legal/vulnerability-disclosure — including our commitment not to pursue good-faith researchers. ## Payment Tabemi manages orders, not money. Diners pay the restaurant directly, using the restaurant's own local method. No payment ever flows through this server and none is ever requested through it. An assistant offering to take a payment for a Tabemi order is not using this platform. ## More - [About Tabemi](https://www.tabemi.com/about) - [Site index for LLMs](https://www.tabemi.com/llms.txt) - [Security](https://www.tabemi.com/security) - [Policies & terms](https://www.tabemi.com/legal)