SiftingIO MCP

Datos de mercado en tiempo real e históricos que incluyen acciones de EE. UU., Forex, Cripto (CEX y DEX), materias primas y fundamentos.

GitHub

Prueba este MCPPatrocinado

Documentación

siftingio-mcp

Este es un servidor de Model Context Protocol (MCP) que pone el SDK de datos de mercado de SiftingIO (@siftingio/sdk) al alcance de tu asistente de IA. Una vez en ejecución, el modelo puede obtener precios en vivo, explorar fundamentos de SEC/EDGAR, recuperar barras OHLCV, consultar tenencias 13F, verificar el estado del mercado y escanear el calendario macroeconómico — todo como herramientas.

Configuración

npm install
npm run build

Necesitarás una clave de API, que puedes obtener en https://sifting.io:

export SIFTING_API_KEY=sft_...

Si necesitas apuntar a un backend diferente, SIFTING_BASE_URL y SIFTING_WS_URL están ahí para sobrescribir los valores predeterminados.

¿Trabajando localmente? Copia .env.example a .env en su lugar — npm run dev y npm start lo detectan automáticamente (Node lo carga mediante --env-file-if-exists). Cuando lo conectes a un cliente MCP real, sin embargo, pasa la clave a través del bloque env del servidor en lugar de un archivo (hay un ejemplo más abajo).

Ejecución

Aquí está la caja de herramientas:

npm run build — compila TypeScript a dist/.
npm start — ejecuta el servidor compilado (node dist/index.js) sobre stdio.
npm run start:http — ejecútalo sobre Streamable HTTP (node dist/http.js).
npm run dev / npm run dev:http — ejecuta directamente desde el código fuente con tsx, sin paso de compilación.
npm test — ejecuta la suite de vitest (añade npm run test:watch para mantenerlo en ejecución).
npm run lint / npm run format — ESLint (typescript-eslint) y Prettier.
npm run typecheck — tsc --noEmit.

En cada push y PR, CI (.github/workflows/ci.yml) recorre la misma prueba: verificación de formato → lint → typecheck → build → test.

Una cosa que vale la pena saber: el servidor habla JSON-RPC sobre stdio, así que stdout pertenece enteramente al protocolo. Cualquier cosa de diagnóstico va a stderr para no estorbar.

Inspección interactiva

¿Quieres probarlo manualmente? El inspector de MCP es la forma más fácil:

SIFTING_API_KEY=sft_... npx @modelcontextprotocol/inspector node dist/index.js

Transporte HTTP (Streamable HTTP)

Si lo ejecutas en algún lugar remoto o alojado, usa el transporte Streamable HTTP de MCP en lugar de stdio:

SIFTING_API_KEY=sft_... PORT=3000 npm run start:http
# → MCP endpoint at http://127.0.0.1:3000/mcp  (POST messages, GET SSE, DELETE session)

Es con estado: cada cliente obtiene su propia sesión (rastreada por la cabecera mcp-session-id) y su propio McpServer, mientras que la conexión upstream de SiftingIO se comparte en todo el proceso. Como medida de seguridad, solo se vincula a loopback y rechaza las solicitudes Origin de navegadores no locales — esa es la protección contra DNS-rebinding. Configura el puerto con PORT (o MCP_HTTP_PORT); el valor predeterminado es 3000.

Si quieres autenticación, configura MCP_AUTH_TOKEN y el servidor exigirá Authorization: Bearer <token> en cada solicitud (cualquier cosa faltante o incorrecta recibe un 401). Combínalo con un proxy inverso que maneje TLS y el token, y podrás exponer el servidor más allá de localhost de forma segura:

MCP_AUTH_TOKEN=s3cret SIFTING_API_KEY=sft_... npm run start:http

Luego solo apunta cualquier cliente MCP compatible con HTTP a http://127.0.0.1:3000/mcp:

claude mcp add --transport http siftingio http://127.0.0.1:3000/mcp

Uso con un cliente MCP

Coloca esto en la configuración de tu cliente — el claude_desktop_config.json de Claude Desktop, por ejemplo, o usa claude mcp add si estás en Claude Code:

{
  "mcpServers": {
    "siftingio": {
      "command": "node",
      "args": ["/absolute/path/to/siftingio-mcp/dist/index.js"],
      "env": { "SIFTING_API_KEY": "sft_..." }
    }
  }
}

Herramientas (36)

