Loading ToolBench
A Model Context Protocol server for Bybit V5 API
The server has 21 tools with complete schema definitions and mostly good descriptions. Tool naming follows verb-noun conventions (get_, set_, internal_transfer, confirm_order). Descriptions are present and reasonably detailed (average ~120 chars, within baseline 34-392 range). However, there are critical gaps: (1) HIGH-RISK tools like place_order, amend_order, cancel_all_orders are referenced in confirm_order's description but not actually visible in the tool definitions provided, this suggests incomplete tool registration or missing tools. (2) Output schemas are not documented in the tool definitions, only input schemas are specified. (3) Error handling guidance is minimal, most tools lack recovery hints for failure cases. (4) Some parameter descriptions are generic (e.g., 'Symbol name (e.g. BTCUSDT)') without explaining what happens if the symbol is invalid or not found. (5) The confirmation pattern is innovative but adds complexity, high-risk tools return only a summary, forcing a second call to confirm_order to execute, which is not intuitive for LLMs.
Execute a previously prepared HIGH-risk operation after review. When a HIGH-risk tool (place_order, amend_order, cancel_all_orders, set_leverage, internal_transfer) is called, it returns a confirmation summary instead of executing. Call this tool with the confirmation_id to actually execute the operation.
Get account margin mode and configuration info.
Query closed profit and loss records.
Query coin balance of a specific account type.
Query coin information including chain info, deposit/withdraw status.
Get trading fee rate.
Missing tool definitions: confirm_order references HIGH-risk tools (place_order, amend_order, cancel_all_orders, set_leverage, internal_transfer) but place_order, amend_order, and cancel_all_orders are not visible in the provided source. This suggests incomplete tool registration or a missing trade.py module listing.
Output schemas not documented: all 21 tools lack documented output/return schemas. LLMs cannot plan downstream tool chains without knowing what fields to expect. For example, get_positions should document it returns fields like position_id, symbol, size, entry_price, pnl, etc., enabling the agent to extract the right data for subsequent calls.
Minimal error handling and recovery guidance: tool descriptions (e.g., get_tickers, get_kline) lack guidance on what happens on failure. No descriptions tell LLM what to do if a symbol is invalid, API rate limit hits, or data is unavailable. Expected pattern: 'If symbol not found, call list_tradable_symbols() first to discover valid symbols.'
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Query historical funding rate.
Query instrument specifications and trading rules.
Query kline/candlestick data.
Get open interest for each symbol.
Query order book depth data.
Query real-time position data.
Query recent public trading data.
Get the current Bybit server time.
Get latest price ticker for a symbol.
Query internal transfer records.
Get wallet balance and account risk information.
Transfer funds between account types under same UID (HIGH risk, requires 'full' mode).
Turn on/off auto-add-margin for isolated margin position (MEDIUM risk).
Set leverage for a position (HIGH risk - requires confirmation).
Set take profit, stop loss, or trailing stop for a position (MEDIUM risk).
Confirmation pattern adds cognitive overhead: HIGH-risk tools (place_order, set_leverage, internal_transfer) return only a confirmation_id summary without executing. This two-step confirm→execute pattern is non-standard and forces LLMs to manage state and remember to call confirm_order. Standard pattern: return a dry-run summary with an optional 'require_confirmation=true' flag, or gate with permission checks. The current design is fragile, if LLM never calls confirm_order, the operation never executes.
Ambiguous enum values in descriptions: parameters like 'category' accept 'spot, linear, inverse, option' and 'accountType' accepts 'UNIFIED, CONTRACT, SPOT, OPTION, FUND', but these are stated as text in descriptions rather than enforced as JSON Schema enums. If schema defines them as free-form strings, LLMs may hallucinate invalid values like 'spot_usd' or 'fund-spot'.
Parameter descriptions lack context on mutual exclusivity and dependencies: e.g., get_open_interest has startTime and endTime, but no hint whether both are required, whether omitting them returns all-time data, or what the default range is. Similarly, get_transfer_history's filter parameters (transferId, coin, status) lack guidance on which combinations are valid or recommended.
Generic descriptions underutilize LLM decision-making: many tool descriptions (e.g., 'Query order book depth data' for get_orderbook) are brief and generic. They should explain WHEN to use this tool vs alternatives (e.g., 'Use get_orderbook to check liquidity before placing large orders; use get_tickers for quick last-price snapshots'). This helps LLMs select the right tool.
No pagination guidance in descriptions: tools returning lists (get_positions, get_closed_pnl, get_transfer_history, get_open_interest, get_public_trades) accept limit and cursor/page parameters but descriptions do not explain the pagination contract. Should state: 'Returns up to [limit] items. Use cursor/next_page to fetch additional results. Total count available as total_items field.'
Tool annotations missing on dangerous tools: confirm_order is annotated with destructiveHint=true, but place_order, amend_order, and cancel_all_orders (if they exist) should also be annotated as destructive, and set_leverage should have destructiveHint=true. This helps clients highlight risky tools in UI.