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

Model Context Protocol donne à un client compatible une manière standard de découvrir des tools 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 checkout. 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 provider ou execute générique. Chaque tool a besoin de schemas, scope Store, risque, idempotence, timeout 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 tools 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 checkout permis ou lire sa commande. L'owner examine drafts, alertes inventory, 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 provider, ni tools d'un autre Store.

Produits, prix, inventory 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 revision checks pour les drafts et idempotency keys pour les effets répétés. Après un timeout provider, 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 audit immuable avec actor. Validez Store, identité, montant, devise, révision de prix, état et capability à l'exécution. Les grants doivent être révocables ; séparez read et write et échouez fermé pour toute tool stale, 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 read-only, puis une draft action réversible, et testez invalid, duplicate, stale, cross-account, timeout et accès révoqué. Prostir Store est en Preview, 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.