Qmax MCP Server

Install Qmax MCP server

claude mcp add --transport http qmax-profitphil https://qmax.exchange/api/mcp

{
  "mcpServers": {
    "qmax-profitphil": {
      "url": "https://qmax.exchange/api/mcp"
    }
  }
}

{
  "mcpServers": {
    "qmax-profitphil": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://qmax.exchange/api/mcp"
      ]
    }
  }
}

{
  "servers": {
    "qmax-profitphil": {
      "type": "http",
      "url": "https://qmax.exchange/api/mcp"
    }
  }
}

{
  "mcpServers": {
    "qmax-profitphil": {
      "serverUrl": "https://qmax.exchange/api/mcp"
    }
  }
}

Context tax

Connecting this server adds ~5,364 tokens of tool definitions to every model turn (heavy, 19 tools). Measured 2026-10-19 via its hosted endpoint; o200k tokenizer, worst case for clients that load all tools up front. How we measure

Input prices as of 2026-10-06. Excludes your own prompt and output.

Tools (19)

• qmax_backtest637 tok

  Replays a strategy over real hourly trade data with the venues' real fees and reports what it would have done: final value, return, buy-and-hold comparison, max drawdown, fees paid, trades. Decisions are made on an hour's close and filled at the next hour's open; hours with no trades cannot be traded. Strategies: 'hold' (buy once, hold), 'dca' (spend amountQu every everyHours), 'bands' (buy fractionPct of the QU when the price is bandPct below its lookbackHours average, sell fractionPct of the holding when above, with a cooldown). READ 'warnings' in the result: there is no order book depth in