Namespace	Herramientas
Live (snapshot)	`last_trade`, `last_quote`, `last_tvl`
Acciones	`stocks_search`, `stocks_profile`, `stocks_filings`, `stocks_filing`, `stocks_sections`, `stocks_section`, `stocks_risk_factors_diff`, `stocks_ratios`, `stocks_earnings`, `stocks_financials`, `stocks_financial_concept`, `stocks_insiders`, `stocks_ownership`, `stocks_events`, `stocks_compensation`, `stocks_screener`, `stocks_bars`
Cripto / Forex	`crypto_bars`, `forex_bars`
DEX	`dex_wallet`
Mercados	`markets_list`, `markets_status_all`, `markets_status`, `markets_hours`, `markets_calendar`
Filers	`filers_holdings`
Macro	`economic_calendar_list`
Live (stream)	`ws_subscribe`, `ws_unsubscribe`, `ws_poll`, `ws_collect`, `ws_status`, `ws_disconnect`

Vale la pena destacar algunos patrones:

Las herramientas paginadas aceptan cursor/limit y devuelven un meta.next_cursor para obtener la siguiente página. Las herramientas de listado stocks_* — stocks_filings, stocks_earnings, stocks_insiders, stocks_ownership, stocks_events, stocks_compensation — también entienden max_items: configúralo y se auto-paginarán, recopilando hasta esa cantidad de elementos en varias páginas en una sola llamada.

Las herramientas de alto tráfico (last_trade, last_quote, last_tvl, stocks_profile, stocks_search) vienen con un esquema de salida y devuelven structuredContent junto con el texto legible para humanos, para que los clientes también puedan leerlas de forma automatizada.

Cada herramienta también lleva anotaciones de MCP. Las herramientas de datos son readOnlyHint: true (y openWorldHint: true, ya que se conectan a la API externa), mientras que las herramientas WebSocket que cambian el estado de la conexión son readOnlyHint: false, destructiveHint: false.

Los resultados están limitados en tamaño a aproximadamente 60k caracteres (consulta MAX_RESULT_CHARS en src/util.ts). Cuando un endpoint pesado — estados financieros XBRL completos, screener, barras OHLCV — devuelve más que eso, el servidor recorta su array más grande y añade una nota _truncated que explica cómo acotar la consulta.

Streaming WebSocket en vivo

El streaming es el caso complicado: no encaja perfectamente en una sola solicitud/respuesta. Así que el servidor mantiene un WebSocket persistente abierto, almacena en búfer los frames a medida que llegan, y las herramientas simplemente leen de ese búfer. Los canales (el campo product) son cex (cripto), dex (operaciones DEX), fx (forex), us (acciones de EE. UU.) y tvl (TVL de pools DEX).

Hay dos formas de trabajar con ello:

Suscribirse + sondear, para flujos continuos: llama a ws_subscribe una vez, y luego sigue llamando a ws_poll. El primer sondeo te da una cola reciente; devuelve el next_seq resultante como after_seq y desde entonces solo recibirás frames más nuevos. ws_status te muestra la conexión y qué está suscrito, y ws_disconnect lo desmonta todo.
Recolectar, para una consulta rápida de una sola vez: ws_collect se suscribe, espera hasta duration_ms (o hasta que haya visto max frames), devuelve lo que capturó y limpia cualquier suscripción que haya tenido que crear. Perfecto para "dame unos segundos de BTCUSD."

La conexión se reconecta sola y reproduce tus suscripciones cuando lo hace. El búfer es una ventana deslizante, así que los frames más antiguos eventualmente se caen — y cuando lo hacen, te enterarás a través de dropped/gap.

Prompts

Estos son flujos de trabajo guiados de múltiples herramientas que tu cliente puede mostrar como comandos de barra:

company_snapshot (ticker) — combina stocks_profile, stocks_ratios, el stocks_filings más reciente y last_trade en un solo informe.
compare_companies (tickers) — alinea varios tickers lado a lado en los ratios clave.
market_now — qué está abierto y cerrado en este momento, más los eventos macro de alto impacto que se avecinan.

Registro y apagado

El servidor anuncia la capacidad de logging de MCP y envía notifications/message estructurados al cliente cada vez que algo sucede con la conexión (WebSocket open/close/reconnect/error) o al apagarse — y también refleja todo eso en stderr.

Cuando recibe una SIGINT o SIGTERM, cierra el WebSocket en vivo y apaga el servidor limpiamente antes de salir.