Tools Layout exposes
Ten tools, deliberately few. Each one is an intent rather than an API call, so a host model makes one decision instead of orchestrating six steps and inventing the parts it does not know.
| Tool | What it does | Spends money | Costs us money |
|---|---|---|---|
order | Everything ordering: preview a restaurant, build a real priced cart, confirm it, check on it or release it | Yes, and only through its confirm action | Yes |
order_status | Read the state of a build or a placement | No | No |
menu | Look up items and prices on a restaurant's live menu, read from their own site | No | In live mode; knowledge mode opens no browser |
item_photo | Show what one menu item looks like, from the photo the restaurant itself published | No | Only when it has to read a fresh menu |
places | Find restaurants that exist near a person or in a place they named | No | No |
place_facts | Say what one place offers: vegetarian food, seating, takeout, good for groups | No | Once per place, then free |
discover | Recommend where this person should eat, from their own order history | No | No |
profile | Read and save the person's lasting food preferences | No | No |
help | Answer a question about Layout from Layout's own published help center | No | No |
get_location | Ask the person to share where they are with one tap, when the host cannot read it | No | No |
An app built on Layout that connects with a developer's build grant sees a smaller set. Each tool has to be allowed for grants explicitly, and a tool nobody decided about is refused.
The only tool that spends
order is the money surface, and it is one tool rather than four so that there is exactly one path to a charge and exactly one place to gate it.
Building and confirming are separate actions inside it. A build spends a browser session and writes an order record, so it requires an idempotency key, and it stops at a priced cart it cannot place. Confirming must name that order and the total the person was shown, and our server refuses it if the total does not match the stored cart, if it would break the daily limit, or if a texted code is owed and missing. The per order ceiling is enforced before the card is held. Nothing in the tool lets a caller skip from one to the other. See money controls.
The read only companion
order_status exists because an order takes a couple of minutes and a host model needs to be able to ask without paying for the privilege. It is free, safe to call repeatedly, and it is what a well behaved host polls instead of starting a second build. A second build is the failure mode that produces two lunches and two charges, so the cheap honest answer is deliberately the easy one to reach.
The one that costs us real money
menu in live mode reads a restaurant's own site with a real browser. That is cents rather than fractions of a cent, so it carries a daily allowance per person and a cooldown before we will read the same restaurant again. Both are stated to the caller when they bite, rather than returned as an empty menu that reads like a restaurant with no food. Knowledge mode, for questions such as what a place is known for, answers from general web knowledge, opens no browser, and says it is not the live menu.
The one that keeps us honest
help answers questions about Layout: refunds, charging, cancelling, privacy, setup. It returns articles from our published help center rather than answers, always with the public URL they came from, and its instruction to the model is explicit that a policy may not be stated from anything else.
An empty result is a real answer. A question our help center does not cover comes back with nothing and an instruction to say so, because handing back the closest unrelated article is how a model ends up confidently inventing a refund window. Everything it returns is fenced as reference material rather than instruction: see untrusted content.
What runs on every call
Whatever the tool, the same gates run in the same order before any work happens: authenticate the token, check the caller may use this tool at all, rate limit, check the scope, validate the input, then check the account's revocation watermark before a session is minted for the call.
The order matters. A call a session may not make costs nothing, not even a rate limit slot. Scope is checked before validation, so a caller without permission cannot learn our input rules by probing them. Idempotency is checked after authorization, so a retried call from somebody unauthorized can never replay a cached success, and the idempotency fingerprint includes the person, so one person cannot replay another's.
Updated October 21, 2026