Most "AI trading agent" demos stop at listing markets.
The hard part starts when the agent can place orders.
What broke first
- Keys on the model host - local MCP servers with private keys in env look fine in a demo, then become a single-point blast radius.
- Write tools always-on - if open/close is available in every chat, one prompt injection is enough.
- No sub-accounts - one shared balance for every agent routine makes audits painful.
Pattern that worked better
- Keep a remote MCP for execution (HTTP/streamable), so the Cursor/Claude machine never holds exchange keys.
- Start read-only (markets, positions, balances).
- Gate writes behind policy / human approve.
- Prefer sub-accounts per routine or per client.
We shipped that pattern as a USDT perpetual futures MCP:
- MCP endpoint: https://mcp.eterna.exchange/mcp
- Agent landing: https://ai.eterna.exchange
- Underlying hybrid venue (CEX-style books, no KYC): https://eterna.exchange
There is also a Deno-oriented SDK surface (~29 methods) if you want typed clients instead of raw tool calls.
Minimal agent loop
- Read markets + positions
- Decide size with hard caps
- Require confirmation before write tools
- Log every tool call
Telegram side note
If your distribution is Telegram-native (Mini Apps / bots), discovery and shipping speed matter as much as the agent:
- Catalog: https://tg.app
- No-code Mini App builder (TON + Stars): https://apps-father.com
Questions for builders
- Do you keep research MCP and execution MCP as separate servers?
- What is your default max notional before human approve?
Happy to compare notes.
Top comments (0)