StampyWallet

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: downloads open inside the app and require a connected session, and the output is a set of links rather than a rendered asset. It stops short of saying whether those download links expire, which keeps it from a 5.

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

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

The output enumeration is front-loaded and the usage conditions and alternative follow in a logical order, with no filler sentences. It is a dense, long single block rather than clearly separated clauses, which slightly hurts scannability but every sentence still earns its place.

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

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

There is no output schema, but the description compensates by enumerating the return payload (QR, public link, card, PDF and PNG/SVG download links). Combined with read-only annotations and a single well-documented optional parameter, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100% and the enum values already carry clear explanations (a5 = demi-feuille / comptoir, a6 = quart de feuille / chevalet). The description only echoes 'PDF A5 ou A6' and adds nothing about default behavior or what changes when a6 is chosen, so the baseline of 3 applies.

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

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

The description opens with a specific verb and enumerates exactly what the tool returns: the registration QR code, the public link, the card, and download links for the printable poster (PDF A5/A6) and the QR alone (PNG, SVG). It names the sibling it is not ('Pour recevoir les PDF par e-mail : envoyer_affichette'), so an agent can distinguish it from envoyer_affichette without opening either schema.

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

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

'À utiliser quand le commerçant veut imprimer son affichette, récupérer son QR code ou le lien à mettre dans sa bio' gives explicit trigger conditions, and the trailing sentence names the alternative tool for the email-delivery case. Both when-to-use and when-not-to-use are covered.

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

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

Goes well beyond the destructiveHint/readOnlyHint annotations by disclosing side effects: closed days don't count toward client absence, mis-declared closures make regulars look 'perdus de vue' and trigger follow-ups, and prevenir_clients sends one message per day to all clients (counting as the day's message). The preview-vs-commit semantics are also spelled out.

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

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

Purpose is front-loaded in the first clause, followed by effect, optional notification, and confirm flow in a logical order. The prose is dense but each sentence carries useful information with little waste.

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

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

For a 6-parameter mutation with side effects and no output schema, the description covers the range, the notification option, and the confirm flow adequately, and annotations already flag the destructive profile. Minor gaps remain around reversibility/undo and how it relates to the closure-listing siblings.

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

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

With 100% schema coverage the baseline is 3, but the description adds meaning by framing du/au as an inclusive range, clarifying that prevenir_clients requires texte and follows envoyer_message rules, and explaining confirmer's preview-vs-execute behavior in context.

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

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

States a specific verb (Ajoute) and resource (période de fermeture / congés) with clear scope (premier au dernier jour inclus) and even explains the downstream effect on client absence tracking. It is very clear what the tool does, though it never explicitly names sibling tools (lister_fermetures, supprimer_conges, regler_jours_fermes) to differentiate the operation.

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

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

Explains the optional notification path (prevenir_clients=true with texte) and the two-step preview/confirm workflow ('confirmer=false rend un aperçu ; confirmer=true enregistre... après accord explicite de la personne'). However, it gives no explicit when-not guidance or routing versus the closure-management siblings.

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

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

The annotations declare the tool as destructive and not idempotent, and the description adds real context beyond them: owner-only authorization, the concrete effect (the invitation link stops working), and a two-step confirmation protocol that must wait for the user's explicit consent. That is exactly the extra behavioral guidance annotations cannot carry.

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

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

It is three compact clauses. The effect and the precondition are front-loaded, the authorization constraint follows, and the confirm protocol comes last. No sentence is wasted.

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

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

For a two-parameter destructive tool with full schema coverage and no output schema, the description covers effect, authorization, and safety flow adequately. It omits what happens if the invitation was already used, such as the error behavior, which would round out the picture.

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

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

Schema description coverage is 100%, and both parameters are already documented in the schema, including the confirmer preview semantics. The description restates the confirmer=false/true behavior but adds no syntax or format detail beyond that, so it is at the baseline.

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

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

The description pairs a specific verb with its resource and adds a limiting condition: canceling an invitation that has not yet been used, and that the link stops working. This distinguishes the tool in practice from inviter_membre, retirer_membre, and lister_equipe, even though no sibling is named explicitly.

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

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

The description states a clear usage context: it is reserved for the owner, it applies only to unused invitations, and it lays out the preview-then-act flow with confirmer. It does not explicitly compare itself with the alternatives or state what to do when an invitation has already been used, which stops it short of a 5.

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

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds genuinely new context: the deletion does not erase message history, and execution must follow an explicit human approval obtained via the preview step. It stops short of saying whether the deleted rule can be recovered, which matters for a destructive, non-idempotent operation.

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

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

Two short sentences with zero filler: the first states the action and its data consequence, the second states the two-step confirmation flow. The most consequential fact (preview vs execute) is placed where it will be read before invocation.

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

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

For a two-parameter destructive tool with no output schema, the description covers the safety protocol and the side effect on history, which are the two things an agent could not derive from structured fields. It leaves open what the preview actually contains and whether the rule can be restored, minor but real gaps.

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

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

Schema description coverage is 100% and both parameters are already fully documented in the schema, including the default and the consent workflow. The description restates the confirmer semantics without adding syntax or edge-case detail beyond what the schema provides, so the baseline 3 applies.

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

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

