Related Servers

The surface is segmented by resource (invoices, payments, payouts, conversions, static addresses, webhooks) and the preview_/create_ step pairs are explicitly labelled, so most tools are separable. The main friction is between invoices, payments and static-address deposits — three ways money arrives — though descriptions steer agents (e.g. 'most agents should use create_invoice instead' of preview_payment, and create_conversion is only for non-USDT holdings). get_payment being the read side for invoice, static address and standalone payments adds mild conceptual overlap but is coherently explained.

Every tool is snake_case with a verb-first prefix (get_, list_, create_, preview_, select_, update_, rotate_), and the prefix reliably signals read vs. write vs. quote. Sub-resources use consistent compound nouns (static_address, invoice_payment_method, webhook_secret) without abbreviations or style drift.

32 tools is heavy for a single MCP connection, but the server genuinely spans seven sub-domains (account, assets/rates, balances/ledger, invoices, payments, static addresses, payouts, conversions, webhooks), each with justified list/get/create operations. The preview→create pairing inflates the count, yet each pair earns its place as a safety step. Still, the bulk will make discovery and selection harder than a tighter 15–20 tool surface would.

Coverage is strong: account lifecycle, asset discovery, fees, balances, ledger, full invoice/payment/payout/conversion lifecycles, static addresses with deposit listing, and webhook management including secret rotation. Gaps are minor but real — no cancel/void invoice, no delete_webhook (only disable via update), and no explicit refund path. Agents can work around these, but cancellation of an open invoice appears absent.