For platform reviewers
If you are reviewing Layout for a connector directory, this is the page to read first. Everything here links to the detail behind it, and if something you need is missing, write to contact@layout.link and we will publish it rather than answer it once in an email.
The connector at a glance
| Server | https://mcp.layout.link |
| Transport | Streamable HTTP, per the MCP specification |
| Authorization | OAuth 2.1, authorization code with PKCE, per the MCP authorization spec |
| Authorization server | https://api.layout.link |
| Scopes issued | One, order |
| Tools | Seven. See tools Layout exposes |
| Money moving tools | One, order, and only after a user confirmation |
| Company | Layout, Inc. |
| Support | contact@layout.link, +1 (877) 318-8673 |
| Status | status.layout.link |
| Legal | Privacy policy, terms, DPA, subprocessors |
The questions reviewers actually ask
Can a model spend money on its own?
No. order is the only tool that can spend, and the placement step requires a confirmation the user gave against a total we calculated and displayed. The check runs on our servers against a stored order record, so no phrasing in a conversation can satisfy it and no host model can decide it has been satisfied. A user may also require a code we text them, bound to that one order at that one amount. New accounts start without it and the toggle reaches orders at or under fifty dollars only: above that figure the code is enforced whatever the setting says, and so is a risk step up. See money controls.
What can the connection reach if a host is compromised?
The scope order covers ordering and the user's own food preferences. A stolen or misused token can attempt orders, and every one of those attempts still hits the confirmation gate, the daily spend limit, and the texted code. It cannot read the user's card number, because we do not have it. It cannot change the user's spending limit, because that is not on this surface at all.
How is the token bound?
The access token is an RS256 JWT our authorization server signs. We verify the signature against our own JWKS and require both the issuer and the audience to match this resource, so a token minted for anything else is refused. The user identity comes from a claim inside that signed token and is never read from anything the caller asserts. See how the connector works.
Can a user revoke it?
Yes, and it takes effect on the next call rather than at the next token expiry. Revocation is a watermark on the account: every credential issued before the moment of revocation is void, including ones already in a host's hands. Layout's iOS app lists connected assistants and revokes them individually.
What happens to card data?
It never reaches us. The card is entered directly into our payment provider's PCI vault and we hold a token. Each order is paid with a Layout virtual card rather than the user's, so the restaurant never receives the user's real number either. See card data.
What stops prompt injection from a restaurant's website?
Two things, in the right order. The gate that matters is mechanical: the part of Layout that drives a checkout holds no card and cannot obtain one without a claim our server minted for a confirmed order, so text on a page has nothing to talk it into. Around that, content we return to a host model is fenced and labelled as reference material rather than instruction. The prompt level boundary is a default, not a guarantee, and we treat it that way. See untrusted content.
Is there rate limiting?
Yes, per user and per connecting client, plus a daily allowance and a short cooldown on the one read that costs us real money. See limits and availability.
What does Layout log?
Order records, event traces for debugging, and telemetry without payment details in it. Card numbers, security codes and session tokens are excluded by construction, not by redaction after the fact. See data we store.
Testing it
Ordering is real. Every successful order buys real food at a real restaurant with a real card, so we do not hand out an account and suggest you try it: a test order is somebody's lunch sitting on a counter.
For a review, write to contact@layout.link and we will set up a review account and walk the flow with you, including the confirmation and code ceremony, at a time when somebody is watching the run. If your review needs a sandbox that places nothing, say so and we will tell you honestly what we can and cannot simulate.
Where we are early
Stated here rather than discovered later. Layout is in invited beta. The card rail is early production: real orders are placed and paid, on a small number of restaurants a day, with a human watching more of them than will be true in a year. Pickup only. The failure we work hardest to avoid is a confident claim about an order that did not happen, and the honest state of any order is always available to the user, including "we are not sure yet."
Updated September 2, 2026
