Fee Optimizer MCP
This server helps AI agents answer crypto exchange fee questions, compare costs, get referral links, and analyze trading scenarios.
Compare trading fees:
compare_exchange_feesranks exchanges by weighted effective fee rate for spot/futures, with VIP tier resolution, token discounts, and pair-level promos.Get referral links:
get_referral_linkreturns discount registration URLs for Binance, OKX, and Gate.io.Calculate savings:
calculate_savingsshows fee reductions from referrals/tokens and includes funding and execution costs.Compare total cost:
compare_total_costranks exchanges by trading fees + funding + withdrawals + spread/slippage + optional fiat deposit/cash-out fees.Recommend an exchange:
recommend_exchangescores venues based on the user's profile, including fiat habits.Annual cost analysis:
calculate_annual_costannualizes fees, funding, withdrawals, and fiat legs, plus VIP upgrade savings.Funding rates:
get_funding_ratesreturns per-exchange perp funding rates (bundled averages or live).Execution cost:
get_execution_costmeasures bid-ask spread and depth-based slippage for market orders (bundled or live book walks).Fiat on/off-ramp costs:
get_fiat_costcompares card/ACH/SEPA/FPS/wire/SWIFT/PIX deposits and withdrawals across venues.Withdrawal fees:
get_withdrawal_feescompares on-chain fees for 16 assets across multiple networks, flagging suspended routes.Persona analysis:
analyze_personaandcompare_personasrun seven trader archetypes through the full annual cost stack and recommend the best venue.Token discount payback:
analyze_token_discountcalculates whether holding exchange tokens for fee discounts is worth it.Volume what-if:
volume_what_ifshows how fees change with volume and when you hit the next VIP tier.Country comparison:
compare_countriesprices one persona across up to 12 countries, showing compliance blocks and cost differences.Actual account fees:
get_account_fee_tieruses a read-only API key to fetch real maker/taker rates and compare to public tiers.Stablecoin access:
get_stablecoin_accessreports MiCA regional access (e.g., USDT in the EEA) and compliant alternatives.Interface cost comparison:
compare_interface_costscompares consumer apps (e.g., Coinbase Simple) vs PRO interfaces, with measured hidden spread.Fee change history:
get_fee_changesprovides an auditable feed of fee-schedule changes with source URLs.Data provenance:
get_data_sourcesreports data freshness, source URLs, and staleness warnings.
Models Binance as a venue in the fee comparison — its 30-day-volume VIP fee ladders for spot and futures (including the BNB holding gate that can block a tier rung), funding costs, and on-chain withdrawal fees, so agents can price a user's all-in Binance cost and find the volume at which the next tier unlocks.
Includes Coinbase in cross-venue cost comparisons as a spot-only venue, pricing its spot fee tiers, fiat rails and withdrawal fees, and correctly flagging it as product-unsupported when the trader persona requires futures.
Provides KuCoin's futures fee tiers in the venue comparison and supports authenticated fee-tier retrieval from KuCoin Futures (read-only API key plus passphrase) to return the account's real maker/taker rates and the gap versus the bundled public VIP tier; also models its EEA venue block under MiCA.
Prices OKX spot and X-Perps fee tiers, supports authenticated account fee-tier lookups with a read-only API key, and supplies OKX funding and withdrawal cost data — including its status as one of the few EEA-eligible futures venues.
Models PIX as a fiat on/off-ramp rail for Brazilian residents, incorporating deposit/withdrawal costs into the cross-venue, cross-country total-cost and country-comparison analyses.
Models SEPA and SEPA Instant as fiat on/off-ramp rails, letting agents compare deposit/withdrawal costs per venue (e.g. free SEPA deposits, low-cost SEPA withdrawals, daily cash-out caps) across EU venues, currencies and countries of residence.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Fee Optimizer MCPwhich crypto exchange has the lowest fees for a limit-order trader?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Fee Optimizer MCP
An MCP (Model Context Protocol) server that helps AI agents answer questions about crypto exchange trading fees, fetch referral links for fee discounts, calculate savings, compare total cost (fees + funding + spread/slippage + withdrawal), annualize the all-in yearly cost with VIP upgrade savings, inspect funding rates (bundled averages or real-time live rates), measure order-book execution cost (bid-ask spread crossing + size-conditional depth slippage, bundled baselines or live book walks), compare direct fiat on/off-ramp costs (card / ACH / SEPA / FPS / wire / SWIFT / PIX deposits and withdrawals across venues, currencies and countries of residence), compare on-chain withdrawal fees per asset and network across venues (16 assets × TRC-20/ERC-20/L2/native routes with suspended-wallet flags and snapshot-price USD conversion), and run a research-anchored trader-persona analysis that annualizes the full cost stack (fees + funding + spread + withdrawals + fiat on/off-ramping) for seven trader archetypes and recommends the best exchange for a user's profile.
When a user asks "which crypto exchange has the lowest fees for a limit-order trader?", "give me a Gate.io discount registration link", "how much can I save on 100k USDT futures held for 16 hours?", or "where does this fee data come from?", the agent can call this server's tools to return concrete, sourced answers — including a referral link the user can register with to receive a fee discount.
Features
Twenty read-only tools. Runs over stdio or stateless Streamable HTTP (v0.29: per-request isolated servers, JSON responses, /health probe — ready for remote/container hosting; v0.32 adds public-hosting hardening: opt-in bearer-token auth, per-IP rate limiting, structured JSON access logs and a production Dockerfile). All fee-bearing tools require a country code for compliance filtering. Every result carries a data_as_of stamp, and get_data_sources reports per-file months_behind/is_stale plus stale_files (v0.33), enforced by an offline npm run audit:data consistency gate. v0.48 adds get_fee_changes (20th tool) — the auditable fee-schedule change feed (data moat): a curated, official-announcement-verified history of VIP rate moves, qualification-threshold changes, rung inserts/removes, promos, token-discount and pricing-model changes (each with effective date, source URL and bilingual summary), plus monthly deterministic fee-ladder snapshots in snapshots/fee_ladders/ that are diffed automatically — snapshot-derived rows carry confidence: "detected" and are NEVER presented as confirmed (a delta can be a data correction); a monthly GitHub Actions workflow captures the new snapshot and opens a review-only PR, and a human verifies against the official fee page before curating into data/fee_changes.json. The curated feed ships in the npm package; snapshots are repo-only, and npm consumers degrade gracefully (snapshot_coverage.available: false). v0.34 adds volume_what_if — a volume what-if/sensitivity sweep: cross-venue cheapest ranking and per-venue fee/cost curves across monthly-volume levels (default points = the union of every venue's VIP thresholds), the exact tier-crossing list, and with baseVolume each venue's next rung, extra volume required and USD/year saved at today's volume (holding-gated rungs like Binance spot's BNB requirement flagged blocked_by_holding_gate). v0.35 adds compare_countries — one trader persona priced through the full annual all-in stack across up to 12 countries in a single call: per-country winner and realistic all-legs pick, the extra annual cost vs the cheapest country on a comparable basis (a rail-less headline winner cannot fake a country), a venue×country availability matrix that distinguishes compliance-blocked from product-unsupported (spot-only Coinbase for a futures trader), venue win counts and the cheapest/costliest gap. v0.36 adds ready-to-paste matrix tables — compare_personas, volume_what_if and compare_countries accept format: "markdown" | "csv" | "both" and return a rendered object alongside the unchanged JSON (tableMetric selects the slice: weighted fee / annual fee / tier for the sweep, availability symbols / cost for countries); markdown tables escape pipes and CSV follows RFC 4180 (quoted commas/quotes/newlines, CRLF) for direct paste into docs or spreadsheets; default calls stay byte-identical. v0.37 adds BloFin as the 13th venue — a derivatives-led Cayman/Marshall-Islands exchange (~$1.2B/24h perp volume, no KYC up to 20k USDT/day withdrawals): 6-tier spot/futures ladders (futures 0.020%/0.060% base → 0%/0.035%, spot 0.10%/0.10% → 0.01%/0.0325%), three-track OR qualification (30d futures volume / 30d spot volume / account assets — just $50k assets reaches futures VIP1), 8h funding, ~3 bps typical perp spread, TRC-20 withdrawals at ~1 USDT/USDC, no native token, no referral link, no direct fiat rails, and blocked in US/CA/CN/SG plus the EEA under MiCA (Germany explicitly modeled). v0.38 adds Bitstamp as the 14th venue — the most regulated venue in the model (founded 2011, Luxembourg, Robinhood-owned; EU MiCA CASP passport, NYDFS BitLicense, UK FCA, SG MAS): an 11-tier volume-only spot ladder (0.30%/0.40% entry → 0.00%/0.03% above $1B 30d turnover) plus regulated USD-margined perps at a flat −0.005% maker rebate / 0.015% taker with 8h peer-to-peer funding — the perps are EU/EEA-eligible-residents only, modeled with a venue×country product gate (v0.40: a positive EEA region allowlist — all 30 EEA states route both products, every other residency including AU/BR/CH gets futures PRODUCT_BLOCKED_IN_COUNTRY while spot stays open; CN is venue-blocked), deep direct fiat rails (free ACH both ways, free SEPA in / €3 out, 0.05%/0.1% SWIFT with floors/cap, ~4% card) and conservative ERC-20-heavy withdrawals (USDT ~20 ERC-20 only — the most expensive USDT route modeled). Funding math defaults to bundled long-run averages and can switch to real-time live rates via fundingMode: "live". Execution cost (spread + slippage) defaults to bundled typical-spread baselines and can switch to real-time order-book walks via spreadMode: "live". v0.39 adds get_account_fee_tier — the leap from the public fee schedule to the caller's actual account rate: pass a read-only API key (Hyperliquid needs only the public 0x wallet address; OKX/KuCoin-Futures take an API passphrase) and the tool calls the venue's authenticated fee endpoint via ccxt, returns the real maker/taker in percent and the signed gap in bps vs the bundled public VIP tier at the given monthly volume (captures server-side BNB deductions, the venue's own rolling-30d VIP window, negotiated/promo rates; 13/18 venues supported — Phemex/BloFin, Finst, Bitpanda and BISON (no public trading API / ccxt connector), plus the spot-only venues' perps (Bitstamp, Bitvavo), return a typed unsupported error). Credentials are per-request only, never cached, never written to logs (audit lines redact apiKey/secret/password; error strings scrub credential literals), and country/product compliance gates run before any authenticated call. v0.40 adds positive region allowlists (regions + product_region_gates in country_restrictions.json) replacing the v0.38 negative-list default key: Bitstamp perps now require membership of the declared EEA region (all 30 states — EU27 + Iceland/Liechtenstein/Norway), so unmodeled non-EEA residencies such as AU/BR/CH/TR/KR are correctly PRODUCT_BLOCKED_IN_COUNTRY instead of being silently over-opened, while every EEA member (FR/NL/ES/IT/…) routes both products; the gate is data-driven and reusable for future region-restricted venues. v0.41 enforces the post-cliff MiCA regime (Article 143(3) transition ended 2026-07-01, no extension) with negative region gates (region_blocked + product_region_blocked): for EEA residents, Binance, MEXC, Bitget, KuCoin, BingX, Phemex and BloFin are venue-blocked for every product (no usable CASP authorization — withdrawn/pending applications or KuCoin's active FMA commencement-of-business ban), and Bybit/Gate perps are product-blocked pending separate MiFID II investment-firm authorization while their spot stays open; the EEA stack is therefore OKX/Gate/Bybit/Kraken/Coinbase/Bitstamp for spot and only OKX (X-Perps), Kraken and Bitstamp for perps, plus non-custodial Hyperliquid (no frontend geo-block — retained with an explicit gray-zone risk caveat). Negative gates narrow EEA results only; non-EEA markets (US/GB/AU/BR/JP/…) are byte-identical to before, including countries routed through the open default key. v0.42 adds Bitvavo as the 15th venue — the largest home-grown euro spot exchange (Amsterdam, founded 2018, ~4M+ users, roughly half of global EUR-denominated spot volume; AFM MiCA CASP registration #41000010 with EEA passporting) — and a new venue-level positive service-area gate (region_allowed in country_restrictions.json): Bitvavo serves only the 30 EEA states, so every other residency (US/GB/CH/JP/SG/AU/BR/CN/… including default-key countries) gets the venue filtered (COUNTRY_BLOCKED semantics), while a whitelist hit authorizes the venue even where a stale per-country allowed enum disagrees. Bitvavo is spot-only: a nine-rung single-track 30-day EUR-volume PRO ladder (0.15%/0.25% entry → 0.00%/0.02% above €25M; no token, no assets track; the Basic consumer UI's embedded spread is not modeled), the tightest EU EUR-book spread in the model at 1.0 bps full / 0.5 bps crossing (Kaiko 2026-05 measured 0.981 bps — best of any European venue), free SEPA/SEPA Instant both legs in EUR (iDEAL/Bancontact ride SEPA; €25k/day cash-out cap) plus a 1% EU card deposit with no card cash-out, and a dynamic BTC-only on-chain withdrawal modeled at 0.00005 BTC (no Lightning; USDT/USDC/ETH/alts surface as unsupported). The EEA spot stack grows to 8 venues; the futures stack is unchanged (Bitvavo lands in unsupported_product for a futures persona). The separate Bitvavo UK and Swiss entities are deliberately not modeled, so GB/CH stay outside the whitelist. v0.43 adds Finst as the 16th venue — the model's first brokerage rather than an order-book exchange (Amsterdam, founded 2022 by an ex-DEGIRO team; AFM MiCA CASP #41000015 granted 2025-07 with EEA passporting, 30 countries / 110k+ users): a smart-order router (SOR) that aggregates external liquidity and charges a flat 0.15% on every buy/sell/swap/auto-invest — no maker/taker split, no volume tiers, no minimum, no spread markup (modeled as a single volume-independent ladder rung plus a 1.0/0.5 bps cohort spread proxy). The same venue-level region_allowed: ["EEA"] gate applies, bringing the EEA spot stack to 9 venues; Finst vanishes from every non-EEA result. It is spot-only (a futures persona sees unsupported_product inside the EEA, blocked outside), offers free SEPA/SEPA Instant/iDEAL/Bancontact both legs in EUR only — no card rail (explicit card queries return available: false), no PayPal, no USD/GBP — and models crypto withdrawals as dynamic network fee at cost plus a flat €2.50 third-party charge: because the schema has no surcharge field, BTC is priced all-in at 0.000085 BTC (≈$6.57) with the two-part composition disclosed in the route note, while the other 400+ markets surface as unsupported. There is no referral program and no public trading API, so get_account_fee_tier is unsupported (live coverage stays 13 venues). v0.44 adds Bitpanda as the 17th venue and the model's first spread-priced brokerage (Vienna, founded 2014, 7.4M+ users; BaFin MiCA CASP authorization 2025-01-27 with EEA30 passporting + Austrian FMA license + UK FCA-registered Bitpanda Broker UK entity): the consumer app quotes an all-in price with the fee embedded as a markup and zero separate commission — a new pricing_model: "spread" (order_book | flat | spread) with no maker/taker split and no volume ladder — 1.49% per side headline for most assets, 0.99% per side for BTC and major stablecoin pairs via pair-level overrides, and 2.49% for sub-€100M small caps (the 1.99% crypto-index band and the consumer app's 10x margin are not modeled; futures unsupported). Because the embedded markup is the spread cost, Bitpanda's bundled typical-spread baseline is pinned to 0 bps so the premium and a spread line can never be double-charged, and a new execution_quality evidence block discloses the gap the broker hides: advertised 2.98% round trip vs TUM's real-money €100 round-trip measurement of 6.23% — 4.25 percentage points of hidden markup (Oct–Nov 2025, independently replicated by the Frankfurt School of Finance in 2026-03 with 432 round trips across 9 platforms) — the largest measured European retail cost gap in the research. Bitpanda serves only the 30 EEA states plus Great Britain via region_allowed: ["EEA","GB"] (GB added as a single-member region key — the same positive gate mechanism, no gate-code change), bringing the EEA spot stack to 10 venues; a futures persona sees unsupported_product inside the service area and blocked outside (US/CA/CN/CH/…); the separate Bitpanda Fusion pro exchange (0.02–0.25% aggregated-liquidity pricing) and stocks/metals/ETFs are deliberately not modeled and disclosed via notes. All consumer-app fiat rails have been free since 2026 — SEPA/SEPA Instant, Visa/Mastercard cards (deposit-only, no card cash-out leg), PayPal and Apple/Google Pay in EUR, plus FPS and cards in GBP; there is no USD route (USD queries retain the venue row with available:false). Crypto withdrawals pass the dynamic network fee through with no markup: **BTC 0.00000598 ($0.46)** and **ETH 0.0006 ($1.51)** at the dated snapshot. There is no referral link and ccxt ships no bitpanda class, so get_account_fee_tier returns ACCOUNT_FEES_UNSUPPORTED (live coverage stays 13 of 17 venues). v0.45 adds BISON as the 18th venue and the model's second spread-priced brokerage (Boerse Stuttgart Group, Stuttgart, launched 2019, 1M+ active users; EUWAX AG quotes as principal counterparty for roughly 10 seconds with no order book; Boerse Stuttgart Digital Custody — formerly blocknox — held the first BaFin MiCA crypto custody/transfer license from 2025-01-17, passported to 29 states, and EUWAX AG's crypto exchange service has been MiCA-authorized since 2025-04-01): the consumer app quotes one all-in price, again modeled with pricing_model: "spread" (no maker/taker, no volume ladder) — 1.25% per side for BTC and ETH via pair-level overrides, 1.75% per side for every other cryptocurrency (round trip ≈2.5% vs ≈3.5%), undercutting Bitpanda's 1.49% headline. The spread baseline is pinned to 0 bps (same anti-double-count guard), and the execution_quality evidence block tells the opposite story to Bitpanda's: advertised 2.5% round trip vs TUM's real-money €100 measurement of 2.58% — only ~0.08 percentage points undisclosed (Oct–Nov 2025, six MiCA-licensed platforms) — by far the closest published-vs-measured alignment of the tested field (Bitvavo next; Bitpanda 6.23%, Coinbase 7.49%), making BISON the European transparency benchmark. BISON serves the 30 EEA states plus Switzerland via region_allowed: ["EEA","CH"] — CH is a new single-member region key (DE/AT/CH actively marketed, other EEA residents served under passive freedoms) — and is blocked for Great Britain, the exact complementary gap to Bitpanda (EEA+GB, not CH), plus US/CA/JP/SG/AU/BR/CN/KR; the EEA spot stack becomes 11 venues, the CH stack 15, and BISON never appears in GB/US/JP results. It is spot-only (futures: [] → unsupported_product in-service, blocked outside; no futures or margin exist). Crypto withdrawals are officially free — no network-fee line, on-chain costs absorbed by EUWAX/the group (unlike Bitpanda's pass-through) — modeled at BTC 0 and ETH 0, which makes BISON the globally cheapest modeled withdrawal for both assets (min 0.001 BTC, no Lightning/Taproot bc1p; Ethereum mainnet only, min 0.01 ETH, no L2 payouts). Fiat is EUR only: SEPA/SEPA Instant free both legs including Swiss users funding in EUR, plus 2.49% deposit-only card/Apple Pay/Google Pay (Solaris SE/Deutsche Bank partner fee, no card cash-out; no GBP/USD/CHF rail — USD queries keep the unavailable row). The €1.99 German stocks/ETFs order fee and the 27% staking reward commission are not crypto-trading fees and are not modeled. The invite-a-friend program carries no affiliate URL (NO_REFERRAL_LINK) and ccxt 4.5.78 ships no bison/euwax class, so get_account_fee_tier returns ACCOUNT_FEES_UNSUPPORTED (live coverage stays 13 of 18 venues). v0.46 adds get_stablecoin_access (18th tool) — MiCA stablecoin regional-access intelligence: Tether never applied for MiCA EMT authorization, and after the CASP transitional cliff on 2026-07-01 (ESMA75-113276571-1679, confirmed non-extendable) USDT venue trading is unavailable across all 30 EEA states — the model carries the full delisting timeline per venue (Coinbase 2024-12, the Binance/Kraken/OKX/Gate/Bitstamp/Bitpanda/Bitvavo wave through 2025-03, Revolut's 2026 buy-stop/residual-conversion dates) plus venue_blocked status for the six EEA-blocked venues and never_offered for BISON/Finst/Hyperliquid; the report distinguishes the venue-side trading ban from personal rights — holding, custody and on-chain withdrawal to self-custody stay legal (Convert/custody mostly retained, DEXs outside the perimeter; Switzerland and Great Britain are deliberately not in the EEA region), names the six modeled MiCA-authorized alternatives (USDC/EURC — Circle France EMI, EURI — Banking Circle, EURCV — SocGen FORGE, USDQ/EURQ — Quantoz) with issuer/authorization detail, and renders bilingual advice. The same STABLECOIN_UNAVAILABLE_IN_REGION warning is auto-injected into every USDT-quoted EEA flow — fee comparisons (per-venue stablecoin_access rows), savings/total-cost/annual-cost/recommendation (top-level stablecoin_warning in trading context), withdrawals (self-custody/withdrawal context), execution cost and persona analysis (5 of 7 personas habitually withdraw USDT) — so an agent can never recommend an EU resident trade USDT on a venue without the constraint surfacing. v0.47 adds compare_interface_costs (19th tool) — consumer vs PRO dual-interface cost modeling: the same account often runs a cheap order-book interface (Kraken Pro, Coinbase Advanced, Bitvavo trade) and an expensive consumer app whose spread is embedded in the quote — priced against the TUM real-money €100 round-trip study (2025-10..11, six MiCA-licensed EU platforms; independently replicated by Frankfurt School 2026-03 with 432 round trips across 9 platforms): retail round-trips span 13x — Bitvavo 0.58% (pass-through, transparency benchmark) < BISON 2.58% < Kraken app 5.81% (3.81pp hidden) < Bitpanda 6.23% (4.25pp hidden) < Coinbase Simple 7.49% (4.51pp hidden, worst — the $2.99 flat fee dominates small DCA buys and even simple LIMIT orders carry a 1% execution fee); per-venue rows give the consumer product name and fee model, a modeled one-way all-in cost, the measured round trip, the hidden markup pp, the PRO maker/taker base and the gap in pp, and with monthly_volume_usd the annualized excess of staying on the app (Coinbase at $1k/mo ≈ $168/yr), plus subscription caveats (Kraken+ $4.99/10k waiver, Coinbase One) and the fact that app volume earns no PRO tier credit; Bitpanda/BISON are broker-only (the premium IS the fee — no PRO interface to switch to), Bitstamp Basic is flagged unverified, residency gating applies, and the same gap auto-injects as consumer_interface hints + CONSUMER_INTERFACE_MORE_EXPENSIVE warnings into the fee/savings/total-cost/recommendation tools. v0.30/v0.31 add bilingual narrative output — the fifteen narrative-bearing tools accept language: "en" | "zh" and localize every advice/warnings/tradeoffs/reasons/tier_warning string (numbers, field names and error codes stay unchanged); v0.31 also fixes the held-back BNB tier warning, which previously rendered "holding at least undefined BNB".
Tool | Trigger (EN / 中文) | Returns |
| "which exchange has the lowest fees" / "交易所手续费对比" | Exchanges sorted by weighted effective fee rate, maker/taker split, VIP tier, token + referral discounts |
| "give me a Binance referral link" / "币安优惠注册链接" | Referral URL + discount % + notes |
| "how much will I save on 100k USDT futures" / "10万U能省多少" | Original fee, fee after referral, fee after token, final fee, savings, optional funding cost |
| "true cost including funding and withdrawal" / "真实总成本对比" | Per-exchange trading fee + funding cost + withdrawal fee, ranked; v0.26 optionally folds annualized direct fiat deposit/cash-out fees ( |
| "which exchange should I use" / "我该选哪个交易所" | Scored best pick (0-100) with reasons, tradeoffs, advice, and ranked alternatives; v0.27 folds the user's direct fiat deposit/cash-out habit into the score (dispersion-driven 0.2–0.5 weight), flags rail-less venues with an explicit tradeoff, and ranks a small card/SEPA on-ramper on fiat rails instead of trading fees alone |
| "what does trading cost me per year" / "一年手续费多少,升VIP能省多少" | Annualized trading fee + funding + withdrawals (+ v0.26 optional annual fiat deposit/cash-out legs in |
| "where does the data come from" / "数据哪来的,多久更新" | Per-file |
| "current funding rate on BTC perps" / "现在各所资金费率多少" | Per-exchange funding rate + interval for a perp pair (default BTC/USDT): bundled averages or real-time live rates with per-venue fallback |
| "spread and slippage on a 50k market order" / "点差滑点多少、大单冲击成本" | Per-exchange one-way execution cost in bps + USD for an order size: full spread, half-spread crossing, depth-walk slippage, levels consumed, fill status — bundled baselines or live top-100 book walks |
| "cheapest way to deposit euros / cash out to bank" / "入金出金手续费、SEPA/ACH/电汇/PIX 哪个便宜" | Per-exchange direct fiat deposit or withdrawal quotes for an amount: fee (pct + fixed with min/max), USD-equivalent, effective %, net amount, ETA, cheapest rail per venue, overall best pick and saving vs worst — card / ACH / SEPA / FPS / wire / SWIFT / PIX in USD/EUR/GBP/BRL with residency-based rail filtering |
| "cheapest network to withdraw USDT / ETH L2 提币费对比" / "各所提币手续费、TRC20/ERC20/ Layer2 哪个便宜、哪条链暂停了" | Per-exchange withdrawal quotes for an asset (and optional network): every route's native-unit fee + USD-converted fee with |
| "which exchange fits a small buyer / scalper / HODLer" / "我这种情况哪个交易所划算、定投囤币/波段/高频场景推荐" | Seven research-anchored trader personas (casual buyer, HODL accumulator, active spot, swing futures, day scalper, VIP/institutional, DEX-native): annual all-in ranking over the FULL cost stack — trading fees + funding + spread + withdrawals + fiat on/off-ramping — with per-component cost mix, component leaders, a |
| "is holding BNB/GT/KCS for fee discounts worth it" / "持有平台币划算吗、折扣多久回本、币价跌多少不亏" | Native-token fee-discount payback: annual fee WITHOUT the token (zero-balance tier, no toggle) vs. WITH it (BNB/MX/BGB/KCS flat deduction, GT/MX/HYPE holding-tier ladder, Gate futures maker-to-zero, GT/KCS/BNB tier lift), annual USD saving, USD opportunity cost of the locked token balance, payback in months, and max one-year token price drop the saving can absorb; omit |
| "which exchange for EVERY kind of trader" / "全部画像对比、什么人用什么所、决策矩阵、最全能的交易所" (v0.28) | One call runs all seven personas (or a subset) for a country through the full annual all-in stack and returns a decision matrix: per-persona headline winner + realistic |
| "how do fees change if my volume grows / how much more trading to hit the next VIP tier" / "月交易量不同手续费差多少、再刷多少量升档省钱、各所档位跳变点、费率随成交量曲线" (v0.34) | Volume what-if sweep for spot/futures across every allowed venue: per-volume-point cross-venue cheapest ranking (tier + weighted fee + annual trading fee), per-venue sweep curves with |
| "same profile across countries / I'm moving countries, what changes / which venues are blocked here" / "同样的习惯在哪个国家最便宜、搬家换居住地、各国有什么交易所、哪些所在我国不能用、国家差异矩阵" (v0.35) | Runs one persona (default active_spot_trader; any of the 7) through the full annual stack across multiple countries (default US/GB/DE/JP/SG/BR/CN, up to 12): per-row headline |
| "what is MY actual fee / my real VIP maker-taker / check my account fee with a read-only API key" / "我的实际费率、账户真实VIP档位、API查我的手续费、只读密钥查费率" (v0.39) | Authenticated real account maker/taker via read-only key + signed gap in bps vs the public schedule tier at the stated volume; 13/18 venues (Phemex/BloFin unsupported by ccxt, Finst, Bitpanda and Bison have no public API/connector; Bitstamp/Bitvavo spot-only so their perps unsupported); keys never cached or logged; compliance gates first; typed auth/network error codes |
| "can I still trade/withdraw USDT in the EU / is USDT delisted here / MiCA stablecoin alternatives" / "USDT在欧盟还能用吗、泰达币下架、欧洲稳定币、USDC/EURC合规稳定币" (v0.46) | MiCA regional access for a stablecoin (default USDT; also USDC/EURC/EURI/EURCV/USDQ/EURQ): issuer + MiCA EMT authorization, regional venue-trading restriction with cliff date (EEA30 post-2026-07-01), custody/withdrawal/self-custody rights, per-venue status (delisted + date / never_offered / venue_blocked, eea/global scope, availability in the queried country), compliant alternatives and bilingual advice; the same warning auto-injects into fee, withdrawal, execution-cost and persona tools for USDT/EEA requests |
| "why is the Kraken/Coinbase app so expensive / hidden spread in Instant Buy or Simple" / "为什么App买币这么贵、App隐藏点差、两套价格、简单买卖手续费、TUM实测" (v0.47) | Per venue: consumer product name + fee model, modeled one-way all-in cost, TUM-measured round-trip, hidden markup pp, the PRO maker/taker base and gap in pp, and with |
| "did any exchange change its fees lately / fee change history / 哪家所最近调过手续费、费率变更历史、怎么监控费率调整" (v0.48) | Auditable fee-schedule change feed: curated high/medium-confidence records verified against official announcements (date, source URL, bilingual summary, before/after) merged with |
Supported exchanges: Binance, OKX, Gate.io, Bybit, MEXC, Bitget, KuCoin, Kraken (spot + futures, full VIP tier tables; MEXC runs a flat Standard tier; Kraken runs one unified 17-tier schedule across both products), Coinbase (Advanced Trade spot-only, volume-only tiers), Hyperliquid (v0.20, the first DEX venue: on-chain L1 order book, 14-day rolling volume tiers, hourly funding, staked-HYPE fee discounts, no KYC), BingX (v0.21: VIP Club ladders with a volume-only Elite rung, a volume-OR-assets qualification track, and 8h funding), and Phemex (v0.24: Singapore-based, ex-Morgan Stanley team, the lowest maker fees in the industry — 0.01% spot/futures at the Standard tier, 30-day-volume-only VIP ladders, 8h funding, flat 20% PT token fee-deduction discount on spot+futures), and BloFin (v0.37: Cayman/Marshall-Islands derivatives venue live since 2023, ~$1.2B/24h perp volume — 6-tier ladders with futures 0.020%/0.060% base down to 0%/0.035% at VIP5, three-track OR qualification via 30d volume/spot-volume/account assets ($50k assets alone reaches futures VIP1), 8h funding, ~3 bps typical perp spread, no native token, no direct fiat rails; blocked US/CA/CN/SG and EEA under MiCA), and Bitstamp (v0.38: Luxembourg-founded (2011), Robinhood-owned, the most heavily regulated venue — MiCA CASP / NYDFS BitLicense / UK FCA / SG MAS; 11-tier volume-only spot ladder 0.30%/0.40% → 0%/0.03% at $1B; EEA30-only regulated USD perps at a flat −0.005% maker rebate / 0.015% taker with 8h P2P funding, gated per country×product via a positive region allowlist (v0.40); free US ACH, free SEPA in / €3 out, 0.05%/0.1% SWIFT, ~4% card; ERC-20-heavy withdrawals — USDT ~20 ERC-20 only, USDC also on Solana/L2; no native token), and Bitvavo (v0.42: Amsterdam (2018), the largest home-grown euro spot exchange — AFM MiCA CASP #41000010 with EEA passporting, 4M+ users and roughly half of global EUR-denominated spot volume; nine-rung single-track 30d EUR-volume PRO spot ladder 0.15%/0.25% → 0%/0.02% above €25M, no token/assets track; the model's tightest EU EUR-book spread at 1.0 bps (Kaiko 2026-05); free SEPA/SEPA Instant both legs (iDEAL/Bancontact) + 1% EU card deposit only; BTC-only dynamic withdrawal at 0.00005; spot-only — no perps; gated by a venue-level positive service-area allowlist (region_allowed: EEA30), so every non-EEA residency including GB/CH (separate unmodeled entities) is venue-blocked), and Finst (v0.43: Amsterdam (2022, ex-DEGIRO team), the model's first brokerage/SOR venue rather than an order-book exchange — AFM MiCA CASP #41000015 with EEA passporting; a FLAT 0.15% on every buy/sell/swap with no maker/taker split, tiers or spread markup, modeled as one volume-independent ladder rung; free SEPA/SEPA Instant/iDEAL/Bancontact both legs EUR-only, no card/PayPal/USD/GBP; BTC withdrawal 0.000085 (dynamic network fee ≈0.00005 + €2.50 flat third-party charge folded into the native fee), other assets unsupported; spot-only; EEA-only via the same region_allowed: ["EEA"] gate — the EEA spot stack is now 9 venues; no referral, no public trading API so account-fee lookup is unsupported), and Bitpanda (v0.44: Vienna (2014), the model's first spread-priced brokerage rather than an order-book venue — BaFin MiCA CASP (2025-01-27) with EEA30 passporting plus Austrian FMA and UK FCA entities, 7.4M+ users; the consumer app embeds its fee as an all-in price markup: 1.49%/side headline, 0.99%/side for BTC and major stablecoin pairs via pair overrides, 2.49% for sub-€100M small caps — no maker/taker split, no volume ladder, pricing_model: "spread" with the spread baseline pinned to 0 bps to prevent double-counting, plus execution_quality evidence (advertised 2.98% round trip vs TUM real-money measured 6.23%, 4.25pp hidden; Frankfurt School 2026-03 replication); free SEPA/SEPA Instant/deposit-only cards/PayPal/Apple-Google Pay in EUR and FPS/cards in GBP since 2026, no USD route; BTC 0.00000598 ($0.46) and ETH 0.0006 ($1.51) dynamic network-cost pass-through; spot-only; EEA30+GB service area via region_allowed: ["EEA","GB"] (GB single-member region key) — the EEA spot stack is now 10 venues and GB is included unlike Bitvavo/Finst; the separate Fusion pro exchange, stocks/metals and 10x margin are not modeled; no referral, no ccxt class so account-fee lookup is unsupported), and BISON (v0.45: Stuttgart (2019), Boerse Stuttgart Group — the model's 18th venue and second spread-priced brokerage — EUWAX AG quotes as principal (no order book, ~10s quote validity); Boerse Stuttgart Digital Custody held the first BaFin MiCA custody/transfer license (2025-01-17) and EUWAX's exchange service has been MiCA-authorized since 2025-04-01, 1M+ active users; the consumer app embeds 1.25%/side for BTC/ETH via pair overrides and 1.75%/side for every other coin (~2.5%/~3.5% round trip) — no maker/taker, no ladder, pricing_model: "spread" with the spread baseline pinned to 0 bps, plus execution_quality evidence (advertised 2.5% vs TUM real-money measured 2.58%, only ~0.08pp hidden — the closest published-vs-measured alignment of the six tested platforms); FREE SEPA/SEPA Instant both legs EUR-only including Swiss users + 2.49% deposit-only card/Apple/Google Pay, no GBP/USD/CHF rail; BTC and ETH on-chain withdrawals officially FREE at fee 0 (network costs absorbed by the group; min 0.001 BTC, no Lightning/Taproot; ETH mainnet only, no L2); spot-only, no futures/margin; service area EEA30+CH via region_allowed: ["EEA","CH"] (CH as a new single-member region key) — the EEA spot stack is now 11 venues, the CH stack 15, and GB is blocked (the complementary gap to Bitpanda); German stocks/ETFs (€1.99/order) and the 27% staking commission are not modeled; invite-a-friend but no affiliate URL, no ccxt class so account-fee lookup is unsupported). Referral links are optional per exchange — tools compare every exchange with fee data and only attach referral_url / referral_discount when a link is configured (Kraken, Coinbase, Hyperliquid, BingX, Phemex, BloFin, Bitstamp, Bitvavo, Finst, Bitpanda and BISON have none).
Fee-model inputs
monthlyVolumeUsd/volume— resolves the correct VIP tier per exchange.tokenBalance(optional) — native-token holdings, with exchange-specific ladder rules (verified against official fee pages 2026-09):Binance spot — AND gate: VIP1+ requires the volume threshold and BNB holdings (VIP1 = $1M + 5 BNB … VIP9 = $4B + 5,500 BNB). Omit it → the volume tier is quoted with a
tier_warning; pass0→ the tier is downgraded and priced correctly. (Binance futures have no holding gate.)Gate spot + futures — OR dual-track: VIP level is the higher of your 30-day volume rung and your GT-holdings rung (VIP1 = $1M or 1,000 GT … VIP9 = $1B or 200,000 GT). GT can only upgrade the tier, never downgrade it; results include a
next_tierupgrade hint. GT holdings also unlock fee-payment discounts (100/500/2000/20000 GT → 10/20/35/50%).KuCoin spot + futures — OR triple-track (v0.13): VIP0–VIP12, and the level is the higher of your 30-day spot-volume rung, 30-day futures-volume rung (spot/futures thresholds differ and are applied per product), or your KCS holdings rung (VIP1 = 1,000 KCS … VIP12 = 150,000 KCS). KCS only upgrades, never downgrades; results include a
next_tier/requires_kcsupgrade hint. KuCoin spot symbols are split into Class A (high-liquidity majors — the ladder quoted), Class B (exactly 2× Class A) and Class C (exactly 3×); spot results carry aspot_class_notereminding the caller to check the pair's class. Compliance note: KuCoin is filtered out forUS,CN,HK,SG,TH.Kraken spot + futures — unified 17-tier triple-track (v0.14): since 2026-07-09 Kraken Pro applies one tier (Tier 1–12, then Pro 1–5) to both products, set by the highest of the 30-day spot-volume track, the 30-day futures-volume track (different thresholds per product), or real-time assets on platform (AOP) passed via
accountAssetsUsd(Tier 3 = $20k AOP … Tier 9 = $1M … Pro 5 = $100M). Tier 1–2 have no asset path — holdings start at Tier 3. Spot runs 0.40%/0.80% at Tier 1 down to 0%/0.05% at Pro 5; futures run 0.02%/0.05% down to -0.006%/0.0125%, with negative maker rebates from Tier 11. Kraken has no native token (souseTokennever applies) and no referral link. Every Kraken result carriesexchange_noteswith the qualification caveats (single-volume-input limitation, US/CA/NZ futures cross-qualification, consumer-app vs Pro pricing). Compliance: Kraken servesUS(spot; CFTC-regulated Kraken/Bitnomial perps in 47 states),HK,JP,THand is blocked forCNandSG.Coinbase spot — volume-only tiers (v0.19): Advanced Trade quotes pure order-book maker/taker rates that refresh hourly on 30-day rolling USD volume across all pairs (Tier 1 = 0.40%/0.60% … Tier 2 = 0.25%/0.40% at $10k … Tier 9 = 0%/0.04% at $400M). Qualification is volume-only — no holdings track, no native token, so
tokenBalance/useTokennever apply andaccountAssetsUsdis ignored. Coinbase is a spot-only venue: it is automatically excluded from futures fee comparisons and from live funding fetches (retail nano BTC/ETH perps are not modeled). Spot execution cost uses a 2.0 bps typical full-spread baseline (live mode walks thecoinbaseexchangebook); withdrawal routes cover BTC / ETH / USDT (ERC-20, Base, Solana) / USDC (Base free, ERC-20) with dynamic gas-based fee notes. Compliance: served toUSandSGresidents, blocked forCN,HK,TH,JP.Hyperliquid spot + futures — 14-day volume tiers + staked-HYPE discount (v0.20): the first DEX venue — a fully on-chain L1 order book (HyperCore) with zero trading gas, USDC-margined perps and a USDC-quoted spot book (deposits arrive via Circle CCTP, min 5 USDC). Tiers refresh daily on a 14-day rolling weighted volume window (spot volume counts 2× — not the 30-day window other venues use, so a steady-pace trader's real tier may sit one rung lower): perps 0.045%/0.015% at Tier 0 down to 0.024%/0% at Tier 6 ($7B), spot 0.070%/0.040% down to 0.025%/0%; maker is plain zero (not negative) from Tier 4. Qualification is volume-only — holding HYPE never qualifies a tier. The staked-HYPE ladder (10/100/1k/10k/100k/500k HYPE → 5/10/15/20/30/40% off all maker+taker fees, spot and perps) stacks multiplicatively with the volume tier; pass
useToken+tokenBalance= the staked amount (merely holding HYPE gives nothing). Funding settles every hour — the bundled 0.00125%/1h equals the same neutral 0.01%/8h average as CEX venues, and live mode is supported. Withdrawals: a single flat ~1 USDC route to Arbitrum One / 22+ CCTP chains (USDC only — no USDT route; deposits are free). Typical BTC perp spread is 0.8 bps (bundled baseline; live mode walks thehyperliquidbook). No KYC, no fiat rails, no referral link. Compliance: US front-end geo-blocked (ToS restricted list); accessible fromCN,HK,SG,JP,TH.BingX spot + futures — VIP Club ladders with a volume-only Elite rung (v0.21): per-product 8-rung ladders (Regular → Elite → VIP1–5 → Supreme) on 30-day volume thresholds that differ between spot and futures. Futures run 0.020%/0.050% at Regular, 0.018%/0.045% at the Elite rung ($5M, inserted 2026-06-26), down to 0%/0.025% at Supreme ($500M); spot runs 0.10%/0.10% at Regular, 0.05%/0.08% at Elite ($0.5M), down to 0.005%/0.02% at Supreme ($15M). Qualification is the highest of three tracks — 30-day spot volume, 30-day Standard Contract futures volume, or previous-day account assets via
accountAssetsUsd(futures VIP1 = $50k … VIP5 = $3M; levels refresh daily 03:00 UTC+8). The Elite and Supreme rungs are volume-only — assets can lift you to VIP1–VIP5 but never to Elite or Supreme (a $10B account still caps at VIP5). VIP4/VIP5/Supreme additionally require API-traded volume ≤20% of total volume (the engine assumes compliance). The close-only Standard Futures copy-trading product (flat 0.045%) is not modeled — ladders quote the Standard Contract order-book book. No native token (souseTokennever applies), no referral link, no direct fiat rails (P2P/third-party gateways only). Funding settles every 8h at the standard 0.01% neutral average (live mode supported via thebingxccxt class); bundled typical BTC spread is 4 bps. Withdrawals cover BTC / ETH / USDT / USDC across TRC-20/ERC-20/BEP20/Arbitrum/Optimism/Base/Polygon/Solana/TON/Aptos and more, with paused routes flagged per chain (e.g. USDC-TRC20, USDT Avalanche-C/opBNB). Every BingX result carries sixexchange_notes(tracks, volume-only rungs, API-ratio rule, Standard Futures exclusion, no token/referral, source verification). Compliance: blocked forUS,CA,GB,CN,HK,SGand — post-MiCA-cliff (v0.41, Austrian FMA application still only "advanced"/unapproved) — venue-blocked across the entire EEA; served inJP,TH,AU,BRand other non-EEA countries.BloFin spot + futures — three-track OR 6-tier ladders (v0.37): BuildLight Future Limited (Cayman/Marshall Islands), derivatives live since Jan 2023, ~$1.2B/24h perp turnover (CoinGecko), Fireblocks custody, ISO 27001, monthly 1:1 proof of reserves; no KYC required (20,000 USDT/day unverified withdrawal cap). Six tiers per product qualify via the highest of three tracks — 30-day futures volume, 30-day spot volume, or daily-snapshot account assets via
accountAssetsUsd(levels refresh daily 00:00–12:00 UTC): futures Regular 0.020%/0.060% (<$10M vol and <$50k assets), VIP1 0.006%/0.050% at $10M or $50k assets (an unusually cheap asset track), through VIP5 0%/0.035% at $500M/$3M; spot 0.10%/0.10% → VIP1 0.035%/0.06% at $1M/$50k → VIP5 0.01%/0.0325% at $8M/$3M. VIP4/VIP5 also require ≥80% of qualifying volume to be non-API (assumed satisfied, caveat surfaced in notes). The singlemonthlyVolumeUsdis matched to the queried product's own thresholds — cross-product qualification (futures volume lifting the spot tier) is not modeled. No native token (nouseToken), no operator referral link, no direct fiat rails (Checkout.com/Simplex/Alchemy third-party widgets only). Funding settles every 8h (00/08/16 UTC) at the 0.01% neutral average; bundled typical BTC perp spread is 3 bps. Withdrawals are dynamic network-cost pass-through with no exchange markup: BTC ~0.0002, USDT/USDC TRC-20 flat ~1, ETH ERC-20/L2 (Arbitrum/Optimism ~$0.5–2). Compliance: blocked forUS,CA,CN,SGand (no MiCA CASP authorization past the 2026-07-01 grandfathering cliff) the EEA —DEis explicitly modeled blocked; served inHK,JP,TH,GB,BRand 150+ other countries.Bitstamp spot + futures — 11-tier volume-only spot ladder + EU-only regulated perps with a venue×country product gate (v0.38): founded 2011 in Luxembourg (the oldest exchange in the model), acquired by Robinhood in 2025 (~$200m); regulated under the EU MiCA CASP passport (CSSF Luxembourg), US NYDFS BitLicense + 40+ state MTLs, UK FCA, Singapore MAS and Canadian registration — the model's compliance anchor venue. Spot PRO/API fees run a single 30-day-USD-turnover track with no asset or token track: 0.30%/0.40% below $10k → 0.20%/0.30% at $10k → 0.10%/0.20% at $100k → 0.00%/0.03% at ≥$1B (11 rungs); the consumer Basic interface quotes spread-based prices and is not modeled, nor is the promotional first-$1,000 free tier or the FX/stablecoin/USDT half-rate sub-schedule. Regulated USD-margined perpetual futures are a single FLAT tier: −0.005% maker (a rebate) / 0.015% taker, peer-to-peer funding every 8h (00:00/08:00/16:00 UTC) with no platform take-rate (bundled average 0.01%). Because the perps are offered only to EEA-eligible residents, Bitstamp is modeled with a per-product gate backed (since v0.40) by a positive region allowlist —
product_region_gates.bitstamp.futures = ["EEA"]against theregions.EEAmembership table (the 30 EEA states: EU27 + Iceland/Liechtenstein/Norway). Venue-level access (spot) is open inUS,GB,CA,JP,SG,HK,TH,DEand the catch-all default, andCNis venue-blocked;futuresis product-blocked for EVERY residency outside the EEA — explicit-key markets (US/GB/CA/JP/SG/HK/TH) and unmodeled countries routed viadefault(AU/BR/CH/TR/KR/MX/IN/…) alike (trading tools returnPRODUCT_BLOCKED_IN_COUNTRY, andcompare_countrieslists it underunsupported_product, notblocked); every EEA member routes both products. This replaces the v0.38 negative-list default key, which over-opened perps to non-EEA countries lacking an explicit entry. Product gating is deliberately NOT applied toget_withdrawal_fees,get_fiat_costorget_referral_link— a US user can still use Bitstamp spot, withdrawals and fiat rails. Direct fiat is deep: US ACH free both directions; SEPA EUR deposits free / withdrawals a flat €3; international SWIFT USD/EUR/GBP 0.05% in ($7.5 floor, $300 cap) / 0.1% out ($25 floor); cards ~4% in USD/EUR/GBP. Withdrawals are conservative and ERC-20-heavy: BTC 0.0005 (no Lightning), ETH 0.005 ERC-20 only (no L2), USDT a flat 20 on ERC-20 only (no TRC-20/Solana — the most expensive USDT route in the model; USDT itself is not tradable on-exchange in the EU), USDC 4 ERC-20 (plus Solana/Arbitrum/Polygon/Optimism/Avalanche/Stellar routes not individually modeled). Bundled typical major-pair spot spread is 2 bps, on par with Coinbase Advanced. No native token (nouseToken), no referral link.Bitvavo spot — nine-rung EUR-volume PRO ladder + venue-level EEA service-area allowlist (v0.42): founded 2018 in Amsterdam; Bitvavo B.V. is registered with the Netherlands AFM under MiCA as a Crypto-Asset Service provider (#41000010) and passportes across the EEA (~4M+ users, a dominant share of EUR-denominated spot volume). Unlike all prior gates (negative
region_blockedbans or product-levelproduct_region_gates), Bitvavo is modeled with a venue-level positive service-area gate —region_allowed.bitvavo = ["EEA"]againstregions.EEA(30 states): ONLY EEA residents can onboard the venue, and every other residency — explicit-key markets and default-key countries alike, includingGB/CHserved in reality by separate Bitvavo entities that are deliberately not modeled — is venue-blocked (COUNTRY_BLOCKED); a whitelist match also overrides any stale per-countryallowedentry. Gate precedence per venue:region_blockedban → countryblocked→region_allowedwhitelist hit (authorize) → whitelist miss (deny) → per-countryallowedenum (empty = open); absent country stays false-safe. Fees are the PRO/API order-book schedule on a SINGLE 30-day trailing EUR-volume track (thresholds treated as USD-equivalent): nine rungs 0.15%/0.25% (<€100k) → 0.10%/0.20% → 0.08%/0.16% → 0.06%/0.12% → 0.05%/0.10% → 0.04%/0.08% → 0.04%/0.06% → 0.00%/0.05% → 0.00%/0.02% (≥€25M, majors); no native token, no assets track, and the consumer Basic interface (embedded-spread pricing; a 2026 TUM study measured ~0.08 pp hidden markup) is not modeled. Bitvavo is spot-only — no perpetuals are offered, so it is absent from every futures stack/funding fetch and appears asunsupported_product(notblocked) incompare_countriesfor an EEA futures persona; outside the EEA it isblocked. EUR books quote in EUR (not USDT) with the tightest typical spread in the model: 1.0 bps full / 0.5 crossing on majors (Kaiko 2026-05 measured 0.981 bps, the tightest of any European venue; long-tail alts run wider via pair-class multipliers). Fiat: SEPA/SEPA Instant EUR free on both legs (iDEAL and Bancontact ride SEPA; cash-out capped at €25,000/day), EU-issued cards ~1% deposit (third-party sources span 0.5–1.5%, modeled midpoint) with no card cash-out leg; PayPal (~2%) is noted but unmodeled; no USD/GBP rails. Withdrawals: dynamic network-cost BTC only, modeled at 0.00005 BTC (no Lightning; an outlier 0.0000063 quote from one aggregator was discarded) — every other asset (USDT/USDC/ETH/…) returnssupported: falserather than a fabricated fee. Account-fee lookup is supported on spot via thebitvavoccxt class.Finst spot — flat-fee SOR brokerage + venue-level EEA allowlist (v0.43): founded 2022 in Amsterdam by an ex-DEGIRO team (KvK 85668117); Finst B.V. holds AFM MiCA CASP registration #41000015 (granted 2025-07) with EEA passporting and serves ~30 European countries. Finst is not an order-book venue: a smart-order-routing brokerage that aggregates external liquidity (400+ EUR/USDC markets) and publishes one flat 0.15% charge on every buy/sell/swap/auto-invest — no maker/taker distinction, no volume ladder, no minimum, and it claims no spread markup. The model therefore carries a single volume-independent rung (
tier: "Flat 0.15%", maker = taker = 0.15% at every volume; the monotonic-ladder audit passes trivially), with a 1.0 bps full / 0.5 bps crossing cohort spread proxy (no order-book research exists for a SOR venue). Access uses the same venue-level positive gate as Bitvavo —region_allowed.finst = ["EEA"]— so only the 30 EEA states price the venue (the EEA spot stack becomes 9: bitstamp, bitvavo, bybit, coinbase, finst, gate, hyperliquid, kraken, okx); every other residency, including GB/US/CH/JP/AU/BR, sees it venue-blocked/absent. Finst offers no derivatives at all —futures: []means no regulatory product gate fires (isVenueUsableForstays true inside the EEA, mirroring Coinbase/Bitvavo semantics) but the venue never enters a futures pricing stack;compare_countrieslists it asunsupported_productfor an EEA futures persona andblockedoutside the EEA. Fiat: a single EUR SEPA route (SEPA Instant/iDEAL/Bancontact) free on both legs; no card route (an explicitmethod: "card"query returns the venue withavailable: false/ empty routes — it stays in the comparison array for EEA countries but can never bebest), no PayPal, no USD/GBP. Withdrawals: the official schedule is a dynamic network fee at cost plus a flat €2.50 third-party charge per crypto withdrawal;WithdrawalFeehas no surcharge field and the schema is deliberately not extended, so the BTC route is modeled all-in as 0.000085 BTC / ≈$6.57 (≈0.00005 BTC ≈$3.86 typical network component at the $77,298 snapshot + €2.50 ≈$2.72 at 0.92 EUR/USD), with the routenotedisclosing both parts; the other 400+ markets returnsupported: false. Deposits are free; unmodeled product lines (Bundle 0.10%/mo management, staking 25–45% fee share, new-customer €10k/2-week free window) are out of scope. Finst exposes no public trading API and ccxt 4.5.x ships nofinstclass, soget_account_fee_tierreturnsACCOUNT_FEES_UNSUPPORTED(matrix deliberately omits the venue; the missing-spec path resolves unsupported) and there is no referral link.Bitpanda spot — embedded-premium spread brokerage + measured-vs-advertised execution evidence (v0.44): founded 2014 in Vienna; Bitpanda GmbH holds BaFin MiCA CASP authorization (2025-01-27) passported across the 30 EEA states, plus the Austrian FMA license, and serves Great Britain through the FCA-registered Bitpanda Broker UK Ltd (~7.4M users). The consumer app is NOT an order-book venue: it quotes one all-in price with the fee embedded as a markup and no separate commission line. The schema gains a third pricing model —
pricing_model: "spread"alongside"order_book"and"flat"— with a single volume-independent rung at 1.49% maker = taker for most assets; pair-level overrides apply 0.99% per side to BTC and the major stablecoin pairs (BTC/EUR, BTC/GBP, BTC/USDC, BTC/USDT and the stablecoin EUR/GBP crosses) while generic alts keep 1.49%; the official 2.49% band for sub-€100M market-cap assets and the 1.99% crypto-index band are disclosed in notes (not individually runged), as is the consumer app's 10x margin product (not modeled). Because the markup already IS a spread-crossing cost,spread_baseline.bitpandais pinned to 0 bps full/crossing andgetSpreadEstimateearly-returns 0 — the anti-double-count guard that keeps the 1.49% premium from reappearing as anannual_spread_costline. A newexecution_qualityobject on the venue's fee spec carries independent real-money evidence:advertised_roundtrip_pct: 2.98vs TUM's measured 6.23% mean €100 round trip (Oct–Nov 2025, 50 round trips per platform) — 4.25 percentage points hidden — replicated by the Frankfurt School of Finance in 2026-03 (432 round trips across 9 platforms); the narrative is auto-appended toexchange_notes. Access is a venue-level positive gate —region_allowed.bitpanda = ["EEA","GB"]— where GB is modeled as a single-member region key (regions.GB = ["GB"]): the whitelist hit authorizes GB through the existing gate precedence with no gate-code change, while US/CA/CN/CH and every other residency is venue-blocked. The EEA spot stack becomes 10 (bitstamp, bitpanda, bitvavo, bybit, coinbase, finst, gate, hyperliquid, kraken, okx) and GB is served (unlike Bitvavo/Finst);futures: []makes a futures persona seeunsupported_productin-service andblockedoutside. The professional Bitpanda Fusion exchange (aggregated external liquidity, 0.02–0.25%) is a separate product and deliberately not modeled; tokenized stocks/ETFs/metals are out of scope. Fiat: since 2026 all consumer-app rails are free — EUR SEPA/SEPA Instant, Visa/Mastercard cards (deposit only; the withdraw leg is modelednull), PayPal, Apple/Google Pay, and GBP FPS + cards; there is no USD rail (a no-country USD query keeps the row withavailable: false/ empty routes). Withdrawals pass dynamic network fees through with no markup, modeled only for BTC 0.00000598 BTC ($0.4622 at the $77,298 snapshot) and ETH 0.0006 ETH ($1.5072) — the JSON deliberately carries nofee_usdfield so the engine recomputes fromasset_prices_usd; every other asset returnssupported: false. There is no referral program and ccxt 4.5.x ships nobitpandaclass, soget_account_fee_tierreturnsACCOUNT_FEES_UNSUPPORTED(live coverage stays 13 of 17 venues).BISON spot — principal spread brokerage with near-perfect advertised-vs-measured alignment + free on-chain withdrawals (v0.45): launched 2019 in Stuttgart by Boerse Stuttgart Group (~1M+ active users, 56 cryptocurrencies as of 2026-01); the trading counterparty is EUWAX AG, which quotes in its own name as principal — quotes stay valid roughly 10 seconds and there is no order book. Custody sits with Boerse Stuttgart Digital Custody GmbH (formerly blocknox), holder of the first BaFin MiCA crypto custody/transfer license (2025-01-17, passported to 29 states); EUWAX AG's crypto exchange service has been MiCA-authorized since 2025-04-01 (8-state passport) with order execution added 2025-11-21 (Germany only). Pricing reuses the spread model — a single volume-independent rung at 1.75% maker = taker for all cryptocurrencies except BTC/ETH, with pair-level overrides at 1.25% per side for BTC/EUR and ETH/EUR (rates float with market conditions and ticket size); the official spread is the only trading cost and there is no separate commission. As with Bitpanda,
spread_baseline.bisonis pinned to 0 bps andgetSpreadEstimateearly-returns 0 so the spread can never be double-counted inannual_spread_cost. Theexecution_qualityblock carries the study's transparency benchmark:advertised_roundtrip_pct: 2.5vs TUM measured 2.58% — just 0.08 percentage points undisclosed on 50 standardized €100 round trips over 12 trading days (Oct–Nov 2025, six MiCA platforms; BISON included in the six-platform sample), the closest published-vs-measured alignment of the sample (Bitvavo −0.58% next; Bitpanda 6.23%, Coinbase 7.49%). Access uses a venue-level positive gate —region_allowed.bison = ["EEA","CH"]— with CH added as a second single-member region key (regions.CH = ["CH"]): all 30 EEA states and Switzerland price the venue (DE/AT/CH actively marketed; other EEA states passively served under treaty freedoms), while GB is venue-blocked — deliberately complementary to Bitpanda (EEA+GB) — together with US/CA/JP/SG/AU/BR/CN/KR; the EEA spot stack becomes 11, the CH stack 15, and GB/US/JP results never contain BISON.futures: [](no exchange-hosted futures or margin is offered) →unsupported_productin-service,blockedoutside. Fiat is EUR only: SEPA/SEPA Instant free on both legs including Swiss users funding in EUR (modeled as region-less routes gated by the venue allowlist, since Switzerland belongs to SEPA but not the EU region table), plus 2.49% instant card/Apple Pay/Google Pay deposits (Solaris SE/Deutsche Bank partner fee; the withdraw leg isnull— no card cash-out); there is no GBP/USD/CHF rail (a no-country USD query keeps the row withavailable: false). Withdrawals are officially free with no network-fee line — on-chain costs are absorbed by EUWAX/the group (a structurally different policy from Bitpanda's pass-through) — modeled only for BTC 0 BTC / $0 (min 0.001; no Lightning, no Taproot bc1p payouts) and ETH 0 ETH / $0 (Ethereum mainnet only, min 0.01; no Arbitrum/Base/Optimism/Polygon/BNB Chain L2), which makes BISON the globalbestfor both assets; every other asset returnssupported: false, and withdrawal comparison is deliberately not country-gated. The €1.99 German stocks/ETFs flat order (Germany only) and the 27% staking reward commission (ETH/SOL) are out of scope. The invite-a-friend program (DE/AT/CH ETH rewards) has no affiliate URL and ccxt 4.5.78 ships nobison/euwaxclass, sogetReferralLinkreturnsNO_REFERRAL_LINKandget_account_fee_tierreturnsACCOUNT_FEES_UNSUPPORTED(live coverage stays 13 of 18 venues).
accountAssetsUsd(optional, OKX / Bybit / Bitget / Kraken / BingX / BloFin) — total account assets in USD. VIP level is the higher of your 30-day volume rung and your asset rung, for both spot and futures (e.g. OKX VIP1 = $100k … VIP9 = $500M with negative maker rebates; Bybit VIP4 = $1M; Bitget VIP1 = $30k; Kraken Tier 3 = $20k AOP … Pro 5 = $100M; BingX VIP1 = $50k … VIP5 = $3M; BloFin VIP1 = $50k … VIP5 = $3M on either product's own thresholds). Assets can only upgrade, never downgrade; volume-only rows (e.g. Bybit Supreme, Kraken Tier 1–2, BingX Elite and Supreme) do not qualify via assets; BloFin VIP4/VIP5 additionally require ≥80% non-API volume (the engine assumes compliance, caveat inexchange_notes). Omitting the parameter quotes the volume tier and returns an asset-path upgrade hint (next_min_assets).pair(optional, v0.12) — a trading pair such asBTC/USDT,BTC/FDUSDorBTCUSDT(separators are normalized). When the pair has a known fee promo, the promo rates replace the account-tier rates and results carrypricing_basis: "pair"plus apair_note; otherwise pricing staysaccount_tier. Verified pair promos: MEXC — all spot pairs 0% maker + 0% taker (0-fee program), 100+ futures pairs at 0/0 subject to per-account quotas; Binance — FDUSD pairs (BTC/ETH/BNB/DOGE/LINK/SOL/XRP) at 0% maker with tier-based taker, USDC pairs at 0% maker / 0.095% taker; Bitget — USDC/USDT and USDGO/USDT at 0/0 (volume does not count toward VIP); Bitpanda (v0.44) — the 0.99%/side embedded-premium band on BTC and major stablecoin pairs vs the 1.49% headline (a spread-broker pricing band, not a promo; non-promo flag); Bison (v0.45) — the 1.25%/side band on BTC/EUR and ETH/EUR vs the 1.75% headline (same non-promo spread-band pattern). A pair override can cover maker only, taker only, or both.makerShare(0-1, default 0) — fraction of volume executed as maker (limit orders). Weighted rate =maker × share + taker × (1-share). Limit-order traders should pass 0.7-1.useToken— prices in native-token discounts: BNB (25% spot / 10% futures), GT (futures maker → 0 plus 10-50% holding-tier discount withtokenBalance), MX (20% spot + futures; 500+ MX lifts the discount to 50% — the greater applies, they do not stack), BGB (20% spot + futures), KCS (20% spot Class A/B/C + futures; at VIP8+ maker is already 0% so only the taker side benefits), OKB (baked into OKX tiers), and staked HYPE on Hyperliquid (10/100/1k/10k/100k/500k staked → 5/10/15/20/30/40% off all maker+taker fees, stacking multiplicatively with the volume tier;tokenBalancemust be the staked amount — holding alone gives nothing).Negative maker rates — OKX VIP7+ makers are negative (spot/futures, down to -0.0075%) and Kraken futures makers are negative from Tier 11 (down to -0.006% at Pro 5), i.e. exchange-paid maker rebates. They pass through referral/token discounts unchanged (a discount cannot shrink a rebate), surface as negative fee estimates, and rank ahead of paid fees.
holdingHours(futures) — monthly position exposure in hours; funding cost at each exchange's funding rate (8h interval for most venues; Hyperliquid settles hourly — its bundled 0.00125%/1h equals the neutral 0.01%/8h CEX average).calculate_annual_costannualizes it ×12. Every funding figure carriesfunding_source(bundledorlive) plusfunding_rate_ts/funding_pairwhen live data was used.fundingMode+fundingPair(optional, v0.15) — funding inputs forcalculate_savings,compare_total_cost,recommend_exchangeandcalculate_annual_cost.fundingMode: "bundled"(default) uses the offline long-run average (0.01%/8h for BTC/USDT — instant and deterministic).fundingMode: "live"fetches the venue's current funding rate in real time via ccxt forfundingPair(defaultBTC/USDT; acceptsETH/USDT,SOL-USDT,BTCUSD…). Each exchange is fetched independently with an 8s timeout; any venue that fails (timeout, geo-block, missing pair) transparently falls back to its bundled average and is listed infailuresfor the dedicated tool. Results are TTL-cached in memory for 5 minutes (funding only settles every few hours). Negative live rates pass through untouched — longs then get paid. The standaloneget_funding_ratestool acceptsfundingMode,fundingPair, optionalexchanges: [...], and optionalcountryfiltering.tradeSizeUsd+spreadMode+spreadPair+side(v0.16) — execution-cost inputs forcalculate_savings,compare_total_cost,recommend_exchangeandcalculate_annual_cost. WhentradeSizeUsd(a single marketable order size, e.g.10000) is passed, every cost result adds the one-way bid-ask crossing cost (half the typical full spread) for that order, tagged withspread_source.spreadMode: "bundled"(default) prices it from offline venue baselines scaled by pair class — majors (BTC/ETH) ×1.0, large caps (SOL/XRP/DOGE … 27 names) ×1.5, other alts ×3 — with zero modeled slippage.spreadMode: "live"fetches each venue's real top-100 order book via ccxt, resolves the correct spot or linear-swap market automatically (KuCoin spot uses thekucoinclass, notkucoinfutures), and VWAP-walks the depth forside: "buy" | "sell"to measure size-conditional slippage beyond the best touch, pluslevels_consumed,available_depth_usdandfully_filled. Per-venue failures (timeout, geo-block, missing market) fall back to the bundled baseline and are listed infailures; when visible depth is smaller than the order the measured value is kept with awarningsentry (impact beyond depth is not extrapolated). Book walks are TTL-cached for 30 seconds.compare_total_costfolds spread + slippage intototal_cost;calculate_annual_costscales them with annual traded notional (monthly ×12, assuming flow sliced intotradeSizeUsd-sized orders);recommend_exchangeblends execution into the score (fee 70% / funding 15% / spread 15% when both apply). The standaloneget_execution_costtool acceptstradeSizeUsd(default $10,000),pair,purpose,side,spreadMode, optionalexchanges: [...]andcountry.Fiat on/off-ramp inputs (v0.17,
get_fiat_cost) —direction: "deposit" | "withdraw"(default deposit),amountin fiat oramountUsd(converted at the static display rate),currency: "USD" | "EUR" | "GBP" | "BRL"(default USD),countryISO residency (drives compliance filtering and regional-rail availability — e.g. Bybit's 1.1% EU-issued card vs 3.05% elsewhere, ACH US-only), optionalmethod: "card" | "ach" | "sepa" | "fps" | "wire" | "swift" | "pix"filter, and optionalexchanges: [...]. Only exchange-operated direct rails are modeled — third-party card gateways (Banxa/Simplex/MoonPay/Zen, typically 1.99–5.5% at checkout), P2P and bank-side charges are excluded by design (they vary per user and are called out inadvice/notes). Fees support percent + fixed with min/max floors (e.g. Bybit SEPA 0.19% min €1, Binance SWIFT fixed 5 capped at 25). Results return per-rail fee, USD-equivalent, effective %, net amount, ETA, per-venue cheapest rail, an overallbest,saving_vs_worst_usd, and warnings (venues with no qualifying rail, missing country for region-locked rails). Cards run 1.1–4.5% across venues while ACH/SEPA/FPS/PIX bank rails are free or near-free almost everywhere.Fiat legs in the all-in cost tools (v0.26) —
compare_total_costandcalculate_annual_costnow acceptfiatCurrency,fiatDepositAmountUsd+fiatDepositsPerYear,fiatCashoutAmountUsd+fiatCashoutsPerYear, and optionalfiatMethod, and fold the cheapest direct rail fee × yearly count into the total asfiat_deposit_cost/fiat_cashout_cost(annual tools:annual_fiat_deposit_cost/annual_fiat_cashout_cost). This prices the FULL stack a retail trader actually pays — trading fees + funding + spread/slippage + on-chain withdrawals + bank/card deposits and cash-outs — in a single call. A free-but-real rail returns cost0withfiat_deposit_available: true; a venue with no direct rail (e.g. Hyperliquid/BingX/Phemex/BloFin) returns the leg excluded (0) withfiat_deposit_available: false, never silently treated as free. When no fiat habit is passed the keys are omitted and behavior is unchanged.Fiat-aware recommendation (v0.27) —
recommend_exchangetakes the same six fiat habit params and joins annualized direct-rail costs to the score. The fiat weight is data-driven by cost dispersion:fiatWeight = 0.2 + 0.3 × dispFiat / (dispFee + dispFiat)where dispersions are the annualized venue-to-venue cost ranges, so it rises from 0.2 to 0.5 exactly when fiat-fee differences dwarf trading-fee differences (small monthly on-rampers) and stays at 0.2 for high-volume traders; the remaining weight re-splits over fee/funding/spread. A rail-less venue scores zero on that direction (free-but-real rails score 100) and receives an explicit tradeoff naming the real third-party/P2P path (typically 1.99–5.5%); the advice also names the cheapest-fiat venue and yearly delta when the winner charges more for the exact same habit. Without the params, scoring is byte-identical to the pre-v0.27 weight table. Example flip (v0.41 EEA): DE spot $500/mo + 12×€1,000 SEPA — without the habit rail-less Hyperliquid wins 100 on fees among EEA-usable venues; with the habit OKX (free SEPA both legs) wins 92.2 vs Hyperliquid 62.7 (Binance/MEXC are no longer EEA-usable).withdrawalAsset+withdrawalNetwork(v0.18 network coverage) — adds network withdrawal fees. The bundled table covers 16 assets (BTC, ETH, SOL, XRP, DOGE, LTC, TRX, ADA, AVAX, DOT, LINK, BCH, TON, POL, USDT, USDC) across TRC-20, ERC-20, BEP20, Arbitrum, Optimism, Base, Polygon, Avalanche C, Solana, TON, Polkadot/AssetHub and each asset's native chain at all 18 venues (route availability varies per venue; Coinbase, BingX, BloFin and Bitstamp cover BTC / ETH / USDT / USDC only; Bitvavo (v0.42) models dynamic BTC only at 0.00005, flagging every other asset unsupported; Finst (v0.43) models BTC only at 0.000085 all-in (dynamic network fee + €2.50 flat third-party charge folded together, disclosed per route note), every other asset unsupported; Bitpanda (v0.44) models dynamic pass-through BTC 0.00000598 ($0.4622) and ETH 0.0006 ($1.5072) only (nofee_usdstored — recomputed from the price snapshot), every other asset unsupported; Bison (v0.45) models BTC and ETH with fee 0 — the group absorbs on-chain network costs, making it the globalbestfor both assets (BTC mainnet min 0.001; ETH mainnet only, min 0.01, no L2s), every other asset unsupported; Hyperliquid lists a single flat ~1 USDC route to Arbitrum / 22+ CCTP chains; BloFin quotes dynamic network-cost pass-through with TRC-20 stablecoins at ~1). Native-unit fees are converted to USD from a 2026-09-12 price snapshot (asset_prices_usd); routes paused in Aug–Sep 2026 (e.g. TON wallets at five venues, USDC-TRC20 at Gate/KuCoin/BingX, DOT relay chain) carrysuspended: trueand are never treated as open. When no network is passed the venue's cheapest open route is priced automatically; network input accepts aliases (trc20,erc20,arb,matic,sol…).calculate_annual_costmultiplies the per-event fee bywithdrawalsPerYear. The standaloneget_withdrawal_fees(asset?, network?, country?, exchanges?)tool (fully offline) returns the full per-route comparison withbest,saving_vs_worst_usdand warnings; error codes:INVALID_ASSET,INVALID_NETWORK,UNKNOWN_EXCHANGE.Trader-persona presets (v0.22,
analyze_persona) — seven research-anchored archetypes indata/personas.jsonbundle a complete behavioral profile: market (spot/futures), monthly volume, maker share, monthly holding hours, typical clip size (tradeSizeUsd), withdrawal asset + yearly count, and yearly fiat deposits/cashouts (currency + rail habit). The personas are casual_buyer (small card-funded buyer — card fees dominate), hodler_accumulator (monthly DCA + BTC withdrawals to cold storage), active_spot_trader, swing_futures_trader (funding is the biggest line), day_scalper (high-volume, 90% maker), vip_institutional ($30M/mo, $3M assets, $100k clips → live spread advised), and dex_native (on-chain USDC flows, no KYC/fiat needs — missing rails are flagged, not zeroed). Each persona runs the same annualized stack the other tools price individually — trading fees + funding + execution + per-event withdrawals + fiat — returns the per-venuecost_mix_pct,component_leaders, a headlinebestplus a separatebest_complete: the cheapest venue where every persona leg is actually priced (e.g. Hyperliquid can headline for a futures persona but lack fiat rails or a USDT/BTC route — it is flagged withwithdrawal_unsupported/fiat-availability and the realistic all-legs pick is shown with its extra cost). Every preset is a default overridable viamonthlyVolumeUsd,makerShare,useToken,tokenBalance,accountAssetsUsd,holdingHours,tradeSizeUsd,pair,currency, plusfundingMode/fundingPairandspreadMode/spreadPairlive overrides; personas are validated to a schema and versioned like every other data file.currency— display currencyUSD(default),EUR,JPY,CNH,GBP. Static display rates only; all math stays USD-based.language(v0.30, extended in v0.31/v0.36) — output language for the narrative layer oncompare_exchange_fees,compare_total_cost,calculate_savings,calculate_annual_cost,get_fiat_cost,get_withdrawal_fees,recommend_exchange,analyze_persona,compare_personas,analyze_token_discount,volume_what_ifandcompare_countries:"en"(default) or"zh". All advice / warnings / tradeoffs / reasons / tier warnings are rendered from a centralized bilingual template catalog (src/i18n.ts); English output is byte-identical to pre-v0.30, and numbers, field names, error codes and machine-oriented notes stay language-independent, so switching language never changes the data schema.format/tableMetric(v0.36, the three matrix tools only) —compare_personas,volume_what_ifandcompare_countriesacceptformat: "json"(default) |"markdown"|"csv"|"both". With any non-JSON format the result gains arendered: { metric, markdown?, csv? }object: a titled, paste-ready table in English or Chinese according tolanguage; persona matrix = venues × personas with annual all-in cost (rail-missing cells carry a†marker in markdown only, CSV stays numeric); what-if = monthly-volume rows × venues withtableMetric: "weighted_fee_pct"(4-dp, default) |"annual_fee_usd"|"tier"; countries = venues × countries withtableMetric: "availability"(✓/⛔/–, default; CSV uses the rawavailable/blocked/unsupported_producttokens) |"cost". CSV is RFC 4180 (fields with commas/quotes/newlines are quoted,"doubled, CRLF line endings); markdown volumes are compact ($100K/$3.5M) while CSV keeps raw numbers. Invalid values returnINVALID_INPUT; the JSON payload itself is unchanged in every format.Every fee result carries a
data_as_offreshness stamp, atier_warningfor the BNB AND gate and the GT/KCS/account-asset/AOP OR upgrade paths, and afreshness_warningonce bundled data is more than 3 months pastlast_verified. Kraken results additionally carryexchange_notes— exchange-specific qualification caveats (unified-tier tracks, regional futures limitations, Pro vs consumer-app pricing).
Related MCP server: TokenLens MCP Server
Install
Use in Claude Desktop / Cursor / any MCP client
Add to your client's MCP config (e.g. claude_desktop_config.json):
{
"mcpServers": {
"fee-optimizer-mcp": {
"command": "npx",
"args": ["-y", "fee-optimizer-mcp"]
}
}
}Run locally from source
git clone https://github.com/gaokai258/fee-optimizer-mcp.git
cd fee-optimizer-mcp
npm install
npm run build
npm start # starts stdio server (default)Streamable HTTP transport (v0.29)
Besides stdio, the server runs as a stateless Streamable HTTP MCP endpoint (MCP 2025-03-26 spec) — one isolated MCP server is created per POST, so requests are concurrency-safe and horizontally scalable without sticky sessions; responses are plain application/json, no Mcp-Session-Id is issued, and SSE GET/DELETE return 405 by design.
# CLI flags
node dist/index.js --transport http --host 0.0.0.0 --port 3333 --endpoint /mcp
# or
npm run start:http
# env overrides: FEE_MCP_TRANSPORT=http, FEE_MCP_HTTP_HOST, FEE_MCP_HTTP_PORT,
# FEE_MCP_HTTP_ENDPOINT (HOST/PORT also accepted)
node dist/index.js --help # all flagsPOST /mcp— JSON-RPC (single message or batch); requiresAccept: application/json, text/event-streamandContent-Type: application/json. Because the service is fully stateless, a handshake-free baretools/callPOST works, and strict clients may also sendinitializein its own POST first.GET /health— load-balancer probe:{ status, service, version, transport, mode, endpoint, auth_required, rate_limit_per_min, uptime_s }(no auth needed even when bearer auth is enabled).Unknown paths →
404; non-POST on/mcp→405withAllow: POST; badAccept→406.
Public hosting hardening (v0.32)
All protections are opt-in via environment variables — local/dev behavior is unchanged. Put a TLS-terminating reverse proxy (nginx/Caddy/Cloudflare) in front when binding 0.0.0.0.
Env var | Effect |
| Every MCP POST must send |
| Fixed-window per-client-IP cap on MCP POSTs; excess → |
| One structured JSON line per request on stdout: |
| Ignore |
Remote MCP client config (HTTP with bearer token):
{
"mcpServers": {
"fee-optimizer-mcp": {
"type": "http",
"url": "https://your-host/mcp",
"headers": { "Authorization": "Bearer <secret>" }
}
}
}Docker
docker build -t fee-optimizer-mcp . # or: npm run docker:build
docker run -d --name fee-mcp -p 3333:3333 \
-e FEE_MCP_BEARER_TOKEN=$(openssl rand -hex 32) \
-e FEE_MCP_RATE_LIMIT_PER_MIN=120 \
-e FEE_MCP_ACCESS_LOG=1 \
fee-optimizer-mcp # or: npm run docker:run
curl -s http://localhost:3333/healthThe multi-stage image runs on node:22-alpine as a non-root user, ships production dependencies + dist/ + data/ only, and includes a /health HEALTHCHECK.
Inspect with MCP Inspector
npm run inspector # stdio
npx @modelcontextprotocol/inspector --transport http http://127.0.0.1:3333/mcp # HTTPTool reference
compare_exchange_fees(purpose, country, monthlyVolumeUsd?, useToken?, makerShare?, tokenBalance?, accountAssetsUsd?, pair?)— Fee table comparison sorted by weighted effective rate.get_referral_link(exchange, country)— Resolves a referral URL; errors withCOUNTRY_BLOCKED/UNKNOWN_EXCHANGE/NO_REFERRAL_LINKwhen applicable.calculate_savings(exchange, volume, type, country, useToken?, holdingHours?, makerShare?, currency?, tokenBalance?, accountAssetsUsd?, pair?, fundingMode?, fundingPair?, tradeSizeUsd?, spreadMode?, spreadPair?, side?)— Savings breakdown vs. the base tier rate; withtradeSizeUsdalso returnsspread_cost/slippage_cost/spread_source/spread_ts/spread_pair.compare_total_cost(purpose, country, volume, holdingHours?, useToken?, withdrawalAsset?, withdrawalNetwork?, makerShare?, currency?, tokenBalance?, accountAssetsUsd?, pair?, fundingMode?, fundingPair?, tradeSizeUsd?, spreadMode?, spreadPair?, side?, fiatCurrency?, fiatDepositAmountUsd?, fiatDepositsPerYear?, fiatCashoutAmountUsd?, fiatCashoutsPerYear?, fiatMethod?)— All-in cost ranking; withtradeSizeUsd, spread + slippage are folded intototal_cost; with the v0.26 fiat habit params, annualized direct-rail deposit/cash-out fees are folded in too (venues without a rail flagged, leg excluded).recommend_exchange(purpose, country, volume, makerShare?, useToken?, holdingHours?, currency?, tokenBalance?, accountAssetsUsd?, pair?, fundingMode?, fundingPair?, tradeSizeUsd?, spreadMode?, spreadPair?, side?, fiatCurrency?, fiatDepositAmountUsd?, fiatDepositsPerYear?, fiatCashoutAmountUsd?, fiatCashoutsPerYear?, fiatMethod?)— Best exchange with score (fee/funding/spread blend when execution is priced), reasons, tier holding warnings, tradeoffs, actionable advice, and alternatives. v0.27: when the fiat habit is passed, annualized direct-rail deposit/cash-out costs join the score with a dispersion-driven fiat weight (0.2→0.5) — the more venue-to-venue fiat-fee differences dominate the year's trading-fee differences (typical for small monthly on-rampers), the more fiat decides; a venue with no direct rail scores zero on that leg and gets an explicit tradeoff instead of winning on an unpriced cost. Example: a German €1,000/month SEPA DCA buyer trading just $500/mo is recommended Binance (free SEPA) over the nominally fee-cheaper MEXC (~$16/yr SEPA fees), while a $100k/mo trader is still ranked on trading fees.calculate_annual_cost(exchange, purpose, country, monthlyVolumeUsd, makerShare?, useToken?, tokenBalance?, accountAssetsUsd?, holdingHours?, withdrawalAsset?, withdrawalNetwork?, withdrawalsPerYear?, currency?, pair?, fundingMode?, fundingPair?, tradeSizeUsd?, spreadMode?, spreadPair?, side?, fiatCurrency?, fiatDepositAmountUsd?, fiatDepositsPerYear?, fiatCashoutAmountUsd?, fiatCashoutsPerYear?, fiatMethod?)— Annualized trading fees (monthly ×12) + funding (monthly exposure ×12) + spread/slippage (annual traded notional × bps, whentradeSizeUsdis given) + withdrawals (per-event × yearly count) + v0.26 direct fiat deposits/cash-outs (cheapest rail × yearly count, leg flagged-and-excluded when the venue has no rail), plus anupgradeblock: the next VIP tier, how to qualify (volume / OKX-Bybit-Bitget account assets / Kraken AOP / Gate GT / KuCoin KCS / Binance BNB), and estimated annual saving.get_data_sources()— Provenance report; no parameters. Returns all 15 bundle files withlast_verified, full source list (official URLs and/or methodology notes), and v0.33 per-file freshness: each file carriesmonths_behindandis_stale(older than 3 months or unparseable), plus report-levelstale_after_monthsandstale_files: [...]so an agent can immediately see which bundle needs re-verification;data_as_ofremains the oldest stamp across files.get_funding_rates(fundingMode?, fundingPair?, exchanges?, country?)— Funding-rate table for a perpetual pair. Bundled mode is offline; live mode fetches real-time rates venue-by-venue and returns{ pair, mode, fetched_at, data_as_of, rates: [{ exchange, rate_pct, interval_hours, source, funding_timestamp?, note? }], failures: [{ exchange, error, fallback: "bundled" }] }. The four cost tools additionally acceptfundingMode?andfundingPair?.get_fiat_cost(direction?, amount? | amountUsd?, currency?, country?, method?, exchanges?)— Direct fiat on/off-ramp cost table; fully offline. Returns{ direction, currency, amount, amount_usd, fx_rate, fetched_at, data_as_of, exchanges: [{ exchange, available, routes: [{ method, region?, fee, fee_usd, effective_pct, net, eta, note? }], cheapest_method?, cheapest_fee_usd?, notes? }], best: { exchange, method, fee, fee_usd, effective_pct, net } | null, saving_vs_worst_usd?, advice, warnings? }. Error codes:INVALID_CURRENCY,INVALID_AMOUNT,MISSING_FX_RATE,UNKNOWN_EXCHANGE.get_execution_cost(tradeSizeUsd?, pair?, purpose?, side?, spreadMode?, exchanges?, country?)— One-way taker execution-cost table. Bundled mode is offline; live mode VWAP-walks each venue's real top-100 book and returns{ pair, purpose, side, trade_size_usd, mode, fetched_at, data_as_of, costs: [{ exchange, spread_bps, crossing_bps, slippage_bps, total_bps, cost_usd, levels_consumed?, fully_filled?, available_depth_usd?, source, book_timestamp?, symbol?, pair_class, note? }], failures: [{ exchange, error, fallback: "bundled" }], warnings?: [{ exchange, message }] }. The four cost tools additionally accepttradeSizeUsd?,spreadMode?,spreadPair?,side?.get_withdrawal_fees(asset?, network?, country?, exchanges?)— On-chain withdrawal-fee comparison; fully offline.assetdefaults toUSDT;networkaccepts canonical names and aliases (trc20,erc20,bsc,arb,op,matic,c-chain,sol,assethub…); without a network every route per venue is returned and ranked by the cheapest open one. Returns{ asset, network?, asset_price_usd?, fetched_at, data_as_of, exchanges: [{ exchange, supported, networks: [{ network, fee, fee_usd, available, note? }], cheapest_network?, cheapest_fee_usd? }], best: { exchange, network, fee, fee_usd } | null, saving_vs_worst_usd?, advice, warnings? }. Suspended routes stay innetworkswithavailable: false; venues with no route for the asset/network returnsupported: falseand an emptynetworkslist. Error codes:INVALID_ASSET,INVALID_NETWORK,UNKNOWN_EXCHANGE.analyze_persona(persona, country, monthlyVolumeUsd?, makerShare?, useToken?, tokenBalance?, accountAssetsUsd?, holdingHours?, tradeSizeUsd?, pair?, currency?, fundingMode?, fundingPair?, spreadMode?, spreadPair?, side?)— Annual all-in analysis for one of seven research-anchored trader personas. Fully offline in default mode. Returns{ persona, country, purpose, inputs, currency, ranking: [{ exchange, tier, annual_trading_fee, annual_funding_cost, annual_execution_cost, annual_withdrawal_cost, annual_fiat_deposit_cost?, annual_fiat_cashout_cost?, annual_all_in, cost_mix_pct, withdrawal_unsupported?, fiat_deposit_available?, fiat_cashout_available?, pricing_basis, tier_warning?, referral_url?, exchange_notes? }], best: { exchange, annual_all_in, runner_up_exchange, saving_vs_runner_up, reasons, tradeoffs } | null, best_complete: { exchange, annual_all_in, extra_vs_winner } | null, component_leaders, warnings, advice, data_as_of, data_sources }. Missing rails/routes are flagged and EXCLUDED from the row (never counted as $0);INVALID_INPUTfor an unknown persona id (the valid id list is returned).analyze_token_discount(exchange, purpose, country, monthlyVolumeUsd, makerShare?, tokenBalance?, accountAssetsUsd?, tokenPriceUsd?, currency?)— Native-token fee-discount payback analysis; fully offline. Computes the annual fee WITHOUT the native token (zero-balance tier, no fee-deduction toggle) vs. WITH it (BNB/MX/BGB/KCS flat deduction, GT/MX/HYPE holding-tier ladder, Gate futures maker-to-zero, GT/KCS/BNB tier lift from holdings), the annual USD saving, the USD opportunity cost of locking the required token balance, payback in months, and the max one-year token price drop the saving can absorb (breakeven_price_drop_pct). WhentokenBalanceis omitted it returnstiers_analysis(every achievable discount level ranked) with arecommended_tier_index(shortest payback among positive-saving tiers). Venues with no separate toggle (OKX, Kraken, Coinbase, Bybit, BingX) reporthas_native_discount: falsehonestly rather than inventing a discount. Token price comes fromdata/token_prices.json(2026-09 snapshot) or thetokenPriceUsdoverride. Error codes:UNKNOWN_EXCHANGE,COUNTRY_BLOCKED,INVALID_INPUT,NO_RESULTS.compare_personas(country, personas?, useToken?, currency?, fundingMode?, fundingPair?, spreadMode?, spreadPair?, side?, language?, format?)(v0.28,formatin v0.36) — Multi-persona decision matrix in one call; fully offline in default mode. Runs every persona (or thepersonas: [...]subset, order-preserving, deduped) through the same engine asanalyze_personaand returns{ country, currency, personas: [{ persona: {id, name_en, name_zh, tagline_zh}, purpose, monthly_volume_usd, best: { exchange, tier, annual_all_in, runner_up_exchange, saving_vs_runner_up, cost_mix_pct, tradeoffs } | null, best_complete: { exchange, annual_all_in, extra_vs_winner } | null, matrix: [{ exchange, annual_all_in, withdrawal_unsupported?, fiat_deposit_available?, fiat_cashout_available? }] }], venues, venue_wins: [{ exchange, headline_persona_ids, complete_persona_ids }], most_versatile, rendered?: { metric, markdown?, csv? }, data_as_of, data_sources, errors? }. The matrix is cheapest-first per persona; a venue absent from a row is blocked in-country or spot-only.venue_winsis sorted by realistic (best_complete) wins then headline wins;most_versatileis the venue with the most all-legs wins. Live depth is resolved per persona (purpose + clip dependent). Error codes:INVALID_INPUT(unknown persona id / bad format),NO_RESULTS.volume_what_if(purpose, country, volumes?, baseVolume?, makerShare?, useToken?, tokenBalance?, accountAssetsUsd?, pair?, currency?, language?, format?, tableMetric?)(v0.34,format/tableMetricin v0.36) — Volume what-if sweep; fully offline. Returns{ purpose, country, currency, maker_share, use_token, base_monthly_volume_usd?, volumes, data_as_of, points: [{ monthly_volume_usd, annual_traded_notional_usd, cheapest: { exchange, tier, weighted_fee_pct, annual_fee_usd }, ranking: [{ exchange, tier, volume_tier?, weighted_fee_pct, annual_fee_usd, tier_crossed? }] }], tier_crossings: [{ at_monthly_volume_usd, exchange, from_tier, to_tier }], exchanges: [{ exchange, current: { monthly_volume_usd, tier, weighted_fee_pct, annual_fee_usd } | null, next_tier?: { from_tier, to_tier, at_monthly_volume_usd, additional_monthly_volume_usd, weighted_fee_pct_now, weighted_fee_pct_next, saving_per_year_usd_at_current_volume, blocked_by_holding_gate? } | null, sweep: [{ monthly_volume_usd, tier, volume_tier?, effective_maker_pct, effective_taker_pct, weighted_fee_pct, annual_fee_usd, tier_crossed? }] }], advice, warnings?, rendered?: { metric, markdown?, csv? } }. Defaultvolumes= the sorted deduped union of every allowed venue's VIP tier thresholds plus0andbaseVolume; unions over 16 points are stride-sampled across the full range (with a warning, always keeping 0/base/max) and explicitvolumesallow up to 24 custom points.next_tieris present only whenbaseVolumeis given (null = already at the venue's top volume rung); referral and optional platform-token discounts apply exactly as incompare_exchange_fees. Trading fees only — funding/spread/withdrawals/fiat are not included.tableMetric(with non-jsonformat):weighted_fee_pct(default) |annual_fee_usd|tier. Error codes:BAD_VOLUME,UNKNOWN_CURRENCY,INVALID_INPUT(bad format/tableMetric),NO_RESULTS.compare_countries(persona?, countries?, monthlyVolumeUsd?, makerShare?, useToken?, tokenBalance?, accountAssetsUsd?, holdingHours?, tradeSizeUsd?, pair?, currency?, fundingMode?, fundingPair?, spreadMode?, spreadPair?, side?, language?, format?, tableMetric?)(v0.35,format/tableMetricin v0.36) — Country diff matrix; fully offline in default mode. Runs the sameanalyzePersonaengine once per country and returns{ persona: {id, name_en, name_zh}, purpose, currency, countries, data_as_of, rows: [{ country, available_venues, winner: {exchange, tier, annual_all_in} | null, best_complete: {exchange, annual_all_in, extra_vs_winner} | null, comparison_basis: "winner"|"best_complete", comparison_annual_all_in, extra_vs_cheapest_country_usd, extra_vs_cheapest_country_pct, blocked_venues, unsupported_product_venues, ranking, error?, error_code? }], cheapest_country: {country, exchange, tier?, annual_all_in, basis} | null, costliest_country, spread_usd, winner_venue_counts: [{exchange, count, countries}], venue_availability: [{exchange, per_country: {CC: available|blocked|unsupported_product}, blocked_in}], advice, warnings?, rendered?: { metric, markdown?, csv? } }. Defaults: personaactive_spot_trader, countriesUS/GB/DE/JP/SG/BR/CN(max 12, deduped). Cross-country deltas usecomparison_annual_all_in= the all-legsbest_completecost when the headline winner misses rails, otherwise the winner — so a venue with no fiat/withdrawal rails cannot make a country look artificially cheap. Live overrides (funding/depth) are fetched once over the union of venues allowed in ANY selected country.tableMetric(with non-jsonformat):availability(default) |cost. Error codes:INVALID_INPUT(unknown persona / bad format/tableMetric),UNKNOWN_CURRENCY.get_account_fee_tier(exchange, purpose, country, apiKey, secret?, password?, pair?, monthlyVolumeUsd?)(v0.39) — the personalized bridge from the public schedule to the caller's actual account fee. Uses a read-only API key against the venue's authenticated fee endpoint via ccxt (fetchTradingFeeswhere available, else per-symbolfetchTradingFee), then returns{ exchange, purpose, pair, credential_type, fetch_method, fetched_at, live_fee: {maker_pct, taker_pct}, bundled_fee: {tier, maker_pct, taker_pct, monthly_volume_usd}, delta_vs_bundled_bps: {maker, taker}, security_note, notes }— a negative bps gap means the account pays less than the public tier at that volume (server-side BNB/fee-token deductions, the venue's own rolling-30d VIP window, negotiated or promo rates are all captured by the live leg). Coverage: 13 of 18 venues — Binance, OKX (password= API passphrase), Gate, Bybit, MEXC, Bitget, KuCoin spot +kucoinfutures(passphrase), Kraken spot +krakenfutures, Coinbase spot (coinbaseexchangeclass), BingX, Bitstamp spot, Bitvavo spot (v0.42,bitvavoclass); Hyperliquid takes only the public 0x wallet address inapiKey(no secret — it queries the publicuserFeesendpoint). Phemex and BloFin have no authenticated fee endpoint in ccxt 4.5.x, Finst (v0.43) exposes no public trading API and ccxt 4.5.x ships nofinstclass, Bitpanda (v0.44) is a spread-quoting brokerage with no public trading API and nobitpandaclass, Bison (v0.45) is an EUWAX principal-quoted brokerage with nobison/euwaxclass in ccxt 4.5.78, and Bitstamp/Bitvavo perps are not modeled (both venues are spot-only) →ACCOUNT_FEES_UNSUPPORTED(fails without any network call). Compliance runs first:UNKNOWN_EXCHANGE/COUNTRY_BLOCKED/PRODUCT_BLOCKED_IN_COUNTRY/NO_FEE_DATAare returned before credentials are used. Runtime failures are typed and credential-scrubbed:ACCOUNT_MISSING_CREDENTIALS,ACCOUNT_AUTH_FAILED(non-retryable — wrong key/secret/passphrase, IP restriction, KYC),ACCOUNT_FEE_FETCH_FAILED(retryable: truefor network/timeout/rate-limit). Credentials are per-request only — never cached, never written to logs.get_stablecoin_access(asset?, country?, exchange?, language?)(v0.46) — MiCA stablecoin regional-access report; fully offline.assetdefaults toUSDT(alsoUSDC/EURC/EURI/EURCV/USDQ/EURQ). Returns{ asset, asset_name?, issuer?, mica_authorized, issuer_note?, fetched_at, data_as_of, restriction: { applies, region?, effective?, venue_trading?, custody_withdrawal?, self_custody_allowed?, note? }, venues: [{ exchange, status, scope, since?, note?, venue_available_in_country }], compliant_alternatives, regulation_note?, advice, data_sources? }. With a country inside the EEA30 the USDT restriction applies (cliff2026-07-01) and all 18 venues are listed (delisted+date for the nine EEA-licensed venues,venue_blockedfor the six banned CASPs,never_offeredfor the three global-scope venues); outside the EEA (US/GB/CH/…)restriction.appliesis false and only global-scope rows return;exchangenarrows to one row. Error codes:INVALID_ASSET(valid ids returned insuggested_action),UNKNOWN_EXCHANGE,COUNTRY_BLOCKED.compare_interface_costs(exchange?, country?, monthly_volume_usd?, language?)(v0.47) — consumer vs PRO dual-interface cost report; fully offline. Returns{ generated_at, data_as_of, study_summary, venues: [{ exchange, venue_name, available_in_country, consumer: { product_name, fee_model, modeled_one_way_pct, published_one_way_pct?, measured_round_trip_pct?, measured_hidden_spread_pp?, subscription?, tier_credit, measurement }, pro?: { product_name, base_maker_pct, base_taker_pct, published_round_trip_pct }, consumer_vs_pro_round_trip_pp?, consumer_vs_pro_annual_excess_usd?, advice, notes? }], advice, data_sources? }. Evidence: the TUM real-money €100 round-trip study (2025-10..11, six MiCA-licensed EU platforms) replicated by Frankfurt School (2026-03, 432 round trips/9 platforms) — Bitvavo 0.58% < BISON 2.58% < Kraken app 5.81% < Bitpanda 6.23% < Coinbase Simple 7.49%; Bitstamp Basic is flagged unverified (venue's own disclosure only), Bitpanda/BISON are broker-only (no PRO interface,proomitted).exchangenarrows to one venue,countryapplies the residency gate (Bitvavo/Bitpanda/BISON blocked outside their service areas), andmonthly_volume_usdaddsconsumer_vs_pro_annual_excess_usdwherever the consumer one-way cost exceeds the PRO taker base. Error codes:UNKNOWN_EXCHANGE,COUNTRY_BLOCKED,INVALID_VOLUME.get_fee_changes(exchange?, product?, since_month?, limit?, language?)(v0.48) — auditable fee-schedule change feed; fully offline. Returns{ generated_at, data_as_of, snapshot_coverage: { months, first?, last?, available }, changes: [{ id, date, exchange, product, kind, tier?, field?, before?, after?, confidence, summary_en, summary_zh?, effective_date?, url?, note?, detected_from_snapshot?, detected_to_snapshot? }], advice }. Two evidence tiers: curated rows (confidence: high|medium) are human-verified against official venue announcements/fee pages and ship indata/fee_changes.json; detected rows are auto-generated by diffing consecutive monthly deterministic snapshots insnapshots/fee_ladders/*.json(repo-only — absent from the npm tarball, wheresnapshot_coverage.availableisfalse) and must never be treated as confirmed.kindis one ofrate | threshold | ladder_structure | promo | token_discount | pricing_model; rate before/after values use the engine's round4 percent precision, and rungs are matched by tier name. Sorted date-descending then confidence rank;productacceptsspot|futures|all(anallrecord matches either),since_monthtakesYYYY-MM. The monthly capture/review is automated via thedata-snapshotGitHub Actions workflow (review-only PR — detected rows never enter the curated file without human verification). Local CLI:npm run snapshot:fees -- snapshot|diff|latest.
Errors are structured JSON: { error, code, retryable?, suggested_action? } with codes such as INVALID_INPUT, UNKNOWN_EXCHANGE, COUNTRY_BLOCKED, PRODUCT_BLOCKED_IN_COUNTRY, NO_RESULTS, UNKNOWN_CURRENCY, NO_REFERRAL_LINK, DATA_LOAD_FAILED, ACCOUNT_FEES_UNSUPPORTED, ACCOUNT_MISSING_CREDENTIALS, ACCOUNT_AUTH_FAILED, ACCOUNT_FEE_FETCH_FAILED.
Data files
All fee/VIP/withdrawal/spread data is local JSON. By default the server makes no external API calls; fundingMode: "live" requests fetch current funding rates and spreadMode: "live" requests fetch order books directly from exchange public endpoints via ccxt (best-effort, per-venue timeout, bundled fallback), and get_account_fee_tier (v0.39) makes one authenticated request per call to the venue's account-fee endpoint with a read-only key supplied by the caller (see Credential handling):
File | Contents |
VIP tier maker/taker rates, spot + futures; v0.44 adds per-venue | |
Referral URLs, user discount %, operator rebate (internal) | |
BNB / OKB / GT / MX / BGB / KCS / PT discount rules + Hyperliquid staked-HYPE ladder (multiplicative, staking required) | |
Pair-level fee promos (MEXC 0-fee, Binance FDUSD/USDC, Bitget USDC/USDT), v0.44 Bitpanda spread-band pricing (0.99% BTC/stablecoin pairs vs the 1.49% headline, non-promo) and v0.45 Bison bands (1.25% BTC/EUR + ETH/EUR vs the 1.75% headline, non-promo) | |
Bundled average funding rate + settlement interval (live-mode fallback) | |
Typical full bid-ask spread per venue (BTC) + majors/large-cap/mid-alt multipliers (2026 order-book snapshot studies; live-mode fallback); v0.44 pins Bitpanda to 0 bps and v0.45 pins Bison to 0 bps because each venue's embedded premium IS the spread (anti-double-count) | |
Per-exchange withdrawal fees for 16 assets across native + multi-chain routes (TRC-20/ERC-20/BEP20/Arbitrum/Optimism/Base/Polygon/Avalanche C/Solana/TON/AssetHub), | |
Static display FX rates (USD base) | |
Per-country blocked/allowed exchanges, per-product negative gates ( | |
Direct exchange-operated fiat rails (card/ACH/SEPA/FPS/wire/SWIFT/PIX) per venue, currency, region and direction, with percent+fixed+min/max fees and ETAs (gateways/P2P excluded) | |
Seven research-anchored trader personas for | |
Static 2026-09 USD snapshot prices for native tokens (BNB/OKB/GT/MX/BGB/KCS/HYPE) used to estimate the opportunity cost of holding a token for fee discounts; overridable per call via | |
v0.46 MiCA stablecoin registry: per-asset issuer/EMT authorization ( | |
v0.47 dual-interface cost model for | |
v0.48 curated fee-schedule change feed for |
Each file carries last_verified (YYYY-MM) and sources (official fee-page URLs, measurement studies or caveats). Override paths via env vars: FEE_RATES_PATH, REFERRAL_LINKS_PATH, TOKEN_DISCOUNTS_PATH, PAIR_FEES_PATH, FUNDING_RATES_PATH, SPREAD_BASELINE_PATH, WITHDRAWAL_FEES_PATH, FX_RATES_PATH, COUNTRY_RESTRICTIONS_PATH, FIAT_ROUTES_PATH, PERSONAS_PATH, TOKEN_PRICES_PATH, STABLECOIN_ACCESS_PATH, INTERFACE_COSTS_PATH, FEE_CHANGES_PATH (file) and FEE_SNAPSHOTS_PATH (directory of monthly YYYY-MM.json ladder snapshots; missing/unreadable degrades to an empty list — the curated feed still works).
Accuracy note: funding rates and withdrawal fees fluctuate; VIP tables change without notice. Treat outputs as estimates and verify via get_data_sources before financial decisions.
Credential handling (v0.39 get_account_fee_tier)
The only tool that makes authenticated calls is get_account_fee_tier, and only when it is explicitly invoked. Security properties:
Read-only keys only — always generate a key with information/read permissions and no trading, withdrawal or transfer permissions; the tool never needs them.
Per-request, never stored — credentials live only for the duration of the call. There is deliberately no result cache (the public-data TTL caches never receive key material), nothing is written to disk, and credentials are never returned in the response.
Redacted everywhere — the stderr
[audit]log redactsapiKey/secret/password/passphrase/walletAddressarguments (***REDACTED***) before serialization, and exchange error strings are scrubbed of literal credential values andsignature=parameters.Compliance first — venue/country/product gates run before any key is used, so a blocked request never touches an exchange auth endpoint.
Hyperliquid needs just the public wallet address (the fee query is a public
userFeescall); no private key is ever requested.
Examples
> User: I'm in Japan, trade 100k USDT futures/month, mostly limit orders, and hold positions ~16h. Which exchange?
Agent → recommend_exchange(purpose="futures", country="JP", volume=100000,
makerShare=0.8, holdingHours=16)
Server → {
"best": { "exchange": "...", "score": 100, "weighted_fee_rate": ...,
"reasons": [...], "tradeoffs": [...], "referral_url": "..." },
"alternatives": [...],
"advice": "Register via the ... link to lock 20% off ...",
"data_as_of": "2026-09"
}> User: 数据是哪来的?费率多久更新一次?
Agent → get_data_sources()
Server → { "data_as_of": "2026-09",
"files": [{ "file": "fee_rates.json", "last_verified": "2026-09",
"sources": [{ "name": "Binance fee schedule",
"url": "https://www.binance.com/en/fee/schedule" }, ...] }, ...] }> User: 我在币安每月交易 100 万U期货,持仓约 720 小时,每年提 12 次 USDT,一年真实成本多少?升 VIP1 能省多少?
Agent → calculate_annual_cost(exchange="binance", purpose="futures", country="JP",
monthlyVolumeUsd=1000000, holdingHours=720,
withdrawalAsset="USDT", withdrawalNetwork="TRC-20",
withdrawalsPerYear=12)
Server → {
"tier": "Regular",
"annual_trading_fee": 4800,
"annual_funding_cost": 108000,
"annual_withdrawal_cost": 18,
"annual_total_cost": 112818,
"upgrade": { "next_tier": "VIP1", "requires_volume_usd": 15000000,
"annual_savings": 960,
"hint": "Reach VIP1 via $15,000,000 30-day volume; estimated annual trading-fee saving $960 ..." }
}> User: 我主要在 MEXC 现货刷 BTC/USDT,听说 0 手续费是真的吗?其他所呢?
Agent → compare_exchange_fees(purpose="spot", country="JP", pair="BTC/USDT", makerShare=0.5)
Server → [
{ "exchange": "mexc", "tier": "Standard", "effective_maker": 0, "effective_taker": 0,
"weighted_rate": 0, "pricing_basis": "pair",
"pair_note": "MEXC 0-fee program: all spot pairs trade at 0% maker + 0% taker ..." },
{ "exchange": "okx", ..., "pricing_basis": "account_tier" },
...
]> User: 现在 BTC 永续各交易所资金费率多少?按实时费率我持 10 万U多单 16 小时要付多少资金费?
Agent → get_funding_rates(fundingMode="live", fundingPair="BTC/USDT")
Server → {
"pair": "BTC/USDT", "mode": "live",
"rates": [
{ "exchange": "binance", "rate_pct": 0.0124, "interval_hours": 8,
"source": "live", "funding_timestamp": "2026-09-12T00:00:00.000Z" },
{ "exchange": "kraken", "rate_pct": 0.01, "interval_hours": 8,
"source": "bundled", "note": "..." }
],
"failures": [{ "exchange": "kraken", "error": "Connect Timeout ...", "fallback": "bundled" }]
}
Agent → calculate_savings(exchange="binance", volume=100000, type="futures",
country="JP", holdingHours=16,
fundingMode="live", fundingPair="BTC/USDT")
Server → { "funding_cost": 24.8, "funding_source": "live",
"funding_rate_ts": "2026-09-12T00:00:00.000Z",
"funding_pair": "BTC/USDT", ... }> User: 我一笔 5 万U的 BTC 市价吃单,各交易所点差加滑点实际要付多少?25 万U的大单呢?
Agent → get_execution_cost(tradeSizeUsd=50000, pair="BTC/USDT",
purpose="futures", side="buy", spreadMode="live")
Server → {
"pair": "BTC/USDT", "mode": "live", "trade_size_usd": 50000,
"costs": [
{ "exchange": "binance", "spread_bps": 1.0, "crossing_bps": 0.5,
"slippage_bps": 0.3, "total_bps": 0.8, "cost_usd": 4,
"levels_consumed": 3, "fully_filled": true, "source": "live",
"symbol": "BTC/USDT:USDT", "book_timestamp": "2026-09-12T..." },
{ "exchange": "kraken", "spread_bps": 5, "crossing_bps": 2.5,
"slippage_bps": 0, "total_bps": 2.5, "cost_usd": 12.5,
"source": "bundled", "pair_class": "majors" }
],
"failures": [{ "exchange": "kraken", "error": "Connect Timeout ...",
"fallback": "bundled" }]
}
Agent → compare_total_cost(purpose="futures", country="JP", volume=100000,
tradeSizeUsd=250000, spreadMode="live", side="buy")
Server → [ { "exchange": "binance", "trading_fee": 1000,
"spread_cost": 12.5, "slippage_cost": 28.2,
"spread_source": "live", "total_cost": 1040.7 }, ... ]> User: 我在德国,想入 1000 欧元,刷卡和 SEPA 转账各所收多少?哪个最便宜?
Agent → get_fiat_cost(direction="deposit", currency="EUR", amount=1000, country="DE")
Server → {
"direction": "deposit", "currency": "EUR", "amount": 1000, "amount_usd": 1086.96,
"fx_rate": 0.92, "data_as_of": "2026-09",
"best": { "exchange": "binance", "method": "sepa", "fee": 0,
"fee_usd": 0, "effective_pct": 0, "net": 1000 },
"saving_vs_worst_usd": 5.43,
"exchanges": [
{ "exchange": "binance", "available": true, "cheapest_method": "sepa",
"cheapest_fee_usd": 0,
"routes": [ { "method": "sepa", "fee": 0, "fee_usd": 0, "effective_pct": 0,
"net": 1000, "eta": "1-2 business days" },
{ "method": "card", "fee": 20, ... } ] },
{ "exchange": "gate", "cheapest_method": "sepa",
"routes": [ { "method": "sepa", "fee": 5, "effective_pct": 0.5, ... } ] },
...
],
"advice": "binance offers a free sepa deposit for EUR — 1000 EUR arrives in full. ..."
}> User: 我要提 USDT 到 TRC-20,8 家所分别收多少?不提网络的话哪家最便宜?最近有哪些链暂停了?
Agent → get_withdrawal_fees(asset="USDT", network="TRC-20")
Server → {
"asset": "USDT", "network": "TRC-20", "asset_price_usd": 1,
"data_as_of": "2026-09",
"exchanges": [
{ "exchange": "mexc", "supported": true,
"networks": [{ "network": "TRC-20", "fee": 0.5, "fee_usd": 0.5, "available": true }],
"cheapest_network": "TRC-20", "cheapest_fee_usd": 0.5 },
{ "exchange": "bybit", ..., "cheapest_fee_usd": 1 },
{ "exchange": "binance", ..., "cheapest_fee_usd": 1.5 },
...
],
"best": { "exchange": "mexc", "network": "TRC-20", "fee": 0.5, "fee_usd": 0.5 },
"saving_vs_worst_usd": 1,
"advice": "Cheapest USDT TRC-20 withdrawal: mexc charges 0.5 USDT (about $0.5) ..."
}
Agent → get_withdrawal_fees(asset="ETH") // no network: cheapest open L2 per venue
Server → {
"asset": "ETH", "asset_price_usd": 2512.03,
"best": { "exchange": "mexc", "network": "Base", "fee": 0.0000013, "fee_usd": 0.0033 },
"exchanges": [ { "exchange": "binance", "cheapest_network": "Optimism",
"cheapest_fee_usd": 0.0377, "networks": [ ... ] }, ... ],
"saving_vs_worst_usd": 0.32
}Development
npm test # vitest unit tests (457 tests: 361 tools + 50 live + 28 http + 13 account + 3 polyfill + 2 version)
npm run build # tsc → dist/
npm run audit:data # offline data-consistency gate (dates, sources, ladder monotonicity, coverage)
node scripts/smoke-test.mjs # end-to-end MCP stdio smoke test (68 requests)
npm run smoke:http # end-to-end Streamable HTTP smoke test
npm run inspector # MCP Inspector UI for manual testingThe same audit → build → test → HTTP-smoke pipeline plus an npm pack artifact/install check runs in CI on every push and pull request (Node 18/20/22, .github/workflows/ci.yml). Release history lives in CHANGELOG.md.
License
MIT
Available Tools
19 toolsanalyze_personaARead-only
当用户描述自己的交易类型/身份(新手小额买入、定投囤币、活跃现货、合约波段、高频刷单、高净值机构、链上无 KYC 玩家)并想知道哪种交易所最适合自己、一年真实总花费多少时使用。Use when the user asks which exchange fits THEIR kind of trading, describes themselves as a beginner/HODLer/swing trader/scalper/institution/no-KYC trader, or wants an all-in annual cost for a trader scenario. Loads a research-anchored persona preset (casual_buyer, hodler_accumulator, active_spot_trader, swing_futures_trader, day_scalper, vip_institutional, dex_native) that bundles monthly volume, maker share, futures holding hours, market-order clip size, withdrawal and fiat on/off-ramp habits, then runs the FULL annual cost stack across every venue allowed in the country — trading fees + funding + spread crossing + on-chain withdrawals + direct fiat deposit/cash-out legs — and returns the ranked venues with cost-mix %, cheapest-venue leader for each cost component, a winner with concrete reasons and trade-offs, and tailored advice (VIP upgrade saving, token-discount hint, live funding/depth suggestions). Every preset parameter can be overridden. Requires persona id and country code.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | 吃单方向,默认 buy;live 模式下 buy 行走卖盘 asks,sell 行走买盘 bids | |
| country | Yes | ISO 3166-1 alpha-2 居住国代码,如 US/CN/JP/GB/DE/BR;用于交易所合规过滤和法币通道地区过滤 | |
| persona | Yes | 交易员画像:casual_buyer=小额随买(银行卡入金主导);hodler_accumulator=定投囤币(银行通道+冷钱包提币);active_spot_trader=活跃现货;swing_futures_trader=合约波段(资金费敏感);day_scalper=高频刷单(90% maker、$300万/月);vip_institutional=高净值/机构($3000万/月+$300万资产);dex_native=链上无KYC(USDC 自托管出入) | |
| currency | No | 显示币种,默认 USD;汇率仅用于展示(法币通道币种由画像设定,默认 USD) | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| useToken | No | 是否使用平台币折扣(覆盖画像默认 false) | |
| makerShare | No | 覆盖画像默认 maker 占比 0-1 | |
| spreadMode | No | 执行成本来源:bundled=内置典型点差基准(默认,半价差、零滑点,离线秒回);live=实时拉取订单簿前100档逐档行走,算出真实半价差+市场冲击滑点(逐所独立请求,单所失败自动回退内置基准并记入 failures,深度不足保留实测值并给 warning)。需配合 tradeSizeUsd 才会计入 | |
| spreadPair | No | 执行成本测算交易对,默认沿用 pair,再默认 BTC/USDT。live 模式现货自动解析现货市场(如 KuCoin 用 kucoin 而非 kucoinfutures),如 ETH/USDT、SOL-USDT | |
| fundingMode | No | 资金费率来源:bundled=内置长期均值(默认,离线稳定);live=实时拉取该合约当前资金费率(逐所独立请求,单所失败自动回退内置值;结果含 funding_source/funding_rate_ts/funding_pair 溯源字段) | |
| fundingPair | No | 资金费率合约对,默认 BTC/USDT 永续;仅 fundingMode=live 时生效,如 ETH/USDT、SOL-USDT | |
| holdingHours | No | 覆盖画像默认月持仓敞口小时数(合约资金费) | |
| tokenBalance | No | 平台币/质押数量,配合 useToken | |
| tradeSizeUsd | No | 覆盖画像默认单笔市价单规模(USD),触发点差穿越成本 | |
| accountAssetsUsd | No | 覆盖画像默认账户总资产(USD) | |
| monthlyVolumeUsd | No | 覆盖画像默认月交易量(USD) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and openWorldHint; the description carries the rest and does so richly: it enumerates the preset bundle contents (monthly volume, maker share, funding hours, clip size, withdrawal and fiat habits), the cost components summed, and the returned artifacts (cost-mix %, per-component cheapest leader, winner with reasons and trade-offs). It also discloses failure semantics elsewhere in the params (live request failures fall back to bundled baselines and are recorded in 'failures', shallow depth yields a warning).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is dense and mostly earns its place, but the entire description is written twice, first in Chinese then in English, which roughly doubles length without adding information for a single reader. Front-loading is reasonable (the use case and persona list appear before the return description), but the duplication and multi-clause sentences hurt scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe the return, and it does: ranked venues, cost-mix percentages, per-component cheapest leader, an overall winner with reasons and trade-offs, plus tailored advice. Combined with 100% schema coverage for the 16 inputs, an agent has everything needed to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, and the enum values for persona are explained in the schema itself. The description adds one genuinely non-derived fact — that every preset parameter can be overridden (hence the 16 optional fields) and that persona id plus country code are required — which is the key mental model for using the schema. It does not add format or interaction detail for the remaining overrides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: it loads a named persona preset and 'runs the FULL annual cost stack across every venue allowed in the country', returning ranked venues with cost-mix and a winner. That is far more than a restatement of the name. It does not, however, explicitly differentiate itself from close siblings such as compare_personas, calculate_annual_cost, or recommend_exchange, which an agent would need to disambiguate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete when-to-use triggers (user describes their trading style, asks which exchange fits them, or wants an all-in annual cost for a scenario), which is genuinely useful. But with 19 siblings including recommend_exchange, calculate_annual_cost, compare_total_cost and compare_personas, no alternative is ever named and no exclusion is stated, so routing remains inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_token_discountARead-only
当用户问持有某个交易所的平台币(BNB/GT/KCS/BGB/MX/HYPE)来抵扣手续费是否划算、多久能回本、能承受币价跌多少时使用。Use when the user asks whether holding an exchange's native token for fee discounts is worth it, how long until the discount pays back the locked capital, or how far the token price can drop before the saving is wiped out. Computes the annual trading fee WITHOUT the native token (zero-balance tier, no fee-deduction toggle) vs. WITH the token (GT/KCS/BNB holdings can lift the VIP tier; BNB/MX/BGB/KCS give a flat fee-deduction; Gate GT and MEXC MX and Hyperliquid HYPE have holding-tier discount ladders; Gate futures maker drops to zero). Returns annual USD saving, the USD opportunity cost of locking the required token balance (2026-09 snapshot price or explicit tokenPriceUsd override), payback in months, and the maximum one-year token price drop the saving can absorb. When tokenBalance is omitted it returns every achievable discount tier as a table with a recommended best-payback tier. Requires exchange, purpose, country, and monthlyVolumeUsd.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ISO 3166-1 alpha-2 居住国代码,用于合规过滤 | |
| purpose | Yes | 交易类型: spot=现货, futures=期货 | |
| currency | No | 显示币种,默认 USD | |
| exchange | Yes | 交易所名称,如 binance, gate, kucoin, mexc, bitget, hyperliquid | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| makerShare | No | maker 挂单占比 0-1,默认 0(纯吃单) | |
| tokenBalance | No | 已持有的平台币数量;省略则返回所有可达档位的回本对比表;对 Hyperliquid 填已质押(staked)的 HYPE | |
| tokenPriceUsd | No | 平台币当前 USD 单价;省略使用内置 2026-09 快照价 | |
| accountAssetsUsd | No | 账户总资产(USD),用于 OKX/Bybit/Bitget/Kraken 的资产档位升级路径 | |
| monthlyVolumeUsd | Yes | 月交易量(USD) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=false already covering safety, the description adds rich behavior: it contrasts fee calculations with and without the token, explains exchange-specific discount ladders, discloses return values (annual USD saving, opportunity cost, payback months, max absorbable drop), and states the default snapshot behavior and override. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with usage triggers and then systematically covers computation, outputs, defaults, and required inputs. However, the Chinese and English trigger sentences are largely duplicated, and the remainder is long, so it is information-dense but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry return-value disclosure, and it does: annual USD saving, opportunity cost, payback months, maximum price drop, and the all-tiers table when tokenBalance is omitted. It also covers required inputs and default behavior, making it complete for an agent to invoke this complex analytical tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by mapping supported exchanges to token behaviors, clarifying that tokenBalance omission returns all reachable tiers with a recommended best-payback tier, and explaining tokenPriceUsd as an explicit override of the 2026-09 snapshot.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific analytical purpose: computing whether holding an exchange's native token for fee discounts pays back, including annual savings, opportunity cost, payback months, and max price drop. It names the supported tokens (BNB/GT/KCS/BGB/MX/HYPE) and discount mechanics, making it easy to distinguish from generic fee-savings siblings like calculate_savings or calculate_annual_cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit trigger conditions: when the user asks whether holding an exchange token is worth it, how long until payback, or how far price can drop. It does not name alternative sibling tools or state when not to use this tool, so it falls short of full when/when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_annual_costARead-only
当用户想知道一年下来在某交易所的真实总花费(年化交易手续费+年化资金费+年提现费)或升 VIP 档位一年能省多少钱时使用。Use when the user asks for annual/yearly cost of trading on an exchange, or how much reaching the next VIP tier would save per year. Annualizes 12 months of trading fees at the resolved VIP tier (referral + optional token discounts), 12 months of futures funding exposure, and per-event withdrawal fees times yearly withdrawal count. Includes an upgrade quote: the next VIP tier, how to qualify (volume, OKX/Bybit/Bitget/Kraken account assets (Kraken AOP), Gate GT, KuCoin KCS, or Binance BNB), and estimated annual saving. Requires exchange, purpose, country, and monthlyVolumeUsd.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | 交易对,如 BTC/USDT、BTC/FDUSD、BTCUSDT 均可。命中币对级费率/0费促销时按促销价计费,未命中则按整所 VIP 档计费 | |
| side | No | 吃单方向,默认 buy;live 模式下 buy 行走卖盘 asks,sell 行走买盘 bids | |
| country | Yes | ISO 3166-1 alpha-2 国家代码 | |
| purpose | Yes | 交易类型: spot=现货, futures=期货 | |
| currency | No | 显示币种,默认 USD;汇率仅用于展示 | |
| exchange | Yes | 交易所名称,如 binance, okx, gate | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| useToken | No | 是否使用平台币(BNB/OKB/GT/MX/BGB/KCS)折扣 | |
| fiatMethod | No | 只按指定法币渠道计价(默认取最便宜):card/ach/sepa/fps/wire/swift/pix | |
| makerShare | No | 挂单(maker)成交占比 0-1,默认 0=纯吃单 | |
| spreadMode | No | 执行成本来源:bundled=内置典型点差基准(默认,半价差、零滑点,离线秒回);live=实时拉取订单簿前100档逐档行走,算出真实半价差+市场冲击滑点(逐所独立请求,单所失败自动回退内置基准并记入 failures,深度不足保留实测值并给 warning)。需配合 tradeSizeUsd 才会计入 | |
| spreadPair | No | 执行成本测算交易对,默认沿用 pair,再默认 BTC/USDT。live 模式现货自动解析现货市场(如 KuCoin 用 kucoin 而非 kucoinfutures),如 ETH/USDT、SOL-USDT | |
| fundingMode | No | 资金费率来源:bundled=内置长期均值(默认,离线稳定);live=实时拉取该合约当前资金费率(逐所独立请求,单所失败自动回退内置值;结果含 funding_source/funding_rate_ts/funding_pair 溯源字段) | |
| fundingPair | No | 资金费率合约对,默认 BTC/USDT 永续;仅 fundingMode=live 时生效,如 ETH/USDT、SOL-USDT | |
| fiatCurrency | No | 法币入金/出金币种,默认 USD(v0.26:可把年化法币通道费并入 annual_total_cost,得到完整成本栈) | |
| holdingHours | No | 期货每月平均持仓时长(小时),用于年化资金费(×12) | |
| tokenBalance | No | 持有的平台币数量(BNB / GT / KCS)。币安现货 AND 门槛;Gate OR GT、KuCoin OR KCS 双轨可升档;同时用于平台币持仓折扣 | |
| tradeSizeUsd | No | 单笔吃单市价单规模(USD),默认不计执行成本。传入后总成本/年化/推荐会加上单边点差穿越成本(半价差);spreadMode=live 时再加上该规模下的订单簿滑点,如 10000=$1万、100000=$10万 | |
| withdrawalAsset | No | 提现资产,如 BTC, ETH, USDT | |
| accountAssetsUsd | No | OKX 账户总资产(USD),OKX 按交易量 OR 资产取高定档 | |
| monthlyVolumeUsd | Yes | 月交易量(USD),年化按此 ×12 | |
| withdrawalNetwork | No | 提现网络,如 TRC-20, ERC-20 | |
| withdrawalsPerYear | No | 每年提现次数,年化提现费=单次提现费×次数,默认 0 | |
| fiatCashoutsPerYear | No | 每年法币出金次数;年化出金费=单次最便宜通道费×次数 | |
| fiatDepositsPerYear | No | 每年法币入金次数,如月薪定投 12;年化入金费=单次最便宜通道费×次数 | |
| fiatCashoutAmountUsd | No | 单次法币出金(提现回银行卡)金额(USD);与 fiatCashoutsPerYear 同时传入时计入年化出金费 | |
| fiatDepositAmountUsd | No | 单次法币入金金额(USD);与 fiatDepositsPerYear 同时传入时,按该所最便宜直连通道计入年化入金费 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, so the read-only and closed-world nature is already covered. The description adds the annualization method (12 months of fees, funding, withdrawal fees times yearly count) and that an upgrade quote is included, which is useful behavioral context beyond annotations. However, it does not disclose any limitations or edge cases. With annotations carrying the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with clear front-loaded usage conditions in both Chinese and English. The first sentence explains when to use, the second describes the calculation method, and the last lists required parameters. Some repetition between the bilingual parts, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 27 parameters (4 required) and no output schema, the description omits any explanation of how the many optional parameters affect the output or what the output looks like. It only mentions the four required parameters, leaving the agent unaware of the optional parameters that can customize the calculation (e.g., useToken, fundingMode, spreadMode, withdrawal parameters). Given the complexity, more guidance is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters in detail. The description only mentions that it requires exchange, purpose, country, and monthlyVolumeUsd, which repeats what the schema already says. It adds no meaning beyond the schema for the 27 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (annualizes) and resource (total trading cost on an exchange), and clearly distinguishes from siblings by naming the three cost components (fees + funding + withdrawal) and the upgrade quote. An agent can tell it apart from calculate_savings or compare_total_cost without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when the user asks for annual/yearly cost of trading on an exchange, or how much reaching the next VIP tier would save per year. This is a clear usage condition with no ambiguity about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_savingsARead-only
当用户询问通过推荐链接注册能节省多少手续费时使用。Use when the user asks how much they can save on fees by registering via a referral link. Computes savings based on monthly trading volume, trade type, VIP tier resolution, optional token discount (BNB/OKB/GT/MX/BGB/KCS), and optional funding cost for futures positions held over time. Returns the savings amount and the referral link to register.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | 交易对,如 BTC/USDT、BTC/FDUSD、BTCUSDT 均可。命中币对级费率/0费促销时按促销价计费,未命中则按整所 VIP 档计费 | |
| side | No | 吃单方向,默认 buy;live 模式下 buy 行走卖盘 asks,sell 行走买盘 bids | |
| type | Yes | 交易类型 | |
| volume | Yes | 月交易量,USDT | |
| country | Yes | ISO 3166-1 alpha-2 国家代码 | |
| currency | No | 显示币种,默认 USD;汇率仅用于展示 | |
| exchange | Yes | 交易所名称 | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| useToken | No | 是否使用平台币折扣 | |
| makerShare | No | 挂单(maker)成交占比 0-1,默认 0=纯吃单 | |
| spreadMode | No | 执行成本来源:bundled=内置典型点差基准(默认,半价差、零滑点,离线秒回);live=实时拉取订单簿前100档逐档行走,算出真实半价差+市场冲击滑点(逐所独立请求,单所失败自动回退内置基准并记入 failures,深度不足保留实测值并给 warning)。需配合 tradeSizeUsd 才会计入 | |
| spreadPair | No | 执行成本测算交易对,默认沿用 pair,再默认 BTC/USDT。live 模式现货自动解析现货市场(如 KuCoin 用 kucoin 而非 kucoinfutures),如 ETH/USDT、SOL-USDT | |
| fundingMode | No | 资金费率来源:bundled=内置长期均值(默认,离线稳定);live=实时拉取该合约当前资金费率(逐所独立请求,单所失败自动回退内置值;结果含 funding_source/funding_rate_ts/funding_pair 溯源字段) | |
| fundingPair | No | 资金费率合约对,默认 BTC/USDT 永续;仅 fundingMode=live 时生效,如 ETH/USDT、SOL-USDT | |
| holdingHours | No | 期货持仓时长(小时),用于计算资金费率 | |
| tokenBalance | No | 持有的平台币数量(BNB / GT / KCS)。币安现货为 AND 门槛(不足降档);Gate OR GT 持仓、KuCoin OR KCS 持仓均可升档(不降档);同时用于平台币持仓折扣 | |
| tradeSizeUsd | No | 单笔吃单市价单规模(USD),默认不计执行成本。传入后总成本/年化/推荐会加上单边点差穿越成本(半价差);spreadMode=live 时再加上该规模下的订单簿滑点,如 10000=$1万、100000=$10万 | |
| accountAssetsUsd | No | 账户总资产(USD),适用于 OKX/Bybit/Bitget(30 日交易量 OR 账户资产取高定 VIP 档)与 Kraken(平台资产 AOP:Tier3 需 $20,000、Tier9 需 $100 万、Pro5 需 $1 亿;资产只升档不降档),如 $100,000 即 OKX VIP1 / Kraken Tier 9 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: it lists the factors that affect the computation and, with no output schema present, discloses the return payload (savings amount plus the referral link to register). It stops short of describing defaults, fallbacks, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger is front-loaded and every clause earns its place, but the Chinese and English trigger sentences are duplicated, which is redundant text for a token-constrained context. Still appropriately sized for an 18-parameter computational tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 18-parameter tool with no output schema, the description covers purpose, trigger, computation basis, and a minimal return summary. It omits the richer narrative output (advice/warnings/tradeoffs/reasons implied by the language parameter) and default/fallback behavior, but the exhaustive schema fills most of the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across all 18 parameters, so the schema already carries the semantics. The description only restates a subset (volume, trade type, VIP tier, token discount, funding cost) and lists token symbols, which adds marginal value over the schema rather than compensating for any gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: computes fee savings from registering via a referral link, and enumerates the drivers (volume, trade type, VIP tier, token discount, funding cost). It is clearly distinguishable from generic fee tools, though it does not explicitly name siblings like get_referral_link or calculate_annual_cost even though it also returns a referral link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger in both languages: 'Use when the user asks how much they can save on fees by registering via a referral link.' This is a clear condition for invocation, but no when-not-to-use or alternative tool routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_countriesARead-only
当用户问"同样的交易习惯在哪个国家最便宜/我要搬家或换居住地(美国/日本/德国/新加坡…)手续费和可用交易所有什么不同/哪些所在我国被封锁/同一画像跨国对比"时使用。Use to run ONE trader persona/profile through the FULL annual all-in stack (trading fees + funding + spread + withdrawals + fiat rails) across SEVERAL countries in a single call and see how residency changes the result: per-country winner + realistic best_complete pick, annual cost and the extra vs the cheapest country (USD and %), the venues blocked by compliance and the venues that simply do not offer the profile's product (e.g. spot-only Coinbase for a futures trader), a venue×country availability matrix, cross-country venue win counts, the cheapest/costliest country and the annual cost gap, and bilingual narrative advice. Defaults to the active_spot_trader persona across 7 representative countries (US, GB, DE, JP, SG, BR, CN); pick any of the 7 personas via persona and pass an explicit countries list (up to 12). Every persona parameter can be overridden (volume, maker share, token, assets, holding hours, clip). Live funding/depth overrides are resolved once over the union of venues allowed in ANY selected country.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | 特定交易对费率活动,如 BTC/USDT | |
| side | No | 吃单方向,默认 buy;live 模式下 buy 行走卖盘 asks,sell 行走买盘 bids | |
| format | No | 矩阵渲染格式:json=仅结构化 JSON(默认,行为不变);markdown=在结果中额外附 rendered.markdown 可直接粘贴的表格;csv=附 rendered.csv(CRLF、RFC4180 转义,可导入 Excel);both=两者都附 | |
| persona | No | 交易者画像,默认 active_spot_trader:casual_buyer/hodler_accumulator/active_spot_trader/swing_futures_trader/day_scalper/vip_institutional/dex_native | |
| currency | No | 显示币种,默认 USD | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| useToken | No | 覆盖画像默认的平台币折扣开关 | |
| countries | No | ISO 3166-1 alpha-2 国家代码列表(最多 12 个,去重),默认 US/GB/DE/JP/SG/BR/CN 七国对比 | |
| makerShare | No | 覆盖画像默认的 Maker 占比 0-1 | |
| spreadMode | No | 执行成本来源:bundled=内置典型点差基准(默认,半价差、零滑点,离线秒回);live=实时拉取订单簿前100档逐档行走,算出真实半价差+市场冲击滑点(逐所独立请求,单所失败自动回退内置基准并记入 failures,深度不足保留实测值并给 warning)。需配合 tradeSizeUsd 才会计入 | |
| spreadPair | No | 执行成本测算交易对,默认沿用 pair,再默认 BTC/USDT。live 模式现货自动解析现货市场(如 KuCoin 用 kucoin 而非 kucoinfutures),如 ETH/USDT、SOL-USDT | |
| fundingMode | No | 资金费率来源:bundled=内置长期均值(默认,离线稳定);live=实时拉取该合约当前资金费率(逐所独立请求,单所失败自动回退内置值;结果含 funding_source/funding_rate_ts/funding_pair 溯源字段) | |
| fundingPair | No | 资金费率合约对,默认 BTC/USDT 永续;仅 fundingMode=live 时生效,如 ETH/USDT、SOL-USDT | |
| tableMetric | No | format 非 json 时表格内容:availability=交易所×国家可用性(✓/⛔/–,默认) / cost=交易所×国家年化总成本 | |
| holdingHours | No | 每次合约持仓小时数(资金费成本) | |
| tokenBalance | No | 平台币持仓数量(BNB/GT/KCS 等) | |
| tradeSizeUsd | No | 单笔下单规模 USD(执行成本) | |
| accountAssetsUsd | No | 账户总资产 USD | |
| monthlyVolumeUsd | No | 覆盖画像默认的月成交量(USD) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint true, openWorldHint false), but the description adds rich behavioral context: what gets computed (fees, funding, spread, withdrawals, fiat rails), how live modes fall back to bundled baselines on failure, and that live overrides are resolved once over the union of venues across selected countries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and dense, packing many clauses and parenthetical lists into a few sentences. It is front-loaded with usage triggers, but several details (e.g., enumerated output components, fallback behavior) could be trimmed or structured more cleanly for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 19 parameters, multiple modes, and no output schema, the description is unusually complete. It explains defaults, persona selection, country limits, live vs bundled modes, fallback behavior, and the kinds of results returned (per-country winner, cost gaps, availability matrix, narrative advice), leaving nothing critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 19 parameters in detail. The description restates some defaults (persona, countries) and mentions overrides, but adds little semantic detail beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'run ONE trader persona/profile through the FULL annual all-in stack ... across SEVERAL countries in a single call'. It clearly distinguishes this multi-country comparison from sibling tools like compare_total_cost or compare_exchange_fees by emphasizing cross-country residency effects and per-country winners.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit user intents ('同样的交易习惯在哪个国家最便宜/我要搬家或换居住地...'), defaults (active_spot_trader, 7 countries), and parameter overrides. However, it does not name alternative tools or state when not to use this tool, so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_exchange_feesARead-only
当用户询问加密货币交易所的手续费、费率比较、或哪个交易所交易成本最低时使用此工具。Use when the user asks about crypto exchange fees, fee comparison, or which exchange has the lowest trading cost. Supports spot and futures, with full VIP tier resolution based on monthly volume. Returns exchanges sorted by weighted effective fee rate, including referral discount and optional token discount (BNB/OKB/GT/MX/BGB/KCS). Requires country code for compliance filtering. Pass monthlyVolumeUsd for accurate VIP tier pricing; pass useToken=true if user holds the exchange's native token; pass makerShare (0-1) if the user trades mostly via limit orders.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | 交易对,如 BTC/USDT、BTC/FDUSD、BTCUSDT 均可。命中币对级费率/0费促销时按促销价计费(输出 pricing_basis=pair 并附 pair_note),未命中则按整所 VIP 档计费 | |
| country | Yes | ISO 3166-1 alpha-2 国家代码,如 CN, US, JP | |
| purpose | Yes | 交易类型: spot=现货, futures=期货 | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| useToken | No | 是否使用平台币(BNB/OKB/GT/KCS 等)折扣 | |
| makerShare | No | 挂单(maker)成交占比 0-1,默认 0=纯吃单。限价交易者设 0.7-1 更准确 | |
| tokenBalance | No | 持有的平台币数量(BNB / GT / KCS)。币安现货 VIP1+ 需交易量 AND BNB 持仓(如 VIP1 需 5 BNB,传 0 会降档);Gate 按 30 日交易量 OR GT 持仓取高者;KuCoin 按 30 日交易量(现货/合约门槛分别计算) OR KCS 持仓取高者(如持 1,000 KCS 升 VIP1,10,000 升 VIP2,40,000 升 VIP5,KCS 只会升档不会降档)。不传则按交易量给档并提示持仓影响 | |
| accountAssetsUsd | No | 账户总资产(USD)。OKX/Bybit/Bitget 按 30 日交易量 OR 账户资产取高者定 VIP 档(如 $100,000 资产即 VIP1,$500,000,000 达 VIP9 享负 maker 返佣);Kraken 按平台资产 AOP 参与统一 Tier/Pro 定档($20,000 升 Tier3,$100 万升 Tier9,Tier1-2 无资产通道)。资产只会升档不会降档。不传则按交易量给档并提示资产升档路径 | |
| monthlyVolumeUsd | No | 月交易量(USD),用于匹配 VIP 阶梯 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely new behavioral context — compliance filtering via country code, full VIP tier resolution, referral and optional token discounts, and a defined sort order. It stops short of 5 because nothing is said about error handling, coverage limits, or rate constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger condition is correctly front-loaded, but the description is essentially written twice in full (Chinese and English), doubling the length without adding information. The parameter hints at the end are useful, but the bilingual duplication is redundant padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and only light annotations, the description carries real weight and handles it: it explains the returned ordering and the referral/token discount components, and flags the country-code compliance requirement. A brief note on what happens when tier inputs are omitted or unknown would close the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by telling the agent when to supply monthlyVolumeUsd, useToken=true, and makerShare (0-1), which is decision guidance rather than restated field docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (compare exchange fees) and scopes it well: spot and futures, VIP tier resolution, output sorted by weighted effective fee rate. That scope implicitly distinguishes it from withdrawal-fee or total-cost siblings, but no sibling is named explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger conditions ('Use when the user asks about crypto exchange fees, fee comparison, or which exchange has the lowest trading cost') plus conditional parameter guidance (pass monthlyVolumeUsd, useToken, makerShare under stated circumstances). It lacks any when-not-to-use or named alternative, so it's a strong but not complete 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_interface_costsARead-only
当用户问"同一个交易所为什么 App 买币这么贵?Kraken app / Instant Buy / Coinbase Simple / 简单交易的手续费是多少?听说 App 里藏了点差(hidden spread)?同一家交易所有两套价格?TUM 实测哪个欧洲平台最坑?"时使用。Compares each venue's CONSUMER interface (Kraken app Instant Buy/custom orders, Coinbase Simple, Bitstamp Basic, Bitvavo Basic one-tap, Bitpanda/BISON spread-model brokerage) against its own PRO order-book benchmark on the same account. Evidence: TUM real-money €100 round-trip study (2025-10..11, six MiCA-licensed EU platforms) independently replicated by Frankfurt School (432 round-trips, 2026-03) — retail round-trips span 13x: Bitvavo 0.58% (pass-through, transparency benchmark) < Bison 2.58% < Kraken app 5.81% (3.81 pp hidden) < Bitpanda 6.23% (4.25 pp hidden) < Coinbase Simple 7.49% (4.51 pp hidden, worst; $2.99 flat fee dominates small DCA buys and simple LIMIT orders still carry a 1% execution fee). Returns per venue: consumer product name + fee model, modeled one-way all-in cost, measured round-trip, hidden markup pp, the PRO maker/taker base, the gap in pp, and — when monthly_volume_usd is passed — the annualized excess of using the consumer app instead of PRO (e.g. Coinbase at $1k/mo ≈ $168/yr); subscription caveats (Kraken+ $4.99/10k waiver, Coinbase One) and the fact that app volume earns NO PRO tier credit. Bitpanda/BISON have no separate PRO interface (the premium IS the fee); Bitstamp Basic is flagged unverified (no third-party measurement). Pass country to apply residency gating (Bitvavo/Bitpanda/BISON are venue-blocked outside their service areas). The same gap is auto-injected as consumer_interface hints into compare_exchange_fees / calculate_savings / compare_total_cost / recommend_exchange rows and as CONSUMER_INTERFACE_MORE_EXPENSIVE warnings on savings/recommendation results.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166-1 alpha-2 居住国代码,如 DE/FR/US/GB;用于逐行标注该场馆在居住国是否可用 | |
| exchange | No | 可选:只看单个交易所(已建模双界面的场馆:kraken/coinbase/bitvavo/bitstamp/bitpanda/bison) | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| monthly_volume_usd | No | 月交易额(USD),传入后计算 consumer 界面相对 PRO 的一年多花金额 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true and openWorldHint=false; the description adds substantial behavior an agent could not infer: source studies and dates, the exact return fields (hidden markup pp, PRO maker/taker base, gap in pp), unverified status of Bitstamp Basic, subscription caveats (Kraken+ waiver, Coinbase One), the fact that app volume earns no PRO tier credit, and residency blocking for Bitvavo/Bitpanda/BISON.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a very long, run-on Chinese quote blob of user phrasings and then continues with dense multi-clause sentences packing statistics, caveats and return-field enumerations. Useful content is present and front-loaded, but the size is far beyond what routing requires and the trigger list is excessive relative to its marginal value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal annotations, the description carries the full burden and does so: it documents return fields, evidence provenance, per-venue coverage limits (unverified Bitstamp, no PRO interface for Bitpanda/BISON), residency gating, and the cross-tool side effects. An agent has enough to call and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real interpretation: country applies per-venue residency gating (with named venue-blocked cases), monthly_volume_usd drives a specific annualized-excess calculation, and language scoping is implied by the outputs described. The exchange parameter's modeled set is also restated with concrete slugs, adding mild value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The core sentence states a specific verb and resource: it 'compares each venue's CONSUMER interface ... against its own PRO order-book benchmark on the same account,' and it enumerates exactly which venues and interfaces are modeled (Kraken app, Coinbase Simple, Bitstamp Basic, Bitvavo one-tap, Bitpanda/BISON spread-model). This is directly distinguishable from sibling tools like compare_exchange_fees, whose rows merely receive the hint, so an agent can route correctly without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit triggering contexts (user questions about app pricing, hidden spread, two price tiers) and conditions like passing country for residency gating and monthly_volume_usd for annualized excess. It does not state when NOT to use it versus the sibling cost tools, only that its output is injected into them, so it falls short of a full when/when-not map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_personasARead-only
当用户想一次看清"什么类型的交易者该用哪个交易所"、要全部 7 种画像并排对比、做决策矩阵/选型总览,或问"哪个交易所适合最多人/最全能"时使用。Use when the user wants a side-by-side decision matrix of ALL trader personas (casual buyer, DCA HODLer, active spot, swing futures, scalper, VIP/institutional, no-KYC on-chain) for their country in one call. Runs each persona's full annual all-in stack across every allowed venue, then returns per-persona winner + realistic best_complete pick (every cost leg actually priced — headline winners with no fiat/withdrawal rail are demoted), a persona×venue annual-cost matrix, cross-persona venue win counts, and the single most versatile venue. Requires only the country; optionally restrict personas or force useToken. This is the fastest way to answer "which exchange for which kind of trader".
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | 吃单方向,默认 buy;live 模式下 buy 行走卖盘 asks,sell 行走买盘 bids | |
| format | No | 矩阵渲染格式:json=仅结构化 JSON(默认,行为不变);markdown=在结果中额外附 rendered.markdown 可直接粘贴的表格;csv=附 rendered.csv(CRLF、RFC4180 转义,可导入 Excel);both=两者都附 | |
| country | Yes | ISO 3166-1 alpha-2 居住国代码,如 US/CN/JP/GB/DE/BR;合规过滤与法币通道按此国执行 | |
| currency | No | 显示币种,默认 USD | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| personas | No | 只跑指定画像子集(默认全部 7 个,按传入顺序去重):casual_buyer/hodler_accumulator/active_spot_trader/swing_futures_trader/day_scalper/vip_institutional/dex_native | |
| useToken | No | 对所有画像统一开启/关闭平台币折扣(默认沿用各画像设定,多数为 false) | |
| spreadMode | No | 执行成本来源:bundled=内置典型点差基准(默认,半价差、零滑点,离线秒回);live=实时拉取订单簿前100档逐档行走,算出真实半价差+市场冲击滑点(逐所独立请求,单所失败自动回退内置基准并记入 failures,深度不足保留实测值并给 warning)。需配合 tradeSizeUsd 才会计入 | |
| spreadPair | No | 执行成本测算交易对,默认沿用 pair,再默认 BTC/USDT。live 模式现货自动解析现货市场(如 KuCoin 用 kucoin 而非 kucoinfutures),如 ETH/USDT、SOL-USDT | |
| fundingMode | No | 资金费率来源:bundled=内置长期均值(默认,离线稳定);live=实时拉取该合约当前资金费率(逐所独立请求,单所失败自动回退内置值;结果含 funding_source/funding_rate_ts/funding_pair 溯源字段) | |
| fundingPair | No | 资金费率合约对,默认 BTC/USDT 永续;仅 fundingMode=live 时生效,如 ETH/USDT、SOL-USDT |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint=true, openWorldHint=false), and the description adds real behavioral substance beyond them: it discloses the computation (full annual all-in stack per persona per venue) and the demotion logic ('headline winners with no fiat/withdrawal rail are demoted') plus the best_complete pick semantics. That is genuinely useful context an agent would not get from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger condition is front-loaded, which is good, but the paragraph is long and the Chinese and English halves largely duplicate each other, so a substantial fraction of the text is redundant rather than additive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter, no-output-schema tool, the description carries the burden of explaining return shape and largely does so (per-persona winner, best_complete pick, persona×venue matrix, win counts, most versatile venue). It is complete enough to call correctly, though a few optional parameters (spreadMode/fundingMode behavior) live only in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the 11 parameters are already documented in the schema. The description only restates that country is required and that personas/useToken are optional, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (run all 7 persona stacks side-by-side for a country) and explicitly scopes it as a single-call multi-persona comparison, which distinguishes it from the sibling analyze_persona (single persona). An agent can tell what it produces without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Front-loads explicit trigger conditions in Chinese ('当用户想…时使用') and mirrors them in English ('Use when the user wants a side-by-side decision matrix of ALL trader personas…'). It gives clear context for when to reach for this tool but never names the alternative (analyze_persona) or states when-not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_total_costARead-only
当用户要求比较不同交易所的真实总成本(交易手续费+资金费率+提现费+点差,v0.26 起可选年化法币入金/出金费)时使用。Use when the user asks for a total cost comparison across exchanges including trading fees, funding rates for futures positions, withdrawal fees, spread, and (v0.26) optional annualized direct fiat deposit/cash-out fees. This is the most comprehensive comparison tool. Requires purpose, country, and monthly volume. Optionally pass holdingHours for funding cost, useToken for token discount, withdrawal details, and fiatDepositAmountUsd/fiatDepositsPerYear (+cashout equivalents) to fold bank/card on/off-ramping into the ranked total.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | 交易对,如 BTC/USDT、BTC/FDUSD、BTCUSDT 均可。命中币对级费率/0费促销时按促销价计费,未命中则按整所 VIP 档计费 | |
| side | No | 吃单方向,默认 buy;live 模式下 buy 行走卖盘 asks,sell 行走买盘 bids | |
| volume | Yes | 月交易量,USDT | |
| country | Yes | ISO 3166-1 alpha-2 国家代码 | |
| purpose | Yes | 交易类型 | |
| currency | No | 显示币种,默认 USD;汇率仅用于展示 | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| useToken | No | 是否使用平台币折扣 | |
| fiatMethod | No | 只按指定法币渠道计价(默认取最便宜):card/ach/sepa/fps/wire/swift/pix | |
| makerShare | No | 挂单(maker)成交占比 0-1,默认 0=纯吃单 | |
| spreadMode | No | 执行成本来源:bundled=内置典型点差基准(默认,半价差、零滑点,离线秒回);live=实时拉取订单簿前100档逐档行走,算出真实半价差+市场冲击滑点(逐所独立请求,单所失败自动回退内置基准并记入 failures,深度不足保留实测值并给 warning)。需配合 tradeSizeUsd 才会计入 | |
| spreadPair | No | 执行成本测算交易对,默认沿用 pair,再默认 BTC/USDT。live 模式现货自动解析现货市场(如 KuCoin 用 kucoin 而非 kucoinfutures),如 ETH/USDT、SOL-USDT | |
| fundingMode | No | 资金费率来源:bundled=内置长期均值(默认,离线稳定);live=实时拉取该合约当前资金费率(逐所独立请求,单所失败自动回退内置值;结果含 funding_source/funding_rate_ts/funding_pair 溯源字段) | |
| fundingPair | No | 资金费率合约对,默认 BTC/USDT 永续;仅 fundingMode=live 时生效,如 ETH/USDT、SOL-USDT | |
| fiatCurrency | No | 法币入金/出金币种,默认 USD(v0.26:可把年化法币通道费并入总成本) | |
| holdingHours | No | 持仓时长(小时),用于资金费率 | |
| tokenBalance | No | 持有的平台币数量(BNB / GT / KCS)。币安现货为 AND 门槛(不足降档);Gate OR GT 持仓、KuCoin OR KCS 持仓均可升档(不降档);同时用于平台币持仓折扣 | |
| tradeSizeUsd | No | 单笔吃单市价单规模(USD),默认不计执行成本。传入后总成本/年化/推荐会加上单边点差穿越成本(半价差);spreadMode=live 时再加上该规模下的订单簿滑点,如 10000=$1万、100000=$10万 | |
| withdrawalAsset | No | 提现资产,如 BTC, ETH, USDT | |
| accountAssetsUsd | No | 账户总资产(USD),适用于 OKX/Bybit/Bitget(30 日交易量 OR 账户资产取高定 VIP 档)与 Kraken(平台资产 AOP:Tier3 需 $20,000、Tier9 需 $100 万、Pro5 需 $1 亿;资产只升档不降档),如 $100,000 即 OKX VIP1 / Kraken Tier 9 | |
| withdrawalNetwork | No | 提现网络,如 TRC-20, ERC-20, Arbitrum | |
| fiatCashoutsPerYear | No | 每年法币出金次数;年化出金费=单次最便宜通道费×次数 | |
| fiatDepositsPerYear | No | 每年法币入金次数;年化入金费=单次最便宜通道费×次数 | |
| fiatCashoutAmountUsd | No | 单次法币出金(提现回银行卡)金额(USD);与 fiatCashoutsPerYear 同时传入时计入年化出金费 | |
| fiatDepositAmountUsd | No | 单次法币入金金额(USD);与 fiatDepositsPerYear 同时传入时,按该所最便宜直连通道计入年化入金费 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe, offline-computation profile is established. The description adds the scope of what gets combined and the required-vs-optional split, but discloses no failure/fallback behavior, no output ranking semantics, and no rate or auth considerations. With annotations carrying the safety burden, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The when-to-use condition is front-loaded, which is good. However the content is duplicated verbatim in Chinese and English, roughly doubling length with no new information per reader, and the sentence "This is the most comprehensive comparison tool" is unsupported boilerplate that does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 25-parameter tool with no output schema, the description covers the trigger, the three required inputs, and the optional families that change the result, which is enough to call it correctly. What is missing is any statement of what the ranked result contains or how the "best exchange" ranking is produced, which an agent presenting results would benefit from.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across all 25 params, so the schema already documents syntax, defaults, enums, and edge behavior. The description only gestures at a handful of them (holdingHours, useToken, fiat amounts, withdrawal details) without adding format or interpretation detail beyond the schema. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (compare total cost across exchanges) and enumerates the exact cost components folded in: trading fees, funding rates, withdrawal fees, spread, and optional fiat on/off-ramp fees. That enumeration implicitly separates it from narrower siblings (compare_exchange_fees, get_withdrawal_fees), though it never names an alternative and instead asserts "most comprehensive" as a self-claim rather than a differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering condition ("当用户要求比较不同交易所的真实总成本...时使用") and lists the prerequisites (purpose, country, monthly volume) plus optional inputs. It stops short of the 5 bar because it names no exclusions and no sibling alternative to route away to when only a partial cost comparison is wanted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_fee_tierARead-only
当用户想知道"我账户里实际生效的手续费率/我的真实 VIP 档位费率/API 查我的 maker taker/为什么我实际手续费和公开表不一样"时使用。Use a READ-ONLY exchange API key (apiKey + secret, OKX/KuCoin-Futures also need passphrase as password; Hyperliquid needs only the PUBLIC 0x wallet address as apiKey) to fetch the account's ACTUAL maker/taker fee for spot or futures, then compares it against this server's bundled public VIP schedule at the given monthly volume and shows the gap in bps. Credentials are used per request only, never cached, never logged (audit logs redact them). Always generate a READ-ONLY key (no trading/withdrawal permissions). Supported: Binance, OKX, Gate, Bybit, MEXC, Bitget, KuCoin (spot + kucoinfutures), Kraken (spot + krakenfutures), Coinbase (spot), Hyperliquid (wallet address), BingX, Bitstamp (spot); NOT supported by the bundled ccxt connector: Phemex, BloFin, Bitstamp perps. Country compliance/product gates are enforced before any authenticated call.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | 用于解析费率的交易对,默认 BTC/USDT(按所解析为现货或永续市场) | |
| apiKey | Yes | 只读 API Key;Hyperliquid 传公开钱包地址(0x…)。必须是只读权限,绝不要给交易/提币权限的 key | |
| secret | No | API Secret(Hyperliquid 钱包模式不需要;其他交易所必填) | |
| country | Yes | ISO 3166-1 alpha-2 居住国代码,如 US/DE/JP(合规与产品闸门先于鉴权调用) | |
| purpose | Yes | 交易类型: spot=现货, futures=合约/永续 | |
| exchange | Yes | 交易所 id:binance/okx/gate/bybit/mexc/bitget/kucoin/kraken/coinbase/hyperliquid/bingx/bitstamp | |
| password | No | API passphrase:OKX 必填;KuCoin Futures 使用合约 API 的 passphrase | |
| monthlyVolumeUsd | No | 月成交量(USD),仅用于选择内置公开费率表的对比档位,默认 0=入门档 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations: credentials used per request, never cached, never logged, audit logs redact them; a read-only key is mandated (no trading/withdrawal); Hyperliquid's wallet-address-as-apiKey mode is called out; and country compliance gates are enforced before any authenticated call. That is exactly the behavioral context an agent needs for a credential-bearing read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the when-to-use trigger, then the mechanics, then the supported/unsupported exchange inventory. The exchange list is long but functional rather than filler; some phrasing (repeating the read-only key requirement) could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter, credential-based tool with no output schema, the description covers intent, credential formats, exchange support boundaries, and compliance gating. The one thing it could add is return-value shape, but it does describe the meaningful output (the bps gap), leaving no material gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the prose adds real meaning: Hyperliquid needs only the public 0x wallet address as apiKey, OKX/KuCoin-Futures need passphrase as password, and monthlyVolumeUsd is only used to pick the comparison tier from the bundled table. Those cross-parameter interactions are not obvious from the individual property descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource: fetch the account's ACTUAL maker/taker fee for spot or futures, compare it against the bundled public VIP schedule at a given volume, and show the gap in bps. This is clearly distinguishable from siblings like compare_exchange_fees or get_execution_cost, which do not reconcile a personal account rate against a schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit user-intent trigger in Chinese ("why is my real fee different from the public table"), which is genuinely strong when-to-use guidance. It also documents which exchanges are supported and which are not, but never names a sibling tool as the alternative for the cases it doesn't cover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_data_sourcesARead-only
当用户质疑费率数据的来源、新鲜度或准确性时使用(例如:这个数据哪来的?费率多久更新一次?)。Use when the user asks where the fee data comes from, how fresh it is, or wants to verify accuracy. Returns per-file last-verified dates and source URLs (official exchange fee pages) plus caveats. No parameters required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it discloses the exact returned artifacts (verification dates, official exchange fee page URLs, caveats), which matters because no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is front-loaded with the trigger condition, which is good. However, the entire description is duplicated verbatim in Chinese and English, roughly doubling length without adding information for a single reader; that redundancy costs it a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only metadata tool this is nearly complete: it covers when to call, what is returned, and that no arguments are needed. Minor gap is that it doesn't describe the shape/volume of the response (e.g., whether it lists all tracked files), though the absence of an output schema is largely compensated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4. The description explicitly confirms 'No parameters required,' which correctly sets the agent's expectation and matches the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (retrieve data sources for fee data) and is unmistakably distinct from every sibling, which are all calculation/comparison tools. The return content (per-file last-verified dates, source URLs, caveats) is named, so an agent knows exactly what this produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger conditions with concrete example questions ('where does this data come from?', 'how often is it updated?'), which is strong usage guidance. It stops short of naming an alternative tool, but none of the siblings overlap with provenance lookup, so differentiation is effectively complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_execution_costARead-only
当用户询问买卖点差、滑点、订单簿深度、大单冲击成本、市价单实际成交成本、各所吃单执行成本对比时使用。Use when the user asks about bid-ask spread, slippage, order-book depth, market impact, or the real execution cost of a marketable order across exchanges. Returns per-exchange one-way execution cost in bps and USD for a specific order size (default $10,000): full spread, crossing cost (half spread), depth-walk slippage beyond the top level, total one-way cost, levels consumed, and fill status. spreadMode=bundled (default) uses offline typical-spread baselines by venue and pair class (majors/large-cap/mid-alt) instantly; spreadMode=live fetches the real top-100 order book per venue independently via ccxt and VWAP-walks it — failures fall back to bundled baselines (listed in failures), shallow books keep the measured cost with a warning. Spot requests use the spot market (e.g. kucoin rather than kucoinfutures). Requires country for compliance filtering unless exchanges are given explicitly.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | 交易对,默认 BTC/USDT;支持 ETH/USDT、SOL-USDT 等。山寨币点差按内置档位放大(mid-alt ×3),live 模式按真实订单簿 | |
| side | No | 方向,默认 buy;buy 吃卖盘、sell 吃买盘,live 时两侧深度可能不同 | |
| country | No | ISO 3166-1 alpha-2 国家代码;传入后按合规可用性过滤交易所(EEA 居民查 USDT 报价对会附稳定币区域可用性警告) | |
| purpose | No | 市场类型,默认 futures(永续);spot 自动解析各所现货市场与符号 | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| exchanges | No | 只查询指定交易所(如 ['binance','kraken']);默认返回全部 9 家(合约比较不含 Coinbase) | |
| spreadMode | No | bundled=内置典型点差基准(默认,秒回、零滑点);live=实时订单簿前100档 VWAP 行走,含真实滑点,单所失败回退 bundled 并记入 failures | |
| tradeSizeUsd | No | 单笔市价单规模(USD),默认 10000($1万)。滑点对规模高度敏感,大单务必传真实值,如 50000、250000 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says live mode 'fetches the real top-100 order book per venue independently via ccxt', which is external network access, while the annotations declare openWorldHint=false. That conflicts with the annotation's closed-world claim, so score 1 per the annotation-contradiction rule. The description otherwise adds useful behavioral detail about bundled vs live modes, fallback behavior, and spot-market routing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with usage triggers and then details return metrics and mode behavior in a structured way. It is longer than strictly necessary because the Chinese and English usage sentences duplicate the same trigger, though that duplication may be intentional for bilingual routing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema and only minimal annotations, the description is largely complete: it explains the returned cost components, mode fallbacks, warning behavior, spot-market routing, and the country/exchange interaction. It still does not fully describe every narrative output field implied by the language parameter (advice/warnings/tradeoffs/reasons), leaving a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, and the schema already documents each parameter thoroughly. The description adds valuable cross-parameter semantics, especially that country is required for compliance filtering 'unless exchanges are given explicitly', and it clarifies mode-dependent behavior for spreadMode and spot requests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns per-exchange one-way execution cost in bps and USD for a given order size, including spread, crossing cost, slippage, levels consumed, and fill status. It also names explicit user intents (bid-ask spread, slippage, order-book depth, market impact, execution-cost comparison), which lets an agent distinguish this from sibling tools like compare_exchange_fees or get_funding_rates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description has clear trigger conditions: '当用户询问... Use when the user asks about bid-ask spread, slippage...'. It does not, however, name when not to use this tool or explicitly contrast it with the many sibling alternatives (e.g. compare_total_cost, compare_exchange_fees).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fiat_costARead-only
当用户询问法币入金/出金成本、刷卡买币手续费、银行卡/信用卡充值费用、银行转账(SEPA/ACH/FPS/PIX/电汇 SWIFT/wire)哪个便宜、提现到银行卡实际到账多少时使用。Use when the user asks how much it costs to move fiat money INTO an exchange (deposit/buy crypto with card or bank transfer) or OUT to a bank account (cash out / withdraw fiat). Prices the direct, exchange-operated rails across venues: credit/debit cards (about 1.1% EU at Bybit to 4.5% at KuCoin; most venues have no card cash-out), US ACH (free at OKX and Kraken), EU SEPA (free deposits at OKX/Kraken/Bitget, about EUR 1 withdrawals; Gate charges 0.5%/1%), UK Faster Payments, Brazil PIX, and SWIFT/domestic wire (fixed USD 4-35 withdrawals). For every venue returns each available rail with fee in fiat AND USD, effective percentage, net amount that arrives, ETA and caveats, plus cheapest overall pick and saving vs the most expensive supported venue. Region/residency-aware: pass country so non-resident rails are filtered (SEPA is EU-only, ACH/wire US-only, FPS GB-only, PIX BR-only). Covers ONLY direct rails — third-party gateway quotes (Banxa/Simplex/MoonPay: 1.99%-5.5% at checkout) and zero-fee P2P (cost embedded in the quote spread) are excluded and called out in notes/advice.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | 法币金额(按 currency 单位,如 1000 欧元),默认 1000;与 amountUsd 二选一 | |
| method | No | 只看指定渠道:card=信用卡/借记卡,ach=美国 ACH,sepa=欧洲银行转账,fps=英国快速转账,wire=美国国内电汇,swift=国际电汇,pix=巴西即时支付 | |
| country | No | ISO 3166-1 alpha-2 居住国(如 US/DE/GB/BR/JP);同时用于通道地区过滤与交易所合规过滤 | |
| currency | No | 法币种类,默认 USD。EUR→SEPA 通道,GBP→FPS,BRL→PIX,USD→ACH/wire/卡 | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| amountUsd | No | 以美元计的金额,工具按内置展示汇率换算成所选法币;与 amount 二选一 | |
| direction | No | 资金方向:deposit=入金买币(默认),withdraw=卖出提现到银行账户 | |
| exchanges | No | 只查询指定交易所(如 ['kraken','okx']);默认返回全部 9 家(合约比较不含 Coinbase) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark it read-only/non-open-world; the description goes well beyond by disclosing the per-venue output shape (fee in fiat AND USD, effective %, net amount, ETA, caveats, cheapest pick, savings vs. priciest venue) and the region/residency filtering behavior driven by country. That is real behavioral context an agent cannot get from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries substantive information, but the definition is very long and duplicates its trigger phrasing bilingually (Chinese then English), which adds bulk without new meaning for an English-reading agent. It is front-loaded on usage, so it is adequate rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so fully: it enumerates the fields returned per rail, the comparative picks (cheapest overall, savings vs. most expensive), and the region-awareness behavior. Nothing an agent needs to invoke or interpret it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema does not: country is not just a locale but a filter that removes non-resident rails (SEPA EU-only, ACH/wire US-only, FPS GB-only, PIX BR-only), and currency determines which rail family applies. Rate detail (1.1%–4.5% cards, free ACH/SEPA deposits, fixed USD 4–35 wires) further grounds expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource (price fiat on/off-ramp costs across exchanges) and explicitly delimits scope: only direct, exchange-operated rails, with third-party gateways and P2P called out as excluded. An agent can distinguish it from siblings like get_withdrawal_fees or get_execution_cost without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with concrete trigger phrases (deposit/buy with card or bank, cash out/withdraw) and names the conditions that select alternatives by explicitly excluding Banxa/Simplex/MoonPay and P2P routes. When-to-use and when-not-to-use are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_funding_ratesARead-only
当用户询问资金费率、资金费、funding rate、当前持仓的资金成本、各交易所永续合约资金费对比时使用。Use when the user asks about perpetual futures funding rates across exchanges, or the current cost of holding a long/short. Returns per-exchange funding rate + settlement interval for a perpetual pair (default BTC/USDT). fundingMode=bundled (default) returns the offline long-run averages instantly; fundingMode=live fetches the real-time current rate from each venue independently via ccxt — venues that fail (timeout, geo-block, missing pair) fall back to the bundled average and are listed in failures, and every row is tagged with source/live timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166-1 alpha-2 国家代码;传入后按合规可用性过滤交易所 | |
| exchanges | No | 只查询指定交易所(如 ['binance','okx']);默认返回全部 9 家(合约比较不含 Coinbase) | |
| fundingMode | No | bundled=内置长期均值(默认,0.01%/8h,离线秒回);live=实时拉取当前资金费率(逐所容错,失败回退内置值) | |
| fundingPair | No | 永续合约对,默认 BTC/USDT;也支持 ETH/USDT、SOL-USDT、BTCUSD 等写法 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds substantial behavior beyond them: per-venue independent fetching via ccxt, graceful fallback to the bundled average on timeout/geo-block/missing pair, a 'failures' list, and per-row source/live timestamp tags. This is exactly the operational detail an agent needs to interpret partial results. The only mild tension is that live mode reaches out to external venues while openWorldHint=false, but the stated default is offline and the description discloses the network behavior explicitly, so it is not a contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is front-loaded with the trigger condition and then the return/mode semantics, and every sentence carries information. The bilingual Chinese/English duplication roughly doubles the length, which is functional for language matching but is not strictly earning its place in a single-locale reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-shape burden and does so: per-exchange rate plus settlement interval, default pair, source/live timestamp tagging, and a failures list for venues that could not be reached. Combined with the annotations, an agent has everything needed to call and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 and the schema already documents country, exchanges, fundingMode and fundingPair. The description goes further by explaining that bundled is instant/offline versus live being real-time with fallback, and that the default pair is BTC/USDT — semantics that make the enum choice actionable rather than merely defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: it returns per-exchange funding rates plus settlement interval for a perpetual pair, with BTC/USDT as the default. It also frames the user intent ('perpetual futures funding rates across exchanges, or the current cost of holding a long/short'), which lets an agent distinguish it from the fee/cost siblings such as compare_exchange_fees or get_execution_cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit trigger conditions ('Use when the user asks about perpetual futures funding rates...'), which is strong when-to-use guidance. It also clarifies the bundled vs live mode tradeoff so the agent can pick correctly. It never names an alternative sibling tool or a when-not-to-use case, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_referral_linkARead-only
当用户要求获取某个加密货币交易所的优惠注册链接、推荐码或返佣链接时使用。Use when the user asks for a discount registration link, referral code, or rebate link for a specific crypto exchange. Returns the referral URL with the fee discount the user will receive. Supports Binance, OKX, Gate.io. Requires exchange name and country code.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ISO 3166-1 alpha-2 国家代码 | |
| exchange | Yes | 交易所名称,如 binance, okx, gate |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds real behavioral context beyond them: it returns the referral URL plus the fee discount the user will receive, and it defines the supported exchange universe and the required inputs. It omits failure behavior for unsupported exchanges, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger condition is front-loaded, which is good, but the entire content is stated twice (Chinese then English) with no added information in the second pass — pure duplication. Still short overall, so not wasteful enough to drop below 3.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return burden and does so: it states the returned referral URL and the fee-discount information. Inputs and supported range are covered. Missing only edge-case behavior for unsupported exchanges/country codes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so 3 is the baseline. The description adds value over the schema by enumerating the supported exchange values (Binance, OKX, Gate.io), which constrains the otherwise free-form 'exchange' string, and by reinforcing that both inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: fetch a referral/rebate registration link for a named crypto exchange, with the supported exchange set (Binance, OKX, Gate.io) stated. An agent can distinguish this from cost-analysis siblings like compare_exchange_fees or calculate_savings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger condition ('when the user asks for a discount registration link, referral code, or rebate link') and scopes it to 'a specific crypto exchange'. It does not name an alternative sibling or state when NOT to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stablecoin_accessARead-only
当用户问"USDT/Tether/稳定币在我的国家(尤其欧洲/EEA/欧盟)还能不能交易、买卖、提币?哪些交易所下架了 USDT?MiCA 合规稳定币有哪些(USDC/EURC/EURI/EURCV/USDQ)?Revolut 的 USDT 怎么办?"时使用。Returns the MiCA regional access status of a stablecoin (default USDT): issuer + MiCA EMT authorization status, whether venue trading is barred in the resident's region (USDT: unavailable across all 30 EEA states after the 2026-07-01 CASP cliff), custody/withdrawal and self-custody rights (holding and on-chain withdrawal stay legal; the restriction binds venues, not people), a per-venue table (delisted with date / never_offered / venue_blocked; scope eea vs global; whether the venue itself serves the country), compliant alternatives and localized advice. CH and GB are NOT in the EEA region. Without a country, global/asset-level status is returned. Also auto-injected as STABLECOIN_UNAVAILABLE_IN_REGION warnings into fee/withdrawal/execution/persona tools for USDT-quoted requests from EEA residents.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | 稳定币符号,默认 USDT;已建模:USDT、USDC、EURC、EURI、EURCV、USDQ、EURQ | |
| country | No | ISO 3166-1 alpha-2 居住国代码,如 DE/FR/NL/US/GB/CH;不传则返回全球/资产级状态,场馆行只含全球策略 | |
| exchange | No | 可选:只看单个交易所(场馆 id,如 coinbase/bison/binance),仍按居住国判定适用性 | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond read-only annotations by disclosing the 2026-07-01 CASP cliff, that restrictions bind venues not people, self-custody rights, and default behaviors (global status without country). It also notes auto-injection of warnings into other tools. This adds substantial context but doesn't detail rate limits or auth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and front-loads a verbose Chinese query pattern before stating the tool's function. The core purpose is buried after a list of user questions, making it hard to parse quickly. It could be significantly trimmed without losing key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of MiCA regulations and the lack of an output schema, the description provides necessary context on return values, default behavior, and regional nuances. It covers what the tool returns and how it interacts with other tools, though it could be more structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains asset, country, exchange, and language thoroughly. The description adds minor context about default asset (USDT) and country omission, but largely repeats what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns MiCA regional access status for a stablecoin, enumerating specific outputs like issuer authorization, venue trading restrictions, and alternatives. However, the Chinese preamble (a long user-query pattern) is verbose and the core purpose doesn't cleanly distinguish from siblings like compare_countries or get_withdrawal_fees that might also touch on regional rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese text gives example user questions (trading USDT, MiCA compliance, Revolut), implying usage context, but there is no explicit 'when to use this vs alternatives' instruction. The mention of auto-injection into other tools is helpful but not framed as a call guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_withdrawal_feesARead-only
当用户询问提币手续费、转出/提现到钱包或其他交易所哪个网络便宜、USDT/USDC 走 TRC-20/ERC-20/BEP20/Arbitrum/Optimism/Base/Polygon/Solana/Avalanche 各要多少、某交易所是否支持某链、BTC/ETH/SOL/XRP/DOGE 等原生币提币费、链上转账费对比时使用。Use when the user asks which exchange has the cheapest crypto withdrawal / network fee for an asset on a given chain, whether a venue supports a network, or wants to compare on-chain transfer costs before moving coins to a wallet or another exchange. Returns every supported route per venue with the fee in native units AND USD (converted from a dated price snapshot), marks wallets currently suspended, names each venue's cheapest open route, and ranks venues with an overall best pick plus saving vs the most expensive one. Covers 16 assets (BTC, ETH, USDT, USDC, SOL, XRP, DOGE, LTC, TRX, ADA, AVAX, DOT, LINK, BCH, TON, POL) across Tron/Ethereum/BSC/Arbitrum/Optimism/Base/Polygon/Avalanche/Solana/Ton/native chains at all venues with routes (Coinbase only lists BTC/ETH/USDT/USDC — dynamic network-fee estimates). Fees are exchange-charged, pass-through on-chain costs (Kraken/KuCoin dynamic), not trading fees — for the all-in cost of a trade use compare_total_cost instead.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | 资产符号,默认 USDT。支持:BTC/ETH/USDT/USDC/SOL/XRP/DOGE/LTC/TRX/ADA/AVAX/DOT/LINK/BCH/TON/POL | |
| country | No | ISO 3166-1 alpha-2 国家代码;传入后按合规可用性过滤交易所(如 US 只剩 okx/gate/kraken) | |
| network | No | 只看指定网络并接受常见别名:TRC-20(trc20/tron)、ERC-20(erc20/ethereum)、BEP20(bsc)、Arbitrum(arb)、Optimism(op)、Base、Polygon(matic)、Avalanche C(avax/c-chain)、Solana(sol)、TON、AssetHub 等;省略则返回该资产全部网络 | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| exchanges | No | 只查询指定交易所(如 ['binance','okx']);默认返回全部 9 家(合约比较不含 Coinbase) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only assert readOnlyHint=true and openWorldHint=false. The description adds substantive behavior: per-venue route listing, fees in native units AND USD from a dated price snapshot, suspended-wallet marking, cheapest-open-route naming, venue ranking with a best pick and savings figure, plus the critical semantic that fees are exchange-charged pass-through costs (dynamic at Kraken/KuCoin) rather than trading fees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads trigger conditions before capabilities, which is the right ordering for retrieval. It is long, and the Chinese/English duplication roughly doubles the length, but each block serves a distinct audience and no sentence is pure padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still specifies what is returned (routes per venue, native and USD fees, suspensions, cheapest route, ranked venues with a best pick and savings). Combined with the fee-semantics caveat and the sibling handoff, an agent has everything needed to call and interpret this read-only lookup correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents asset, country, network, language and exchanges in detail, including network aliases and the language enum's limited scope. The description largely restates the covered asset and network lists, adding only the note that Coinbase lists just BTC/ETH/USDT/USDC with dynamic fee estimates — a minor increment over structured data, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (withdrawal fees) and enumerates the exact questions it answers — cheapest network, per-asset per-chain fees, venue network support, on-chain transfer cost comparison. It explicitly distinguishes itself from compare_total_cost, which covers the all-in cost of a trade, so an agent can separate it from siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use triggers in two languages (moving coins to a wallet or another exchange, comparing on-chain costs) and names the alternative tool plus the condition that selects it ('for the all-in cost of a trade use compare_total_cost instead'). This is explicit routing, not implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_exchangeARead-only
当用户不确定选哪个交易所、希望根据自身情况获得个性化推荐时使用。Use when the user wants a personalized exchange recommendation based on their trading volume, style, and holding habits. Scores available exchanges on weighted fees (maker/taker blend), token discounts, referral discounts, funding cost for futures, and (v0.27) the user's direct fiat deposit/cash-out habit — small monthly card/SEPA on-rampers get ranked on fiat rails too (the fiat weight grows 0.2→0.5 as venue-to-venue fiat-fee differences dominate trading-fee differences, and venues with no direct rail score zero on that leg rather than winning on an unpriced cost). Returns the best option with score, concrete reasons, tradeoffs, and actionable advice, plus ranked alternatives. Requires purpose, country, and volume.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | 交易对,如 BTC/USDT、BTC/FDUSD、BTCUSDT 均可。命中币对级费率/0费促销时按促销价计费,未命中则按整所 VIP 档计费 | |
| side | No | 吃单方向,默认 buy;live 模式下 buy 行走卖盘 asks,sell 行走买盘 bids | |
| volume | Yes | 月交易量,USDT | |
| country | Yes | ISO 3166-1 alpha-2 国家代码 | |
| purpose | Yes | 交易类型 | |
| currency | No | 显示币种,默认 USD;汇率仅用于展示 | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| useToken | No | 是否持有并使用平台币(BNB/OKB/GT/MX/BGB/KCS)折扣 | |
| fiatMethod | No | 只按指定法币渠道评分(默认取最便宜):card/ach/sepa/fps/wire/swift/pix | |
| makerShare | No | 挂单(maker)成交占比 0-1,默认 0=纯吃单。限价交易者设 0.7-1 | |
| spreadMode | No | 执行成本来源:bundled=内置典型点差基准(默认,半价差、零滑点,离线秒回);live=实时拉取订单簿前100档逐档行走,算出真实半价差+市场冲击滑点(逐所独立请求,单所失败自动回退内置基准并记入 failures,深度不足保留实测值并给 warning)。需配合 tradeSizeUsd 才会计入 | |
| spreadPair | No | 执行成本测算交易对,默认沿用 pair,再默认 BTC/USDT。live 模式现货自动解析现货市场(如 KuCoin 用 kucoin 而非 kucoinfutures),如 ETH/USDT、SOL-USDT | |
| fundingMode | No | 资金费率来源:bundled=内置长期均值(默认,离线稳定);live=实时拉取该合约当前资金费率(逐所独立请求,单所失败自动回退内置值;结果含 funding_source/funding_rate_ts/funding_pair 溯源字段) | |
| fundingPair | No | 资金费率合约对,默认 BTC/USDT 永续;仅 fundingMode=live 时生效,如 ETH/USDT、SOL-USDT | |
| fiatCurrency | No | 法币入金/出金币种,默认 USD(v0.27:传入入金/出金习惯后,推荐评分会纳入法币通道成本,小额刷卡/定投用户尤其重要) | |
| holdingHours | No | 期货平均持仓时长(小时),用于资金费率评分 | |
| tokenBalance | No | 持有的平台币数量(BNB / GT / KCS)。币安现货 AND 门槛(不足降档);Gate OR GT、KuCoin OR KCS 均可升档(不降档);用于实际 VIP 档位与平台币持仓折扣,不传会提示持仓影响 | |
| tradeSizeUsd | No | 单笔吃单市价单规模(USD),默认不计执行成本。传入后总成本/年化/推荐会加上单边点差穿越成本(半价差);spreadMode=live 时再加上该规模下的订单簿滑点,如 10000=$1万、100000=$10万 | |
| accountAssetsUsd | No | 账户总资产(USD):OKX/Bybit/Bitget 按交易量 OR 账户资产取高定 VIP 档(如 $100,000 即 VIP1,$5 亿达 VIP9 负 maker);Kraken 按 AOP 定档($20,000 升 Tier3)。不传会提示资产升档路径 | |
| fiatCashoutsPerYear | No | 每年法币出金次数;无直连通道的所该腿得 0 分,不会因成本未计而虚高 | |
| fiatDepositsPerYear | No | 每年法币入金次数,如月薪/定投 12;法币费在各所差异越大,评分权重越高(0.2-0.5) | |
| fiatCashoutAmountUsd | No | 单次法币出金(提现回银行卡)金额(USD);与 fiatCashoutsPerYear 同时传入时纳入评分 | |
| fiatDepositAmountUsd | No | 单次法币入金金额(USD);与 fiatDepositsPerYear 同时传入时,推荐评分纳入年化入金通道费 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the annotations (readOnlyHint/openWorldHint), which only cover the safety profile. It discloses the scoring model (weighted maker/taker fees, token and referral discounts, futures funding cost, fiat rails), the dynamic fiat weight growth 0.2→0.5, the zero-score penalty for venues lacking a direct rail, and the required inputs — exactly the behavioral context an agent needs to trust and interpret the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the usage trigger, then the methodology and return shape, so the important content comes first. However, the bilingual duplication of the trigger sentence and the embedded version annotation ('v0.27') add length that is not strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by describing the return payload (score, reasons, tradeoffs, advice, ranked alternatives). Combined with full schema coverage for 23 parameters, an agent has everything needed to invoke and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across 23 well-documented parameters, so the schema already carries parameter meaning. The description only restates the required set (purpose, country, volume) and sketches the factors (volume, style, holding habits) without adding syntax or format detail beyond the schema — the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource (recommend an exchange) and explicitly scopes the output: best option with score, concrete reasons, tradeoffs, actionable advice, plus ranked alternatives. This clearly separates it from sibling calculators like compare_total_cost and compare_exchange_fees, which produce comparisons rather than a personalized pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening sentence gives an explicit trigger: use when the user is unsure which exchange to pick and wants a personalized recommendation based on their volume, style, and holding habits. It stops short of naming specific alternative siblings (e.g. use compare_total_cost for raw side-by-side numbers), so there is no explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
volume_what_ifARead-only
当用户问"月交易量达到 X 手续费多少/如果成交量增长到不同水平呢/再刷多少量能升 VIP 档省钱/各交易所档位跳变点",或要看一条跨成交量的费率-成本曲线时使用。Use for volume what-if / sensitivity analysis: scans monthly trading volume from zero up through the VIP ladder for spot OR futures across EVERY venue allowed in the country, returning (1) per-volume-point cross-venue ranking with the cheapest venue and its annual trading fee, (2) per-venue sweep curves with tier/maker/taker/weighted fee at each point, (3) the exact tier-crossing list (at which volume each venue moves to which rung), and when baseVolume is given, (4) each venue's next volume rung, how much MORE monthly volume it needs, and the USD/year it would save at the caller's current volume (holding-gated rungs like Binance spot's BNB requirement are explicitly flagged as unreachable by volume alone). Sweep points default to the union of every venue's tier thresholds (sampled if >16); pass explicit volumes for custom points. Applies referral discounts and the optional platform-token toggle exactly like compare_exchange_fees. Trading fees only — funding, spread, withdrawals and fiat are not included (use compare_total_cost for the full stack).
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | 特定交易对(如 BTC/USDT、FDUSD、USDC)以适用交易对专属费率活动;默认账户档位费率 | |
| format | No | 矩阵渲染格式:json=仅结构化 JSON(默认,行为不变);markdown=在结果中额外附 rendered.markdown 可直接粘贴的表格;csv=附 rendered.csv(CRLF、RFC4180 转义,可导入 Excel);both=两者都附 | |
| country | Yes | ISO 3166-1 alpha-2 居住国代码,如 US/CN/JP/GB/DE/BR | |
| purpose | Yes | 交易类型:spot 现货 / futures 合约 | |
| volumes | No | 自定义扫描点(月成交量 USD 数组,最多 24 个,自动去重排序)。不传则默认取所有交易所档位阈值的并集(超过 16 个时全区间抽样并给出警告) | |
| currency | No | 显示币种,默认 USD | |
| language | No | 输出语言:en=英文(默认),zh=中文。仅影响 advice/warnings/tradeoffs/reasons 等叙述性文字,数值、字段名与错误码不受影响 | |
| useToken | No | 是否开启平台币抵扣/折扣(BNB/MX/BGB/GT/KCS/HYPE/PT 等),默认 false | |
| baseVolume | No | 你当前的 30 天成交量(USD)。提供后会返回精确的"下一 VIP 档还需多少量、当前量下一年省多少"建议,并保证该点出现在扫描中 | |
| makerShare | No | Maker 成交占比 0-1,默认 0.4;用于 maker/taker 加权费率 | |
| tableMetric | No | format 非 json 时表格的指标列:weighted_fee_pct=加权费率%(默认) / annual_fee_usd=年化交易费 / tier=生效档位名 | |
| tokenBalance | No | 平台币持仓数量(BNB/GT/KCS 枚数,或 MX/HYPE 等的枚数);影响 AND/OR 档位与持仓折扣 | |
| accountAssetsUsd | No | 账户总资产 USD(OKX/Bybit/Bitget/Kraken 等的资产升档通道) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, but the description goes well beyond them: it enumerates the four return blocks, discloses that holding-gated rungs (e.g. Binance spot BNB requirement) are flagged as unreachable by volume alone, and notes referral discounts and the platform-token toggle are applied. It also discloses sampling behavior and a warning at >16 points.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with when-to-use, then the numbered output enumeration keeps the returns easy to scan. However, the bilingual Chinese/English pair largely restates the same content, which adds length without adding information for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with no output schema, the description fully compensates by describing the return shape in four numbered blocks and the default sweep construction. An agent has enough to call it correctly and interpret the results without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already carries per-parameter meaning; baseline would be 3. The description adds semantic ties the schema omits, notably that referral/token discounts are applied 'exactly like compare_exchange_fees' and that baseVolume guarantees the point appears in the sweep, giving cross-tool consistency context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific operation (scan monthly volume from zero through the VIP ladder) and a specific output (fee-cost sensitivity curve) for spot OR futures across every allowed venue. It distinguishes itself from siblings by explicitly naming compare_total_cost for the full cost stack and compare_exchange_fees as the discount-model analog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with concrete user question triggers (fee at volume X, growth scenarios, VIP upgrade, tier jump points, cross-volume curves) in both Chinese and English, then specifies when to pass explicit volumes vs rely on the default union-of-thresholds sampling. It also states the scope boundary and the alternative tool to use outside it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
19 tool updates
v0.47.1- First observed
analyze_persona - First observed
analyze_token_discount - First observed
calculate_annual_cost - First observed
calculate_savings - First observed
compare_countries - First observed
compare_exchange_fees - First observed
compare_interface_costs - First observed
compare_personas - First observed
compare_total_cost - First observed
get_account_fee_tier - First observed
get_data_sources - First observed
get_execution_cost - First observed
get_fiat_cost - First observed
get_funding_rates - First observed
get_referral_link - First observed
get_stablecoin_access - First observed
get_withdrawal_fees - First observed
recommend_exchange - First observed
volume_what_if
TDQS
Scored across 19 tools
There is a large cluster of heavily overlapping 'compute a cross-venue cost' tools—compare_exchange_fees, compare_total_cost, calculate_annual_cost, calculate_savings, recommend_exchange, analyze_persona, compare_personas, compare_countries, and volume_what_if all return ranked fee comparisons with only subtly different lenses. The descriptions do cross-reference each other (e.g. 'for the all-in cost of a trade use compare_total_cost instead'), which helps, but an agent asked a generic 'which exchange is cheapest' question faces genuine selection ambiguity.
Nearly all tools follow a consistent snake_case verb_noun pattern (calculate_savings, compare_total_cost, get_funding_rates, analyze_persona, recommend_exchange). The only outlier is volume_what_if, which drops the verb prefix, but the set is otherwise predictable and readable.
At 19 tools the surface is on the heavy side for a fee-optimization server, and several tools appear consolidatable (e.g. compare_exchange_fees / compare_total_cost / calculate_annual_cost are variants of the same comparison). The breadth of the domain (multi-exchange, multi-cost-leg, personas, countries) justifies many of them, but 19 is borderline.
Coverage of the fee-optimization domain is exceptionally thorough: trading fees, funding rates, execution/spread, withdrawal fees, fiat on/off-ramps, token discounts, consumer-interface markups, stablecoin regional access, API-verified account tiers, referral links, data provenance, plus persona/country and what-if analysis. No obvious operational gaps or dead ends for the stated purpose.
Maintenance
Related MCP Connectors
Live crypto prices, conversion, gas tracker, portfolio tools, and calculators for AI agents.
Crypto yield data for AI agents: lending, savings, staking, borrowing & stablecoin rates. 18 tools.
AI agent access to Asian crypto markets. Korean exchange routing and x402 paid APIs.
Crypto trading intelligence MCP — 34+ endpoints, x402 pay-per-use, AI agent strategy & execution
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides live cryptocurrency market data from over 100 exchanges, enabling AI agents to fetch prices, order books, funding rates, and more for trading analysis and arbitrage opportunities.132MIT
- FlicenseAqualityDmaintenanceEnables AI agents to compare AI model pricing plans, run cost scenarios, find break-even points, and get plan recommendations using TokenLens data.4-
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to calculate, compare, and recommend AI API costs from multiple providers, with support for currency conversion and platform fee analysis.1MIT
- AlicenseAqualityCmaintenanceEnables AI agents to fetch real-time exchange trading fees, compare rebate-adjusted costs, obtain referral links, calculate trading costs, and identify compliant exchanges for crypto trading.684 npmMIT