Layout MCP - Order Coffee, Food, and Drinks Through Your AI Assistant

What this is

Layout MCP is a server that exposes Layout's merchant network as a set of tools any modern AI assistant can call. Through a Layout-aware agent, a user can say things like:

"Order me a medium iced oat latte with an extra shot from Blue Dove Coffee, pickup in 20 minutes."

…and the assistant will find the shop, pull the live menu, confirm the cart, and place a real order that prints on the café's kitchen display system. The user walks in 20 minutes later and the drink is ready at the counter.

This is not a chatbot demo. The orders are real. The menus are real. The merchants are real Layout customers running their daily business on Square-connected POS infrastructure. The same ticket that prints when a customer orders from the shop's branded Layout app prints when Claude places the order. Same SKUs, same modifiers, same kitchen workflow, same fulfillment.

The thing we're really shipping here is access. Independent shops have spent the last decade watching big chains build apps, build loyalty programs, build delivery integrations, and build whatever else the next platform shift required. Most local shops can't afford any of that. Layout's job has always been to close that gap by giving them the same tooling chains have, without making them build it themselves. Layout MCP is the next piece of that. Big chains will pay millions to be the default answer when somebody asks an AI to order coffee. Layout shops get it for free, by being on Layout.

Who it's for, right now

Three audiences, three doors.

1. AI platforms

Any MCP-compatible AI assistant can connect to Layout. Claude is the first integration, and the same surface is built to power ChatGPT, Perplexity, Gemini, and anything else MCP-shaped that comes next. AI platforms get a single API key, identify themselves as the calling platform, and act on individual users' behalf through short-lived consumer session tokens.

If you're an AI platform building agentic commerce features, the entire interface is described in one Markdown file at bedrock.layoutmobile.com/v1/docs.md. Fetch it, read it, you're done. There's no SDK to install. That's intentional. Agents read documentation, agents do not install SDKs. The doc is the contract, and it's written for the model to consume directly, with the same structure, examples, and error tables a developer would want.

The platform key identifies you as the calling AI, not the user. Each call that acts on a specific user's behalf carries a second token, the consumer session, that's tied to that one user. That separation means we can rate-limit per platform and per consumer independently, audit which platform placed which order, and revoke a single user's access without affecting the platform.

2. Merchants

Layout MCP is opt-in per merchant, controlled by a toggle inside the Layout Dashboard. Any merchant who is already running on Layout, which is a Square-native, white-labeled mobile ordering platform for independent cafés, QSRs, and restaurants, can enable agentic ordering and immediately become visible to every AI assistant on the network. No extra integration. No new menu management. The menu the merchant already maintains in Square is the menu the agent sees.

The MVP today serves Square-connected merchants. Toast, Clover, and Shopify support are on the roadmap as Layout's POS integration footprint expands.

We're rolling out merchants in waves. Nord Coffee is our first live partner. The reason for the slow rollout is simple: we'd rather get the agent flow right against a handful of real shops and real orders than ship something half-broken to hundreds of merchants at once. Every order that goes through the system right now gets reviewed. Every edge case in modifier handling, every weird menu shape, every timezone bug, gets caught early and fixed before the network expands. Merchants reading this who want in early can reach out and we'll prioritize onboarding.

3. End users

Customers don't sign up for "Layout MCP" specifically. They interact with their AI assistant the way they already do. The first time they ask Claude to order something from a Layout merchant, Claude hands them a one-time browser link to verify their phone and create a Layout account in about 30 seconds. After that, the agent can place orders on their behalf any time.

The user never gives the agent their phone verification code. They never give the agent any sensitive information. All of the trust-establishing steps happen in the user's own browser, on a Layout-controlled page, with Firebase Phone Auth doing the verification. The agent only ever sees a short-lived session token, which can be revoked at any time by saying "sign me out of Layout" or by hitting the same revoke endpoint from the dashboard.

How it works

The flow is deliberately short. There are five steps, in order.

1. Onboard

The agent calls start_onboarding with one of three modes: signup for a new user, signin for a returning user, or dashboard for a user who wants to view or edit their account. The server returns a single-use URL that expires in 15 minutes and a session ID the agent uses to poll for completion.

The agent hands that URL to the user in the chat: "Tap this link to connect your Layout account." The user opens it, verifies their phone via SMS, fills in their name and email if they're new, and the page mints a consumer session token. The agent polls poll_onboarding_status every few seconds, and when status flips to completed, the token is returned exactly once. The agent saves it associated with that user's identity on the platform side. If the user later asks to update their email or check their account, the same flow runs again in dashboard mode and lands them on the account view page.

