Crypto MCP Server: How to Connect Live Hyperliquid Orderflow to ChatGPT, Claude, and Cursor

A crypto MCP server is only useful if your AI client can authenticate to it, and that is exactly where most setups die. ChatGPT custom connectors in Developer Mode offer OAuth, Mixed, or No Authentication. There is no field for a static Authorization header. Claude Code and Cursor allow custom headers. So the same server, with the same API key, connects in thirty seconds from one client and looks completely broken from another.

The fix is not OAuth. It is knowing which transport each client actually supports, and how the server reads your key.

Why ChatGPT Custom Connectors Reject Header Based API Keys

Most API documentation tells you to pass your key as Authorization: Bearer your_key or as x-api-key: your_key. Both work from a terminal, from Python, and from any MCP client that lets you define headers.

ChatGPT custom connectors do not expose that field. You get a URL, an authentication mode, and nothing else. Choosing OAuth requires the server to run a full OAuth 2.1 authorization server with dynamic client registration, which almost no small data provider has built. Choosing No Authentication sends nothing at all, and a gated server answers with a tier error.

The workaround is a key in the query string. The Buildix MCP endpoint accepts it directly:

` https://www.buildix.trade/api/mcp?api_key=bx_your_key_here `

Set the connector authentication to No authentication, because the key already travels in the URL. Worth knowing before you paste it anywhere: a URL ends up in client logs, in browser history, and in any proxy along the path, so use a dedicated key for that one connector and revoke it if it leaks.

There is a subtle failure mode here that is worth checking on any server you try this with. If the server reads the Authorization header first and stops at the first non empty value, a connector in Mixed mode sends something useless in that header and the query key is never read. The request resolves as anonymous and every gated tool refuses. On Buildix that precedence bug was fixed on September 15, 2026: each source is now only accepted if it actually carries a key.

Connecting the Same MCP Server From ChatGPT, Claude Code, and Cursor

The endpoint is the same for every client, https://www.buildix.trade/api/mcp, over streamable HTTP, protocol revision 2025-06-18. What changes is how the key gets attached.

For ChatGPT, add a custom connector with the URL including ?api_key=, authentication set to No authentication.

For Claude Code, the server takes a custom header, which is the safer form:

` claude mcp add --transport http buildix https://www.buildix.trade/api/mcp \ --header "Authorization: Bearer bx_your_key_here" `

For Cursor and other desktop clients that use a JSON config, the same idea in config form:

`json { "mcpServers": { "buildix": { "url": "https://www.buildix.trade/api/mcp", "headers": { "Authorization": "Bearer bx_your_key_here" } } } } `

Both Authorization: Bearer and x-api-key are accepted, and the header always takes precedence over the query string. Keys are created at buildix.trade/dashboard/api-keys and start with bx_.

The Seven Tools a Crypto MCP Server Should Expose

Tool design matters more than tool count. An AI agent works well when each tool returns a compact, typed answer, and badly when a single call floods the context window.

get_screener returns the live cross market scan across 530 plus pairs. get_pair returns price, 24 hour change and volume, open interest, funding and annualized funding, mark and oracle price, and max leverage for one symbol. Both are open and need no key, which means open interest and funding cost you nothing.

get_cvd returns cumulative volume delta as a time series, with interval set to 5m, 15m or 1h and a lookback in buckets. Each bucket carries buy volume, sell volume, delta, cumulative CVD, and trade count. get_liquidation_map returns liquidation clusters around spot plus cascade scenarios. get_smart_money returns the wallet leaderboard with positions and aggregates. get_signals returns active orderflow signals, and get_hip4_edge covers HIP-3 market structure.

Access follows the plan: screener and pair are open, signals need Trader, smart money needs Pro, and CVD, liquidation map and HIP-4 edge need Whale. Gating happens at call time, so an agent sees all seven in the tool list and gets a readable plan error on the ones it cannot use.

One practical warning. get_smart_money returns over 200 KB in a single response. Inside an agent that is a meaningful slice of the context window spent in one call, so query it deliberately rather than on every turn.

Five Prompts That Turn Orderflow Into Something an AI Can Reason About

The value of a crypto MCP server is not that an AI can fetch a price. It is that an AI can combine four different data shapes in one pass and tell you when they disagree.

Divergence detection. Ask for the 15m CVD on BTC over the last hour alongside price change over the same window, and have the model flag the case where price makes a higher high while cumulative delta does not. That disagreement between price and aggressive flow is the classic setup CVD exists to catch.

Liquidation asymmetry. Ask for the liquidation clusters above and below spot and which side carries more notional. Cascade scenarios make the question concrete: if price trades through a given level, how much forced selling sits behind it.

Funding versus flow. Ask for funding, annualized funding and open interest from get_pair, then the 5m CVD trend. Positive funding with negative delta means longs are paying to hold a position that aggressive flow is not supporting.

Cross market scan. Ask the model to pull the screener and rank pairs where funding is negative while delta is positive, then check the top three individually. This is the kind of loop that is tedious by hand and trivial for an agent with tool access.

Wallet context before entry. Ask which smart money wallets are net long a symbol and how large the positions are, then check whether current CVD confirms or contradicts them.

What Sampled CVD Can and Cannot Tell You

Honest limits make the difference between a tool you trust and one you stop using after a week.

The CVD series is computed on a sample of the tape, a rolling buffer of roughly 300 fills per symbol, not on every trade. That has two consequences. Coverage is about one hour on liquid symbols like BTC, which is 13 to 17 buckets at 5m, and stretches to several hours on thin ones where 300 fills take longer to accumulate. And the absolute dollar figures are a sample, not total market volume. Every response carries sampled, coverage_minutes and trades_per_bucket so your agent can see exactly what it is working with.

For direction and for price versus delta divergence on a short horizon, that is enough. For session volume profiles or multi day delta accumulation, it is not, and no amount of prompting fixes it. All orderflow is Hyperliquid native, so there is no cross exchange aggregation in the current API.

Rate limits shape agent design too. A Whale key allows 2,000 requests per day, counted per key and reset at midnight Central European time, with a burst ceiling of 10 per minute on the CVD and deep view endpoints and 60 per minute elsewhere. Polling four tools every five minutes lands around 1,150 calls per day, which fits. Polling every minute does not.

If you want to try the shape of the data before wiring anything up, the screener and the per pair deep views at buildix.trade/screener are the same numbers the MCP tools return, in a browser.

The interesting shift is not that an AI can read a chart. It is that a model with tool access can hold funding, open interest, liquidation structure and aggressive flow in the same reasoning step, notice that three of them point one way and one does not, and say so before you take the trade.