Servidor MCP cripto para agentes de IA

#Conecta tu IA al servidor MCP cripto

Una URL y una cabecera. El servidor está cerrado por defecto: sin una X-API-KEY válida, no se anuncia ninguna herramienta y toda petición se rechaza con 401 (X-Deny-Reason: missing_api_key si falta la cabecera, invalid_api_key si la clave es desconocida o está revocada).

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

La forma exacta del archivo de configuración depende del agente de IA, y el bloque genérico de arriba no sirve para todos: Claude Desktop, ChatGPT y Gemini CLI lo leen de otra manera. La página del servidor MCP da la config lista para pegar de cada cliente: Claude Desktop, Claude Code, ChatGPT, Cursor, Codex, VS Code, LangChain, n8n y más.

El transporte es Streamable HTTP sin sesión: cada petición es autónoma. serverInfo.version es la versión de la superficie MCP (1.0.0) — sus herramientas, sus instrucciones y la forma de sus respuestas —, distinta de la versión del contrato de la API (1.0.2); cada respuesta la repite en mcp_version. Algunos clientes conservan las definiciones de herramientas recibidas al conectarse: cuando mcp_version cambia (una nueva versión mayor señala un cambio al que adaptarse), vuelve a conectar el conector para cargar las nuevas. Las capacidades solo anuncian lo que existe — herramientas y recursos, sin notificaciones listChanged — y un recurso desconocido responde con el error JSON-RPC -32002. CORS está abierto en /mcp: un cliente MCP que se ejecuta en un navegador puede conectarse. Los conectores que inician sesión con OAuth (claude.ai, ChatGPT, Claude Code) no necesitan clave: una petición sin clave recibe 401 con WWW-Authenticate: Bearer resource_metadata=…, que señala el servidor de autorización, bytnode.com, donde apruebas la conexión. Si no, la clave va en la cabecera X-API-KEY, o como Authorization: Bearer. Sin clave, la ficha del servidor https://api.bytnode.com/.well-known/mcp/server-card.json describe toda la superficie (herramientas, recursos, versión, autenticación), y /mcp/server.json es su entrada para el registro oficial de MCP.

#Las once herramientas de datos del mercado cripto

Las once son de solo lectura, sin efectos secundarios e idempotentes: un agente de IA puede repetirlas sin riesgo. Las cinco herramientas de datos tienen cada una su objetivo — un par, un activo, todo el mercado, la macro, on-chain — y funcionan igual: fields (los nombres de los campos que devolver), limit, since_ms / until_ms, last, columns, detail y max_tokens (detallados en get_pair_data) significan lo mismo en todas, cada respuesta lleva server_time y response_tokens, y sus convenciones comunes — modos, ventanas, resumen, unidades, presupuesto de tamaño — están en las instrucciones del servidor, enviadas una vez al conectarse en lugar de repetirse en cada descripción. rank_pairs clasifica todos los pares según una métrica, y read_export lee el resto de una respuesta recortada por su presupuesto.

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},
    ],
})

#Dato cripto actual o histórico

El modo depende de una sola cosa: la presencia de una ventana fechada. Sin since_ms, until_ms ni last, una herramienta de datos responde con el valor actual; con uno de ellos, cada campo pedido responde con su histórico en la ventana — varias métricas fechadas en una sola llamada.

#Seleccionar pares y mercados cripto

Cada herramienta de datos tiene su objetivo: un par para get_pair_data (symbol, obligatorio), un activo para get_options_data (asset, obligatorio), una serie de catálogo para get_macro_data (series), ninguno para get_market_overview y get_onchain_data. Cada campo pertenece a una sola herramienta. Lo que no encaja se rechaza antes de la primera llamada de red, nunca se absorbe, y todos los problemas se enumeran en el mismo mensaje.

#Los 64 campos del mercado cripto

Los nombres son los de la API, idénticos en valor actual y en histórico, con estas diferencias: el mercado global se llama global_market aquí y global en el snapshot REST (global es una palabra reservada de Python, el lenguaje del servidor); el mercado es un parámetro aquí (market: "spot") y un sufijo de ruta en REST (/v1/cvd/spot); las cifras de cada vencimiento de opciones llegan con expiries: true de get_options_data (REST: /v1/options/expiry) y las capacidades de un par con el catálogo symbol_capabilities (REST: /v1/capabilities?symbol=…); y un histórico indica el paso que la herramienta eligió en timeframe_applied, ya que puede elegirlo. El detalle de cada campo — su herramienta, qué contiene, sus unidades, qué cuenta N, su máximo, su histórico — lo da describe_fields; la descripción de cada herramienta lleva una línea por campo, con sus etiquetas (timeframe, solo valor actual, live, limit máximo). Consulta también el catálogo de datos.

#La respuesta: datos de mercado cripto que tu agente de IA puede leer

Los datos conservan los nombres, unidades y convenciones de la API, con una clave por campo, pero se presentan para un agente de IA en lugar de devolverse tal cual. Un campo con timeframe tiene la clave campo@tf; con varios pares, cada clave lleva su par delante (ETHUSDT/funding_next, BTCUSDT/cvd@1h). Una respuesta lleva mode, data, api_requests, server_time (la hora del servidor, ISO 8601 UTC), mcp_version (la versión de la superficie MCP) y response_tokens (su propio tamaño, en tokens estimados), más, cuando aplican, scopes, summary, ranges, freshness, warnings, errors, partial, unavailable, omitted_columns, missing, truncation, export, timeframe_applied y window; get_market_indicators y rank_pairs responden con el mismo sobre. Una serie vacía o que no aplica vale null, y unavailable indica por qué. unavailable y out_of_plan_fields son las del snapshot. Ninguna herramienta declara un outputSchema: las claves se describen aquí, y structuredContent lleva el mismo JSON que el texto.

