MCP pour l'e-commerce : utiliser les outils Store avec l'IA en sécurité

Modèle Context Protocol donne à un client compatible une manière standard de découvrir des outils nommés, lire des resources bornées et appeler un serveur avec des arguments structurés. Il ne sécurise pas un Store, n'autorise pas un paiement et ne remplace pas seul le paiement. Le serveur MCP identifie l'acteur, valide chaque entrée, applique les règles du produit et du Store et rend un résultat typé. Le modèle est un client qui demande une capacité, pas le propriétaire de l'état commerce.

Publiez des actions étroites comme search_catalog, get_product, create_cart_draft, request_checkout, get_order_status ou draft_catalog_update. N'exposez pas de requêtes brutes, HTTP arbitraire, secrets fournisseur ou execute générique. Chaque outil a besoin de schémas, périmètre Store, risque, idempotence, délai d’attente et échec clair. Les resources expliquent règles et catalogue, mais un texte non fiable ne donne aucun outil et ne réduit aucun contrôle.

Les outils acheteur et creator-management relèvent de surfaces d'autorité différentes. Un acheteur peut chercher, comparer, préparer le panier d'un Store, commencer un paiement permis ou lire sa commande. L'responsable examine brouillons, alertes stock, remises, commandes et reconciliation seulement avec le grant exact. Un Agent lié reçoit uniquement les capacités sélectionnées et n'hérite ni ownership, ni accès fournisseur, ni outils d'un autre Store.

Produits, prix, stock vendable, commandes, paiements, remboursements, fulfillment, clients et consentement restent dans les services commerce autoritatifs. MCP traduit une requête typée et rapporte le résultat engagé ; il ne fabrique pas une seconde vérité depuis la conversation. Utilisez révision checks pour les brouillons et idempotency keys pour les effets répétés. Après un délai d’attente fournisseur, rendez unknown ou pending et réconciliez au lieu d'inventer un succès.

Utilisez OAuth ou une identité vérifiée et scoped, le moindre privilège, des sessions courtes, une confirmation explicite pour les writes importantes et un contrôle immuable avec actor. Validez Store, identité, montant, devise, révision de prix, état et capacité à l'exécution. Les grants doivent être révocables ; séparez lecture et write et échouez fermé pour toute outil obsolète, absente, cross-Store ou ambiguë. La confirmation ne remplace pas la validation serveur.

Codex, ChatGPT, GitHub Copilot et les autres clients diffèrent en transport, authentification, discovery, approvals et contrôles admin ; vérifiez le client et le plan exacts. Commencez par catalogue ou statut de commande lecture-only, puis une brouillon action réversible, et testez invalid, duplicate, obsolète, entre comptes, délai d’attente et accès révoqué. Prostir Store est en Aperçu, autour d'un commerce root, d'un Agent existant autorisé et de https://{slug}.store.prostir.build/mcp ; validez l'adéquation avant de remplacer un chemin stable.