Aperçu des agents de commande

Tout ce que contient cette section est tourné vers le client. Pour un assistant agissant pour le restaurant (lire ses commandes, ses ventes et ses menus, créer des codes de réduction et des liens de paiement), consulte plutôt le MCP marchand. L’agent achète le déjeuner pour le compte de quelqu’un, il doit donc répondre aux mêmes questions que le client : quel établissement, ce qu’il y a au menu, ce que ça coûte, si c’est disponible maintenant. storekit répond à ces questions via quatre surfaces, chacune lue par un type différent d’agent côté client. Cette page sert de carte ; chaque surface a sa propre page de référence. Rien ici ne concerne le côté restaurant du comptoir. Au maximum de leurs permissions, ces surfaces lisent un menu public et remplissent un basket : elles ne modifient pas un menu, ne consultent pas la file d’attente des commandes et ne touchent pas aux réglages d’un magasin, et aucun identifiant sur cette page n’accorde ce type d’accès.

​

Quelle surface choisir

Chaque lecteur ci-dessous agit pour le client, jamais pour le restaurant : Les deux premières partagent les règles de formatage et de tarification, donc un burger est décrit, tarifé et refusé sur les mêmes bases quel que soit l’appelant. Ce ne sont cependant pas les mêmes outils. Leurs noms, arguments et écritures diffèrent, et un client ne peut pas remplacer l’un par l’autre : WebMCP lit la page ouverte par le client et écrit dans le basket sous ses yeux, tandis que l’endpoint MCP lit l’API publique et construit un cart qui survit à l’appel.

​

Ce que l’agent d’un client peut et ne peut pas faire

Sur les deux surfaces d’outils, les lectures ne nécessitent aucun identifiant et les écritures s’arrêtent avant l’argent. La découverte UCP et llms.txt sont plus étroites : un profil et un instantané en texte brut, pas des outils. Via les outils WebMCP et MCP :

• Un agent peut lire un établissement, son menu, les groupes d’options d’un article, les modes de commande acceptés et savoir s’il est ouvert. Les créneaux horaires restants sont réservés à la lecture via l’endpoint MCP.
• Un agent peut mettre des articles dans un basket ou un cart, modifier les quantités et choisir un mode de fulfillment.
• Un agent ne peut pas payer. Il n’y a pas d’outil de checkout, pas de règlement Pay at Table et pas de gestion de réduction. Le client ouvre la page de l’établissement pour vérifier le basket et payer, et un cart construit via l’endpoint MCP revient avec un lien pour faire exactement cela.
• Un agent ne reçoit jamais les données personnelles d’un client. Rien sur ces surfaces ne lit ou ne stocke un compte, un carnet d’adresses ou un historique de commandes.
• Un agent ne peut pas agir en tant que restaurant. Il n’y a pas d’outil pour modifier un menu, mettre en snooze un article, lire la file d’attente des commandes ou modifier les réglages du magasin : ceux-là appartiennent à l’exploitant, via le dashboard et les webhooks et l’API REST.

Les outils de lecture portent l’annotation MCP readOnlyHint et pas les écritures dans le basket, ce qui permet à un client bien élevé d’appeler une lecture de sa propre initiative et de demander confirmation au client avant une écriture.

​

Statut actuel

​

Pour le côté restaurant

Une interface destinée au staff (un assistant que l’équipe d’un restaurant peut interroger sur ses commandes, ses ventes et ses menus) est un produit distinct : le MCP marchand à mcp.storekit.com. Il répond au restaurant plutôt qu’au client, s’authentifie avec une connexion au dashboard, et est actuellement en beta. Rien sur les quatre pages ci-dessus ne s’y applique. Tu développes contre l’une de ces surfaces, ou tu veux les activer pour tes magasins ? Contacte le support, ou utilise le formulaire storekit MCP/API Access Request si tu as aussi besoin de l’API REST.