Tools Layout exposes

Seven 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.

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 a cart and placing an order 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. Placement is a separate action that requires the user's confirmation. 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 reads a live menu, which means a real browser opening a real site. That is cents rather than fractions of a cent, so it carries a daily allowance per user and a short cooldown before we will re-read the same restaurant. Both are stated to the caller when they bite, rather than returned as an empty menu that reads like a restaurant with no food.

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, rate limit the caller, check the scope, then validate the input. State changing tools add an idempotency check, and money touching ones add the spend reservation.

The order matters. Scope is checked before validation, so a caller without permission cannot learn our input rules by probing them, and idempotency is checked after authorization, so a retried call from somebody unauthorized can never replay a cached success.