Usual menus answer first
When you ask for the menu of a location Layout has not read yet, POST /v1/menus and the MCP menu tool now answer at once with the restaurant's usual menu, if Layout knows it. Before, the answer was status: "reading" and the usual menu came back only if that read failed. See POST /v1/menus.
What changed
- Order of answers. This location's own recent menu first. Then the restaurant's usual menu, marked
scope: "chain". A live read starts only when Layout knows neither. - No allowance spent. A usual menu draws nothing from your live menu read allowance. The per-person request limit still applies.
- The location is still read. Asking counts toward Layout reading this location, so a later ask can return its own priced menu, with no
scope.
Why it matters
You get a menu on the first call for most locations of a restaurant Layout already knows, instead of polling a read.
What to do
Nothing, if you already handle scope: "chain". If you do not, treat it as what this location probably carries, not its exact menu, and show no prices for it.
Breaking changes
None. No field was added or removed. You may see scope: "chain" more often, and status: "reading" less often.