Serveur MCP crypto pour agents IA

#Connecter votre IA au serveur MCP crypto

Une URL et un en-tête. Le serveur est fermé par défaut : sans X-API-KEY valide, aucun outil n’est annoncé et toute requête est refusée en 401 (X-Deny-Reason: missing_api_key si l’en-tête est absent, invalid_api_key si la clé est inconnue ou révoquée).

{
  "mcpServers": {
    "bytnode": {
      "type": "http",
      "url": "https://api.bytnode.com/mcp",
      "headers": { "X-API-KEY": "your_key" }
    }
  }
}

La forme exacte du fichier de configuration dépend de l’agent IA, et le bloc générique ci-dessus ne convient pas à tous : Claude Desktop, ChatGPT et Gemini CLI le lisent autrement. La page du serveur MCP donne la config prête à coller de chaque client : Claude Desktop, Claude Code, ChatGPT, Cursor, Codex, VS Code, LangChain, n8n et d’autres.

Le transport est Streamable HTTP sans session : chaque requête se suffit à elle-même. serverInfo.version est la version de la surface MCP (1.0.0) — ses outils, ses instructions et la forme de ses réponses —, distincte de la version du contrat de l’API (1.0.2) ; chaque réponse la répète dans mcp_version. Certains clients gardent les définitions d’outils reçues à la connexion : quand mcp_version change (une nouvelle version majeure signale un changement auquel s’adapter), reconnectez le connecteur pour charger les nouvelles. Les capacités n’annoncent que ce qui existe — outils et ressources, sans notification listChanged — et une ressource inconnue répond l’erreur JSON-RPC -32002. Le CORS est ouvert sur /mcp : un client MCP qui tourne dans un navigateur peut se connecter. Les connecteurs qui se connectent par OAuth (claude.ai, ChatGPT, Claude Code) n’ont besoin d’aucune clé : une requête sans clé reçoit 401 avec WWW-Authenticate: Bearer resource_metadata=…, qui désigne le serveur d’autorisation, bytnode.com, où vous approuvez la connexion. Sinon, la clé passe dans l’en-tête X-API-KEY, ou en Authorization: Bearer. Sans clé, la fiche du serveur https://api.bytnode.com/.well-known/mcp/server-card.json décrit toute la surface (outils, ressources, version, authentification), et /mcp/server.json est son entrée pour le registre officiel MCP.

#Les onze outils de données du marché crypto

Les onze sont en lecture seule, sans effet de bord et idempotents : un agent IA peut les rejouer sans risque. Les cinq outils de données ont chacun leur cible — une paire, un actif, tout le marché, la macro, l’on-chain — et fonctionnent de la même façon : fields (les noms des champs à rendre), limit, since_ms / until_ms, last, columns, detail et max_tokens (détaillés sous get_pair_data) veulent dire la même chose dans chacun, chaque réponse porte server_time et response_tokens, et leurs conventions communes — modes, fenêtres, résumé, unités, budget de taille — sont dans les instructions du serveur, envoyées une fois à la connexion plutôt que répétées dans chaque description. rank_pairs classe toutes les paires sur une métrique, et read_export lit la suite d’une réponse coupée par son budget.

await c.call_tool("get_market_indicators", {
    "symbol": "BTCUSDT",
    "timeframe": "1h",
    "limit": 60,
    "indicators": [
        {"id": "rsi_7", "type": "rsi", "period": 7},
        {"id": "rsi_21", "type": "rsi", "period": 21},
        {"id": "macd", "type": "macd", "fast": 12, "slow": 26, "signal": 9},
        {"id": "adx_14", "type": "adx", "period": 14},
    ],
})

#Donnée crypto courante ou historique

Le mode ne dépend que d’une chose : la présence d’une fenêtre datée. Sans since_ms, until_ms ni last, un outil de données répond avec la valeur courante ; avec l’un d’eux, chaque champ demandé répond avec son historique sur la fenêtre — plusieurs métriques datées en un seul appel.

#Cibler les paires et les marchés crypto

Chaque outil de données a sa cible : une paire pour get_pair_data (symbol, requis), un actif pour get_options_data (asset, requis), une série de catalogue pour get_macro_data (series), aucune pour get_market_overview et get_onchain_data. Chaque champ appartient à un seul outil. Ce qui ne colle pas est refusé avant le premier appel réseau, jamais absorbé, et tous les problèmes sont listés dans le même message.

#Les 64 champs du marché crypto

