The safety design is the reason to trust this one: trading tools error out by default, a separate read-only setting overrides everything, orders are capped by notional value, and validation and dry runs work regardless. On the read side, the snapshot tool is the practical win — one call instead of five when an agent wants the state of an instrument.
A server over the Bybit API split into three groups: market data, account reads, and mutating trading calls that stay disabled until you enable them.
- Market data: get_orderbook, get_kline, get_tickers, get_public_trade_history, get_instruments_info, get_funding_rate_history, get_open_interest, get_fee_rate and get_server_time
- market_snapshot bundles order book, ticker, candles, instrument metadata and recent trades — plus funding rate and open interest for futures — into a single call
- Account: get_wallet_balance, get_positions, get_order_history, get_open_orders and get_api_key_information
- Trading once enabled: place_order, amend_order, cancel_order, cancel_all_orders, set_trading_stop for take-profit and stop-loss, set_margin_mode and set_leverage
- validate_order checks an order without placing it and is never blocked by the trading switches; place_order also has a dry-run mode
- Trading is off by default, and a separate read-only setting hard-blocks every mutating tool regardless of the other switches
- An order-size cap limits the estimated notional value of any single order
- A trimmed response mode cuts ticker and position payloads down to their core fields to save context
A Bybit API key and secret, with read permission at minimum, wallet permission for balances, and trade permission only if you intend to place orders. The README recommends restricting the key to the IP the server runs from. Python, run from a checkout or the published container image, with a testnet mode for experimenting.
One command plus a key — npx -y @smithery/cli install @dlwjdtn535/mcp-bybit-server --client claude, then supply credentials