{
  "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: una lista de filas llega como {columns, rows}, filas de la más reciente a la más antigua; un punto único, como objeto; una serie vacía o que no aplica, como null. Una serie de paso regular no tiene columna time sino first_time y step_s, sea cual sea su número de filas, una incluida: la fila i tiene la fecha first_time + i × step_s, siendo step_s negativo, desde la fila más reciente hacia atrás; ante el menor hueco, la columna time se mantiene. Los eventos (operaciones y liquidaciones individuales) y las tablas conservan su time, y lo que comparten todas las filas se indica una vez en el bloque: date (cada time es entonces la hora UTC de ese día, 12:54:30.494Z) o un solo time (todas las filas en ese instante, como una tabla de vencimientos); .000 desaparece cuando ninguna fila tiene milisegundos. Los flotantes conservan 6 cifras significativas, salvo las ofertas y los acumulados, que conservan sus unidades enteras. Con detail: "compact" (por defecto), las filas pesadas conservan sus columnas principales, is_closed se omite cuando todas las filas están cerradas y los identificadores de operaciones se omiten; omitted_columns nombra lo que se dejó fuera, y detail: "full" lo devuelve.
• scopes: el alcance real de cada clave — symbol:X, asset:X, series:X, o market para un campo sin objetivo. macro pedido sin series se etiqueta market, nunca con una serie. Con varios pares, el prefijo de la clave ya nombra su par: solo quedan los alcances de los demás objetivos (market…).
• mode: latest o history; en histórico, window repite los límites y ranges indica, por serie, lo que realmente se cubre: timeframe, row_count, from y to (el inicio del primer y del último bucket, como el time de cada fila), note y truncated; cuando una serie se recorta, missing indica cómo obtener el resto — un limit menor, una ventana anterior que termina en next_until_ms, o read_export desde el offset que da.
• summary: por serie, sobre su columna principal, el último y el más antiguo valor, el mínimo y el máximo con su instante, y la media; la suma para un flujo (liquidaciones, volumen neto…), con en sums la de sus componentes (long_usd y short_usd, buy_volume y sell_volume), la variación (y change_pct cuando tiene sentido) para un estado; las velas añaden high_max y low_min con su instante. Los trades y liquidaciones individuales añaden by_side (número, cantidad y USD por lado).
• freshness (valor actual): age_s, los segundos transcurridos desde la última entrega del flujo de origen de cada clave (la fecha de una fila es su time), y stale, las claves cuyo flujo va con retraso, según el monitor de flujos; warnings nombra cada campo retrasado — su valor no es actual — y cada columna de proyección que un campo ignoró.
• Tamaño: una respuesta se limita a 6000 tokens estimados por defecto; el parámetro max_tokens de las herramientas de datos, de get_market_indicators, de rank_pairs y de read_export lo ajusta de 1500 a 16 000, y response_tokens da el tamaño de cada respuesta. Más allá del presupuesto, las series más pesadas conservan sus filas más recientes, el recorte se indica una vez, en el ranges de cada serie (row_count filas devueltas de total_row_count, y missing: cómo obtener el resto, a menudo el max_tokens que basta para la respuesta entera; el mismo campo recortado para varios pares lleva una sola indicación, en el missing del nivel superior; truncation solo para lo que no tiene ranges), los metadatos idénticos para varios pares (ranges, omitted_columns, freshness) se escriben una vez por campo, con el nombre del campo, y export guarda los datos completos durante una hora, para la misma clave: read_export los lee página a página con export.export_id, en el formato de las respuestas, sin petición a la API ni cuota. También es el recurso MCP bytnode://exports/{id}, para los clientes que leen recursos, en un solo bloque, con 8 cifras significativas y el time de cada fila.
• timeframe_applied: el paso realmente aplicado, en cuanto un campo lo ha usado; live: presente cuando se pidió la vela en formación.
• errors y partial: un campo con error no bloquea los demás, ni un par rechazado los otros pares. Se indica en errors (un par, con su nombre) y la respuesta lleva partial: true.
• api_requests: las peticiones que esta llamada contó en tu cuota — por cada par, una para los valores actuales de los campos del snapshot juntos; una para cada otro campo, cada histórico y expiries.
• oi_usd: cada fila de oi lleva el open interest en USD, oi × el cierre de la vela spot de referencia del mismo bucket (null sin ella), también en valor actual, sin petición adicional; get_pair_brief también lo lleva. Del mismo modo, cada fila de cvd lleva cumulative_net_volume, el acumulado de net_volume desde la fila más antigua de la serie servida: la curva de CVD sobre el periodo. El valor actual de liquidations_cumulative es su último bucket cerrado (1h por defecto), fechado en su inicio como cualquier fila.

#Errores en las llamadas de datos de mercado cripto

Todo error empieza por Error (HTTP NNN): message. Cuando la API ha respondido, termina con [code: …], el error.code estable de la API. Una llamada de herramienta fallida se marca como error MCP (isError), nunca se devuelve como dato, y lleva el mismo error en campos en structuredContent.error: {status, code, message, param?, hint?, retry_after_s?}. code es el de la API cuando lo dio (invalid_symbol, plan_family, history_depth, rate_limited, quota_exceeded…); si no, sigue el estado (invalid_request para un 422, unauthorized para un 401…); un campo pedido a la herramienta equivocada da wrong_tool, con la herramienta correcta en hint (call get_market_overview), un campo o una columna desconocidos unknown_field, un parámetro desconocido unknown_parameter, con did you mean … en hint; retry_after_s es la espera indicada cuando el mensaje da una.