Skip to main content
Glama

StampyWallet

Envoyer un message aux clients

envoyer_message
Destructive

Envoie une notification sur l’écran verrouillé des clients (via leur carte Apple Wallet ou Google Wallet). À utiliser pour annoncer une nouveauté, une offre, un événement, ou faire revenir des clients. L’audience est paramétrable (tous, habitués, perdus de vue, presque à la récompense, nouveaux, récompense à retirer, inactifs) et se combine avec des filtres (jours sans passage, tampons sur la carte, passages, date d’inscription). Texte de 180 caractères au plus, envoyé tel quel. Un seul message par jour et par commerce. AVEC client_id (rendu par chercher_clients) : un message à CE client seul, par exemple « votre commande est prête » (pressing, cordonnerie, traiteur, fleuriste) : un modèle prêt (modele = pret, retrait, recu, attente), ou texte + modele=libre ; en option aussi_sms et aussi_email. Il ne compte pas dans le message du jour à tous ; deux par client et par jour au plus. Appeler d’abord avec confirmer=false : l’aperçu donne le texte exact, le nombre de destinataires et combien peuvent vraiment le recevoir, sans rien envoyer. N’appeler avec confirmer=true qu’après l’accord explicite de la personne : un message parti ne se reprend pas. Pour les messages automatiques (relance, anniversaire, rappels), utiliser regler_automatismes.

Input Schema

NameRequiredDescriptionDefault
texteNoLe texte exact de la notification, 180 caractères au plus. Il est précédé du nom du commerce sur le téléphone : inutile de le répéter. Obligatoire sans client_id ; avec client_id, seulement pour modele=libre.
langueNoAvec client_id et un modèle : la langue du texte prêt. Par défaut, celle du commerce.
modeleNoAvec client_id : pret = « Votre commande est prête… », retrait = « Votre article est prêt à être retiré… », recu = « Nous avons bien reçu votre commande… », attente = « Votre commande vous attend toujours… », libre = le texte donné. Par défaut : libre si texte est donné.
audienceNoQui reçoit le message. tous = tous les clients ; habitues = 4 passages ou plus sur 60 jours ; perdus = habitués dont l’absence dépasse une fois et demie leur rythme habituel, ou le délai du commerce sans assez d’historique (la définition de l’écran Clients) ; presque = il ne manque qu’un tampon avant la récompense ; nouveaux = inscrits depuis 30 jours (ou depuis inscrit_depuis) ; recompense_prete = une récompense gagnée, pas encore retirée ; inactifs = tout client sans passage depuis inactif_depuis_jours jours d’ouverture (par défaut le délai du commerce), habitué ou non. Toute audience autre que tous, ou tout filtre, demande la fonction « notifications ciblées ».tous
aussi_smsNoAvec client_id : aussi par SMS (formule Croissance, budget du mois, entre 8 h et 20 h, sinon à l’ouverture). Défaut false.
client_idNoIdentifiant (UUID) d’UN client, rendu par chercher_clients ou fiche_client : le message part à lui seul. Exclut audience et filtres.
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.
aussi_emailNoAvec client_id : aussi par e-mail, si le client en a laissé un. Défaut false.
tampons_maxNoFiltre : au plus N tampons sur la carte en cours.
tampons_minNoFiltre : au moins N tampons sur la carte en cours.
passages_minNoFiltre : au moins N passages au total depuis l’inscription.
inscrit_avantNoFiltre : inscrits avant ce jour-là (AAAA-MM-JJ, exclu).
inscrit_depuisNoFiltre : inscrits ce jour-là ou après (AAAA-MM-JJ).
actif_depuis_joursNoFiltre : au moins un passage dans les N derniers jours d’ouverture.
inactif_depuis_joursNoFiltre : pas de passage depuis au moins N jours d’OUVERTURE (les jours fermés et les congés ne comptent pas).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond annotations, it discloses critical behavioral traits: one message per day per commerce, two per client per day when using `client_id`, that single-client messages do not count toward the daily broadcast limit, that `confirmer=false` returns an exact preview with recipient counts, and that a sent message cannot be recalled ('un message parti ne se reprend pas'). These details materially affect safe invocation and align with the destructive/non-idempotent annotations.

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 a single dense paragraph that front-loads purpose and then layers audience, filters, client-specific mode, preview workflow, and alternatives. It is efficient for a 15-parameter tool, though it could be more scannable with structure; some audience definitions repeat schema content.

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 tool's complexity (15 parameters, destructive mutation, no output schema), the description covers everything an agent needs: audience definitions, filter combinations, single-client flow, preview/confirmation requirements, daily limits, and the alternative for automated messages. No critical gap remains.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already defines each parameter thoroughly. The description adds cross-parameter semantics: `client_id` excludes `audience` and filters, `modele` applies only with `client_id`, and the confirmation flow. It does not add much new per-parameter detail beyond the schema, but the relational guidance is valuable.

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 and resource: 'Envoie une notification sur l’écran verrouillé des clients (via leur carte Apple Wallet ou Google Wallet)'. It distinguishes the tool from siblings by naming `regler_automatismes` for automated messages and `chercher_clients` as the source of `client_id`, so an agent can route correctly without opening schemas.

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 explicit when-to-use cases ('annoncer une nouveauté, une offre, un événement, ou faire revenir des clients') and clear when-not/alternatives ('Pour les messages automatiques… utiliser regler_automatismes'). It also specifies the two invocation modes (broadcast with audience/filters vs. single-client with `client_id`) and mandates a preview-first workflow with `confirmer=false` before `confirmer=true`.

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