Les noms sont ceux de l’API, identiques en valeur courante et en historique, avec ces différences : le marché global s’appelle global_market ici et global dans le snapshot REST (global est un mot réservé de Python, la langue du serveur) ; le marché est un paramètre ici (market: "spot") et un suffixe de chemin en REST (/v1/cvd/spot) ; les chiffres de chaque échéance d’options viennent avec expiries: true de get_options_data (REST : /v1/options/expiry) et les capacités d’une paire avec le catalogue symbol_capabilities (REST : /v1/capabilities?symbol=…) ; et un historique dit le pas que l’outil a retenu dans timeframe_applied, puisqu’il peut le choisir. Le détail de chaque champ — son outil, ce qu’il contient, ses unités, ce que compte N, son plafond, son historique — est donné par describe_fields ; la description de chaque outil en porte une ligne par champ, avec ses étiquettes (timeframe, valeur courante seule, live, limit maximal). Voir aussi le catalogue des données.

#La réponse : des données de marché crypto lisibles par votre agent IA

Les données gardent les noms, unités et conventions de l’API, sous une clé par champ, mais elles sont présentées pour un agent IA plutôt que rendues telles quelles. Un champ à timeframe a pour clé champ@tf ; avec plusieurs paires, chaque clé est précédée de sa paire (ETHUSDT/funding_next, BTCUSDT/cvd@1h). Une réponse porte mode, data, api_requests, server_time (l’heure du serveur, ISO 8601 UTC), mcp_version (la version de la surface MCP) et response_tokens (sa propre taille, en jetons estimés), plus, quand ils s’appliquent, scopes, summary, ranges, freshness, warnings, errors, partial, unavailable, omitted_columns, missing, truncation, export, timeframe_applied et window ; get_market_indicators et rank_pairs répondent dans la même enveloppe. Une série vide ou sans objet vaut null, et unavailable dit pourquoi. unavailable et out_of_plan_fields sont celles du snapshot. Aucun outil ne déclare d’outputSchema : les clés sont décrites ici, et structuredContent porte le même JSON que le texte.

{
  "mode": "latest",
  "data": {
    "klines@1h": {
      "first_time": "2026-10-21T13:00:00.000Z",
      "step_s": -3600,
      "columns": ["open", "high", "low", "close", "volume"],
      "rows": [[…], …]
    },
    "oi@1h": { "first_time": …, "step_s": -3600, "columns": ["oi", "oi_usd", … ], "rows": [ … ] },
    "funding_next": { … },
    "price_change": { … }
  },
  "scopes": {
    "symbol:BTCUSDT": ["klines@1h", "oi@1h", "funding_next", "price_change"]
  },
  "summary": {
    "klines@1h": { "column": "close", "latest": …, "min": …, "max": …, "mean": …,
                   "change_pct": …, "high_max": …, "low_min": …, … }
  },
  "freshness": { "age_s": { "klines@1h": 4, "funding_next": 2, … }, "stale": [] },
  "omitted_columns": { "klines@1h": ["is_closed"] },
  "timeframe_applied": "1h",
  "unavailable": { … },
  "api_requests": 1,
  "server_time": "2026-10-21T14:02:31.512Z",
  "response_tokens": 1840
}

