Ordering moves to MCP
Building a cart over REST has moved to Layout's MCP server. POST /v1/orders now answers 410:
HTTP/1.1 410 Gone
{
"error": {
"code": "moved_to_mcp",
"message": "Building an order over REST has moved to Layout's MCP interface. Mint a build session with POST /v1/users/:id/grant, connect it to https://mcp.layout.link, and drive the `order` tool (preview, then build). Provisioning (POST /v1/users), order reads (GET /v1/orders/:id) and the events feed are unchanged."
}
}
Why it moved
Ordering is rarely one request. Which branch, which size, an item that is out of stock today, a choice the menu insists on: a single REST call has nowhere to put those questions, so it stalled or guessed. An MCP tool loop can ask, using the restaurant's own options, and build again with the answer.
What to do
Mint a build grant for the person, then connect it to the MCP server as a bearer token. There is no OAuth step for a server-minted grant.
curl -X POST https://api.layout.link/v1/users/usr_4b8e/grant \
-H "Authorization: Bearer $LAYOUT_SECRET"
201 Created
{ "token": "lgb_9f3a2c…", "expiresAt": "2026-09-13T18:00:41Z", "scope": "build" }
{
"mcpServers": {
"layout": {
"url": "https://mcp.layout.link",
"headers": { "Authorization": "Bearer lgb_9f3a2c…" }
}
}
}
Then drive the order tool: preview resolves a real store, build assembles the cart, and status follows it. Pass an idempotencyKey on build and carry it into any retry. The session builds and reads; confirming and paying happen on Layout's hosted page. See Ordering over MCP.
Honest tool discovery
A build grant session used to list every tool on the server and refuse most of them when called. It now lists only the three it can use: order, order_status and places. The boundary itself has not moved; discovery just stopped advertising tools you could not call.
Breaking changes
Yes. Any call to POST /v1/orders now fails with 410 moved_to_mcp. Provisioning, GET /v1/orders/:id, GET /v1/events and webhooks are unchanged, and orders built over MCP appear in all of them.