nakazanie-ton/myrocket

xRocket Exchange

Verwenden Sie semantische xRocket MCP-Tools. Halten Sie öffentliche Analysen schnell und jede private oder finanzielle Aktion faill-closed.

Sicher starten

1. Identifizieren Sie die angeforderte Umgebung und Operation. Die Umgebung wird beim Start des MCP-Servers festgelegt: Wenn der Benutzer keine angibt, fordern Sie einen testnet-konfigurierten Server an und überprüfen Sie die von den Tools zurückgegebene environment, bevor Sie Schreiboperationen durchführen.
2. Verwenden Sie public für Marktdaten. Verwenden Sie private-read nur, wenn Kontostand benötigt wird. Verwenden Sie full nur, wenn der Benutzer explizit eine unterstützte Finanzaktion anfordert.
3. Fragen Sie niemals im Chat nach dem API-Token oder übergeben Sie es als Tool-Argument. Wenn ein privates Tool nicht verfügbar ist, erklären Sie die erforderliche Umgebungskonfiguration, ohne nach dem Geheimnis zu fragen.
4. Lesen Sie references/api-map.md für die Toolauswahl. Lesen Sie references/safety.md vor jeder Schreiboperation, references/errors.md für Fehler und references/advanced-workflows.md für mehrschrittige Arbeiten.

Öffentlicher Markt-Workflow

1. Lösen Sie das Asset/Symbol mit xrocket_market_symbols oder xrocket_asset_info vor der Analyse auf.
2. Rufen Sie nur die benötigten Nachweise ab: Ticker, Orderbuch-Snapshot, Trades, Candlesticks, Kurse oder Handelsgebühren.
3. Bewahren Sie Zeitstempel und Dezimalzeichenfolgen. Kennzeichnen Sie veraltete oder fehlende Felder; synthetisieren Sie keine Finanzierungsrate, offenes Interesse, Positionen, Hebel oder Derivatedaten, da die geprüfte API diese nicht bereitstellt.
4. Beschreiben Sie das Ergebnis als xRocket REST-Snapshot, nicht als Live-WebSocket-Stream.

Privater Lese-Workflow

1. Bestätigen Sie, dass der Benutzer seine Kontodaten sehen möchte und dass private-read oder full lokal konfiguriert ist.
2. Verwenden Sie xrocket_account_balances, xrocket_orders, xrocket_transfers, xrocket_withdrawals oder xrocket_withdrawal_quotas.
3. Minimieren Sie die Offenlegung in der Antwort. Geben Sie weder das Bearer-Token, vollständige Auszahlungsadressen noch nicht zusammenhängende Kontodaten wieder.
4. Unterscheiden Sie Handels- und Funding-Guthaben. Beschreiben Sie Exchange-Transfers nur als interne funding ↔ trading-Bewegungen.

Finanzieller Schreib-Workflow

Springen Sie niemals direkt zu einem Ausführungstool.

1. Lesen Sie die aktuellen Symbol-/Asset-Regeln, relevante Guthaben und – falls zutreffend – das Auszahlungskontingent.
2. Fordern Sie eine eindeutige Client-Kennung für jede neue Order, interne Überweisung oder Auszahlung. Die Stornierung kann stattdessen die bestehende Order per orderId identifizieren.
3. Rufen Sie das passende *_prepare-Tool auf und prüfen Sie dessen genaue Vorschau.
4. Präsentieren Sie Umgebung, Operation, Asset/Symbol/Netzwerk, Richtung/Seite, Dezimalbetrag/Größe/Guthaben, Preis/Stop-Preis, Gebühr/Schätzung, Ziel/Konto und Client-Kennung. Fragen Sie nach expliziter Zustimmung zu dieser Vorschau.
5. Führen Sie nur nach der aktuellen Zustimmung des Benutzers aus und übergeben Sie ausschließlich das zurückgegebene kurzlebige approvalReceipt. Der Server ruft die exakte gespeicherte Absicht ab; reichen Sie das Payload nicht erneut ein oder rekonstruieren Sie es nicht.
6. Lesen Sie den Zustand anhand der Client-Kennung zurück. Bei Timeout/Verbindungsabbruch/mehrdeutiger Antwort des Upstreams melden Sie unbekanntes Ergebnis und gleichen Sie ab, bevor Sie einen weiteren Versuch vorschlagen. Wiederholen Sie einen Schreibvorgang niemals automatisch.

Mainnet erfordert eine separate explizite Benutzerentscheidung und XROCKET_ALLOW_MAINNET_WRITES=true. Eine vorherige Testnet-Genehmigung autorisiert kein Mainnet.

Einzahlungen und Onboarding

Die geprüfte Exchange-API hat keinen Endpunkt für Einzahlungsadressen. Erfinden oder akzeptieren Sie keine unbestätigte Adresse. Verwenden Sie xrocket_onboarding_links für UI-Anweisungen, geben Sie offen an, dass die CTAs den Referral-Code kaban enthalten und dem Betreuer zugutekommen können, und aktualisieren Sie anschließend die Funding-Guthaben, nachdem der Benutzer die Einzahlung abgeschlossen hat.

Hängen Sie den Referral-Code niemals an API-, WebSocket-, Dokumentations-, Repository-, Support- oder MCP-URLs an. Die vom Projekt verwalteten Produktions- und Testnet-Bot-CTAs, die vom Tool zurückgegeben werden, verwenden beide das start=kaban-Payload; erfinden Sie keine anderen Referral-URL-Formen.

Harte Grenzen

• Behandeln Sie interne Exchange-Transfers nicht als Zahlungen von Benutzer zu Benutzer. xRocket Pay ist ein separates Produkt und über diese Tools nicht verfügbar.
• Zwingen Sie finanzielle Dezimalzeichenfolgen nicht durch binäre Fließkommazahlen.
• Behaupten Sie keine Orderbuch-Delta-Rekonstruktion, Wiedergabe oder Vollständigkeit privater Ereignisse; 0.1.0 stellt REST-Snapshots bereit.
• Kopieren Sie nicht unterstütztes Angebot/Deal-Verhalten aus Tutorials in API-Aufrufe.
• Verwenden Sie TON nicht als Asset-Kennung, wenn die aktuellen Exchange-Metadaten TONCOIN erfordern; Netzwerk TON und Asset TONCOIN sind unterschiedliche Felder.
• Stellen Sie private/Schreib-Profile nicht hinter einem öffentlichen, nicht authentifizierten MCP-Endpunkt bereit.