The description pairs a specific verb with a specific resource ('Arrête et supprime un message récurrent') and clarifies the scope of the deletion by noting that already-sent messages remain in history. It does not explicitly contrast with the close sibling 'suspendre_message_recurrent', so an agent must infer that this is permanent removal rather than a pause, but the verb 'supprime' carries that distinction.

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

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

It clearly specifies the operational protocol: confirmer=false returns a preview, confirmer=true executes, and execution requires the person's explicit consent first. What is missing is guidance on when to prefer this tool over 'suspendre_message_recurrent' or 'modifier_message_recurrent', which is the main ambiguity among siblings.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds genuinely useful context: a mandatory preview-then-confirm flow, the fact that only supplied fields change (partial update), and that retirer_lien cuts off all requests. It also cites Google's policy constraints (no intermediate rating, no filtering, no incentive), which explain why certain behaviors are absent. Some of this repeats what the confirmer parameter description already says, keeping it below 5.

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

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

The read/write distinction and the preview-confirm rule are front-loaded and the sentences are dense with information. The semicolon-chained style is slightly heavy but nearly every clause carries a distinct fact. Minor redundancy with the confirmer schema text.

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

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

For a 9-parameter, zero-required, destructive configuration tool with no output schema, the description covers the read path, the write path, the confirmation protocol, and the partial-update semantics. What it does not describe is the shape of the 30-day statistics it returns, though that is arguably minor and inferable from the field names given.

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

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

Schema description coverage is 100%, so the schema already explains lien, moment, passages, délai, texte, and the removal flags in detail. The description only restates a subset (lien, demande active, moment, délai, texte) without adding syntax or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description names the resource (Google reviews for the business) and two clear capabilities: showing 30-day figures and configuring the review request. It cross-references regler_automatismes for the channel setting, which helps separate the two tools. It falls short of 5 because the opening is a bare noun phrase rather than a verb-first statement of what the tool does.

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

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

It gives an explicit operating rule: with no changes it is read-only; with changes, confirmer=false returns a before/after preview and confirmer=true persists. That tells the agent exactly how to sequence calls. It does not state when to prefer a sibling tool (e.g. regler_automatismes for the channel itself) beyond a passing reference.

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

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

Annotations already declare destructiveHint=true and non-idempotent, so the safety profile is covered. The description adds real context beyond that: an owner-only authorization requirement and a mandatory two-phase preview-then-confirm flow with the affected person's consent. It stops short of saying the previous role is replaced/lost, which would be the final useful detail.

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

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

Three short sentences with zero filler: purpose, authorization, then the preview/confirm rule. The most operationally important constraint (confirmer semantics) is front-loaded and easy to act on.

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

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

For a destructive, owner-restricted mutation with no output schema, the description covers permissions, the safe preview path, and the consent gate, and all four parameters are documented in the schema. Only the shape of the preview response is left unstated, which is a minor gap.

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

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

Schema description coverage is 100%, and the enum values plus the confirmer preview/execute semantics are already spelled out in the property descriptions. The description restates the confirmer behavior rather than adding syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description uses a specific verb and resource ("Passe un membre de l'équipe en employé ou en responsable") and names the two allowed target states, so the operation is unambiguous. It does not explicitly contrast itself with nearby siblings like inviter_membre or retirer_membre, but the purpose is inherently distinct.

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

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

It states the prerequisite ("Réservé au propriétaire") and prescribes the workflow: preview with confirmer=false first, then act only "après accord explicite de la personne." It doesn't name alternatives or exclusions, but the when/how guidance is concrete.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, but the description adds a meaningful data-disclosure guarantee: it returns only id, prénom, initiale du nom, visites, dernière visite and card state, and "jamais d'e-mail ni de téléphone". That privacy boundary and the pagination/tri behavior are genuine additions. It stops short of 5 because it says nothing about volume limits beyond pagination or about empty-result behavior.

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

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

Front-loaded with purpose, then filters, then return shape, then usage — a sensible order with no filler sentences. It runs long as a single dense block and re-enumerates the segment list that the schema already defines, which is redundant for an agent that reads schemas.

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

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

With 17 optional parameters and no output schema, the description carries the burden well: it discloses the exact fields returned, the privacy exclusions, and how sorting/pagination apply. Nothing material an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description names the filter dimensions (prénom, tampons, visites, dates, wallet) and glosses the segments in human terms ("habitués, perdus de vue, à un tampon..."), which helps map colloquial phrasing to enum values, but it adds no syntax or semantics beyond what the enum descriptions already spell out in detail.

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

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

Opens with a specific verb ("Liste") and resource ("les clients du commerce"), then states the two axes it operates on: segment and filters, plus sorting and pagination. It also distinguishes itself from fiche_client by positioning itself as the way to obtain a client identifier first, so an agent can route without opening either schema.

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

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

Gives concrete trigger questions ("qui sont mes meilleurs clients ?", "qui n'est pas revenu ?", "qui est proche de sa récompense ?") and an explicit downstream handoff ("retrouver l'identifiant d'un client avant fiche_client"). This is real when-to-use guidance plus an alternative-tool routing rule, not implied usage.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: nothing is persisted, logo and reward images are displayed in the preview but not stored, and all parameters are optional with business-adapted defaults. It does not describe what the preview response actually contains (image, link, structured data), which is the remaining gap.

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

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

Front-loaded with purpose and scope, then usage, then defaults, then iteration, then handoff — a logical order with no filler. It is dense but every sentence carries a distinct instruction; only the image-URL sentence is slightly redundant with the schema.

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

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

