> ## Documentation Index > Fetch the complete documentation index at: https://storekit.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Endpoint MCP > Connecte un assistant IA à un magasin storekit via MCP : lis menu, options d'articles, modes de fulfillment et créneaux, et construis un cart tarifé. **À qui ça s'adresse :** un assistant ou une application agent agissant pour le client, hors de son navigateur. Si l'assistant agit pour le restaurant, tu veux plutôt le [MCP marchand](/docs/fr/developers/mcp/overview) à `mcp.storekit.com`. Chaque hôte de commande storekit est aussi un serveur [MCP](https://modelcontextprotocol.io) distant. Un assistant qui n'est nulle part près du navigateur du client (ChatGPT, Claude, une application agent, un IDE) peut s'y connecter, lire le menu d'un établissement, obtenir un prix et construire un cart que le client ouvre ensuite pour payer. ## Endpoints Il y a deux niveaux, et tous deux sont atteints sur l'hôte de commande propre au magasin : | Endpoint | Portée | | - | - | | `POST https://{host}/{venueSlug}/api/mcp` | Un seul établissement, pour un agent qui parle déjà d'un lieu | | `POST https://{host}/api/mcp` | Tous les établissements du brand sur cet hôte, résolus par appel | `{host}` est le domaine sur lequel les pages de commande du magasin sont servies, par exemple `order.storekit.com`. Les deux endpoints sont restreints à cet hôte, si bien qu'un brand sur son propre domaine ne peut répondre que pour ses propres établissements. Utilise l'endpoint brand quand le client n'a pas encore dit quelle succursale il veut : `find_venues` renvoie le slug que tous les autres outils prennent ensuite comme argument `venue`. Utilise l'endpoint venue quand le lieu est déjà fixé. Un `GET` ou `HEAD` sur l'un ou l'autre endpoint renvoie `200` et une ligne indiquant ce qu'est l'endpoint, ce qui permet à un client de le sonder avant d'ouvrir une session. ## Protocole JSON-RPC 2.0 sur HTTP, un message par `POST`. Les méthodes implémentées sont `initialize`, `ping`, `tools/list` et `tools/call` ; les révisions MCP `2025-06-18`, `2025-03-26` et `2024-11-05` sont toutes traitées dans la révision que le client demande. ```bash theme={null} curl -X POST https://order.storekit.com/gordon-ramsay-plane-food-1/api/mcp \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "search_menu", "arguments": { "query": "something vegan" } } }' ``` Chaque résultat est du JSON dans un bloc de contenu texte, dupliqué comme `structuredContent` pour les clients qui le lisent. L'endpoint est stateless : `initialize` ne renvoie aucun identifiant de session et rien n'est retenu entre les requêtes, donc une conversation porte le slug de l'établissement et l'identifiant du cart plutôt qu'une session. Les erreurs se répartissent selon qui peut agir dessus. Un argument mal formé est un JSON-RPC `-32602` nommant le paramètre ; tout ce dont l'assistant peut se remettre (pas de catégorie de ce nom, pas de correspondance, un établissement qui n'accepte plus de commandes) revient sous forme de résultat d'outil avec `isError: true` dont le texte indique quoi faire ensuite. ## Outils de lecture | Outil | Description | | - | - | | `find_venues` | Liste les établissements du brand, filtrés par nom, ville ou code postal. Renvoie le slug pris par les autres outils. | | `get_menu` | Le menu de l'établissement : chaque catégorie avec ses articles, prix, tags diététiques et disponibilité. Un menu très long est résumé, et un nom de catégorie renvoie cette catégorie complète. | | `search_menu` | Recherche dans le menu par nom de plat, catégorie ou description. Pour les menus trop longs pour être renvoyés entiers. | | `get_item` | Un article complet : les allergènes qu'il contient et peut contenir (`allergens.contains`, `allergens.mayContain`, parmi les 14 allergènes UK ; `null` quand l'établissement n'a rien déclaré, listes vides quand il a déclaré l'article sans allergène), sa valeur nutritionnelle quand l'établissement la publie (`nutrition` : kcal, puis grammes ; `null` sinon), le nombre de personnes qu'il sert dans un établissement de traiteur (`servings`), et chaque groupe d'options, combien de choix il accepte et combien coûte chacun. Les deux champs décrivent l'article de base ; une option qui ajoute des allergènes ou de la nutrition porte ses propres `allergens` / `nutrition`. | | `get_venue_info` | L'établissement lui-même : nom, adresse, numéro de téléphone, site web, description, s'il est ouvert maintenant, les horaires du jour, les horaires d'ouverture de la semaine complète (schema.org `OpeningHoursSpecification`) et les modes de commande qu'il propose. | | `get_available_fulfillment` | Comment on peut commander à cet établissement, le montant minimum pour chaque mode, s'il est ouvert maintenant, et les horaires du jour. | | `get_available_slots` | Les créneaux de livraison ou de retrait encore libres un jour donné. | `get_menu` et `search_menu` prennent tous deux des listes optionnelles `excludeAllergens` et `diets`. `excludeAllergens` nomme l'un des 14 allergènes UK (`celery`, `gluten`, `crustaceans`, `fish`, `eggs`, `lupin`, `milk`, `molluscs`, `mustard`, `nuts`, `peanuts`, `sesame`, `soya`, `sulphites`) et écarte tout article qui contient ou peut contenir l'un d'eux ; un article sans information d'allergène est conservé, car « non étiqueté » n'est pas la même chose qu'« exempt de ». `diets` nomme l'un des `halal`, `kosher`, `vegan`, `vegetarian`, `gluten free` et `dairy free`, et ne conserve que les articles étiquetés comme correspondant à chacun d'eux. Ce sont les mêmes règles que la page de commande applique à ses propres filtres allergènes et régimes, et le résultat renvoie sous `filters` les filtres qui ont été appliqués. Sur l'endpoint brand, chaque outil sauf `find_venues` prend un argument `venue` supplémentaire, et un slug qui n'appartient pas à ce brand est refusé avec la liste propre du brand plutôt que traité à partir du menu d'un autre brand. Les lectures portent `readOnlyHint`, si bien qu'un client peut les appeler sans demander au client au préalable. Les prix sont des chaînes formatées dans la devise de l'établissement, les descriptions sont nettoyées et tronquées, et chaque liste est plafonnée. > [!NOTE] > > Les modes de fulfillment sont rapportés à partir de ce que le payload de l'établissement prouve : Delivery, Pickup et InStore. Le Catering n'est pas proposé via MCP. ## Outils cart La capability cart suit exactement le [binding MCP cart d'UCP](https://ucp.dev/2026-08-25/specification/shopping/cart/mcp/), donc un client UCP n'a besoin d'aucune table de correspondance. | Outil | Description | | - | - | | `create_cart` | Construis un cart à cet établissement à partir d'articles du menu, tarifé dans la devise de l'établissement. | | `get_cart` | Relis et retarife un cart par identifiant. | | `update_cart` | Remplace les lignes du cart. Un remplacement complet, pas un patch : envoie chaque ligne que le cart doit contenir. | | `cancel_cart` | Abandonne le cart. | Ce que le binding signifie en pratique : * Chaque appel porte `meta["ucp-agent"]` avec ton profil d'agent. Un appel sans est rejeté. * L'identifiant du cart est un `id` de premier niveau, jamais imbriqué dans `cart`. * Les montants sont des entiers en unités mineures (`450` correspond à £4,50). * Un problème métier est un résultat réussi portant `messages[]` : une ligne qui n'est plus vendable y est signalée plutôt que de disparaître. * Les lignes sont nommées par identifiant d'article avec les options entre parenthèses, `BURGER(CHEESE;BACON:2)`, la même grammaire que celle utilisée par les [liens basket prefill](/docs/fr/developers/basket-prefill). Un cart contient une intention, pas des prix : chaque opération le résout et le retarife par rapport au menu tel qu'il est à cet instant, si bien qu'un cart stocké ne peut pas afficher un montant que la page de l'établissement contredirait. Les carts expirent 24 heures après leur dernière écriture, et rien de propre au client n'y est stocké. > [!WARNING] > > Un cart n'est pas une commande, et ces outils ne parlent que pour le côté client. Rien ici ne lit la file d'attente des commandes d'un magasin, ne modifie un menu ou ne change un réglage. Les outils renvoient une `continue_url` que le client ouvre pour vérifier le cart et payer sur la page de l'établissement : il n'y a pas d'outil de checkout, de paiement ou de réduction, et aucune commande n'est passée tant qu'il n'a pas terminé là-bas. ## Voir aussi > **[Découverte UCP](/docs/fr/developers/agents/ordering/ucp)** > > Le profil qui publie ces endpoints et la capability cart. > **[Outils WebMCP](/docs/fr/developers/agents/ordering/webmcp)** > > Le jeu d'outils distinct qu'un agent appelle à l'intérieur du navigateur du client. ## Related topics - [Découverte UCP](/docs/fr/developers/agents/ordering/ucp.md) - [Introduction pour les développeurs](/docs/fr/developers/introduction.md) - [Aperçu des agents de commande](/docs/fr/developers/agents/ordering/overview.md) - [Outils WebMCP](/docs/fr/developers/agents/ordering/webmcp.md) - [llms.txt](/docs/fr/developers/agents/ordering/llms-txt.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.