• qmax_build_plan438 tok

  Quotes an order and returns the exact transactions a wallet must sign to carry it out, in order. QMax signs nothing and sends nothing: you (or the user) sign each step with your own wallet and broadcast it. Steps (in order): any share-management move needed first (selling shares that the other market manages), then one call per market. Each step: kind, description, destination (a smart contract by index), inputType (procedure number), amountQu to attach (QU that may leave the wallet; unused QU is refunded by the contracts) and payloadBase64 (the call's input bytes). 'maxOutlayQu' is the most

• qmax_get_candles412 tok

  Open, high, low, close, QU volume, units and trade count per candle, built from every trade QX and QSwap logged (a minute wide at the finest; about six months back, which is all the Qubic archive has: its trade records begin in April 2026). A candle exists only where something traded, so a gap means no trades. The response also gives the last 24 hours of volume across both markets. Returns: { asset, range, interval, venue, candles: [{ t (ms), o, h, l, c, volumeQu, volumeQty, trades }], truncated?, available?, volume24hQu, trades24h }. Prices are QU per unit.

• qmax_swap_quote386 tok

  Plans swapping one token for another as two linked trades: sell 'from' for QU (leg 1), then buy 'to' with the QU (leg 2), each routed across QX and QSwap by the best route. Read-only: nothing is signed. Returns both quotes, 'upfrontQu' (QU the wallet must hold BEFORE leg 1 for its flat fees), 'expectedOutQty' (what you should get) and 'minOutQty' (guaranteed by the limits only if neither price moves past the slippage limit), plus warnings. Leg 2 can only be sized exactly after leg 1 settles, from the wallet's real balance, so a swap is never one atomic transaction: if leg 1 completes and leg

• qmax_get_quote306 tok

  Prices an order and finds the cheapest route across the QX order book and the QSwap pool, splitting the order across both when that is cheaper. Nothing is placed. Returns the total in QU, the average price, each leg (venue, quantity, price range, fees, price impact), what each single market alone would cost, a plain-English line saying what the routing saved, and warnings. All amounts are QU; quantities are whole units. The quote is a snapshot: prices move, so re-quote before acting.

• qmax_check_arbitrage265 tok

  Searches, live and at full depth, for a profitable buy-on-one-market, sell-on-the-other loop after every venue fee, and returns the most profitable size or null. It is two separate transactions, so the second leg can fill worse than shown; this is a snapshot, not a guarantee. Only assets on both markets can have one. A found result may be billed to the caller's QMax key (50 QU).

• qmax_venue_premium263 tok

  Hour by hour, the gap between the asset's QX and QSwap prices (positive = QSwap dearer) and how often it was wider than the trading costs for a trade of 'reference_qu'. This is an UPPER BOUND on arbitrage, not a profit: it uses hourly average prices, so it leaves out the QX bid-ask spread (often wider than the costs) and the delay between the two transactions. Returns { bothVenues, breakEvenPct, points, summary, note }.

• qmax_get_health251 tok

  A 0 to 100 score and A to E grade for an asset, from its QX order book, its QSwap pool and six months of trades, with flags and plain-English reasons (most important first). Flags include thin-book, wide-spread, quiet, few-trades, new-listing, volume-spike, one-sided, pool-dominated and wash-suspected / bot-burst (a single wallet churning tiny same-size swaps against itself, which inflates trade counts but not volume). Many assets grade D or E because QX markets are thin: that is information, not an error. It is an automated estimate from public data and NOT advice; the absence of 'wash-suspe

• qmax_get_wallet_ledger246 tok

  Every QX and QSwap buy and sell a wallet made (read from public on-chain transfers, so any 60-letter identity works): price, QU net of fees, estimated fees, running position, and average-cost realized profit, plus current positions with unrealized profit and loss. ESTIMATED. Read 'warnings' and 'truncated': the archive has no events for about 10 to 14 June 2026, units that arrived before the window or by transfer have no known cost (selling them is not counted as profit), and QSwap liquidity changes appear as transfers. Unrealized P&L uses the mid or pool price, which can mislead on thin mark

• qmax_get_tape240 tok

  The most recent trades on both markets in one feed, newest first: time, market, asset, quantity, QU, price and direction. The direction is the TAKER's side (the person who started the trade): 'buy' or 'sell'. Rows also carry the transaction hash. The answer includes 'flow24h', the last 24 hours of buy versus sell volume, and 'latestId': pass it back as 'since' to get only newer trades. Served from memory, so cheap to poll.

• qmax_get_sellers236 tok

  For the last 7 days: the wallets that sold the asset on QX or QSwap, how long each had held the units (each unit sold is matched, first in first out, to the purchase it came from), what they paid and whether they sold above or below that, with a plain-language reading ("what the numbers say"). Read from the public Qubic archive, so the first call for an asset starts the reading and answers status "working" with its progress and what is known so far: call again in 30 to 60 seconds until status is "ready" (a reading takes a minute or two and is kept for six hours). The chain shows who sold and w

• qmax_get_liquidity_positions228 tok

  Every QSwap pool a wallet has liquidity in (public chain data, so any 60-letter identity works): its liquidity units, share of the pool, what removing it all would pay (QU and tokens, before QSwap's flat 100,000 QU fee) and its value in QU at the pool's own price, read live from the contract. Read-only. Adding or removing liquidity is done in the QMax app with a wallet; this tool never builds or signs one. Check 'complete': when false, a pool could not be read and its positions are missing. 'earnedFeesQu' is already inside what removing pays, nothing pays it separately. Values are estimates a

• qmax_get_price_history217 tok

  The asset's price over time as points (ms timestamp, price in QU, and for recently recorded points the best bid, ask and pool price). Points before 'recordedSince' were rebuilt from past trades as hourly volume-weighted averages (marked src 'trades'); after it QMax recorded the price about every 10 minutes. Use qmax_get_candles for OHLC and volume.

• qmax_list_assets216 tok

  Lists assets that trade on QX and/or QSwap, most liquid first, or searches by symbol. Use this first to find the right asset symbol and to see which markets it trades on ('QX', 'QSwap' or both: only assets on both can be split for a better price). Returns: { count, assets: [{ id, symbol, category ('contract' shares or 'token'), venues, priceQu, liquidityQu, activity }] }. Prices are QU per unit.

• qmax_pool_detail193 tok

  One pool's numbers explained, and for a deposit size (position_qu, the QU value of both sides together) an estimate of fees per day, per 30 days and the impermanent loss for price moves of 10%, 25% and 50%. Adding and removing liquidity each cost a flat 100,000 QU.

• qmax_get_order_book192 tok

  What is resting on the QX order book (grouped by price, with cumulative size and cost from the best price outward, best bid/ask, spread) and the QSwap pool (reserves, price, and how far trades of 0.1% to 5% of the pool would move the price). Use it to judge depth before sizing an order.

• qmax_get_flow174 tok

  Buy and sell volume (QU and units), trade counts and net pressure (positive = more buying) over the last hour or 24 hours, for one asset or the whole market. Direction is the taker's side. 'partial' is true while the server is still loading the window.

• qmax_list_pools172 tok

  Every QSwap liquidity pool with its TVL, trailing swap volume, estimated fee APR (from real swap volume; only 0.192% of each swap's volume reaches liquidity providers), price change and impermanent loss over the window. A trailing estimate: past fees do not predict future fees, and volume that looks inflated (wash trading) is flagged in each pool's notes.

• qmax_get_liquidity_pool147 tok

  A QSwap pool's reserves (QU and tokens), total liquidity units and price, read from the contract. Use it to see how deep a pool is before talking about providing liquidity. Adding or removing liquidity each cost a flat 100,000 QU on top of any deposit. Read-only.

Security signals

92/100 — no known issues found as of 2026-10-19, from the checks below. This is not a guarantee of safety; review what a server can do before connecting it.

Scan it yourself before installing with vectra-guard, the open-source agent security CLI. Scoring rules

Freshness

Active — last maintenance signal 1d ago. The newest of the signals below sets the band.

1. Last commit (default branch)

   2026-10-17 · 1d ago · GitHub

2. Latest release

   no data · GitHub

3. Package published

   no data · npm/PyPI

4. Registry entry updated

   2026-10-17 · 1d ago · official registry · v1.0.0