For a 20-parameter, zero-required, no-output-schema tool, the description covers the workflow, the optionality, the image handling and the follow-up tool. The one omission is the return value: with no output schema, the agent is not told whether the preview comes back as an image, a URL, or a structured card, which matters for relaying results to the user.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already carries the enum and format semantics. The description still adds value by explaining the optionality contract ('sans eux, une carte adaptée au métier est proposée') and by clarifying that logo_url and paliers[].image_url are https addresses shown in the preview without being saved — behavior the schema does not state.

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

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

States a specific verb and resource ('Dessine une carte de fidélité StampyWallet') plus the crucial scope constraint ('sans compte et sans rien enregistrer'). It also implicitly separates itself from creer_commerce by naming that sibling as the next step, so an agent can distinguish preview from creation.

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

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

Explicit trigger conditions are given ('quand quelqu’un veut une carte de fidélité, fidéliser ses clients, ou voir à quoi ressemblerait sa carte'), plus an iteration loop ('Rappeler l’outil avec les réglages rendus, modifiés') and a handoff rule to creer_commerce when satisfied. This is when/when-next guidance, not just implied usage.

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

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

Goes well beyond the annotations: it discloses the auth model ('Sans compte' — the recipient clicks and signs in with their e-mail), what the returned link unlocks (card, printable QR, free trial), and that logo/photo URLs are fetched and placed on the card. It also explains that confirmer=false produces a preview with no changes, which is the key side-effect distinction for a non-readOnly, non-idempotent creation tool.

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

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

The creation action and its outcome come first, then image handling, then the confirmation workflow — a sensible order with no filler. The opening sentence is long and packs the link flow, QR and free trial into one clause, which slightly blurs the front-loading but wastes no words.

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

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

For a 21-parameter creation tool with no output schema, the description compensates by describing the return value (the personal ownership link and what the recipient sees) and the preview/execute split. Combined with 100% schema coverage, an agent has everything needed to call it correctly and safely.

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

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

Schema description coverage is 100%, so every parameter including the large enums (forme, tampon, metier, paliers) is already fully documented in the schema, and the confirmer semantics in the description merely restate the schema. The only added value is the note that parameters mirror 'concevoir_carte' and that logo_url/paliers[].image_url are fetched over https — useful but marginal. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Crée le commerce sur StampyWallet avec la carte conçue') plus the outcome ('rend un lien personnel pour en devenir propriétaire'). It explicitly anchors itself to the sibling 'concevoir_carte' ('mêmes paramètres que concevoir_carte'), so an agent can tell design-a-card apart from create-the-business without opening either schema.

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

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

Gives an explicit call sequence: call first with confirmer=false to show the recap, then with confirmer=true only after the person agrees. That is concrete operational guidance rather than implied usage. It stops short of stating when *not* to use this (e.g. when only a card design is wanted, use concevoir_carte) — that routing is left to inference.

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

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

Annotations declare destructiveHint=true and openWorldHint=true, but the description adds what annotations cannot: nothing changes with confirmer=false, the recipient is restricted to the connected account's address (never arbitrary), and the announce-then-confirm protocol. It does not contradict the annotations — the 'destructive' flag is conservative for a self-addressed send, and the description makes the actual effect explicit.

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

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

Three short sentences, front-loaded with what is sent and where, then the recipient constraint, then the confirmation protocol. Every sentence carries a distinct, actionable constraint; nothing is padding.

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

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

For a one-parameter mutation with no output schema, the description covers content, format, recipient restriction, and the mandatory confirmation sequence — enough to invoke correctly. It could say what the tool returns after a successful send (success message, delivery caveats), but that is a minor omission.

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

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

Schema coverage is 100% and the schema property already spells out the confirmer preview/execute semantics, so the baseline is 3. The description reinforces the parameter's place in the workflow ("Appeler avec confirmer=false (défaut) pour annoncer l'envoi, puis confirmer=true après accord"), adding flow context rather than new syntax, so slightly above baseline.

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

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

States a specific verb and resource ("Envoie l'affichette de comptoir") plus the exact content and channel (PDF A5/A6 with inscription QR, sent by e-mail). It is distinguishable from the sibling 'affichette' by the delivery channel, though the sibling is never named explicitly to make the contrast airtight.

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

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

Gives a clear use case ("pour l'imprimer depuis un autre appareil ou chez un imprimeur") and a hard constraint ("Seulement à cette adresse, jamais à une autre"), plus the ordering of the two-step confirmation. It stops short of routing the agent to a named alternative (e.g. 'affichette' for on-screen preview).

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

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.

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.

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.

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.

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.

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.

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

Annotations already establish read-only, idempotent, non-destructive, and closed-world behavior, so the description only needs to add context. It does so by describing returned history fields, candidate-list behavior for ambiguous names, and the fact that contact details are excluded. It does not discuss errors or rate limits, but those are less critical here.

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

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

The description is front-loaded with the core resource and remains information-dense without obvious filler. It is somewhat long and run-on due to field enumeration and multiple clauses, but nearly every sentence carries useful selection or return-value context.

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

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

With no output schema and read-only annotations, the description carries the burden of explaining return content, and it does: it lists the history fields, explains ambiguous-name candidate output, and notes the contact-detail exclusion. It is complete enough for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some lookup semantics beyond the schema, especially that the id comes from chercher_clients and that multiple name matches produce a candidate list, but it does not explain mois, inclure_offerts, or historique_limite beyond what the schema already says.

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

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

