Skip to main content
Everything in this section faces the customer. For an assistant acting for the restaurant — reading its orders, sales and menus, creating discount codes and payment links — see the merchant MCP instead. The agent is buying lunch on someone’s behalf, so it has to answer the same questions the customer does: which venue, what is on the menu, what does it cost, is it available now. storekit answers those questions over four surfaces, each read by a different kind of customer-side agent. This page is the map; each surface has its own reference page. Nothing here is for the restaurant’s own side of the counter. At their most permissive these surfaces read a public menu and fill a basket; they do not change a menu, see an order queue or touch a store’s settings, and no credential on this page grants any of that.

​
Which Surface You Want

WebMCP tools

An agent inside the customer’s browser, on the page they are looking at.

MCP endpoint

An assistant somewhere else — ChatGPT, Claude, an IDE — talking to a venue.

UCP discovery

A commerce platform that reads a profile before it connects to anything.

llms.txt

A crawler that wants plain text instead of a JavaScript app.
Every reader below is acting for the customer, never for the restaurant: The first two share the shaping and pricing rules, so a burger is described, priced and refused on the same grounds whichever one asks — but they are not the same tools. Their names, arguments and writes differ, and a client cannot swap one for the other: WebMCP reads the page the customer has open and writes to the basket in front of them, while the MCP endpoint reads the public API and builds a cart that outlives the call.

​
What a Customer’s Agent Can and Cannot Do

On the two tool surfaces, reads need no credential and writes stop before money. UCP discovery and llms.txt are narrower: a profile and a plain-text snapshot, not tools. Over the WebMCP and MCP tools:
  • An agent can read a venue, its menu, an item’s option groups, the ordering methods it accepts and whether it is open. Remaining time slots are an MCP endpoint read only.
  • An agent can put items in a basket or a cart, change quantities and choose a fulfillment method.
  • An agent cannot pay. There is no checkout tool, no Pay at Table settlement and no discount handling. The customer opens the venue page to review the basket and pay, and a cart built through the MCP endpoint comes back with a link for exactly that.
  • An agent is never handed customer records. Nothing on these surfaces reads or stores an account, an address book or an order history.
  • An agent cannot act as the restaurant. There is no tool for editing a menu, snoozing an item, reading the order queue or changing store settings — those are the operator’s, through the dashboard and the webhooks and REST API.
Read tools carry MCP’s readOnlyHint annotation and basket writes do not, which is what lets a well-behaved client call a read on its own and ask the customer before a write.

​
Current Status

These surfaces are early. Treat the tool names and payload shapes as unstable until a page says otherwise, and expect the WebMCP half to move with the standard it follows.

​
For the Restaurant Side

A staff-facing interface — an assistant a restaurant’s own team can ask about its orders, sales and menus — is a separate product: the merchant MCP at mcp.storekit.com. It answers to the restaurant rather than to a customer, is credentialled with a dashboard sign-in, and is currently in beta. Nothing on the four pages above applies to it. Building against any of these, or want them turned on for your stores? Contact support, or use the storekit MCP/API Access Request form if you also need the REST API.