MCP tools
Use optional tools over the public API; keep live data on WebSockets.
What the hosted MCP server provides
The Edel MCP server is a stateless Streamable HTTP service at /mcp. It forwards tools through the public REST API using the same scoped account credential and error contracts. Trading execution, custody and live data keep their existing product boundaries.
Configure the endpoint explicitly supplied for your approved venue, then verify the connected server and client. Edel Markets is on Devnet, with Testnet and Mainnet coming soon. Keep credentials scoped to their environment; see environments and endpoints.
Configure a remote client securely
Complete the owner-approved device grant outside the hosted MCP service. Configure your client to send Authorization: Bearer with the resulting API key on every HTTP request. Use the client's private secret mechanism. The example below shows only the shape; each client's remote-server configuration syntax differs.
A compatible client must support remote Streamable HTTP, persistent private header configuration and the owner's tool-approval controls. Support for private headers and tool approvals varies by client, plan and mode. Check the specific client's current capabilities before adding the server.
{
"mcpServers": {
"edel": {
"url": "<MCP URL supplied by Edel for your environment>",
"headers": {
"Authorization": "Bearer <key supplied by the client secret store>"
}
}
}
}Confirm access with read-only tools
Call edel_connect to inspect the supplied key’s metadata, then edel_status to check account readiness. On the hosted server, edel_connect inspects an existing credential; complete the browser approval flow before configuring the MCP client.
Next, edel_markets reads the catalogue and edel_price reads market statistics and book snapshots. These hosted tools require an approved read-capable key. Public REST market reads are available without a credential. See the MCP tool reference and check the connected server’s advertised tools.
Manage keys independently of MCP sessions
The hosted service keeps no client key between requests and does not write keys to disk. Every request supplies its own bearer. An MCP session identifier does not grant account authority.
When the key expires, complete a fresh device grant with owner approval and update the private header. When revoked, stop and obtain owner direction before reconnecting. Recheck account readiness after changing credentials. Do not fall back to the owner's browser session bearer or paste a key into a prompt to work around client configuration.
Use tools within their actual capabilities
MCP snapshot tools are not live price feeds. Use WebSockets for ongoing market and account observation. Ticket minting, rotation and revocation are not exposed as MCP tools. A direct client manages WebSocket authentication separately.
MCP cannot deposit, withdraw, change secure account identity or manage keys. Closing a position uses a reduce-only market order. Funding output is cumulative by position episode, not a payment ledger. See tool coverage and agent permissions before enabling writes.
Connection and snapshot tools
The tools below inspect connection metadata and read market or account snapshots. Hosted requests require an approved read-capable key. The server derives accountId from that key, and other request fields retain their REST names.
Use the connected server’s current schemas and readOnlyHint, destructiveHint and idempotentHint annotations when configuring tool behavior and approval controls.
| Tool | Behavior | Public REST mapping |
|---|---|---|
| edel_connect | Hosted: read current supplied key metadata | GET /v1/api-keys/current |
| edel_status | Read account and secure-setup readiness | GET /v1/accounts/{accountId}; GET /v1/accounts/{accountId}/party |
| edel_markets | Read catalogue | GET /v1/markets |
| edel_price | Read stats and book | GET /v1/markets/{marketId}/stats; GET /v1/markets/{marketId}/book |
| edel_account | Read account snapshot | GET /v1/accounts/{accountId} |
| edel_kyc_status | Read KYC status | GET /v1/accounts/{accountId}/kyc |
| edel_market | Read one market snapshot | GET /v1/markets/{marketId} |
| edel_candles | Read historical candles | GET /v1/markets/{marketId}/candles |
| edel_candidate_markets | Read candidate-market discovery | GET /v1/market-data/candidate-markets |
| edel_leaderboard | Read public leaderboard | GET /v1/leaderboard |
| edel_affiliate_availability | Read public affiliate availability | GET /v1/affiliate/availability |
Order, position and history reads
History tools return one page, default 50 and maximum 100, with nextCursor and projection freshness. All histories support marketId; order and position histories also support their documented status filters. Pass the returned cursor to continue. Live open orders and historical order projections answer different questions.
| Tool | Behavior | Public REST mapping |
|---|---|---|
| edel_orders | Read live open orders | GET /v1/accounts/{accountId}/orders/open |
| edel_positions | Read current positions | GET /v1/accounts/{accountId}/positions |
| edel_order | Read one order's lifecycle state | GET /v1/orders/{orderId} |
| edel_order_history | Read paginated order projection | GET /v1/accounts/{accountId}/orders |
| edel_trade_history | Read paginated fills | GET /v1/accounts/{accountId}/fills |
| edel_position_history | Read paginated position episodes | GET /v1/accounts/{accountId}/positions/history |
| edel_funding | Read cumulative funding by position episode | GET /v1/accounts/{accountId}/positions/history |
| edel_preview_order | Estimate an order; does not reserve or submit it | POST /v1/orders/preview |
Trading mutations
Trading tools require trade scope. Configure the client to keep each call within the owner’s approved action or strategy limits. Placement requires a caller-chosen clientOrderId; retain it and identical arguments across retries, including after a lost response. Use each tool’s current input schema for its idempotency fields.
| Tool | Effect | Public REST mapping |
|---|---|---|
| edel_place_order | Submit one market or limit order | POST /v1/orders |
| edel_cancel_order | Cancel an owned order's unfilled remainder | POST /v1/orders/{orderId}/cancel |
| edel_close_position | Read position, then submit a reduce-only market order | GET /v1/accounts/{accountId}/positions; POST /v1/orders |
| edel_place_order_batch | Submit 1–32 independently decided limit orders | POST /v1/orders/batch |
| edel_cancel_order_batch | Cancel 1–24 named owned orders | POST /v1/orders/batch/cancel |
Interpret tool results
edel_funding labels its basis cumulative_per_position_episode. fundingPaidAtoms belongs to the whole position episode; the tool does not produce per-payment funding history. edel_close_position submits an order and must be reconciled like any other order. Batch tools may partially succeed.
Take profit and stop loss travel in autoClose on placement or each supported batch entry. There is no separate trigger-management tool. There is also no /v1 timeInForce input or atomic amend-order tool. Use the documented placement fields for attached exits and reconcile cancel/new orders as separate commands.
Owner workflows and separate interfaces
Deposits, withdrawals, browser sign-in, passkey approval, secure identity changes, agent approval and key management remain owner workflows. API keys also cannot access private transfer/affiliate reads or edit favorites.
WebSocket ticket management and health/contract probes are outside the MCP tool set. Use direct APIs for those supported operations, and use the listed /v1 tool for capabilities also available through CCXT. Methods returning HTTP 501 NotSupported are unavailable through MCP.
The tool descriptions and the agent permission map describe supported operations. Check both the connected server and client, because a client interface may expose only part of the available tool set.
Verify the connection configuration
Set the supplied Devnet MCP URL where MCP is enabled, following environments and endpoints, and load the key through the client’s secret-storage mechanism. Keep the endpoint, credential and approved account together when managing multiple environments.
After a configuration or credential change, run edel_connect and edel_status again before enabling trading tools. Check that the connected server’s tool schemas match your client, and confirm that the intended approval controls are active. See the tool descriptions and agent authorization.