Skip to main content
Glama

StampyWallet

Modifier ma carte de fidélité

modifier_carte
Destructive

Change un ou plusieurs réglages de la carte de fidélité du commerce, en un seul appel : nom imprimé, style (collection, palette ou couleur libre), tampon, règle de récompense (mode tampons/paliers/points, seuils, récompenses), tampons offerts à l’inscription, expiration des récompenses, en mode paliers la forme de la carte (forme_paliers : tampons ou l’une des cinq formes), et en mode points le nom des points, la forme de la carte (forme_points), la valeur par défaut d’un passage, les raccourcis et les points par euro. Seuls les réglages donnés changent ; lire d’abord la carte avec voir_carte. Appeler avec confirmer=false (défaut) pour montrer l’avant/après, puis avec confirmer=true après accord explicite. Un changement de règle s’applique aussi aux cartes déjà chez les clients. Les images (logo, fond, tampon en image) se changent dans l’application, page Carte.

Input Schema

NameRequiredDescriptionDefault
nomNoNom du commerce, imprimé en haut de la carte.
modeNotampons : une récompense à un seuil (le plus simple). paliers : plusieurs récompenses sur la même carte (ex. 5 et 10). points : le commerçant saisit un nombre de points à chaque passage (paniers variables).
tamponNoLe signe posé à chaque passage. « rond » : le point simple. Beauté : etincelle, eclat, goutte, main, pinceau, oeil, ciseaux, sechoir, fleur, lotus, coeur, etoile, diamant, couronne, soleil, lune, talon, robe, sac, serviette. Food : cafe, grain, the, cookie, gateau, pain, part, burger, glace, bol, plat, verre, biere, bulles, cocktail, cerises, orange, avocat, piment, oeuf, poisson, fromage, popcorn, couteau, carotte, bocal, esquimau. Divers : feuille, flamme, eclair, sourire, patte, chien, chat, cadeau, haltere, velo, livre, note, appareil, palette, dent, parapluie, ballon, tshirt, basket, tulipe, plante, os, cintre, lavelinge, voiture, cle, botte, montagne, trophee, des, camion.
couleurNoCouleur de fond libre, en hexadécimal. L’encre (texte) est choisie automatiquement pour rester lisible.
paletteNoPalette de la collection : 0, 1 ou 2 (chaque collection en propose trois ; pass en propose une quatrième, 3). Ignorée si « couleur » est donnée.
paliersNoLes récompenses et leurs seuils (modes paliers et points). Du plus petit au plus grand.
tamponsNoNombre de passages pour obtenir la récompense (mode tampons), de 2 à 30.
confirmerNofalse (défaut) : rend seulement un aperçu de ce qui serait fait, sans rien changer. true : exécute. Toujours montrer l’aperçu à la personne et attendre son accord avant de repasser avec true.
collectionNoStyle de la carte : original (sobre), cafe (cadre fin), botanique (italique, feuillages), trattoria (festonné), atelier (moderne), pass (comme un pass Apple Wallet : logo en grand, tampons en objets ombrés, fond franc).
recompenseNoLa récompense (mode tampons). Ignorée si « paliers » est donné.
forme_pointsNoMode points : le dessin de la carte. medailles (défaut) : une jauge épaisse et une grande médaille par récompense. vitrine : les récompenses côte à côte, chacune sa petite jauge. remplissage : la prochaine récompense en grand, qui se colore à mesure. chemin : une route en S, les récompenses en étapes. anneau : une jauge ronde autour de la prochaine récompense, la liste à côté. Les photos des récompenses se déposent dans l’application, page Carte.
forme_paliersNoMode paliers : le dessin de la carte. tampons (défaut) : les tampons en grille, chaque récompense à la place du tampon de son seuil. Ou l’une des cinq formes des points, qui compte alors des tampons : medailles (une jauge et une médaille par récompense), vitrine (les récompenses côte à côte, chacune sa jauge), remplissage (la prochaine récompense en grand, qui se colore), chemin (une route en S où chaque tampon fait avancer le curseur), anneau (une jauge ronde autour de la prochaine récompense). Les photos des récompenses se déposent dans l’application, page Carte.
nom_des_pointsNoMode points : comment s’appellent les points (« points », « graines », « étoiles »…).
points_par_euroNoMode points : points par euro dépensé, repère affiché au commerçant (ex. 1 ou 0,5).
points_par_defautNoMode points : points posés par défaut à chaque passage (1 à 100 000).
points_raccourcisNoMode points : les valeurs proposées d’un geste au scan (jusqu’à 6, triées et dédoublonnées). Ex. [1, 2, 5, 10].
tampons_bienvenueNoTampons offerts à l’inscription du client (0 à 5). 1 par défaut : une carte entamée donne envie d’être finie.
expiration_recompense_joursNoJours pendant lesquels une récompense gagnée reste valable : 0, 30, 60, 90, 180, 365 (0 = n’expire pas).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructive=true, idempotent=false and readOnly=false; the description adds important behavioral context beyond them: only supplied settings change, rule changes affect cards already held by customers, and changes should first be previewed. The preview/confirmation contract is especially valuable for a destructive mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized for a complex 18-parameter mutation and is front-loaded with purpose, prerequisites and confirmation workflow. However, it is a dense single paragraph rather than structured bullets, making the mode-specific parameter groups harder to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity, annotations and lack of output schema, the description covers what an agent needs: scope, preview-before-commit, read-first guidance, propagation to existing customer cards, and what is out of scope. No critical decision information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 18 parameters are already well documented in the input schema. The description restates the parameter groups and mode-specific forms, but adds little parameter meaning beyond the schema apart from saying that only provided settings change.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (modifier) and resource (carte de fidélité) plus the exact settings that can change, so the tool is clearly distinguishable from voir_carte and from unrelated siblings. It also explicitly frames this as a multi-setting modification in a single call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit workflow: read first with voir_carte, call with confirmer=false to show the before/after, then call with confirmer=true only after explicit agreement. It also says images must be changed elsewhere in the app, page Carte, which correctly excludes part of the resource from this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources