Comparatif CMS

Votre agent peut gérer la boutique, pas seulement les textes

Enregistrer un remboursement, créer un code d'excuses, mettre à jour la bannière promo et publier - une conversation avec Claude, un serveur MCP, un workspace. Et ce que cmssy laisse volontairement à votre prestataire de paiement.

É
Équipe Cmssy
7 min read

Votre agent peut gérer la boutique, pas seulement les textes

La plupart des serveurs MCP de CMS s'arrêtent au contenu. Voici un cas de support - remboursement, réduction, bannière, publication - traité par un agent en une conversation, avec ses garde-fous.

Un mardi après-midi

Un client écrit : le mug est arrivé cassé. Voici ce que cela demande habituellement dans une architecture headless :

  1. Rembourser l'argent chez le prestataire de paiement.
  2. Enregistrer le remboursement dans le backend de commerce pour que stock et rapports concordent.
  3. Créer un code de réduction pour que le client revienne.
  4. Pendant que vous y êtes, la bannière de la page d'accueil annonce encore la promotion de la semaine dernière. La modifier dans le CMS et publier.

Cela fait trois ou quatre panneaux d'administration, et avec la plupart des CMS headless au moins deux fournisseurs, car le CMS détient le texte et autre chose détient les commandes.

Dans cmssy, les commandes, les réductions et les pages vivent dans un seul workspace, et le serveur MCP les expose toutes. Chaque étape après la première tient en une seule conversation avec un agent.

Le même après-midi, en une conversation

Voici Claude Code connecté à un workspace cmssy via MCP. Les prompts sont ce que vous tapez ; les noms d'outils sont ce que Claude appelle.

1. Retrouver la commande

Trouve la dernière commande de anna@example.com et montre-moi ses lignes.

Claude appelle list_orders avec search (qui correspond à l'e-mail du client), puis get_order pour les lignes, les paiements, les colis et les totaux.

2. Enregistrer le remboursement

J'ai remboursé le mug dans Stripe, id de remboursement re_3Q... pour 24.00 EUR.
Enregistre-le sur la commande.

Claude appelle refund_order avec l'id de la commande, amount: 2400 (les montants sont en unités mineures) et l'id de remboursement Stripe comme reference.

Notez ce que cela fait et ne fait pas. cmssy ne déplace pas d'argent. Les paiements sont encaissés et remboursés par votre propre prestataire. cmssy enregistre le résultat. L'id de remboursement est obligatoire, et envoyer deux fois le même id n'enregistre rien en double. Un remboursement total remet aussi en stock les unités qui n'avaient pas encore été expédiées et annule les colis qui attendaient encore leur expédition. Dans tous les cas, cmssy déclenche un webhook order.refunded ou order.partially_refunded, de sorte que votre service de comptabilité ou d'e-mail en soit informé.

3. Créer le code d'excuses

Crée un code de 15 % SORRY-ANNA, une seule utilisation, valable 30 jours.

create_discount avec type: "percentage", value: 15, maxUses: 1 et un endsAt. La boutique l'applique au paiement via l'API de diffusion, comme n'importe quel autre code.

4. Mettre à jour le bloc promo

Sur la page d'accueil, change la bannière promo pour annoncer la livraison
gratuite ce week-end, dans toutes les langues que nous avons.

Claude lit la page avec get_page, trouve le bloc de la bannière et le modifie avec update_block_content. Claude prend les noms de champs dans le manifeste de blocs de votre site (list_block_types), et le serveur avertit lorsque le contenu ne correspond pas, de sorte que la bannière reçoit les champs que votre composant affiche. La modification reste dans le brouillon.

5. Publier

Publie la page d'accueil.

publish_page. Si votre site a une route de revalidation abonnée à content.changed, la nouvelle bannière est en ligne quelques secondes plus tard. cmssy n'affiche pas la page ; c'est votre application qui le fait, sur votre hébergeur.

Ce que couvre le serveur

Le même serveur, avec le même jeton :

  • Contenu : pages, blocs, zones de mise en page, types de pages, médias, formulaires et leurs soumissions, modèles de données personnalisés et enregistrements.
  • Commerce : commandes (commandes manuelles, modifications, paiements enregistrés, remboursements, annulations, factures, pipeline de commandes), retours, expéditions, paniers, réductions, produits et stock, listes de prix et canaux de vente.
  • Clients : les comptes qui se connectent à votre site. Claude peut les lister, en suspendre ou en débloquer un, ou envoyer une réinitialisation de mot de passe.
  • Webhooks : créer, modifier et renouveler les endpoints, et lire leur journal de livraison.

La liste complète, avec la permission requise par chaque outil, se trouve dans la documentation du serveur MCP.

Comparaison

Contentful, Sanity et Storyblok ont tous des serveurs MCP officiels, et ils font bien ce que ces produits stockent : entrées et documents, assets, types de contenu et schémas, releases. Si vous n'avez besoin que d'un agent qui rédige et publie du contenu, n'importe lequel fera l'affaire, et nous aussi.

La différence apparaît quand la tâche touche à l'argent. Ces plateformes ne détiennent pas vos commandes ; une boutique construite dessus garde ses commandes dans un système de commerce séparé. Les étapes 1 et 2 ci-dessus passent alors par l'API d'un autre fournisseur, avec un autre serveur MCP ou une intégration que vous maintenez. Dans cmssy, la commande, la réduction et la bannière se trouvent dans le même workspace, sous les mêmes rôles, derrière le même serveur.

Et pour être clair sur les limites : cmssy n'est pas un processeur de paiement et ne cherche pas à l'être. Votre checkout dialogue avec Stripe ou un autre prestataire, votre backend vérifie le webhook du prestataire, et seulement alors le paiement est enregistré dans cmssy.

Garde-fous

Un agent capable de rembourser une commande mérite plus de précautions qu'un agent qui modifie un titre. Voici ce qui le limite réellement :

  • Les rôles. Un jeton ou une connexion hébergée agit comme la personne qui l'a créé, avec le rôle de cette personne dans le workspace. Un remboursement exige la permission orders-manage. Un membre qui ne l'a pas obtient une erreur, pas un remboursement.
  • Les connexions en lecture seule. Lorsque vous connectez Claude via le serveur hébergé, vous pouvez n'accorder que la lecture. Toute écriture est alors refusée par le serveur, quel que soit le prompt.
  • L'approbation dans le client. Le serveur marque comme destructif chaque outil qui supprime, publie, rembourse ou annule. Claude Code demande confirmation avant d'exécuter tout outil que vous n'avez pas autorisé : gardez donc refund_order, cancel_order, publish_page et delete_page hors de votre liste d'autorisations et vous approuvez chacun au fur et à mesure.
  • L'assistant intégré à l'admin demande aussi. Quand ces mêmes outils s'exécutent dans l'assistant de l'admin, le serveur lui-même retient les outils destructifs jusqu'à ce que vous les approuviez d'un bouton.

À vous d'essayer

La configuration se résume à un jeton d'API, un .mcp.json et deux variables d'environnement. Le tutoriel Claude Code la détaille avec une application Next.js. Le contenu fonctionne sur toutes les offres ; le panier et le checkout nécessitent Pro.