tradingview-mcp

Un servidor MCP para el flujo de trabajo de análisis de criptomonedas descrito en config/rules.json: obtiene velas, calcula los indicadores que te interesan y evalúa tu sesgo y reglas de riesgo contra ellos.

Nota de diseño: por qué esto no se conecta a TradingView

La guía de configuración de la que partió esto manejaba la aplicación de escritorio de TradingView a través del Protocolo de Herramientas para Desarrolladores de Chrome (--remote-debugging-port=9222). Ese enfoque le da al servidor el control total de una sesión de navegador en la que has iniciado sesión — puede leer tu cuenta, no solo tus gráficos.

Nada en rules.json lo necesita. Los pares spot de Binance, velas 1S/1D/4H, RSI, MACD, EMAs y volumen están disponibles desde endpoints públicos sin autenticación. Por lo tanto, este servidor lee datos públicos del mercado, no contiene credenciales y nunca toca una sesión iniciada.

Lo único que el enfoque CDP te proporcionaría son datos a los que esto no puede acceder: tus diseños y dibujos guardados, indicadores de pago y fuentes de intercambio a las que estás suscrito. Si necesitas eso, esa es la compensación que debes reabrir deliberadamente.

Related MCP server: Tickory MCP Server

Instalar

npm install
npm test          # 46 unit + integration tests, no network required
npm run smoke     # live end-to-end check against the real API

Regístralo con Claude Code fusionando config/mcp-entry.json en ~/.claude.json, reemplazando <HOME> con tu directorio personal:

{
  "mcpServers": {
    "tradingview": { "command": "node", "args": ["<HOME>/tradingview-mcp/src/server.js"] }
  }
}

Si mcpServers ya existe, añade la clave tradingview en lugar de reemplazar el objeto.

Apunta el servidor a un archivo de reglas diferente con TRADINGVIEW_MCP_RULES=/ruta/a/rules.json.

Herramientas

Cómo se decide el sesgo

bias_criteria en rules.json es texto en prosa — útil para un humano y para el modelo, pero no analizable por máquina. Los umbrales numéricos que realmente impulsan get_bias viven en bias_engine, por lo que ambos se mantienen deliberadamente sincronizados.

Un símbolo es alcista solo cuando se cumplen las tres condiciones: precio por encima de la EMA de tendencia, RSI diario dentro de la banda alcista y estructura del mercado que muestra máximos más altos y mínimos más altos. Bajista es el espejo. Cualquier otra cosa es neutral.

get_bias siempre devuelve los resultados de las condiciones individuales junto con la etiqueta, para que puedas ver por qué — y si una entrada no está disponible (por ejemplo, una EMA 200 en un par sin 200 velas de historial) devuelve unknown con la razón en lugar de un número que no puede respaldar.

Dos consecuencias deliberadas que vale la pena conocer:

• RSI por encima de 70 no es alcista. Tu banda termina en 70, por lo que una subida vertical se lee como neutral, no como una señal de largo.

• La puerta RSI siempre proviene del diario, incluso al juzgar el 4H, porque rules.json especifica la condición RSI "en diario".

El período EMA

Tus reglas originales tenían una contradicción: los tres bias_criteria hacían referencia a una EMA 500, mientras que indicators_i_care_about listaba solo la 50 y la 200. Establecí bias_engine.trend_ema_period en 50, coincidiendo con tu lista de indicadores — una EMA 500 en la semanal necesitaría aproximadamente una década de velas, que la mayoría de estos pares no tienen.

Si querías decir 500, es un cambio de una línea en config/rules.json, y la ruta unknown significa que obtendrás un honesto "historial insuficiente" en lugar de una respuesta incorrecta en silencio.

Fuentes de datos y sus limitaciones

REST público de Binance para pares spot; CoinGecko /global para los agregados CRYPTOCAP.

Las entradas CRYPTOCAP son solo valores actuales — el historial gratuito de capitalización de mercado no está disponible, por lo que get_indicators y get_bias los rechazan en lugar de inventar una serie. scan_watchlist los omite y los lista bajo skipped_macro. TOTAL3 se deriva como TOTAL x (1 - BTC.D - ETH.D).

Binance bloquea geográficamente algunas regiones. Si tv_health_check reporta inalcanzable desde una red que esperas que funcione, eso es lo primero que debes verificar.

Pruebas

npm test se ejecuta completamente sin conexión: las matemáticas de los indicadores se verifican contra los valores de referencia RSI publicados por Wilder, y la capa MCP es manejada por un cliente real sobre un transporte en memoria con una fuente de datos simulada.

npm run smoke es la parte que necesita red real — inicia el servidor sobre stdio como lo haría un cliente y llama a la API en vivo.

No es asesoramiento financiero

Esto informa lo que tus propias reglas dicen sobre los datos públicos. No decide nada por ti, y las ventanas no_trades_during en rules.json se muestran como recordatorios, no se aplican — nada aquí verifica un calendario económico.