Loading ToolBench
Analyze Hyperliquid accounts: positions, PnL, fills, open orders, funding. Full clearinghouse state for any wallet. The portfolio layer agents need for Hyperliquid trading intelligence.
Four tools with complete input schemas and strong descriptions (194 - 350 chars, well above 10-char minimum). All parameters typed and described. Tool names follow verb_noun pattern (get_*). Descriptions include WHEN to use, what to return, and explicit DO NOT use guidance. However, output schemas are documented only in description text, not as formal JSON Schema objects. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Error handling guidance is absent, no recovery paths or actionable error messages defined. Parameter constraints (e.g., limit max 100) are stated in descriptions but not enforced via JSON Schema minima/maxima. All tools are READ_ONLY, reducing risk, but no formal permission gates or audit trail patterns visible.
Use this when you need to retrieve the full portfolio state of a Hyperliquid perpetuals account. Returns the complete clearinghouse state for any wallet address including account-level metrics and per-position details. Returns: 1. accountValue: total account equity in USD 2. totalNtlPos: total notional position size across all open positions 3. totalMarginUsed: margin currently locked in positions 4. withdrawable: available balance that can be withdrawn 5. positions[]: array of open positions, each with coin, size, entryPrice, unrealizedPnl, leverage, liquidationPrice, marginType (cross/isolated) Example output: { accountValue: "125430.50", totalNtlPos: "89200.00", withdrawable: "36230.50", positions: [{ coin: "BTC", size: "1.5", entryPrice: "67500.00", unrealizedPnl: "2340.00", leverage: 5, liquidationPrice: "54200.00", marginType: "cross" }] } Use this BEFORE analyzing a trader's risk exposure, checking margin health, or evaluating portfolio allocation on Hyperliquid. Essential for copy-trading evaluation and risk monitoring. Do NOT use for trade history -- use hyperliquid_get_trade_fills instead. Do NOT use for open orders -- use hyperliquid_get_open_orders instead. Do NOT use for funding payments -- use hyperliquid_get_user_funding instead. Do NOT use for vault performance -- use hyperliquid_get_vault_details instead. Do NOT use for whale tracking -- use hyperliquid_detect_whale_trades instead.
Use this when you need to see all pending/open orders for a Hyperliquid perpetuals account. Returns every resting order on the book with full order parameters. Returns: 1. coin: the perpetual market (BTC, ETH, SOL, etc.) 2. side: buy (bid) or sell (ask) 3. limitPx: limit price of the order 4. sz: order size 5. orderType: limit, stop-market, stop-limit, take-profit, etc. 6. reduceOnly: whether the order can only reduce an existing position 7. timestamp: when the order was placed 8. oid: unique order ID Example output: { orders: [{ coin: "BTC", side: "buy", limitPx: "65000.00", sz: "0.5", orderType: "limit", reduceOnly: false, oid: 123456 }], count: 3 } Use this to understand a trader's pending strategy, detect limit orders near current price, evaluate order-to-position ratio, or monitor stop-loss placement on Hyperliquid. Do NOT use for executed trades -- use hyperliquid_get_trade_fills instead. Do NOT use for current positions -- use hyperliquid_get_account_state instead. Do NOT use for market-level orderbook -- use hyperliquid_get_market_data instead.
Output schemas documented only in description text, not as formal JSON Schema. LLMs cannot parse unstructured prose to extract field types and structure for downstream tool chaining.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are READ_ONLY but this is not formally declared in the tool definition, forcing LLMs to infer safety from descriptions.
No error handling guidance. Tools lack recovery paths (e.g., 'If address not found, try search_addresses()') or actionable error messages. Agents cannot self-correct on failures.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |
Use this when you need to retrieve recent trade executions (fills) for a Hyperliquid perpetuals account. Returns the most recent trades with full execution details including realized PnL on closed positions. Returns: 1. coin: the perpetual market (BTC, ETH, SOL, etc.) 2. side: buy or sell (A = sell/ask, B = buy/bid) 3. size: position size filled 4. price: execution price 5. fee: trading fee paid in USD 6. closedPnl: realized PnL if the trade closed a position (0 if opening) 7. timestamp: execution time in milliseconds 8. hash: transaction hash for the fill 9. crossed: whether the order crossed the spread (taker) Example output: { fills: [{ coin: "ETH", side: "buy", size: "10.0", price: "3450.50", fee: "0.69", closedPnl: "0.00", timestamp: 1712000000000 }], count: 20 } Use this to analyze a trader's recent activity, calculate realized PnL, evaluate trading frequency, or audit trade execution quality on Hyperliquid. Do NOT use for current positions -- use hyperliquid_get_account_state instead. Do NOT use for open/pending orders -- use hyperliquid_get_open_orders instead. Do NOT use for funding payments -- use hyperliquid_get_user_funding instead. Do NOT use for market-wide whale trades -- use hyperliquid_detect_whale_trades instead.
Use this when you need to retrieve funding payments received/paid by a Hyperliquid wallet: coin, amount, rate, timestamp.
Parameter constraints (e.g., limit max 100) stated in descriptions but not enforced via JSON Schema minima/maxima. LLMs cannot parse prose constraints reliably.
hyperliquid_get_user_funding description is minimal (47 chars). Lacks WHEN to use, what fields are returned, and how it differs from other funding-related tools.