The description states a specific verb and resource: the history of ONE client, then enumerates the exact data returned (registration date, wallet, visit counts/rhythm, current card, rewards, recent visits). It clearly distinguishes this from the sibling search tool by noting that the identifier comes from chercher_clients and that ambiguous names return candidates.

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

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

It gives explicit when-to-use examples such as “quand est venue Zoé pour la dernière fois ?” and “combien de fois Louis est-il venu ?”, explains lookup by id or first name/initial, and covers the ambiguity case by returning candidate clients. It also states a useful exclusion: no e-mail or phone is provided.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description earns extra credit by explaining the preview/confirm workflow that governs any destruction, plus the important non-obvious guarantee that an old public link keeps working after a change so already-printed QR codes stay valid. It also discloses that lieu addresses are geocoded (BAN/OSM) and shown in the preview, matching openWorldHint=true.

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

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

Three sentences, front-loaded with scope, then the read/write semantics, then the link-persistence caveat — every sentence conveys something operationally useful. The first sentence is dense and long, partly restating field names that the schema already lists, which keeps it just short of ideal.

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

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

For a 15-parameter, no-required-parameter tool with no output schema, the description covers the critical unknowns: read vs. write mode, the mandatory preview-before-write protocol, and what changing the public link does not break. An agent has enough to call it correctly and safely without opening the schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: why panier_moyen exists (dashboard estimations), the concrete shape of the public link (stampywallet.com/rejoindre/<lien>, used by the QR) and its persistence, and the 10-lieu cap including the main address. It does not re-explain field-level constraints already carried by the schema, which is appropriate.

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

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

Opens with a precise verb pair and resource ('Lit ou modifie la fiche du commerce') and then enumerates every field class it governs, so an agent knows this is the shop-profile tool, not the loyalty-card design tool. It never names a sibling (modifier_carte, voir_carte, creer_commerce) explicitly, so differentiation is inferred rather than stated.

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

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

Clearly states the two operating modes: with no change parameters it returns the current fiche, with change parameters it previews by default (confirmer=false) and only writes with confirmer=true after explicit human agreement. This is actionable guidance on when to call and how, but there is no comparison to sibling tools that might also read or alter shop data.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real value by disclosing sort order, the four delivery-status buckets, the automatic-message summary over the period, and the 'can a message still go out today' signal. It does not mention pagination behavior or result size limits, which the schema only partially covers.

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

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

Front-loads the core action and result content, then closes with usage guidance. It is somewhat long, but each clause carries distinct information (ordering, status buckets, automatic summary, usage triggers) rather than restating the name.

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

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

With no output schema, the description must convey return content, and it does: per-message delivery status plus an aggregate summary of automatic messages and a same-day sendability indicator. Only pagination/truncation behavior and the shape of the summary are left implicit.

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

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

Schema description coverage is 100%, so all four parameters (depuis, jusqu_au, limite, decalage) are already documented, including the default 30-day window for the automatic summary. The description itself adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('Liste les messages déjà envoyés aux clients') plus ordering (du plus récent au plus ancien) and the exact content of the result (bilan de remise: reçus, sans écran, échecs, en cours). This clearly separates it from envoyer_message and lister_messages_recurrents, which deal with composing or recurring templates rather than sent history.

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

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

Gives three concrete use cases: knowing what was sent, verifying delivery, and checking before writing a new message. That last clause implicitly routes the agent to envoyer_message afterwards, but no sibling is named explicitly and no exclusion ('ne pas utiliser pour…') is stated.

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

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

Annotations already declare non-read-only, destructive and open-world, so the description adds real value beyond that: the 14-day validity, e-mail versus returned link delivery, role-scoped visibility, owner-only authorisation, and the preview/confirm protocol with the requirement of explicit consent. These are traits an agent could not infer from the annotations alone.

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

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

The purpose and the two role scopes are front-loaded, followed by delivery mode, ownership and the confirmation protocol. It is dense but well ordered; a few clauses duplicate what the schema fields already say, which keeps it just below top marks.

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

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

With four well-documented params and no output schema, the description covers permissions, delivery, role semantics, expiry and the safety protocol. It never says what the preview contains or whether the returned link can be re-retrieved, which is a minor remaining gap.

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

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

Schema description coverage is 100%, so the schema already explains nom, role, email and confirmer in detail; the description largely restates the same role and e-mail semantics. Baseline 3 applies, with only the owner-assignment aside as marginally new information.

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

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

The description states a specific verb and resource: creating a personal invitation valid for 14 days, with the two role options and the two delivery modes named. An agent can tell it apart from siblings such as annuler_invitation, changer_role_membre or lister_equipe without opening the schema.

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

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

It clearly states the prerequisite (owner only), the out-of-scope case (naming an owner happens in the app), and the two-step workflow: preview with confirmer=false, then act with confirmer=true only after explicit consent. It does not point to the sibling used to cancel or list invitations, so the alternative routing is not complete.

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

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

The annotations already establish read-only, idempotent, non-destructive, and closed-world behavior, so the description does not need to repeat safety basics. It adds useful context beyond annotations by stating the owner-only access restriction and summarizing the returned data, though it does not discuss ordering, pagination, or link sensitivity.

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

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

