Loading ToolBench
MCP server for Zebpay cryptocurrency trading exchange. Provides tools for spot trading, futures trading, market data, order management, and account operations on the Zebpay platform.
The server registers 7 tools with explicit schemas and descriptions. However, quality is inconsistent across tools. The public futures tools (1-6) have minimal parameter sets and acceptable descriptions, but lack nuance around expected output formats and chaining requirements. The critical DESTRUCTIVE tool (zebpay_spot_placeMarketOrder) has an extremely lengthy description (2000+ chars) that buries key constraints and includes example values that LLMs tend to reuse literally rather than adapt. Input schemas are present for most tools, but several lack proper type constraints (e.g., 'symbol' and 'limit' in getOrderBook are free-form strings without enum or pattern validation). Error handling is present via try-catch blocks but provides no guidance to agents on recovery strategies. Output schemas are not documented in the tool definitions themselves, agents must infer structure from responses.
Get aggregate trades (compressed recent trades) for a futures symbol (no auth). When to use: - To inspect recent trading activity and momentum - For lightweight trade history without full raw trades
Get futures market info (fees, limits, min qty/price, filters) (no auth). When to use: - Before placing orders to understand precision, minimum quantity, and price tick size - To validate user inputs against exchange rules
Get list of all futures markets and tradable symbols (no auth). When to use: - To discover available futures symbols and market metadata - Prior to validating a user-provided symbol Notes: - Symbols are typically uppercase without hyphens, e.g., "BTCUSDT".
Get futures order book (market depth) for a symbol (no auth). When to use: - To analyze bid/ask depth, spread, and liquidity for a symbol - Before placing a limit order to choose price levels Example: { "symbol": "BTCUSDT", "limit": 50 }
Get 24h ticker statistics for a futures symbol (no auth). Includes: - Last price, 24h high/low, volume, price change absolute and percentage. Example: { "symbol": "BTCUSDT" }
zebpay_spot_placeMarketOrder description is 2000+ characters with embedded example values ('100 INR', '0.0001 BTC', '8900000'). LLMs reuse example values literally rather than adapt them to context, causing incorrect orders. Description violates the 10 - 1024 character guideline and pattern:tool-description principle of token efficiency.
Parameters 'symbol' and 'limit' in getOrderBook, getTicker24Hr, getAggregateTrades are typed as free-form strings with no enum, regex pattern, or numeric range validation. Descriptions mention format ('e.g. BTCUSDT') but do not declare constraints. LLMs will hallucinate invalid symbols (mixed case, hyphens, unknown coins). Should use regex pattern or enum for known symbols, or at minimum enforce uppercase alphanumeric.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get current health status of the Zebpay Futures public API (no auth). When to use: - Before making other futures requests to confirm API availability - To troubleshoot connectivity or rate limit issues Response: - Returns a status payload indicating whether services are operational.
Place a market order on Zebpay spot trading exchange with automatic currency conversion. This tool executes an immediate buy or sell order at the current market price. Market orders are filled instantly at the best available price, unlike limit orders which wait for a specific price. **When to use this tool:** - User wants to buy or sell cryptocurrency immediately - User needs to execute a trade quickly without waiting for a specific price - User wants to convert one cryptocurrency to another or to fiat currency **Important notes:** - Market orders execute immediately at current market price - Supports BOTH quote currency (INR) and base currency (BTC) specifications - Automatic conversion using current market price when needed - All quantities are trimmed to 6 decimal places - Symbol format is typically BASE-QUOTE (e.g., BTC-INR means buying/selling Bitcoin with Indian Rupees) **How conversion works:** For BUY orders: - User specifies quoteOrderAmount (100 INR) → Used directly as quoteOrderAmount - User specifies amount (0.0001 BTC) → Converted: 0.0001 × market_price = INR value → Used as quoteOrderAmount For SELL orders: - User specifies amount (0.0005 BTC) → Used directly as amount - User specifies quoteOrderAmount (200 INR) → Converted: 200 ÷ market_price = BTC quantity → Used as amount **Example use cases:** 1. User says "Buy 100 INR worth of BTC" → Use symbol="BTC-INR", side="BUY", quoteOrderAmount="100" 2. User says "Sell 0.0005 BTC" → Use symbol="BTC-INR", side="SELL", amount="0.0005" 3. User says "Buy 0.0001 BTC" → Use symbol="BTC-INR", side="BUY", amount="0.0001" (auto-converts to INR) 4. User says "Sell 200 INR worth of BTC" → Use symbol="BTC-INR", side="SELL", quoteOrderAmount="200" (auto-converts to BTC) **Example request (BUY with quote currency):** { "symbol": "BTC-INR", "side": "BUY", "quoteOrderAmount": "100" } → Body sent to API: { symbol: "BTC-INR", side: "BUY", type: "MARKET", quoteOrderAmount: "100" } **Example request (BUY with base currency - auto-converted):** { "symbol": "BTC-INR", "side": "BUY", "amount": "0.0001" } → At market price 8900000: 0.0001 × 8900000 = 890 INR → Body sent to API: { symbol: "BTC-INR", side: "BUY", type: "MARKET", quoteOrderAmount: "890" } **Example request (SELL with base currency):** { "symbol": "BTC-INR", "side": "SELL", "amount": "0.0005" } → Body sent to API: { symbol: "BTC-INR", side: "SELL", type: "MARKET", amount: "0.0005" } **Example request (SELL with quote currency - auto-converted):** { "symbol": "BTC-INR", "side": "SELL", "quoteOrderAmount": "200" } → At market price 8900000: 200 ÷ 8900000 = 0.000022 BTC → Body sent to API: { symbol: "BTC-INR", side: "SELL", type: "MARKET", amount: "0.000022" } **Example response:** The tool returns order details including order ID, status, executed price, and quantity filled. **Rate Limits:** - Maximum 10 requests per second for authenticated endpoints - Burst limit: 20 requests - Rate limit headers (X-RateLimit-*) are included in responses - If rate limited, wait 1 second before retrying **Related Tools:** - Use zebpay_spot_getBalance before placing orders to check available funds - Use zebpay_public_getTicker to check current market price before trading - Use zebpay_public_getOrderBook to analyze market depth and liquidity
No output schemas documented in tool definitions. Agents cannot plan downstream calls or extract chaining IDs (e.g., 'Can the result of getOrderBook be passed to placeMarketOrder?'). Without documented return types, agents waste tokens inferring structure.
Error responses lack recovery guidance. Try-catch blocks in code (e.g., withLogging) catch errors and record metrics, but error messages returned to agent are not visible in source. No evidence of pattern:recovery-guide or pattern:error-classification, agents do not know if an error is retryable, user-fixable, or fatal.
Destructive tool zebpay_spot_placeMarketOrder accepts mutually exclusive parameters (amount vs quoteOrderAmount) but does not validate that only one is provided. Description warns 'use this OR amount, not both' but no code validation visible. LLMs may pass both, causing ambiguous behavior.
No dry-run, confirmation, or approval mechanism for destructive operation (placeMarketOrder). Agents can execute irreversible financial trades without explicit confirmation. pattern:confirmation-request not implemented.
Tool naming ambiguity: 'zebpay_spot_placeMarketOrder' does not distinguish between BUY and SELL in the name itself. Related tools like getBalance, getTicker are referenced in description but not present in the server. Agent must discover via trial-and-error which tools exist.
Parameters clientOrderId and platform in placeMarketOrder are optional but lack constraints. clientOrderId description states 'must be 1-36 characters' and 'contain only [a-zA-Z0-9._:/\-]' but no regex pattern in schema enforces this. LLMs will pass invalid IDs.