Skip to content

Build with an AI agent

These docs are written to be read by an agent. There are two ways to hand over the integration.

Two machine-readable index files sit at the API root:

File What it is
/llms.txt A compact map of the docs — sections and links. Point an agent here first.
/llms-full.txt Every doc concatenated into one file. Paste it into a chat and ask for the integration.

Both follow the llms.txt standard. A prompt that works:

Read https://api.troncharts.xyz/llms.txt, then write me a TypeScript script that calls the REST API to create a prop firm, waits for readiness, dry-run deploys, then goes live. My multisig is 0x… and my fee config is 5% entry / 10% payout.

Because the docs carry the exact endpoints, scopes, and request shapes, an agent can produce a working integration without guessing at them.

Give the agent tools instead of prose. It calls create_firm and check_firm_readiness rather than writing HTTP, the trading catalog is filtered by your credential’s tier, and the backend enforces scopes on every call — so it cannot reach past what you granted. See MCP server.

  • Feeding docs is best for generating code you own and run yourself.
  • MCP is best for an agent that operates the firm live — monitoring readiness, deploying, working the payout queue.

Both share the same credential and scopes.

Whichever route you take, an agent with a fullTrading credential can place real orders. Two habits make that safe:

  1. Rehearse on a sandbox account. POST /api/v1/sandbox/paper-account exercises the identical order path with no real money.
  2. Issue the narrowest tier. An agent that only reports doesn’t need more than readonly. Over REST, liquidation reaches exactly /api/v1/oms/cancel, /api/v1/oms/cancel-all and /api/v1/oms/flatten; every other mutating OMS call comes back 403 tier_insufficient. On the MCP route the split is narrower — a liquidation credential gets cancel_order and cancel_all_orders only, so an agent that must flatten needs fullTrading there.