Loading ToolBench
MCP server for CoinDCX cryptocurrency exchange API integration, providing public market data and private trading functionality
This server has 11 tools with basic functionality but significant quality gaps. All tools have terse descriptions (8-37 chars, far below the 194-char baseline), lacking LLM-friendly context about WHEN to use each tool. Input schemas are present but minimal, most parameters lack descriptions (required by pattern:tool-description). Parameter types are inferred from Python annotations but not explicitly declared in JSON Schema. No output schemas are documented, forcing LLMs to guess what fields to expect. Error handling is absent, no recovery guidance, no categorization of failures as retryable or fatal. Security concerns: the server accepts credentials via environment variables (good) but provides no permission gates on destructive operations (cancel_all_orders, place_limit_order). Tool composition is reasonable (one action per tool), but the naming could be clearer, get_markets, get_ticker, get_all_tickers have overlapping responsibility (discovery).
Cancel all open orders
Cancel order by ID
Fetch active orders
Get tickers for all markets
Fetch wallet balances
Get OHLCV candles
List all CoinDCX trading pairs
All tool descriptions are under 40 characters; most are 8 - 37 chars. Baseline is 194 chars. Descriptions lack WHEN to use, prerequisites, and dependencies. Per pattern:tool-description, LLMs cannot determine when to select a tool without a complete docstring.
Parameter descriptions are entirely missing from the schema. Example: get_ticker accepts 'symbol' but the schema does not document what format is expected (BTCINR vs I-BTC_INR?). Required by pattern:tool-description, every parameter needs a description explaining what it controls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Get order book for a symbol
Fetch order history
Get ticker for a symbol
Place a limit buy/sell order
No output schemas are documented. LLMs cannot plan downstream calls or extract data without knowing what fields are returned. E.g., place_limit_order succeeds, does it return order_id? Is that order_id what cancel_order expects? Responses are opaque.
No error handling or recovery guidance. If place_limit_order fails (invalid symbol, insufficient balance, order exceeds limit), the LLM gets no hint about retrying, asking the user, or calling a different tool. Pattern:recovery-guide requires error responses to guide next steps.
Destructive operations (cancel_all_orders, place_limit_order) have no dry-run, confirmation, or permission gate. An agent can wipe all open orders or place a large buy without verification. Pattern:confirmation-request and pattern:permission-gate require a safety mechanism.
Overlapping tool names signal multiple responsibilities: get_markets, get_ticker, get_all_tickers all fetch price discovery data. Per pattern:tool, each tool should do exactly one thing. Consider: list_available_markets() vs get_market_price(symbol). Current names are ambiguous, LLM may struggle to pick the right one.
Parameter 'symbol' is documented inconsistently. get_ticker expects 'BTCINR' but get_order_book expects 'I-BTC_INR'. No enum constraint. Per review:param-validation-rules, describe format, range, and allowed values in parameter descriptions. LLMs will guess wrong format and fail.
place_limit_order parameter 'side' is documented as a free-form string ('buy or sell') with no enum constraint. LLMs may pass 'BUY', 'Buy', 'purchase' and fail. Per pattern:constrained-input, declare enums for known value sets.
No input validation in tool descriptions. place_limit_order has no documented constraints on price, quantity, or order_value. Code has a MAX_ORDER_VALUE guard, but LLMs don't see it. Per review:param-validation-rules, state ranges and limits in parameter descriptions.
No pagination support on tools that could return large result sets (get_markets, get_all_tickers, get_order_history). Per pattern:paginated-result, tools returning lists must accept limit/offset and return a total count. Without pagination, responses can blow the context window.
Tool composition chain broken for common workflows. place_limit_order accepts 'symbol' but doesn't document what get_markets or get_ticker returns, LLM can't chain discovery → order creation. Per pattern:tool-chain, tool outputs must contain the IDs/refs downstream tools need.