The token returned here is the only credential the agent ever holds on the user's behalf, and it's scoped narrowly. It can place orders, pull menus, read the user's order history, and revoke itself. It cannot do anything else.

2. Find a merchant

search_merchants takes a query string and returns merchants that have opted into agent ordering. The response includes the merchant's name, cuisine type, description, website, currency, and an array of locations with addresses, timezones, and phone numbers. Each merchant also carries an acceptsAgentOrders flag.

Merchants who haven't opted in aren't returned from the search endpoint at all. If the agent queries a specific merchant by ID and that merchant exists but is opted out, the response comes back with acceptsAgentOrders: false and a specific error code (merchant-not-accepting-agent-orders) the agent uses to give the user a clear answer: "I found this shop, but they don't accept agent-placed orders yet." No guessing, no failed orders, no ambiguity.

3. Get the menu

get_menu returns the merchant's live catalog: categories, items, variations (size and style choices), modifier lists (milk choices, extras, syrups), prices in cents, availability flags, sold-out state, and item images. This is the same catalog the merchant manages in their Square dashboard. There is no separate "agent menu" to maintain.

The shape is designed for agents to reason about cleanly. Each item has a list of variations the user must pick exactly one of. Each item has a list of modifier lists, and each modifier list has required: true or false, plus minSelection and maxSelection bounds, and a selectionType of single or multiple. Required modifier lists must be resolved with the user explicitly. The agent does not pick defaults silently when a shop says "you must choose a milk." Sold-out items are flagged and not offered. Prices are authoritative, the agent never guesses, never estimates, and never makes up a number.

The catalog response also includes category ordinals so the agent can present items in the order the merchant intends, not alphabetically or by some arbitrary sort.

4. Confirm with the user

Before placing an order, the agent presents the full cart to the user: merchant name, each item with its variation and modifiers and quantity and individual prices, the pickup time, and the total. The user has to explicitly confirm. The agent doesn't pick defaults silently on required choices, doesn't fabricate items, and doesn't proceed on ambiguous answers like "sure I guess." If the user wants to change something, the agent updates the cart and re-confirms from the top.

This is a hard rule, not a suggestion. The API will accept the order whether or not the agent confirmed, but the docs the agent reads are explicit that confirmation is required, and the audit logs we keep make it obvious when an agent platform skips this step. We expect every integration to do this right.

5. Place the order

place_order sends the cart to the Layout REST API, which translates it into a Square order, attaches the consumer's Square customer record, applies the appropriate fulfillment metadata, and routes it to the merchant's kitchen display system. The request body includes the company ID, optional location ID, an array of items with their catalogVariationId and quantity and optional notes and modifiers, an optional pickupAt time (defaulting to 15 minutes from now), and an idempotencyKey we strongly recommend the agent generates and reuses on retries.

The response comes back with an order ID, the underlying Square order ID, the Square location ID, the status (typically placed on success), the subtotal and total in cents, the currency, a compApplied flag, and the confirmed pickup time. The agent then tells the user where and when to pick it up.

get_order_status returns the same shape later if the agent or the user wants to check in. list_my_orders returns up to 50 of the consumer's most recent orders, useful when the user asks "what did I order last time?" or "reorder my usual."

Payments, and why we're not collecting them yet

This is one of the most important design choices in the MVP, so it gets its own section.

Pickup orders placed through Layout MCP today are not charged. No card collection in chat, no card-on-file requirement, no payment screen anywhere in the flow. The order goes through to the merchant as a comped order, with compApplied: true set on the response so the agent and the user both know payment was not taken.

The reason for this is straightforward. Payment data is the highest-stakes piece of agentic commerce. Getting it wrong, exposing it to the wrong party, letting an agent see something it shouldn't, fumbling the fraud surface, any of those undermines trust in the entire category before it has a chance to prove itself. We'd rather get the ordering rails completely right first, on a small set of merchants who are happy to comp the early agent orders while we validate the flow, and then layer payments on top once we know the foundation is solid.

The merchant side of this is also intentional. Comped orders are a small marketing expense for the shop, equivalent to the kind of free-drink promotion they'd run on their own loyalty program, in exchange for being the very first shops on the agentic commerce network when AI assistants become the primary way people discover and order from local businesses. The shops we've talked to understand the trade and are excited about it.

When payments do come online, they'll work the way they should: one card on file in your Layout account, used by every agent on every platform, without any agent ever seeing the card itself.

What you don't have to think about

A lot of work went into making the agent-side and merchant-side experiences boring in the right way.