The description is a single compact sentence with the main purpose front-loaded, followed by returned fields and access restrictions. Every clause contributes useful information without wasted prose.

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

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

With no parameters, rich annotations, and no output schema, the definition is complete enough for an agent to invoke it correctly. The description supplies the key operational context: what is returned and that access is owner-only.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain. The baseline for a parameterless tool applies, and the description appropriately avoids unnecessary parameter discussion.

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

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

The description names a specific verb and resource: listing the commerce team and pending invitations. It also enumerates returned fields (name, email, role, stamps, invitation link), which clearly distinguishes it from sibling mutation tools such as inviter_membre, changer_role_membre, and annuler_invitation.

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

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

It states an important access condition, “Réservé au propriétaire,” and reinforces that it is read-only with “Ne change rien.” However, it does not explicitly say when to use this tool instead of related siblings like fiche_commerce, tableau_de_bord, or the member-management tools, leaving usage largely implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the domain rule is the real contribution: closed days do not count toward a client's absence, which changes how the returned data should be interpreted downstream. 'Ne change rien' partly restates readOnlyHint, but the interpretive caveat about 'perdus de vue' clients is genuine context the annotations cannot convey.

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

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

Three sentences, front-loaded with what is listed, then the read-only reassurance, then the domain caveat. The final sentence is long and rationale-heavy, but it earns its space because it explains the business consequence of undeclared holidays.

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

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

With no parameters, no output schema and safety already covered by annotations, the description covers what an agent needs: what is listed, the time window, that ids are included, and that nothing is mutated. The only gap is the shape of the response (fields per congé, representation of weekly closures), which an output schema would otherwise have supplied.

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

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

The tool takes zero parameters with a schema that forbids additional properties, so there is nothing for the description to disambiguate. Baseline of 4 applies; the mention that results carry an id is a small but relevant hint about the returned records.

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

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

States a specific verb ('Liste') and two concrete resources (congés du commerce, jours fermés chaque semaine) with a scope qualifier (upcoming plus the last two months, with their id). It is clearly distinguished from the mutating siblings ajouter_conges / supprimer_conges / regler_jours_fermes by the 'list' semantics, though it never names those alternatives.

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

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

The description supplies clear situational context — read-only inspection of declared holidays and weekly closed days — and states 'Ne change rien' to keep an agent from confusing it with the write siblings. It stops short of explicitly saying when to choose this over e.g. fiche_commerce or tableau_de_bord, so there are no explicit exclusions or named alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so 'Ne change rien' largely restates structured data. The description does add value by naming the returned fields (id, rythme, groupe visé, prochain envoi), which matters since there is no output schema, but it says nothing about volume, pagination or ordering of the list.

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

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

A single sentence that front-loads the resource and scope, then lists the payload, closed by a one-clause safety note. No filler.

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

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

With no params, no output schema and rich annotations, the description covers the essentials, and the field enumeration substitutes for a missing output schema. It falls short only on list behavior (ordering, whether paused items are interleaved) and on routing to the mutation siblings.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline applies. The description correctly gives no parameter discussion, avoiding noise.

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

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

Uses a specific verb+resource ('Liste les messages récurrents du commerce') and narrows the scope (actifs et en pause), then enumerates what each entry carries. It never names a sibling to contrast with, so an agent must infer the boundary with outils like historique_messages or modifier_message_recurrent.

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

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

The trailing 'Ne change rien' implies a read-only consultation context, but there is no explicit when-to-use or when-not-to-use guidance, and no pointer to the state-changing siblings (suspendre_message_recurrent, reprendre_message_recurrent, arreter_message_recurrent) that an agent would need when the user's intent is to modify rather than view.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so safety is covered. The description adds valuable operational context: results are in the shop's local time, periods are configurable, and current periods include today. It does not explain how averages are computed or whether zero-visit days are included, so not a 5.

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

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

The description is compact and front-loaded: it opens with what the tool shows, then the aggregation modes, then the secondary measure, then usage examples. Every sentence carries information. Slightly dense with three example questions, but still efficient.

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

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

With no output schema and seven optional parameters, the description explains what kinds of outputs to expect (weekday averages, hourly distribution, busiest slots) and the measures available. It omits detail on the result shape per mode, but for a read-only analytics tool it is largely sufficient for correct invocation.

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

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

Schema coverage is 100%, so every parameter including the three enums is already documented in the schema. The description does not add syntax or format details beyond what the schema provides; it only restates the three aggregation modes at a high level. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific capability – showing when customers visit, broken down by weekday average, hour distribution, or busiest day+hour slots – and adds a secondary measure (new signups). The verb and resource are unambiguous, and it is clearly distinct from siblings like tableau_dashboard or rentabilite which deal with other analytics.

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

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

The tool includes three concrete example questions ('quel est mon meilleur jour ?', 'à quelle heure ai-je le plus de monde ?', 'quand lancer une offre pour remplir un creux ?') that anchor when to use it. It lacks explicit when-not-to-use guidance or named alternatives (e.g., contrast with tableau_de_bord), which keeps it from a 5.

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

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.

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.

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.

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.

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.

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.

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

Despite annotations declaring destructiveHint=true and non-idempotent, the description adds substantial context the annotations cannot: partial-update semantics ('seuls les champs donnés changent'), that sans_fin=true removes the end condition, the one-message-per-day rule, closure/holiday skipping or shifting, quiet hours, the 60-day first-send window, and the mandatory preview-before-execute gate.

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

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

