Loading ToolBench
MCP server for trading on Bybit perpetual futures with agent registration and API key management
Critical gaps across all dimensions. While tool names follow verb_noun convention reasonably well, descriptions are inconsistent (some missing entirely), input schemas are minimal or absent, and output schemas are completely undocumented. The server exposes sensitive information (API keys) as tool parameters, violating security patterns. Error handling and parameter validation are absent. No evidence of pagination, result limiting, or response shaping for API data. The example code suggests this is a wrapper around Bybit's API, but the tool definitions lack the rigor needed for reliable LLM interaction.
Get the current account balance and available margin
Get perpetual contract specifications for a given symbol
Get the order book (bid/ask levels) for a trading pair
Get all open positions in the account
Get available Bybit perpetual trading pairs and their current prices
Register a new trading agent and receive an API key
Output schemas completely undocumented. LLMs cannot predict what fields to expect from get_tickers, get_balance, get_positions, or get_order_book. This forces agents to make assumptions, mis-chain tools, and waste tokens on field discovery.
register_agent exposes API keys as tool output without any guidance on secure storage or usage. API credentials should never be returned in plain text to LLM context. The example code shows credentials being logged and parsed from text output, creating audit and security risks.
No error handling guidance. Tools have no documented error cases, recovery paths, or actionable error messages. If get_instruments fails for an invalid symbol, the LLM cannot determine whether to retry, search for the symbol, or ask the user.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Parameter descriptions are generic or missing. 'The trading pair symbol (e.g., BTCUSDT)' provides an example but no validation rule. Is BTCUSDT the only format? Are lowercase versions accepted? What happens if an invalid symbol is passed? Agents cannot validate input without explicit constraints.
No pagination or result limiting documented. get_tickers and get_positions likely return variable-length arrays, but no limit parameter, offset/cursor, or total_count field is mentioned. Large result sets could exhaust context windows without bounds.
Tool composition broken. register_agent returns a credential, but get_balance, get_positions, get_order_book, and get_instruments do not document how they use or require that credential. The examples show manual header injection, but the tools themselves do not explain the authentication flow or dependency on register_agent output.
No tool annotations. None of the tools declare whether they are read-only, destructive, or idempotent via tool hints. This forces LLMs to infer safety from descriptions alone, risking incorrect tool sequencing or retry logic.