Set the wallet address and the trading tools cannot work, whatever the model decides to try; the private key is what turns them on. Once it is on, this executes rather than advises — placing, flattening and withdrawing are each one call.
A Hyperliquid client covering the whole trading surface: orders placed, modified and cancelled, leverage set per asset, market data at trading depth, fills and fees, and USDC withdrawal. Two configurations, and the difference matters — a wallet address alone is read-only, and the trading tools return an error until a private key is present.
- A full order lifecycle: place, modify in place, cancel one, bulk-cancel a set, or cancel everything with an optional asset filter
- The minimum order size for the exchange's own minimum-value rule worked out before the order goes in, rather than after it is rejected
- Market data deep enough to trade on — L2 order book, historical OHLCV candles, and current and historical funding rates for perpetuals
- Positions and spot balances read separately, leverage adjustable per asset, and the account's own fee tier
- Fills as recent activity or across a time range you name
- Order status by ID, and open orders listed
- USDC withdrawn from Hyperliquid to an external wallet
Python, installed from PyPI or run straight through uvx as hyperliquid-mcp. For reading only, set HL_WALLET_ADDRESS and nothing else. Trading needs HL_PRIVATE_KEY, which stays on your machine — the server runs locally over stdio and talks only to Hyperliquid's API. With the key present, an order placed is a live order and a withdrawal moves real funds, so the project's own advice is a dedicated wallet with limited funds.
One command plus a key — uvx hyperliquid-mcp, then supply credentials