Nitech — heating spare parts and ordering MCP Server

Créer une vraie commande Nitech dans le canal MCP autonome, sans boutique Web ni paiement. Appeler d’abord avec confirmation.confirmed=false pour présenter au client les articles, adresses, montant, terms_version et le lien terms_url des CGV conservables. Faire consulter ce lien avant de recueillir l’accord. Après son accord explicite, rappeler avec la même clé UUID, le token retourné, confirmed=true, confirmed_at, proof_reference et terms_version. Prix, stock, port et conditions sont revérifiés. Un changement exige un nouveau récapitulatif. Conserver la même clé et les mêmes arguments pour toute reprise, y compris après timeout ou résultat incertain ; ne jamais créer une nouvelle clé pour contourner pending ou un conflit. 30 lignes, 100 unités par ligne, 300 au total, 32 Kio. Ne déclenche ni paiement, facture, e-mail ni réservation. Après création, poursuivre par défaut sur MCP avec prepare_payment. Les liens privés web_resume des quatre boutiques restent des alternatives uniquement si le client les demande ; ne pas les proposer systématiquement. Ils conservent le même caddie et leur validité existante. Livraison GLS optionnelle : delivery={mode:gls_pickup,relay_id}, identifiant obtenu par search_relay_points ; destination de recherche complète requise pour les devis. Aucun champ libre de relais. Le récapitulatif confirmed=false porte le mode, le relais vérifié, les frais et le total. Conserver identité/email/téléphone du destinataire, et facturation indépendante. Toute modification exige un nouvel aperçu et un nouvel accord/token ; jamais de remplacement silencieux du relais. En cas de saisie invalide rejetée avant création (category=invalid_input, operation_outcome=not_created), lire error.fields (path, reason, expected_correction), demander la correction puis rappeler confirmed=false avec la même clé. Présenter les coordonnées et le montant actualisés et recueillir un nouvel accord avant confirmed=true. Une ancienne confirmation ne couvre pas une adresse corrigée. Pour unknown, pending ou un conflit d’idempotence : ne changer ni clé ni arguments, réconcilier. La facturation utilise la référence pays, pas les zones desservies. Aucun contrôle d’existence de rue ou de correspondance rue–ville–code postal.

Lire une commande privée avec cart_id et cart_access (m1 privé ou p2 permanent). Le numéro seul ne suffit jamais. Reprend la même vérification d’accès que get_payment. Lecture seule : état de commande, paiement serveur, bordereaux et quantités documentées, déclaration de départ, transporteur explicitement renseigné. Un bordereau ne prouve pas la préparation physique ; une déclaration de départ ne prouve pas la livraison. Numéro/lien de suivi absents de ces sources : null et unavailable explicites. Ne rien déduire du paiement sur l’expédition. Ne pas recréer ni repayer en cas d’incertitude.

Lire le produit public Nitech courant par PID, y compris les produits hors vente historiquement publics. Textes, caractéristiques, appareils, éclatés, repères et documents conservent leur provenance ; une relation historique ou un contenu observé ne vaut pas qualification humaine.

Lire les seuls documents connus et publiables du produit ou de ses appareils liés, avec leur type et les contrôles humains applicables à leur source. Les autres contenus restent à vérifier ; aucune qualification n'est déduite automatiquement.

Contrat JSON : destination et lines sont obligatoires à la racine. country_code et postal_code sont des chaînes DANS destination, jamais à la racine. Sans delivery (domicile), destination contient uniquement country_code et postal_code : ne pas envoyer city ni address_line1. France : postal_code complet requis. lines est un tableau d’objets {product_id: entier, quantity: entier}, sans autre champ. Exemple minimal domicile France : {"destination":{"country_code":"FR","postal_code":"54000"},"lines":[{"product_id":1843,"quantity":1}]}. Avec delivery GLS, conserver le contrat existant : destination contient aussi city et address_line1, delivery={mode:gls_pickup,relay_id} obtenu par search_relay_points. quote_cart n’accepte ni confirmation ni coordonnées de commande. Préparer un devis complet du panier depuis les offres et le port Nitech actuels. Pays et code postal selon la zone, product_id et quantity seulement. 30 lignes distinctes, 100 unités par ligne, 300 au total, 8 Kio. Doublons refusés. Lecture seule sans panier, réservation, commande ni paiement. Toute ligne invalide bloque les totaux. Offres et port à relire lors de la commande ; checkout des boutiques autoritaire. Livraison GLS optionnelle : delivery={mode:gls_pickup,relay_id}, identifiant obtenu par search_relay_points ; destination de recherche complète requise pour les devis. Aucun champ libre de relais. Le récapitulatif confirmed=false porte le mode, le relais vérifié, les frais et le total. Conserver identité/email/téléphone du destinataire, et facturation indépendante. Toute modification exige un nouvel aperçu et un nouvel accord/token ; jamais de remplacement silencieux du relais. Lire category et fields (path, reason, expected_correction) dans les erreurs. Corriger la saisie si demandé ; destination_not_served appelle une autre destination ou Nitech ; temporarily_unavailable appelle la même demande sans accuser l’adresse. Après correction : nouveau devis, puis coordonnées et montant à faire confirmer avant création. Aucun contrôle postal réel.

