Loading ToolBench
MCP server for Binance.US exchange - spot trading, wallet management, and US-specific features
Server has 18 tools with reasonable schema definitions and mostly complete descriptions. Naming follows verb_noun conventions (binance_us_*). However, several critical gaps emerge: (1) No visible output schema documentation for any tool, descriptions state what info is returned but no formal JSON Schema for responses; (2) Some parameter descriptions are generic or lack detail on constraints; (3) Risk annotations (READ_ONLY, WRITE, REVERSIBLE) are present in metadata but not exposed as tool annotations in the MCP schema; (4) Descriptions are adequate (avg ~150 chars) but could be more specific about error cases and prerequisites; (5) No evidence of error handling guidance or recovery paths in tool implementations. Tools are well-organized by domain (account, market, trade, wallet, custodial, credit-line) and input schemas use Zod properly with type definitions. Moderate-quality server suitable for read-heavy use cases but lacking production-grade error handling and output documentation.
Get current account information including balances and permissions. Returns all asset balances (free and locked), account permissions, and trading status.
Get comprehensive credit line account information. ⚠️ REQUIRES INSTITUTIONAL CREDIT LINE AGREEMENT. This API is only available to institutional users with approved credit facilities. Response includes clAccountId, masterAccountId, LTV ratios (currentLTV, initialLTV, marginCallLTV, liquidationLTV), interest rates, contract details, permissions, loan information, and balances.
Get margin call and liquidation alert history for credit line account. ⚠️ REQUIRES INSTITUTIONAL CREDIT LINE AGREEMENT. Returns alert records including alertTime, alertType (MARGIN_CALL or LIQUIDATION_CALL), currentLTV, thresholds, totalBalance, loanAssets, and balances.
Get transfer history for credit line account. ⚠️ REQUIRES INSTITUTIONAL CREDIT LINE AGREEMENT. Returns transfer records including transferId, transferType (TRANSFER_IN or TRANSFER_OUT), asset, amount, status (SUCCESS, PENDING, FAILED), and transferTime.
No output schema documentation for any tool. Tool descriptions state what is returned (e.g., 'Returns all asset balances, account permissions, and trading status') but do not provide a formal JSON Schema describing the response structure, field types, or nesting. LLMs cannot reliably predict output structure for downstream tool chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get balance information for Binance.US exchange wallet and custodial sub-account. ⚠️ REQUIRES CUSTODIAL SOLUTION API KEY - Standard API keys will not work. This endpoint is for institutional custody partners (e.g., Anchorage, BitGo). Response includes exchangeWalletBalance and custodialAcctBalance with asset, free, locked, inSettlement, and lastUpdatedTime.
Get list of assets supported for custodial solution transfers and settlements. ⚠️ REQUIRES CUSTODIAL SOLUTION API KEY. Response includes transferEligible and settlementEligible assets with asset symbol, precision, and network.
Transfer assets from custodial partner account to Binance.US custodial sub-account. ⚠️ REQUIRES CUSTODIAL SOLUTION API KEY. Use this to move assets from your custodial partner (e.g., Anchorage) to your Binance.US custodial sub-account for trading. Response includes asset, amount, transferId, custodyAccountId, custodyAccountName, status, and createTime.
Undo a previous transfer from your custodial partner. ⚠️ REQUIRES CUSTODIAL SOLUTION API KEY. Use this to reverse a custodian transfer that hasn't been fully processed. Response includes transferId, asset, and amount.
Transfer assets from Binance.US exchange wallet to custodial sub-account. ⚠️ REQUIRES CUSTODIAL SOLUTION API KEY. Use this to move assets from your Binance.US exchange wallet to your custodial sub-account for trading. Response includes asset, amount, clientOrderId, transferId, status, and createTime.
Get balance information for Binance.US exchange wallet and custodial sub-account. ⚠️ REQUIRES CUSTODIAL SOLUTION API KEY - Regular API keys will not work. Returns exchangeWalletBalance and custodialAcctBalance arrays with asset, free, locked, inSettlement, and lastUpdatedTime.
Request asset transfer from a custodial partner account to Binance.US custodial sub-account. ⚠️ REQUIRES CUSTODIAL SOLUTION API KEY. ⚠️ This initiates a transfer request to your custody partner! This requests your custodial partner to transfer assets to your Binance.US account. The actual transfer is executed by the custody partner.
Get list of assets supported for custodial transfers and settlements. ⚠️ REQUIRES CUSTODIAL SOLUTION API KEY. Returns transferEligible and settlementEligible lists with asset symbol, precision, and network.
Undo a previous transfer from your custodial partner. ⚠️ REQUIRES CUSTODIAL SOLUTION API KEY. ⚠️ Only certain transfers can be undone - check with your custodial partner. This reverses a previous custodian transfer by its transfer ID.
Transfer assets from your Binance.US exchange wallet to your custodial sub-account. ⚠️ REQUIRES CUSTODIAL SOLUTION API KEY. ⚠️ This moves funds - verify details carefully! This transfers from your main Binance.US account to your custodial sub-account, which can then be traded or settled to your custodial partner.
Get trade history for a specific trading pair. Returns executed trades including price, quantity, commission, and timestamps.
Get current trade order count rate limits for all time intervals. Shows how many orders you can place within each interval.
Get your current maker & taker fee rates for spot trading based on your VIP level. BNB fee discount (25% off) is not factored in.
Get total trade volume for the past 30 days. Volume is calculated on a rolling basis every day at 0:00 AM (UTC).
Risk metadata (READ_ONLY, WRITE, REVERSIBLE) declared in server documentation but not exposed via MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot determine from the tool schema alone which operations are safe to retry or which have destructive side effects.
Error handling in tool implementations (src/tools/account/index.ts example) is minimal. Caught errors return a generic message ('Failed to get account info: <error>') with no guidance on root cause, retryability, or next steps. LLMs cannot distinguish transient API failures from invalid parameters.
Duplicate or near-duplicate tool sets: binance_us_cust_* and binance_us_custodial_* provide overlapping functionality (balance, supported_assets, wallet_transfer, custodian_transfer, undo_transfer). Descriptions note slightly different API key requirements, but names do not disambiguate the distinction. LLMs will waste reasoning cycles deciding between similar-named tools.
Parameter constraints documented in descriptions but not enforced via schema. E.g., recvWindow 'cannot be greater than 60000', limit defaults and max values. Lack of min/max in Zod schema means validation happens at runtime in external API; LLMs may pass invalid values and wait for API rejection.
Some parameter descriptions are generic. E.g., 'Your reference ID (auto-generated if not provided)' for clientOrderId does not explain when to provide it, how it is used, or format constraints. Descriptions should follow pattern: what it does, when to use it, allowed format, example.
Descriptions for custodial and credit-line tools include heavy warnings ('⚠️ REQUIRES INSTITUTIONAL CREDIT LINE AGREEMENT') but do not clearly state what error the LLM will see if the user lacks credentials. Descriptions should guide recovery: 'If you see API error 403, the API key does not have this permission. Request the appropriate credential from your account administrator.'