nakazanie-ton/myrocket

Échange xRocket

Utilisez les outils MCP sémantiques xRocket. Gardez l'analyse publique rapide et chaque action privée ou financière sécurisée par défaut (fail-closed).

Démarrage sécurisé

1. Identifiez l'environnement et l'opération demandés. L'environnement est fixé au démarrage du serveur MCP : lorsque l'utilisateur n'en spécifie pas, exigez un serveur configuré en testnet et vérifiez l'environment renvoyé par les outils avant toute écriture.
2. Utilisez public pour les données de marché. Utilisez private-read uniquement lorsque l'état du compte est nécessaire. Utilisez full uniquement lorsque l'utilisateur demande explicitement une action financière prise en charge.
3. Ne demandez jamais le jeton API dans le chat et ne le passez pas comme argument d'outil. Si un outil privé est indisponible, expliquez la configuration d'environnement requise sans solliciter le secret.
4. Lisez references/api-map.md pour la sélection des outils. Lisez references/safety.md avant toute écriture, references/errors.md pour les échecs et references/advanced-workflows.md pour les travaux en plusieurs étapes.

Workflow de marché public

1. Résolvez l'actif/symbole avec xrocket_market_symbols ou xrocket_asset_info avant l'analyse.
2. Récupérez uniquement les preuves nécessaires : ticker, snapshot du carnet d'ordres, transactions, bougies, taux ou frais de négociation.
3. Préservez les horodatages et les chaînes décimales. Identifiez les champs obsolètes ou manquants ; ne synthétisez pas le taux de financement, l'intérêt ouvert, les positions, l'effet de levier ou les données de produits dérivés car l'API auditée ne les expose pas.
4. Décrivez le résultat comme un snapshot REST xRocket, et non comme un flux WebSocket en direct.

Workflow de lecture privée

1. Confirmez que l'utilisateur souhaite ses données de compte et que private-read ou full est configuré localement.
2. Utilisez xrocket_account_balances, xrocket_orders, xrocket_transfers, xrocket_withdrawals ou xrocket_withdrawal_quotas.
3. Minimisez la divulgation dans la réponse. Ne renvoyez pas le jeton porteur, les adresses de retrait complètes ou les données de compte non pertinentes.
4. Distinguez les soldes de trading et de financement. Décrivez les transferts Exchange uniquement comme des mouvements internes funding ↔ trading.

Workflow d'écriture financière

Ne sautez jamais directement à un outil d'exécution.

1. Lisez les règles actuelles du symbole/actif, les soldes pertinents et, le cas échéant, le quota de retrait.
2. Exigez un identifiant client unique pour chaque nouvel ordre, transfert interne ou retrait. L'annulation peut plutôt identifier l'ordre existant par orderId.
3. Appelez l'outil *_prepare correspondant et inspectez son aperçu exact.
4. Présentez l'environnement, l'opération, l'actif/symbole/réseau, la direction/côté, le montant/taille/fonds décimal, le prix/prix d'arrêt, les frais/estimation, la destination/compte et l'identifiant client. Demandez l'approbation explicite de cet aperçu.
5. Exécutez uniquement après l'approbation actuelle de l'utilisateur, en passant uniquement le approvalReceipt de courte durée renvoyé. Le serveur récupère l'intention exacte stockée ; ne soumettez pas et ne reconstruisez pas la charge utile.
6. Relisez l'état par identifiant client. En cas de timeout/déconnexion/réponse amont ambiguë, signalez un résultat inconnu et conciliez avant de proposer une nouvelle tentative. Ne réessayez jamais automatiquement une écriture.

Le mainnet nécessite une décision utilisateur explicite séparée et XROCKET_ALLOW_MAINNET_WRITES=true. Une approbation préalable en testnet n'autorise pas le mainnet.

Dépôts et intégration

L'API Exchange auditée n'a pas de point de terminaison d'adresse de dépôt. N'inventez pas et n'acceptez pas une adresse non vérifiée. Utilisez xrocket_onboarding_links pour les instructions de l'interface utilisateur, divulguez que ses appels à l'action (CTA) contiennent le code de parrainage kaban et peuvent bénéficier au mainteneur, puis actualisez les soldes de financement après que l'utilisateur a effectué le dépôt.

N'ajoutez jamais le code de parrainage aux URL de l'API, WebSocket, documentation, dépôt, support ou MCP. Les CTA des bots de production et de testnet gérés par le projet, renvoyés par l'outil, utilisent tous deux la charge utile start=kaban ; n'inventez pas d'autres formes d'URL de parrainage.

Limites strictes

• Ne traitez pas les transferts internes Exchange comme des paiements d'utilisateur à utilisateur. xRocket Pay est un produit distinct et n'est pas disponible via ces outils.
• Ne convertissez pas les chaînes décimales financières via une virgule flottante binaire.
• Ne prétendez pas à la reconstruction delta du carnet d'ordres, à la relecture ou à l'exhaustivité des événements privés ; la version 0.1.0 expose des snapshots REST.
• Ne copiez pas le comportement d'offre/deal non pris en charge des tutoriels dans les appels API.
• N'utilisez pas TON comme identifiant d'actif là où les métadonnées actuelles d'Exchange nécessitent TONCOIN ; le réseau TON et l'actif TONCOIN sont des champs différents.
• Ne déployez pas de profils privés/d'écriture derrière un point de terminaison MCP public non authentifié.