Crypto MCP Servers: A Research Stack for Claude and Codex

TL;DR: A useful crypto research stack in an AI assistant combines official data MCP servers (CoinGecko for market data, Dune for SQL over on-chain tables, Nansen for wallet and flow analytics, plus optional Glassnode, Santiment or DefiLlama) with Trigr's MCP, which turns the resulting hypothesis into a point-in-time backtest and a paused paper agent. All of them can run together in Claude Code, Codex or Cursor. Keep any exchange MCP read-only in that same session, because some of them can place real orders.

Which crypto data MCP servers exist?

The Model Context Protocol lets an assistant discover and call a server's tools without glue code. By September 2026 most large crypto data providers publish an official remote server, including CoinGecko and Nansen. The details below come from each provider's own documentation, as of September 2026; limits and plans change, so check before relying on them.

Two gaps are worth knowing. We could not find an official Hyperliquid MCP server, only community ones, and we found no official Arkham MCP. For a CEX or Hyperliquid read path, the official CCXT MCP server runs locally and is read-only by default.

Where does Trigr fit in the stack?

The data servers answer "what is happening". None of them answers "would a rule built on this have made money after costs, without look-ahead". That is the job of the last server in the stack.

Trigr's remote MCP server at https://trigr.xyz/mcp searches a capability catalog of assets, timeframes, indicators and data sources, saves strategy drafts, runs credit-metered point-in-time backtests with optional slippage and funding, runs ML optimization, and reads stored runs and full trade logs for free. It can also create a paper agent in a PAUSED state. It cannot start execution, place a live trade or withdraw funds. The trading MCP server guide covers the full tool set.

One constraint shapes the whole workflow: a Trigr backtest reads only sources in its catalog. Those include price and indicators, funding rate, open interest, long/short ratio, liquidations, DVOL, Santiment on-chain and social metrics, FRED macro series and the VIX (see the live data catalog). A Nansen wallet list or a Dune query result cannot be pasted into a backtest. The external servers help you find and sharpen an idea; the test has to be expressed in inputs Trigr can replay point-in-time.

How do you connect several servers in Claude Code?

Claude Code adds remote servers with one command each, and authorizes OAuth servers from inside a session. The syntax below follows the Claude Code MCP documentation.

# Trigr (browser OAuth, no key to copy)
claude mcp add --transport http --scope user trigr https://trigr.xyz/mcp

# Keyless or OAuth data servers
claude mcp add --transport http coingecko https://mcp.api.coingecko.com/mcp
claude mcp add --transport http dune https://api.dune.com/mcp/v1
claude mcp add --transport http santiment https://api.santiment.net/mcp
claude mcp add --transport http glassnode https://mcp.glassnode.com

# Key-based server: the header value is stored in your local config
claude mcp add --transport http nansen https://mcp.nansen.ai/ra/mcp \
  --header "NANSEN-API-KEY: $NANSEN_API_KEY"

Then start claude, run /mcp, and authenticate Trigr, Dune and Santiment in the browser. claude mcp list shows what is connected.

A few practical points:

• Scope. The default local scope and the user scope live in ~/.claude.json. The project scope writes .mcp.json, which is meant to be shared through git, so never put a keyed server there.
• Output size. Claude Code warns when a tool returns more than 10,000 tokens and caps output at 25,000 by default. Raise it with MAX_MCP_OUTPUT_TOKENS if long Dune results or trade logs get cut off.
• Many tools. Tool search is on by default from v2.1, so tools load on demand and a six-server stack does not flood the context.
• Trigr prompts. Trigr's workflows appear as slash commands such as /mcp__trigr__build_strategy and /mcp__trigr__research_marketplace.

The same Trigr setup, step by step, is in connecting Claude Code and Codex to Trigr.

How do you configure Codex and Cursor?

Codex reads ~/.codex/config.toml (or a project .codex/config.toml). Remote servers take a url, and optionally bearer_token_env_var or http_headers. Raise tool_timeout_sec (default 60) for backtests.

[mcp_servers.trigr]
url = "https://trigr.xyz/mcp"
tool_timeout_sec = 300

[mcp_servers.coingecko]
url = "https://mcp.api.coingecko.com/mcp"

[mcp_servers.dune]
url = "https://api.dune.com/mcp/v1"

Then run codex mcp login trigr and codex mcp login dune for OAuth, and codex mcp list to confirm. Per-server enabled_tools, disabled_tools and default_tools_approval_mode let you narrow what each server may do.

Cursor reads ~/.cursor/mcp.json (global) or .cursor/mcp.json (project). Remote entries take a url and optional headers, and values can be interpolated from the environment with ${env:NAME}:

