The project ships with a deliberate adversarial feed and a constrained execution model. Understanding why the feed is adversarial, what the architecture enforces automatically, and how to handle credentials correctly is the minimum required reading before enabling the live broker or theDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/theonetrade/ai-trading-mcp/llms.txt
Use this file to discover all available pages before exploring further.
/loop automation.
The Feed Is Adversarial by Design
The default demo channel (CC_TELEGRAM_CHANNEL = -1002833393903) is a real Telegram “signals” channel. It wears every classic scam marker in the book: 100x cross position screenshots, a BingX referral code, a “DM @… for 500% profit” call to action, and withdrawal screenshots used as social proof.
This is deliberate. The rig’s working assumption is that the feed is untrusted input — a stream of potentially manipulated data that should influence analysis but must never be able to directly execute anything. Switching to a trustworthy private feed does not change the design; the architecture enforces safe behaviour regardless of what the channel contains.
In a recorded live session the channel posted “who has a $3000+ deposit and doesn’t know how to grow it — DM @…”. The scheduled agent classified the post as recruiting, took no trade action, and appended its own source assessment to the status report: “P&L numbers between posts don’t add up; I would not trust this as data.”
What the Architecture Enforces
The safety properties below are structural — they hold because of what the code does and does not expose, not because of what the prompt says.Constrained tool vocabulary
The agent’s entire vocabulary is three tools:
get_status, open_position, and close_position. open_position carries only symbol, position (long | short), and note. There is no size parameter, no leverage parameter, no address field, no withdrawal verb.Symbol whitelist + validation chain
Every
open_position call passes through the full engine validation chain: MCP → strategy → risk profiles → actions. A symbol outside CC_SYMBOL_LIST cannot be traded. Duplicate-open attempts (symbol already holds a position or a pending signal) are rejected by the engine.Instructions are data, not commands
Text embedded in feed posts arrives as content inside a
get_status response — a tool result. It cannot call tools, modify engine state, or override validation. The model decides what to do with it, bounded by the three tools above.Audit trail closes the loop
Every
get_status response — including every feed post and chart screenshot the model saw — is dumped to dump/mcp/<timestamp>.md before it leaves the process. Position notes echo back through every status call. There is no gap between what happened and what was recorded.The /loop Prompt’s Report-Only Rule
The/loop automation (Quick Start step 4) uses exactly this prompt structure:
/loop) never widens the agent’s vocabulary. The loop re-runs the same three-tool context on a timer — it does not grant additional permissions, unlock new endpoints, or change the engine’s validation chain.
Credentials and Secrets
session.txt — Telegram user session
session.txt is written by the --session authorization flow and stores a GramJS user session string. It grants full access to the Telegram account that completed the QR scan: reading all chats, sending messages, and everything else a logged-in user can do.Keep session.txt out of version control. Keep it off shared machines. Treat it like a password.BINANCE_API_KEY / BINANCE_API_SECRET
Used only in live mode. The adapter only needs spot trading permissions — enable read access and spot order placement, and nothing else. Withdrawal permission must never be granted to these keys; the adapter has no withdrawal code path and granting the permission only widens the blast radius of a key leak.
CC_TELEGRAM_API_ID / CC_TELEGRAM_API_HASH
The Telegram API pair is obtained from my.telegram.org. The repository ships with a development fallback value hardcoded in the config for convenience. Do not ship the fallback values in production. Set your own pair via environment variables before deploying to any shared or persistent environment.
What the Engine Validates
The validation chain runs on everyopen_position and close_position call. None of these guards can be bypassed through prompt engineering — they are enforced in code before any broker call is made.
MCP layer
The request arrives through the HTTP bridge from the stdio MCP server. Transport success is not operation success — the outcome travels in an envelope where
error is either an empty string or the engine’s exact message.Strategy layer
The strategy’s signal is validated against the registered
strategyName. Calls that do not originate from a registered strategy are rejected.Risk profiles
The engine applies configured risk rules — position sizing, cost limits, and the symbol whitelist (
CC_SYMBOL_LIST). A symbol not in the whitelist is rejected here. The 13-symbol default whitelist (BTCUSDT, ETHUSDT, and 11 others) is set in packages/main/src/config/params.ts.Run in paper mode (
--paper) for at least several /loop cycles before enabling live mode. Paper mode uses real Binance market data and real Telegram feed content with simulated fills — it is the closest possible rehearsal of the live setup without real money at risk. Understanding what the feed actually contains, how the agent responds to it, and which symbols the engine accepts is essential context before going live.