Security

The biggest risk with any exchange integration is API-key exposure. This server is built so that the worst case is small, and so that the moment it can move money is an explicit choice you make — not the default.

Your keys never leave your machine

The server runs as a local subprocess and talks to your AI client over stdio. It is not a hosted service. Your credentials are read from your local environment and used only to call Delta's API directly from your machine. They never pass through the AI model or any Delta server beyond the normal trading API.

The only hop that sees your key is the server-to-Delta call on your own machine (the right edge above). Nothing sensitive crosses to the AI model.

Read-only by default

Out of the box the server has no code path to place, edit, cancel, or close an order, change leverage, or move funds — every tool is a read-only GET. If you never opt into trading, the worst case for a leaked key is someone reading your data, not losing it.

This matters: attackers have drained funds by abusing trade-enabled API keys. A read-only key removes that entire class of attack — so if you only need data, use one.

It can never withdraw

Even with trading enabled, the server has no withdrawal or transfer tool. The trading tools place and manage orders and positions; they cannot move funds off the exchange. There is no code path to a withdrawal.

Trading is an explicit opt-in

The trading tools register only when both of these are true:

1. You set DELTA_MCP_MODE=trade in the server's environment, and
2. You supply an API key that has Trading permission enabled.

Leave either out and the server stays fully read-only. This is a deliberate two-key-turn: a read-only key in trade mode still can't trade, and a trading-permission key without DELTA_MCP_MODE=trade still can't trade.

Guardrails when trading is on

• Dry run. Every mutating tool takes a dry_run flag. With dry_run: true it validates and echoes the exact payload it would send, without sending it. Ask the assistant to "place it as a dry run first," read it back, then confirm.
• No silent retries. Reads are retried on transient errors; mutations are never auto-retried. A timeout is surfaced, not re-sent.
• Explicit scope. Blast-radius tools (cancel_all_orders, close_all_positions) act on nothing until you set their scope flags.
• Not yet, planned: notional / position-size caps and confirmation prompts are on the roadmap, not in the current build — treat dry-run + your own confirmation as the control today.

Audit log

When trading is on, every mutation — dry-run or real — is appended as one JSON line to an owner-only (0600) audit log at ~/.delta-exchange-mcp/audit/. It records the tool, parameters, and result/order id, and never records your credentials. It's on by default in trade mode; disable with DELTA_MCP_AUDIT=off or relocate with DELTA_MCP_AUDIT_FILE. Ask the assistant "where is the audit log?" (the get_trading_status tool returns the path).

Choose the right key

When you create your API key on Delta, grant only what you need: Read Data for data-only use, or Trading if you intend to enable trade mode. Add an IP whitelist so the key works only from your machine, and revoke it anytime (revocation is immediate). Step-by-step in Authentication.

Public data needs no key

The 14 market-data tools (tickers, order book, candles, options chain, OI, funding, indices, and more) work with no credentials at all. You add a key only for the 13 account tools (positions, balances, fills, order history) and, if you opt in, the 13 trading tools.

Match your environment

Use production keys with DELTA_MCP_ENV=india_prod and testnet keys with india_testnet. Test on testnet first if you are unsure.

Open source

The server is MIT-licensed and open. Audit exactly what it does before you run it. Source: github.com/delta-exchange/delta-exchange-mcp.