Calculer le port actuel depuis les produits, profils et zones Nitech relus à chaque appel. Entrées : pays, code postal requis pour la France, product_id et quantity. Limites : 30 lignes, 100 unités par produit, 300 au total. Renvoie HT, TVA, TTC, zone, groupes tarifaires et politique observée. Ce résultat n’est pas une réservation ; aucune commande n’est créée ; montant à relire lors d’une future commande. Le calcul commercial des boutiques reste autoritaire. Livraison GLS optionnelle : delivery={mode:gls_pickup,relay_id}, identifiant obtenu par search_relay_points ; destination de recherche complète requise pour les devis. Aucun champ libre de relais. Le récapitulatif confirmed=false porte le mode, le relais vérifié, les frais et le total. Conserver identité/email/téléphone du destinataire, et facturation indépendante. Toute modification exige un nouvel aperçu et un nouvel accord/token ; jamais de remplacement silencieux du relais. Lire category et fields (path, reason, expected_correction) dans les erreurs. Corriger la saisie si demandé ; destination_not_served appelle une autre destination ou Nitech ; temporarily_unavailable appelle la même demande sans accuser l’adresse. Après correction : nouveau devis, puis coordonnées et montant à faire confirmer avant création. Aucun contrôle postal réel.

Retrouver les preuves publiables pièce/appareil du pilote. verified exige une décision humaine active liée à la preuve exacte, au SHA, à la page et au repère courants. stale_source impose une nouvelle vérification. Les scores ne sont pas des probabilités de compatibilité.

Lire l'offre canonique à l'heure d'observation : mise en vente, stock compté, disponibilité et autorisation de commande distinctes. Cette consultation ne réserve aucun stock ; la qualification métier de la fiche reste séparée.

Carte explicitement choisie et préparation confirmée : remettre action.url, lien Nitech privé stable /payments/card, sans ouvrir ce lien dans les outils de l’assistant. Le client clique et le navigateur rejoint Scellius par le transfert bancaire existant, sans nouveau choix du moyen. Ne jamais donner un formulaire bancaire ou son jeton temporaire comme lien durable. payment_page conserve la page générale de choix et de suivi ; utiliser cette page si aucun moyen n’a été choisi. Virement, chèque et suivi permanent conservés. Retrouver le même caddie MCP, son montant accepté, les trois moyens card/transfer/cheque, le moyen choisi, les instructions et son état bancaire Scellius. payment_page fournit une URL privée stable du caddie, sans date d'expiration, commune aux trois moyens ; elle reste consultable après paiement. Le jeton p2 de cette page peut remplacer le jeton mcp_resume pour les appels suivants. awaiting_receipt signifie attente du règlement et ne prouve aucun paiement. Fournir cart_id et cart_access : le jeton mcp_resume privé obtenu dans un lien web_resume de create_order ou du BO. Ne jamais fournir un simple numéro comme preuve d’accès. NOT_PREPARED et PREPARED ne prouvent aucun paiement. Pour le client, AUTHORISED, AUTHORISED_TO_VALIDATE et CAPTURED se présentent simplement comme Paiement accepté ; ne pas détailler les étapes bancaires internes. business_effects et status signalent les réconciliations. Ne pas payer à nouveau en cas d’incertitude.

