Buildix runs a public Model Context Protocol server, so an AI agent can read live Hyperliquid orderflow analytics the same way you read them in the app. Point Claude, Cursor, ChatGPT or any MCP client at one URL and the model gets seven read-only tools: the screener, one pair in detail, current orderflow signals, smart money positioning, the liquidation map, the HIP-4 edge engine and the CVD time series. Each tool sits at the same plan as its REST equivalent, so there is one answer to what a plan includes whichever protocol you speak.
https://www.buildix.trade/api/mcp
JSON-RPC over POST. Server-sent events are disabled, so there is no session to keep alive and no Redis in the path. Every tool is read-only: nothing on this server places an order or moves funds.
get_screenerOPENinput: noneEvery tradable Hyperliquid perpetual with mark price, 24h change, 24h volume, open interest in USD and funding, both raw and annualized. The starting point for universe scans, top movers, funding extremes and open interest leaders.
get_pairOPENinput: symbol: string, for example "BTC"One pair in detail: mark price, oracle price, 24h change, 24h volume, open interest, funding raw and annualized, max leverage and size decimals, plus a deepViewUrl into the Buildix orderflow workspace.
get_signalsTRADERinput: noneCurrent actionable signals from the Buildix V5 and V6 orderflow engines across all pairs. Each entry carries direction, a signed score, confidence on a 0 to 100 scale, the detected regime, the components that passed their gate and up to six reasons.
get_smart_moneyPROinput: noneThe top whale wallets on Hyperliquid by recent trading volume, their open positions and the aggregated long or short bias per coin. Cached server side for two minutes.
get_liquidation_mapWHALEinput: symbol: string, price_range_pct?: 1 to 20, scenarios?: number[]On-chain liquidation clusters around the mark for one symbol, with the estimated size in USD at each price level, plus cascade scenarios projecting the notional liquidated on moves of N percent. HIP-3 markets are addressed as "<dex>:<COIN>", for example "xyz:BRENTOIL".
get_hip4_edgeWHALEinput: underlying?: string, min_abs_divergence?: 0 to 1, edge_flag?: enum, limit?: numberActive HIP-4 outcome markets ranked by the gap between model and market. Each row carries implied probability, model fair probability, divergence, an edge_score that blends the absolute divergence with the V5 orderflow signal on the underlying perp, and an edge_flag of confirmed, contradicted, neutral, no_signal or no_divergence. A consistency_flag appears when bucket sums or binary versus bucket parity breach the 4 percent no-arbitrage band.
get_cvdWHALEinput: symbol: string, interval?: "5m" | "15m" | "1h", lookback?: numberCumulative volume delta for one pair as a time series. Every bucket carries buy_usd, sell_usd, delta, a running cvd and the trade count. The delta is computed on a sample of the tape, a rolling buffer of roughly 300 fills per symbol, so read it as a directional measure and as the basis for price versus CVD divergence work, never as absolute traded volume. The payload repeats that caveat in sampling_note and reports the real coverage_minutes for the symbol.
Generate a key in your Dashboard, API Keys. A Buildix key is bx_ followed by 32 hex characters, with no live or test split. Pass it on every MCP request, in either header:
Authorization: Bearer bx_0123456789abcdef0123456789abcdef x-api-key: bx_0123456789abcdef0123456789abcdef
Some connector interfaces offer only OAuth, Mixed or No Authentication and give you no field for a static header. ChatGPT Developer Mode custom connectors are the common case. There, put the key on the endpoint URL instead:
https://www.buildix.trade/api/mcp?api_key=bx_0123456789abcdef0123456789abcdef
Same key, same plan, same daily quota. Headers are read first and the query parameter is only the fallback, so where a header is possible that form stays the recommended one. A key in a URL can end up in your own client logs, in browser history and in any proxy between you and us, so use a dedicated key for that connector and revoke it from the dashboard if it is ever exposed. Revocation takes effect on the next request.
A request with no key is treated as anonymous: the two open tools answer at free-tier limits, and every gated tool explains what it needs.
Open Settings, Developer, Edit Config and add the server to claude_desktop_config.json. Restart Claude Desktop afterwards.
{
"mcpServers": {
"buildix": {
"type": "http",
"url": "https://www.buildix.trade/api/mcp",
"headers": {
"Authorization": "Bearer bx_0123456789abcdef0123456789abcdef"
}
}
}
}Add the server to ~/.cursor/mcp.json for every project, or to .cursor/mcp.json inside one repository. Enable it under Settings, MCP.
{
"mcpServers": {
"buildix": {
"url": "https://www.buildix.trade/api/mcp",
"headers": {
"Authorization": "Bearer bx_0123456789abcdef0123456789abcdef"
}
}
}
}One command registers the server:
claude mcp add --transport http buildix https://www.buildix.trade/api/mcp \ --header "Authorization: Bearer bx_0123456789abcdef0123456789abcdef"
To confirm the server answers before wiring an agent to it, list the tools with curl:
curl -X POST https://www.buildix.trade/api/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Two limits apply, and they are independent. The per-minute burst guard sits at the edge and is the same for everyone: /api/mcp accepts 60 requests per minute per IP address, in a bucket shared with the other uncategorized /api/ routes. It does not vary by plan. The daily quota is what the plan buys, it is counted per API key, and it is shared with the REST API: an MCP tool call and a REST call spend from the same allowance.
Counters reset at Europe/Rome midnight, not UTC. Exhausting the daily quota returns HTTP 429 with a Retry-After header carrying the seconds until that reset. Whale moved from 50,000 to 2,000 requests per day in September 2026 and the 50,000 allowance moved to the API plan; a Whale subscription that started before 8 September 2026 keeps 50,000 per day for 60 days from that date. Call /api/v1/usage to read the limit actually applied to your key.
A tier refusal is not an HTTP error. It comes back inside the JSON-RPC envelope as an MCP error result whose text names the tool, the plan it requires, the plan your request resolved to, and both header spellings that carry a key. An agent can read that out to you, where a bare 403 would be invisible. The call still succeeds at the HTTP layer, so nothing in your client crashes.
Buildix MCP: "get_signals" requires the trader plan or above. This request resolved to "anonymous". Pass a Buildix API key with every MCP request, as a header: Authorization: Bearer bx_xxxxxxxx or x-api-key: bx_xxxxxxxx
Two conditions do answer at the HTTP layer, because they are about the request rather than about one tool: a key that is not valid returns 401, and an exhausted daily quota returns 429 with Retry-After. An unknown tool name is refused rather than served.
Connect an agent
The screener and pair tools answer without a key, so you can wire the server up and see it work before you decide anything. A key unlocks the gated tools at the plan you are on, and the same key works on the REST API.
Questions about the server or a client that will not connect: hello@buildix.trade