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 what the assistant can do is decided by one thing you control: the permission on the key you give it.

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. Requests are signed locally with HMAC-SHA256. The credentials 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.

Market data needs no key at all

With no credentials the server has no code path to your account. The account and trading tools are never registered, and the 14 market-data tools that remain read public data. If all you want is prices, chains and candles, give it no key and there is nothing to leak.

It can never withdraw

Whatever key it holds, 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.

Your key's permission is the only gate

Save any valid key and both the account tools and the trading tools register. The server adds no gate of its own: what happens next is decided on Delta's side.

• A Read Data key reads your positions, balances and fills. Delta rejects every order sent with it, with UnauthorizedApiAccess - API key lacks permission for this endpoint.
• A key carrying Trading permission places real orders from the moment it is saved. There is no mode to set, no restart, and no confirmation step.

That boundary holds because Delta enforces it, not because this server chose to. Pick the permission you actually want, and give an assistant a Read Data key unless you want it trading your account.

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 want the assistant to place orders. Add an IP whitelist so the key works only from your machine (Delta requires one on Trading keys), and revoke it whenever you want. Revocation is immediate, and it is how you take trading back. 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 for the 12 account tools (positions, balances, fills, order history) and the 13 trading tools, which register together.

Two more tools are always registered and need no key either: setup_credentials and get_connection_status. Neither returns your key, your secret, or a fingerprint of either.

The key never goes through the assistant

There are two ways to hand over a key, and neither puts it in the conversation. Your client's own config holds it outside the chat. The in-chat form runs in its own frame, so what you type there goes straight to ~/.delta-exchange-mcp/config.env, a file the server creates owner-only, and the assistant cannot read it.

Sending the key to the assistant as an ordinary chat message is not the same thing. A message is in the model's context and is stored in the conversation. If an assistant offers to take your key that way, decline.

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.