Skip to main content
Glama

StampyWallet

Retirer un membre de l’équipe

retirer_membre
Destructive

Retire l’accès d’un membre au commerce et ferme ses sessions ouvertes. Les tampons qu’il a posés restent dans l’historique. Réservé au propriétaire. confirmer=false (défaut) rend un aperçu ; confirmer=true agit, après accord explicite de la personne.

Input Schema

NameRequiredDescriptionDefault
emailNoOu l’e-mail du membre, à la place de membre_id.
confirmerNofalse (défaut) : rend seulement un aperçu de ce qui serait fait, sans rien changer. true : exécute. Toujours montrer l’aperçu à la personne et attendre son accord avant de repasser avec true.
membre_idNoIdentifiant du membre, lu avec lister_equipe.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources