nakazanie-ton/myrocket

Exchange xRocket

Use as ferramentas MCP semânticas do xRocket. Mantenha a análise pública rápida e mantenha toda ação privada ou financeira com falha segura (fail-closed).

Inicie com segurança

1. Identifique o ambiente e a operação solicitados. O ambiente é fixo quando o servidor MCP inicia: quando o usuário não especificar um, exija um servidor configurado para testnet e verifique o environment retornado pelas ferramentas antes de qualquer escrita.
2. Use public para dados de mercado. Use private-read apenas quando o estado da conta for necessário. Use full apenas quando o usuário solicitar explicitamente uma ação financeira suportada.
3. Nunca peça o token de API no chat ou passe-o como argumento de ferramenta. Se uma ferramenta privada estiver indisponível, explique a configuração de ambiente necessária sem solicitar o segredo.
4. Leia references/api-map.md para seleção de ferramentas. Leia references/safety.md antes de qualquer escrita, references/errors.md para falhas e references/advanced-workflows.md para trabalhos de várias etapas.

Fluxo público de mercado

1. Resolva o ativo/símbolo com xrocket_market_symbols ou xrocket_asset_info antes da análise.
2. Busque apenas as evidências necessárias: ticker, snapshot do orderbook, trades, candles, taxas ou taxas de negociação.
3. Preserve carimbos de data/hora e strings decimais. Identifique campos obsoletos ou ausentes; não sintetize taxa de funding, juros em aberto, posições, alavancagem ou dados de derivativos porque a API auditada não os expõe.
4. Descreva o resultado como um snapshot REST do xRocket, não um stream WebSocket ao vivo.

Fluxo de leitura privada

1. Confirme que o usuário deseja seus dados de conta e que private-read ou full está configurado localmente.
2. Use xrocket_account_balances, xrocket_orders, xrocket_transfers, xrocket_withdrawals ou xrocket_withdrawal_quotas.
3. Minimize a divulgação na resposta. Não ecoe o bearer token, endereços de retirada completos ou dados de conta não relacionados.
4. Distinga saldos de trading e funding. Descreva transferências Exchange apenas como movimentos internos funding ↔ trading.

Fluxo de escrita financeira

Nunca pule diretamente para uma ferramenta de execução.

1. Leia as regras atuais do símbolo/ativo, saldos relevantes e — quando aplicável — a cota de retirada.
2. Exija um identificador de cliente único para cada nova ordem, transferência interna ou retirada. O cancelamento pode, em vez disso, identificar a ordem existente pelo orderId.
3. Chame a ferramenta *_prepare correspondente e inspecione sua prévia exata.
4. Apresente ambiente, operação, ativo/símbolo/rede, direção/lado, valor/tamanho/fundos decimal, preço/preço de parada, taxa/estimativa, destino/conta e identificador do cliente. Peça aprovação explícita dessa prévia.
5. Execute somente após a aprovação atual do usuário, passando apenas o approvalReceipt de curta duração retornado. O servidor recupera a intenção exata armazenada; não reenvie ou reconstrua o payload.
6. Leia o estado de volta pelo identificador do cliente. Em caso de timeout/desconexão/resposta ambígua do upstream, reporte resultado desconhecido e reconcilie antes de propor outra tentativa. Nunca tente novamente automaticamente uma escrita.

Mainnet requer uma decisão explícita separada do usuário e XROCKET_ALLOW_MAINNET_WRITES=true. Uma aprovação anterior em testnet não autoriza mainnet.

Depósitos e onboarding

A API Exchange auditada não tem endpoint de endereço de depósito. Não invente ou aceite um endereço não verificado. Use xrocket_onboarding_links para instruções de UI, divulgue que seus CTAs contêm o código de referência kaban e podem beneficiar o mantenedor, então atualize os saldos de funding após o usuário completar o depósito.

Nunca anexe o código de referência a URLs de API, WebSocket, documentação, repositório, suporte ou MCP. Os CTAs de bot de produção e testnet gerenciados pelo projeto, retornados pela ferramenta, ambos usam o payload start=kaban; não invente outras formas de URL de referência.

Limites rígidos

• Não trate transferências internas da Exchange como pagamentos entre usuários. xRocket Pay é um produto separado e não está disponível através destas ferramentas.
• Não force strings decimais financeiras através de ponto flutuante binário.
• Não alegue reconstrução de delta do orderbook, replay ou completude de eventos privados; 0.1.0 expõe snapshots REST.
• Não copie comportamento de oferta/deal não suportado de tutoriais em chamadas de API.
• Não use TON como identificador de ativo onde os metadados atuais da Exchange exigem TONCOIN; a rede TON e o ativo TONCOIN são campos diferentes.
• Não implante perfis privados/escrita atrás de um endpoint MCP público não autenticado.