{
  "mcpServers": {
    "trigr": { "url": "https://trigr.xyz/mcp" },
    "coingecko": { "url": "https://mcp.api.coingecko.com/mcp" },
    "nansen": {
      "url": "https://mcp.nansen.ai/ra/mcp",
      "headers": { "NANSEN-API-KEY": "${env:NANSEN_API_KEY}" }
    }
  }
}

Cursor asks for approval before tool calls by default. Trigr documents ChatGPT, Claude, Claude Code and Codex; with other clients, confirm the browser authorization completes before relying on the connection.

What does a worked research flow look like?

Here is an end-to-end session, with the servers above connected. The market and thresholds are illustrative, not a recommendation.

1. Scan. "Using CoinGecko, list the ten large-cap tokens with the biggest 30-day volume change. Using Nansen, summarize smart-money net flows for SOL over the same period." This is context gathering, and Nansen calls cost credits, so keep the question narrow.
2. Dig. "Use Dune to find a table of Solana DEX volume and chart daily volume against SOL price for the last year." Dune returns SQL you can inspect, which is better than a summary you cannot audit.
3. Form a hypothesis. Suppose the data suggests that crowded long positioning after activity spikes tends to unwind. Write it down before testing: "On SOL 4H, when funding is above 0.0005 (0.05% per 8h) and open interest is up more than 5% over 24h, short entries outperform. Costs: 5 bps slippage per side plus historical funding. Budget: at most five variants."
4. Translate to catalog inputs. "Use Trigr: search the catalog for funding rate and open interest on SOL, then call trigr_get_data_coverage for SOL and disclose the coverage window." The hypothesis now uses sources Trigr can replay point-in-time.
5. Create and backtest. "Create one strategy for this idea and backtest it with 5 bps slippage per side and real historical funding." Trigr fills at the next bar's open and applies trading fees on every run. Without the frictions, the result is labeled gross.
6. Iterate as labelled experiments. "Run variants as experiments on this strategy: 'Exp 1 — funding > 0.001', 'Exp 2 — add ATR trail 2.5x', 'Exp 3 — OI change over 7d instead of 24h'." Switching to 1H would be a new idea, not an experiment. Each call to trigr_run_backtest passes the strategyId and an experimentLabel, so variants land in one version history instead of five near-duplicate strategies. Iterating with experiments explains why that keeps the trial count honest.
7. Read the evidence. trigr_get_backtest_result lists runs with their labels, and trigr_get_backtest_trades pages through each trade log for free. Trade prices there are bar prices before slippage, and P&L is in base-100 account units, not dollars.
8. Freeze and forward-test. Save the winner with trigr_edit_strategy, then "create a paper agent for this strategy with 1,000 capital". Trigr creates it PAUSED. You review it and start it in the Trigr app.

Step 8 matters because a standard Trigr backtest uses the full available history, and its shaded trailing 25% is a recent-period diagnostic, not a holdout. Genuinely unseen evidence comes from ML walk-forward output or from a paper forward test. Backtests are not guarantees; perps are leveraged and can lose more than expected.

How do you keep a multi-server session safe?

Adding servers adds authority. Treat the session like a shared terminal with several people's keys in it.

• Exchange MCPs can place real orders. CCXT's server trades if you set "trading": "live" (it then requires a maxOrderValue cap). Community Hyperliquid servers such as edkdev/hyperliquid-mcp place orders with a private key. OKX's Agent Trade Kit exposes trading tools. In a research session, keep them read-only: CCXT's default mode, or an info-only Hyperliquid server such as kukapay/hyperliquid-info-mcp, which needs only a public address.
• Never mix a trading key with untrusted text. Token names, Dune query descriptions, news items and marketplace text are third-party content. If a trading-capable tool is connected, a crafted string is one confused step away from an order.
• Use client controls. Codex disabled_tools, Claude's per-tool "Allow once" and disabled tools, and Cursor's default approvals all narrow what a server can do.
• Budget the paid servers. Nansen bills every call, DefiLlama charges a credit per query, and Trigr backtests cost credits (cached results and stored-run reads are free).

Trigr's side of this is deliberate. Its MCP has no tool that trades, starts an agent or withdraws, so no prompt can produce one. Consequential actions go through a ten-minute, single-use authorization bound to the exact arguments, in manual or autonomous mode. Going live happens in the Trigr app, through a trade-only Hyperliquid agent key that cannot withdraw. The limits are covered in AI trading agent safety.

What this means for you

You can do on-chain digging, market scans and strategy validation in one conversation, without copying numbers between tabs. The data servers are good at breadth. Trigr adds what they lack: a backtest that fills at the next bar's open, applies fees always and slippage and funding when you ask, keeps variants in one history, and stops at a paused paper agent rather than an order.

Next steps

Connect Trigr alongside your data servers from the MCP setup page, then run the flow above on one idea. The AI agents and MCP docs list every Trigr tool and its limits.