• data : une liste de lignes arrive en {columns, rows}, lignes de la plus récente à la plus ancienne ; un point seul, en objet ; une série vide ou sans objet, en null. Une série à pas régulier n’a pas de colonne time mais first_time et step_s, quel que soit son nombre de lignes, une comprise : la ligne i est datée first_time + i × step_s, step_s étant négatif, de la ligne la plus récente vers le passé ; au moindre trou, la colonne time reste. Les événements (trades, liquidations unitaires) et les tables gardent leur time, et ce que toutes les lignes partagent est dit une fois sur le bloc : date (chaque time est alors l’heure UTC de ce jour, 12:54:30.494Z) ou un seul time (toutes les lignes à cet instant, comme une table d’échéances) ; .000 disparaît quand aucune ligne n’a de millisecondes. Les flottants gardent 6 chiffres significatifs, sauf les offres et les cumuls, qui gardent leurs unités entières. Avec detail: "compact" (le défaut), les lignes lourdes gardent leurs colonnes principales, is_closed disparaît quand chaque ligne est close et les identifiants de trades sont retirés ; omitted_columns nomme ce qui a été laissé, et detail: "full" le rend.
• scopes : la portée réelle de chaque clé — symbol:X, asset:X, series:X, ou market pour un champ sans cible. macro demandé sans series est étiqueté market, jamais avec une série. Avec plusieurs paires, le préfixe de la clé nomme déjà sa paire : seules restent les portées des autres cibles (market…).
• mode : latest ou history ; en historique, window rappelle les bornes et ranges dit, par série, ce qui est réellement couvert : timeframe, row_count, from et to (le début du premier et du dernier bucket, comme le time de chaque ligne), note et truncated ; quand une série est coupée, missing dit comment obtenir la suite — un limit plus bas, une fenêtre plus ancienne qui finit à next_until_ms, ou read_export à partir de l’offset qu’il donne.
• summary : par série, sur sa colonne principale, la dernière et la plus ancienne valeur, le min et le max avec leur instant, et la moyenne ; la somme pour un flux (liquidations, volume net…), avec dans sums celle de ses composantes (long_usd et short_usd, buy_volume et sell_volume), la variation (et change_pct quand elle a un sens) pour un état ; les bougies ajoutent high_max et low_min avec leur instant. Les trades et liquidations unitaires ajoutent by_side (nombre, quantité et USD par côté).
• freshness (valeur courante) : age_s, les secondes écoulées depuis la dernière livraison du flux source de chaque clé (la date d’une ligne est son time), et stale, les clés dont le flux est en retard, selon le moniteur des flux ; warnings nomme chaque champ en retard — sa valeur n’est pas courante — et chaque colonne de projection qu’un champ a ignorée.
• Taille : une réponse est bornée à 6 000 jetons estimés par défaut ; le paramètre max_tokens des outils de données, de get_market_indicators, de rank_pairs et de read_export la règle de 1 500 à 16 000, et response_tokens donne la taille de chaque réponse. Au-delà du budget, les séries les plus lourdes gardent leurs lignes les plus récentes, la coupe est dite une fois, dans le ranges de chaque série (row_count lignes servies sur total_row_count, et missing : comment avoir la suite, souvent le max_tokens qui suffit à la réponse entière ; le même champ coupé pour plusieurs paires porte une seule consigne, dans le missing de premier niveau ; truncation seulement pour ce qui n’a pas de ranges), les métadonnées identiques pour plusieurs paires (ranges, omitted_columns, freshness) sont écrites une fois par champ, sous le nom du champ, et export garde les données complètes une heure, pour la même clé : read_export les lit page par page avec export.export_id, au format des réponses, sans requête à l’API ni quota. C’est aussi la ressource MCP bytnode://exports/{id}, pour les clients qui lisent les ressources, d’un seul bloc, avec 8 chiffres significatifs et le time de chaque ligne.
• timeframe_applied : le pas réellement appliqué, dès qu’un champ l’a utilisé ; live : présent quand la bougie en formation a été demandée.
• errors et partial : un champ en erreur n’empêche pas les autres, ni une paire refusée les autres paires. Il est signalé sous errors (une paire sous son nom) et la réponse porte partial: true.
• api_requests : les requêtes que cet appel a décomptées de votre quota — pour chaque paire, une pour les valeurs courantes des champs du snapshot ensemble ; une pour chaque autre champ, chaque historique et expiries.
• oi_usd : chaque ligne d’oi porte l’open interest en USD, oi × la clôture de la bougie spot de référence du même bucket (null sans elle), en valeur courante aussi, sans requête de plus ; get_pair_brief le porte également. De même, chaque ligne de cvd porte cumulative_net_volume, le cumul de net_volume depuis la ligne la plus ancienne de la série servie : la courbe de CVD sur la période. La valeur courante de liquidations_cumulative est son dernier bucket clos (1h par défaut), daté à son début comme toute ligne.

#Erreurs sur les appels de données de marché crypto

Toute erreur commence par Error (HTTP NNN): message. Quand l’API a répondu, elle se termine par [code: …], l’error.code stable de l’API. Un appel d’outil en échec est signalé comme une erreur MCP (isError), jamais rendu comme une donnée, et porte la même erreur en champs dans structuredContent.error : {status, code, message, param?, hint?, retry_after_s?}. code est celui de l’API quand elle en a donné un (invalid_symbol, plan_family, history_depth, rate_limited, quota_exceeded…), sinon il suit le statut (invalid_request pour un 422, unauthorized pour un 401…) ; un champ demandé au mauvais outil donne wrong_tool, avec le bon outil dans hint (call get_market_overview), un champ ou une colonne inconnus unknown_field, un paramètre inconnu unknown_parameter, avec did you mean … dans hint ; retry_after_s est le délai à attendre quand le message en donne un.