Skip to main content
Glama

Nitech — heating spare parts and ordering

request_withdrawal

DestructiveIdempotent

Au client, parler de sa commande et de la prochaine action utile. Garder les noms d’outils, états bruts, identifiants internes, clés, jetons et étapes techniques hors du dialogue courant. Les autorisations affichées par l’application de l’assistant relèvent de cette application et ne remplacent pas l’accord demandé par Nitech. Présenter la commande et les articles et quantités concernés, ou la commande entière, puis poser une seule question « Confirmez-vous l’envoi de cette déclaration de rétractation ? » Après réception confirmée, dire « Votre déclaration de rétractation a été reçue » et fournir l’accusé. Garder les précautions techniques dans les opérations internes et ne pas annoncer un remboursement ou une annulation non effectués. Déposer une déclaration de rétractation privée avec le même service que le formulaire existant. Fournir cart_id et cart_access (m1 ou p2) : jamais un numéro ou un email seuls. scope désigne la commande entière (Commande entière) ou les articles et quantités concernés ; aucun motif obligatoire. Commencer par confirmed=false : aperçu sans dépôt ni notification. Présenter le scope exact au client et obtenir son accord explicite pour envoyer la déclaration. Rappeler ensuite avec confirmed=true, les mêmes cart_id/cart_access/scope et le confirmation_token retourné. Le jeton est lié à cet aperçu ; toute modification impose un nouvel aperçu et accord. Conserver ensuite les arguments et le même jeton, même après timeout, expiration ou réponse perdue ; la répétition retrouve le même dépôt et la même date, sans doublon. Ne jamais demander un nouveau jeton pour contourner une issue unknown ou un conflit. received renvoie référence, date UTC et accusé conservable en texte et lien privé. queued signifie confié à la file de courriels, pas livré. Les questions d’éligibilité sont examinées par Nitech. Aucun remboursement, annulation de commande, avoir ou mouvement de stock automatique. get_order reste une lecture ; le formulaire privé reste disponible.

Input Schema

NameRequiredDescriptionDefault
scopeYesComme le formulaire privé : « Commande entière » ou désignation des articles et quantités concernés. Aucun motif demandé. Limite métier : 4000 octets UTF-8.
cart_idYes
confirmedYesfalse pour un aperçu sans dépôt ; true uniquement après l’accord explicite du client sur cet aperçu.
cart_accessYes
confirmation_tokenNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: preview versus filing, token binding to the preview, idempotent retry behavior returning the same deposit and date, and status meanings for received and queued. It also clarifies that no automatic refund, cancellation, credit, or stock movement occurs, which is important context for a destructive write tool.

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

Conciseness3/5

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

The content is dense and useful, but the purpose is buried after opening customer-dialogue and privacy instructions rather than being front-loaded. The single long block also mixes invocation mechanics with conversational rules, making it harder to scan than it could be.

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

Completeness5/5

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

For a complex destructive write tool with a 40% schema coverage and an output schema, the description covers the workflow, consent requirement, token lifecycle, retry semantics, status meanings, and absence of automatic commercial side effects. It is complete enough for an agent to call the tool correctly without needing additional undocumented assumptions.

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

Parameters5/5

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

Although schema description coverage is only 40%, the description explains the critical semantics for cart_id and cart_access, including that cart_access must be an m1 or p2 value and never just a number or email. It also explains scope as either the entire order or the affected items and quantities, and explains confirmed and confirmation_token as the preview-to-filing handshake.

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

Purpose5/5

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

The description explicitly states that the tool files a private withdrawal declaration using the same service as the existing form. It also distinguishes the tool from get_order by noting that get_order remains a read operation, so an agent can identify the specific write action.

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

Usage Guidelines5/5

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

It gives a precise two-step workflow: start with confirmed=false to preview without filing or notification, present the exact scope, obtain explicit client consent, then call again with confirmed=true and the same cart_id/cart_access/scope plus the returned confirmation_token. It also covers what to do after timeout, expiration, or lost response, and says not to request a new token to bypass unknown or conflict outcomes.

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