Front-loaded with the core action and the id provenance, then the mutation rule, then the confirmation protocol. The middle 'Règles :' run-on packs six constraints into one sentence, which is dense but each clause carries real operational information.

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

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

For a 14-parameter destructive mutation with no output schema, the description covers partial-update behavior, scheduling constraints and the safe two-step confirm flow. It stops short of describing what the preview returns or how validation failures surface, which would be the remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-field meaning: sans_fin as the removal switch for either end date or send count, si_ferme=decaler shifting to the next open day, and the frequence↔jours / jour_mois / rang+jour_rang dependency. It still doesn't explain every parameter (e.g. heure bounds are only in the schema).

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

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

The description opens with a specific verb+resource: changing the text or rhythm of an existing recurring message, with the id sourced from lister_messages_recurrents. That clearly separates it from creation (programmer_message_recurrent) and lifecycle siblings (arreter/suspendre/reprendre), though it never names those alternatives explicitly.

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

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

It gives an actionable usage protocol: call with confirmer=false to get a preview, show it to the person, then re-call with confirmer=true only after explicit agreement. What's missing is guidance on when to prefer this over programmer_message_recurrent or the suspend/stop siblings.

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

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

Beyond destructiveHint=true and openWorldHint=true, the description discloses non-obvious behavior: one message per day (colliding occurrences are skipped), closed days and vacations skipped or shifted via si_ferme, quiet hours respected, first send must fall within 60 days, and the target group is recomputed at each send. The preview/confirm safety path is spelled out, which the annotations alone would not convey.

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

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

Front-loaded with purpose, then cadence, examples, business rules, the confirmer workflow, and finally the sibling alternative — a deliberate ordering with no filler despite the density required by 13 parameters. Every sentence carries an operational constraint.

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

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

For a 13-parameter mutation tool with no output schema, the description supplies the missing pieces: collision rules, closure handling, the 60-day horizon, quiet hours, and the mandatory preview-then-confirm protocol. Nothing an agent needs to invoke it safely is absent.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including enum meanings and defaults; that sets the baseline at 3. The description reinforces parameter meaning with worked examples ('chaque mardi 11 h', 'le 1er de chaque mois') and the 07:00–21:45 time window, but most of this restates what the schema says.

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

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

States a specific verb and resource ('Programme un message qui se répète... sur l'écran verrouillé des clients') and enumerates the two scheduling modes (weekly / monthly) with concrete examples. It explicitly contrasts itself with envoyer_message for one-off sends, so an agent can route correctly without opening the schema.

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

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

Explicit when-to-use (recurring weekly/monthly at a business hour) and when-not ('Pour un envoi unique et immédiat, utiliser envoyer_message'). It also prescribes the operational flow: run with confirmer=false for a preview, show it to the person, then re-run with confirmer=true only after explicit consent.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety bar is lower; the description nonetheless adds the crucial dual-mode semantics (no-param call is a pure read returning texts) and the preview-before-commit workflow that the annotations cannot express. It does not spell out what effacer actually destroys or that some effects (already-opened birthday gifts) are irreversible — that detail lives only in the schema.

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

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

Front-loaded with the action and scope, then the mode semantics, then the sibling pointer — the right ordering. It is dense with nested parentheticals explaining the relance threshold rule, so a few clauses could be trimmed, but every sentence carries information the agent needs.

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

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

With 25 optional parameters and no output schema, the description correctly covers the highest-risk gaps: read vs write mode, preview vs commit, partial updates, and the default/effacer path. Return values are only summarized ('rend l'état actuel, textes compris'), which is thin given the absence of an output schema, but adequate for an agent to decide and call correctly.

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

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

Schema description coverage is 100% across all 25 parameters, including enum explanations and default/effacer semantics, so the schema does the heavy lifting. The description adds domain grouping (relance, anniversaire, rappels, heures calmes) but no per-parameter syntax or format detail beyond it, which is the correct baseline 3.

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

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

States a specific verb pair and resource ('lit et règle les messages que StampyWallet envoie tout seul'), then enumerates the exact sub-domains covered: relance, anniversaire, rappels with delay, heures calmes, and the Monday summary. It explicitly routes the one-off case to the sibling `envoyer_message`, so the boundary is unambiguous without opening any schema.

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

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

Gives an explicit decision tree: no parameters → read current state; with changes → confirmer=false for a preview, confirmer=true to persist. It also states the partial-update rule ('seuls les champs fournis changent') and names the alternative tool for a one-off message, leaving nothing to inference.

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

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

Adds substantial context beyond annotations: it discloses that this replaces the full weekly list, affects absence/lost-client tracking, optionally triggers a mass notification (governed by envoyer_message rules, one message/day), and that confirmer=true executes/sends. This meaningfully expands on destructiveHint and openWorldHint.

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

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

Front-loads the core purpose and constraints. Slightly wordy with the 'habitués perdus de vue' explanation, but that sentence earns its place by justifying the absence-tracking effect. No critical redundancy.

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

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

For a destructive, open-world mutation tool with no output schema, the description covers the preview/confirm safety workflow, side effects, and cross-parameter coupling. Nothing an agent needs to call it safely is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning: texte only applies when prevenir_clients=true, prevenir_clients counts as the day's message, and confirmer separates preview from execution. These interactions exceed the individual field descriptions.

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

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

States a specific verb (remplace/règle) and resource (les jours fermés chaque semaine) with a concrete example. It is clearly distinguishable from lister_fermetures (which lists) by the explicit 'remplace' (replaces) semantics.

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

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

Explains the preview-then-confirm workflow clearly ('confirmer=false rend un aperçu ; confirmer=true enregistre... après accord explicite de la personne') and when notification applies. However it never explicitly names a sibling as an alternative (e.g. lister_fermetures to view current closures), leaving that inference to the agent.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety burden is covered; the description adds meaningful context beyond that by flagging that the euro figures are estimates (passages × panier moyen) and that reward cost is left unquantified when cout_recompense is omitted. It stops short of describing response shape or whether relaunch results depend on prior configuration, but the estimate caveat is genuinely useful.

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

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

The metrics list is long but every item is a distinct output the agent may care about, and the usage questions plus the tableau_de_bord exclusion are packed into the final two sentences. It is dense rather than padded, though the opening sentence runs on before the reader learns what is actually returned.

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

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

With no output schema, the description carries the return-value burden and does so by naming each computed block, including the estimation method and the un-priced-reward edge case. For a zero-required-parameter analytics tool with six optional inputs, nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description lifts it by explaining the purpose of the two override parameters — panier_moyen and cout_recompense exist so the calculation can be re-run with different assumptions, and omitting cost means rewards aren't priced. That is business meaning the schema's per-field text only partially conveys.

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

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

Opens with a specific verb and resource — "Dit si la carte de fidélité rapporte" — then enumerates the exact metrics returned (retention share, return visits, euro value, median interval, rewards cost, pending rewards, relaunch outcome). It explicitly distinguishes itself from tableau_de_bord, which supplies raw figures instead of the profitability reading.

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

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

Names the concrete questions that select this tool ("est-ce que ça vaut le coup ?", "ça me rapporte combien ?", "mes clients reviennent-ils ?") and routes the agent elsewhere for plain period stats via "Pour les chiffres bruts d’une période, tableau_de_bord." The when-to-use and the alternative are both explicit.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description discloses a non-obvious behavioral rule: the pause days are not caught up, the restart begins today. It also spells out the two-phase preview/execute contract and the consent requirement, which annotations alone cannot convey.

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

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

Two sentences, front-loaded with the effect and the no-catch-up rule, followed by the confirmation protocol. Nothing is padded and no sentence is redundant.

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

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

For a two-parameter mutation with no output schema, the description covers the effect, the time semantics, and the safety protocol. It does not say what the preview contains or how failures (e.g., a rule that is not paused) are surfaced, a minor remaining gap.

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

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

Schema coverage is 100% and the schema already documents both `id` (obtained from lister_messages_recurrents) and the `confirmer` preview/execute semantics. The description largely restates the confirm flag rather than adding syntax or format detail, so the baseline of 3 applies.

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

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

States a specific verb ("relance ... en pause") and resource ("message récurrent"), plus the key scope detail that the restart begins today. This implicitly separates it from suspendre/arrêter/modifier_message_recurrent, but it never names a sibling, so the differentiation must be inferred.

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

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

The description gives clear operating context: this applies only to a paused recurring message, and it prescribes a preview-then-confirm workflow with explicit human approval. It does not state what to do if the message is not paused or when to prefer modifier_message_recurrent instead, so the exclusions are missing.

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

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

Goes well beyond the annotations: it discloses the side effects (open sessions closed, past stamps preserved in history), the authorization constraint (owner only), and the exact two-phase semantics of confirmer. This is exactly the extra context destructiveHint=true alone cannot convey.

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

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

Four short sentences, front-loaded with the destructive outcome before the permission note and the confirmation protocol. No filler.

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

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

Strong for a destructive mutation with no output schema: impact, permissions, and the confirm flow are all covered. The one gap is that the schema marks all three parameters optional, and the description never states that either membre_id or email must be supplied.

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

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

Schema coverage is 100% and the confirmer semantics in the description largely restate the schema's own parameter description. It reinforces the human-consent workflow but adds no syntax or format details beyond the schema.

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

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

States a specific verb and resource ('Retire l'accès d'un membre au commerce') and immediately scopes the effect ('ferme ses sessions ouvertes', 'les tampons restent dans l'historique'), which clearly separates it from changer_role_membre or inviter_membre without needing to name them.

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

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

Gives clear operating context: owner-only ('Réservé au propriétaire') and a mandatory two-step preview→confirm flow with the requirement of the person's explicit consent. It stops short of naming sibling alternatives such as changer_role_membre when role reduction rather than removal is intended.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds "Sans compte" (no account required), a genuine auth-context detail, but says nothing about the shape of the returned figures or precision assumptions.

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

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

Two tight sentences: what is computed first, when to use it second, with no filler. Nothing is redundant with the schema or annotations.

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

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

With 8 parameters at full schema coverage and no output schema, the description needs mainly to define scope and trigger conditions, which it does. It stops short of describing what the simulation returns, which would matter since there is no output schema.

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

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

Schema description coverage is 100%, so every parameter including defaults and ranges is already documented. The description only alludes to reward-vs-basket cost and number of passages, adding no units, defaults, or interaction detail beyond the schema; baseline 3 applies.

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

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

States a specific verb ("Estime") with a specific resource ("carte de fidélité à tampons") and names the two quantities computed: reward cost relative to the basket and the extra visits needed to break even. This clearly separates it from siblings like concevoir_carte or modifier_carte, though no sibling is named explicitly.

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

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

Gives concrete usage contexts: choosing a reward and a stamp count, or answering 'is a card worth it?'. It does not state exclusions or point to alternatives such as rentabilite, which is the main gap for a 5.

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

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

Annotations already flag destructive=true and idempotent=false, but the description adds what the annotations cannot: the two-phase preview/execute safety gate, the consent requirement, and the side effect that a client notification is queued and counts as the day's message (one per day). That is meaningful behavior beyond structured fields.

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

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

Three dense sentences with no filler, and the identification source (id from lister_fermetures) plus the optional notification are front-loaded. Slightly packed, but every clause carries actionable information.

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

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

For a destructive, open-world mutation with four params and no output schema, the description covers the identifier source, the preview/confirm protocol, the consent requirement, and the notification side effect and rate rule. Nothing essential for a correct call is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds cross-parameter meaning the schema does not, notably that texte is only relevant when prevenir_clients=true and that confirmer governs preview vs. execution. It stops short of describing the preview's contents or failure modes.

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

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

States a specific verb+resource: deleting a closure period by its id, and names lister_fermetures as the source of that id. An agent can distinguish it from ajouter_conges/lister_fermetures without opening any schema.

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

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

Gives an explicit operating procedure: call with confirmer=false for a preview, show it to the person, get explicit agreement, then re-call with confirmer=true. It also spells out the optional path (prevenir_clients=true + texte) and references envoyer_message for the notification rules.

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

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

Annotations already indicate a non-read-only, non-destructive operation. The description adds important behavior: active messages stop sending until resumed, and confirmer=false returns a preview while confirmer=true executes only after explicit human approval.

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

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

The definition is two compact sentences, with the core effect and confirmation workflow front-loaded and no wasted wording.

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

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

For a two-parameter tool with complete schema descriptions and annotations covering safety traits, the description supplies enough behavioral context to call it correctly, including the required preview-and-consent sequence.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema. The description reinforces the confirmer preview/execute workflow but adds little semantic detail beyond what the schema descriptions already provide.

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

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

The description states a specific verb and resource ('Met en pause un message récurrent actif') and defines the scope: nothing is sent until reprendre_message_recurrent. It is clearly distinguishable from resuming or stopping a recurring message.

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

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

It gives clear context for use: the message must be active, and execution requires first showing the preview and obtaining explicit consent. It names reprendre_message_recurrent as the resumption path, though it does not explicitly contrast with arreter_message_recurrent for permanent stopping.

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

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

The annotations already state readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond them: chiffre_estime is an estimate rather than register data, comparison uses the preceding equal-length period, and curve granularity has automatic thresholds. It does not discuss auth or rate limits, but those are less central for this annotated read-only tool.

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

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

The description is front-loaded with scope and metrics, then usage examples, then sibling disambiguation. The first sentence is dense but every clause maps to a parameter or returned concept, and there is no filler.

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

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

For a seven-parameter analytics tool with no output schema, the description lists the main returned indicators and explains period, curve, comparison, and alternatives. It does not fully describe the response structure or every indicator, but the schema is complete for parameters and annotations cover the safety profile.

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

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

Schema description coverage is 100%, and the schema itself documents all seven parameters, including enum values, defaults, date formats, taux_retour, and chiffre_estime definitions. The description adds high-level context but little syntax or semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description names the resource (a commerce loyalty dashboard) and enumerates the metrics, period, curve, and comparison it returns. It also distinguishes the tool from chercher_clients and rentabilite, so an agent can identify it as an analytics query rather than a client lookup or profitability tool.

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

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

It gives concrete user questions such as « comment ça marche ce mois-ci ? », « combien de clients en août ? », and « est-ce que ça monte ? ». It also explicitly redirects client lists to chercher_clients and card ROI to rentabilite, providing clear when-to-use and alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description reinforces read-only while adding substantial context beyond annotations: it lists the exact rule data shown (mode, thresholds, welcome stamps, expiration, points settings, style, color, stamp, public signup link). With no output schema, this is exactly the disclosure an agent needs about the return content.

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

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

Front-loaded with the core action and then the usage rule; the long enumeration of settings is informative rather than filler. The closing 'Lecture seule' repeats the readOnly annotation and is the only clearly redundant phrase.

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

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

No output schema exists, so the description must convey what is returned, and it does so thoroughly by listing the card preview and rule fields. Parameters are schema-documented and safety is annotation-documented, leaving nothing important for an agent to call this tool correctly.

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

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

Schema description coverage is 100%, so the meaning of qr, variantes, and tampons_poses is fully documented in the schema. The description only adds the cross-tool note that modifier_carte uses the same setting names, which is useful but does not explain the parameters themselves, so baseline 3 applies.

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

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

States a specific verb and resource — it shows the loyalty card as customers see it in Apple/Google Wallet — and enumerates the rule fields returned. It also explicitly contrasts with modifier_carte, so an agent can distinguish it from the sibling mutation tool without opening either schema.

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

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

Gives explicit when-to-use conditions: before any modification, because modifier_carte reuses the same setting names, or when the merchant asks what the card looks like or what its rule is. The alternative is named alongside the condition that selects it.

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