Merchants don't change their workflow. Agent orders look like regular pickup orders on the KDS. Staff don't need to know an AI placed it. The ticket prints with the customer's first name and pickup time, exactly like a Layout app order or a phone order.

Menus are unified. No "agent menu" versus "in-store menu." The Square catalog the merchant already maintains is the source of truth. When the merchant marks an item sold out, Layout MCP knows within seconds. When the merchant adds a new seasonal drink, the agent sees it on the next menu fetch. There is no syncing step, no double-entry, no agent-specific copy to write.

Identity is real. Each user has a real Layout consumer account, tied to a verified phone number, with a real first name, last name, and email. No anonymous bot orders. If a shop calls a number to ask about an order, there's a real person on the other end.

Audit trail is complete. Every order is shadow-logged with the agent platform, the consumer session ID, the full request payload, the Square response, and the merchant disposition. If something goes wrong, there's a record. If an agent platform behaves badly, we can see it. If a single user reports an issue, we can trace exactly what happened in seconds.

Rate limits are enforced. 60 requests per minute per platform key, 30 per minute per consumer session, 5 orders per hour per consumer, 20 per day per consumer. Agents can't run wild, can't accidentally double-order, can't flood a shop with traffic. When limits hit, the API returns a 429 with a Retry-After header the agent reads and respects.

Errors are structured and specific. Every error response carries a machine-readable code (merchant-not-found, invalid-pickup-at, order-velocity-hour, and so on) and a human-readable message. The docs spell out exactly what the agent should say to the user for each case. No raw error codes leak to end users. No agent has to invent error copy on the fly.

Standards-based, not vendor-locked. Built on MCP, the open protocol any AI tool can speak. The same REST surface beneath it will power non-MCP integrations like OpenAI function tools without a rewrite. Nothing about this design ties merchants or users to one AI platform.

The bigger picture

Layout MCP is a launch, but it's also a bet. We think agentic ordering is going to be a major category over the next few years, on the same scale that mobile ordering became a major category in the 2010s. The shift is going to favor whoever has the merchant network and the rails ready when the moment arrives.

Local shops have been losing ground to chains for two decades because chains have better technology. Better apps, better loyalty, better data, better deals with delivery platforms. Layout exists to close that gap, shop by shop. Layout MCP extends that mission to the next interface. When the default way to order coffee becomes "ask the AI assistant on your phone," local shops on Layout will be there in the answer set, right next to Starbucks and Dutch Bros, without having paid a dime for distribution.

That's the goal. That's what we're building.

What's next

A few things on the roadmap worth flagging.

Unified payments across every agent platform. Today's MVP is about getting the rails right, proving that orders flow end-to-end, that menus are accurate, that fulfillment works at the merchant's counter. The next phase introduces a single Layout-managed payment method that any agent on any platform can use to charge a real card. You'll set up your payment method once in your Layout account, and Claude, ChatGPT, Perplexity, and any other agent will all be able to use it without ever seeing your card data themselves.

More POS integrations. Square is first because it's where Layout's current merchant base lives. Toast, Clover, and Shopify support are on the roadmap, which will roughly quadruple the addressable merchant footprint when complete.

More agent platforms. Claude is the first integration. The architecture is platform-agnostic. Every other major AI assistant ships with the same surface as soon as they're ready to plug in.

More merchant categories. The MVP focuses on cafés, QSRs, and pickup-friendly restaurants, the categories Layout already serves. As the network grows, the same agent ordering layer extends naturally to any merchant where ordering through a mobile app already makes sense: bakeries, bowls, sandwiches, juice bars, breakfast spots, fast-casual everything.

Scheduled and recurring orders. "Order my usual every Tuesday at 7:30am" is a feature we want to ship. The plumbing already supports it. The agent surface and the user-side approval flow are what's left.

Saved favorites and reorder. The list_my_orders endpoint is the start of this. The next step is making "reorder my last drink from Nord Coffee" a one-message interaction with no confirmation friction, while still keeping the explicit-confirmation rule intact for new or changed orders.

Try it

If you're a developer building on top of an MCP-compatible AI assistant, point your client at https://mcp.layoutmobile.com/mcp, request a platform API key, and read the agent API reference at bedrock.layoutmobile.com/v1/docs.

If you're a Layout merchant, the agentic ordering toggle is now visible in your Order Settings page in the Layout Dashboard (currently behind the testing flag during rollout). Flip it on, and your shop becomes part of the network.

If you're a user, just ask Claude to order you a coffee from a shop you know is on Layout. It'll walk you through the rest.

If you run a shop that isn't on Layout yet and you want to be part of this, the place to start is layoutmobile.com.

For everything else: hello@layoutmobile.com.