Une demande explicite identifiant commande, montant, devise et moyen vaut accord pour cette préparation. Exécuter aperçu confirmed=false puis confirmed=true sans reposer la même question UNIQUEMENT si le résultat concorde exactement et qu’aucune nouvelle condition ne nécessite un accord. Conserver la même clé UUID, le jeton retourné et proof_reference identifiant le message explicite ; ne jamais inventer une preuve. S’il manque un élément ou si le résultat diffère, demander seulement la précision ou le nouvel accord nécessaire. Résultat accepté ou incertain : ne pas préparer une nouvelle tentative. Carte explicitement choisie et préparation confirmée : remettre action.url, lien Nitech privé stable /payments/card, sans ouvrir ce lien dans les outils de l’assistant. Le client clique et le navigateur rejoint Scellius par le transfert bancaire existant, sans nouveau choix du moyen. Ne jamais donner un formulaire bancaire ou son jeton temporaire comme lien durable. payment_page conserve la page générale de choix et de suivi ; utiliser cette page si aucun moyen n’a été choisi. Virement, chèque et suivi permanent conservés. Préparer le moyen de paiement du même caddie MCP : payment_method=card, transfer ou cheque. Pour virement/chèque, confirmer enregistre seulement c_stat=3 et c_moyp=3/2 et renvoie les instructions existantes : aucun règlement reçu, stock, e-mail ou facture. Une carte en cours/incertaine ou une commande déjà prise en compte interdit un autre moyen. Pour la carte, préparer le paiement autonome Scellius. Appeler avec confirmed=false, cart_access, expected_amount, currency=EUR et une clé UUID pour présenter le montant au client. Uniquement après son accord explicite, rappeler confirmed=true avec confirmation_token et proof_reference. Renvoyer payment_page ou action.url au client : URL stable sans expiration (expires_at=null). La préparation UNISSUED peut attendre ; le formulaire bancaire est daté et marqué ISSUED seulement au départ explicite du client. Les confirmations temporaires sont renouvelées derrière la page. Une session ISSUED ou LEGACY_UNKNOWN reste protégée jusqu'au résultat authentifié ; ne jamais inventer une expiration bancaire. Le client saisit sa carte uniquement chez Scellius. Aucun envoi de carte ou authentification via MCP. Répétitions et clés différentes retrouvent la même tentative ; aucun nouvel essai automatique après un refus, une expiration ou une incertitude. Après REFUSED, ABANDONED ou EXPIRED authentifié par le serveur, demander un nouveau récapitulatif avec une nouvelle clé et retry_of=attempt_id, puis recueillir un nouvel accord explicite. get_payment donne la preuve serveur et les effets métier. Un lien ne valide pas le paiement.

Rechercher dans le catalogue actif par PID, référence observée, ancienne référence, désignation, marque ou appareil lié. La recherche textuelle porte sur une sous-chaîne continue dans chaque champ : fournir une référence connue ou un fragment court, pas toute la demande client. Pour une pièce décrite, utiliser auto ou designation avec des termes distinctifs contigus, par exemple Deville 9424 ; vérifier ensuite dimensions et compatibilité dans get_product. Un numéro d’appareil ne prouve pas une référence fabricant : utiliser designation/model plutôt que manufacturer_reference sans preuve. Après no_match sans continuation, essayer au plus deux fragments plus courts pertinents en designation ou auto avant de demander une précision. Ne pas conclure à une absence du catalogue à partir d’une seule formulation. Si next_after_pid est non nul, des candidats restent à parcourir. Conserver les références, dates et incertitudes ; ouvrir les candidats avec get_product, sans inventer de PID.

Pour search_relay_points, destination désigne l’adresse du client autour de laquelle rechercher les points relais. Réutiliser l’adresse déjà fournie lorsqu’elle est complète ; ne demander que les informations manquantes. Pour le numéro et la rue, demander par exemple : « Pour trouver un point relais près de chez vous, pouvez-vous préciser votre numéro et votre rue ? » Ne pas appeler cette adresse « adresse de départ » ou « adresse d’expédition » : ce n’est pas le lieu d’expédition Nitech. Cette adresse de recherche ne vaut ni choix d’un relais ni modification de l’adresse de facturation. Rechercher les points relais GLS autour de destination (country_code, postal_code, city, address_line1) pour les lignes du panier, via l'API GLS existante. Lecture seule. Identifiant, nom, adresse, horaires lisibles, pauses et fermetures GLS lorsqu'ils sont fournis. Aucune distance ou capacité inventée, aucune réservation. Les heures affichées suivent le format REST GLS (millisecondes + 1h). Présenter les pauses et fermetures fournies ; un jour absent ne signifie pas fermé, et aucun horaire ne prouve une ouverture actuelle. Reprendre un relay_id retourné dans delivery={mode:gls_pickup,relay_id} de quote_cart_shipping, quote_cart et create_order. Le serveur revérifie le choix. Garder shipping_address comme destinataire réel et conserver billing_address séparée. Présenter mode, relais vérifié, frais et total, puis obtenir un nouvel accord si relais, adresse ou montant change. Lire category/fields/next_action dans les erreurs. Panne GLS : réessayer la même demande, sans modifier les adresses.

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.