Crypto Prices, ICT Signals & Channel Stats API

Pay-per-call crypto toolkit: one tool call per run, structured JSON in the dataset, no API key. It exposes twelve ready-made tool calls — market data (prices, ICT analysis, sentiment) plus read-only, backtested Telegram signal-channel statistics — as an Apify Actor that AI agents and automations can call directly.

What you get

• Live prices & 24h stats for 100+ coins.
• Historical prices with technicals – candles plus SMA/EMA/RSI/MACD and the price range.
• OHLC candles with ICT analysis – order blocks, fair value gaps, liquidity sweeps, market structure, displacement.
• Sentiment – Fear & Greed index, price/RSI sentiment, social snapshot, trending coins.
• Market overview – global market cap, BTC dominance, top coins, market mood.
• Coin comparison – price, volume and performance side by side.
• ICT scalping signal in Cornix format, plus the raw ICT block behind it.
• Signal-channel statistics – our tracked Telegram signal channels, continuously backtested signal-by-signal (1-minute candles, fixed risk unit R, several exit strategies): leaderboard plus per-channel expectancy, win rate, drawdown and methodology. Look up any channel by name / @username (channel_find) or by ID (get_channel_stats). Missing one? channel_request queues it for tracking automatically (backtest-only, capped; no forwarding). Read-only proxy of the operator's tracking API.

Why use it

• Zero setup – no API keys, no exchange accounts, no infrastructure: one tool call in, one structured JSON item out. Pay only for successful calls (failures are free), no subscription.
• Built for agents – 12 ready-made tool calls that drop straight into AI agents, n8n, Make, LangChain or plain HTTP. No crypto-API plumbing to build or maintain.
• ICT analysis included – order blocks, fair value gaps, liquidity sweeps and market structure, plus a ready-to-read signal in Cornix format.
• Statistics you cannot buy elsewhere – leaderboard and per-channel numbers (expectancy, win rate, profit factor, drawdown, lower confidence bound) for tracked Telegram signal channels that are continuously backtested – query any of them by name / @username or channel ID. Check a channel's real track record before following it.
• Safe to automate – read-only, posts nothing, touches no database; every response carries ok, data and duration_ms.
• No lock-in – ≈ $5 per 1,000 successful calls (see Pricing); every run is a fresh decision.

Tools and arguments

Tool	Arguments	Returns
get_crypto_price	coin, currency?	Live price, 24h change, day high/low, volume, 7d sparkline
get_historical_prices	coin, currency?, days	Candles plus SMA/EMA/RSI/MACD technicals and price range
get_ohlc_data	coin, currency?, days	OHLC candles with ICT analysis (order blocks, FVGs, liquidity sweeps, market structure)
get_crypto_sentiment	coin, currency?	Fear & Greed, price sentiment, social data, trending
get_market_overview	currency?, limit?	Global market cap/dominance, top coins, market mood
compare_coins	coins (comma list), currency?	Side-by-side price, volume and performance
generate_trading_signal	coin, currency?, timeframe?	ICT scalping signal (Cornix format) plus the raw ICT block
channel_leaderboard	min_trades?, strategy?, sort?, limit?	Tracked signal channels ranked by the lower confidence bound of expectancy, plus hidden/pending counts
get_channel_stats	channel_id, strategy?	Full statistics for one channel: expectancy (mean/median), hit rate, profit factor, drawdown, per-strategy comparison
channel_find	name, min_trades?, limit?	Resolve a channel name or @username fragment to matching tracked channels with their statistics
channel_methodology	–	How the numbers are produced: simulation assumptions, risk unit R, ranking and admission rules (plain text)
channel_request	channel_id or name	Queues a not-yet-tracked channel for tracking (backtest-only, capped at 5 new channels/day); tells whether the channel is already tracked

How to use it

Input – exactly one tool call per run:

{ "tool": "get_ohlc_data", "arguments": { "coin": "bitcoin", "days": "30" } }

Signal-channel statistics example (read-only, no API key):

{ "tool": "channel_leaderboard", "arguments": { "min_trades": 20, "limit": 10 } }

Missing channel? Request it — the operator's tracker queues it (backtest-only, capped):

{ "tool": "channel_request", "arguments": { "channel_id": -1001234567890 } }

Dataset output – one item per run:

{
  "tool": "get_ohlc_data",
  "arguments": { "coin": "bitcoin", "days": "30" },
  "ok": true,
  "data": { "coin": "bitcoin", "interval": "4h", "total_candles": 180, "candles": ["..."], "ict_analysis": { "...": "..." } },
  "duration_ms": 926,
  "generated_at": "2026-09-25T06:52:31.000Z"
}

The key-value store also holds a compact run summary under OUTPUT (tool, ok, duration_ms, generated_at). A failed call is written with ok: false and an error message and is not charged.

Pricing

Pay-per-event: $0.005 per successful tool call plus $0.00005 actor start. No subscription, no API key.

Notes and limits

• Sources: Binance public market data, CoinGecko, alternative.me (Fear & Greed).
• The Telegram sender and the scanner-state tools of the MCP server are not part of this Actor – it never posts to a chat.
• The channel statistics tools are a read-only proxy of the operator's channelstats API (server-side credentials; the Actor never touches a database). They return simulated results for publicly tracked channels, not trade advice.
• Analysis output only, not financial advice. Crypto markets are highly volatile.

---

🚀 Crypto Trading MCP Server (self-hosted scanner & MCP server)

MCP Server für ICT-basierte Crypto Trading Signale im Cornix Format mit 25X Cross Leverage.

🔍 For detailed pipeline architecture, AI gate logic, reject reasons, and fail-open/fail-closed behaviour, see ./AGENTS.md.

Features

• 📊 Echtzeit Crypto Preise (CoinGecko API)
• 📈 Historische Preisdaten mit technischen Indikatoren (SMA, EMA, RSI, MACD)
• 🕯 OHLC Kerzendaten mit ICT Analyse
• 🧠 Sentiment Analyse (Fear & Greed, Social Media, Community)
• 🎯 ICT Trading Signale im Cornix Format (Scalping)
• 🌍 Markt-Übersicht mit Top Coins
• 🩺 Strukturierter Scanner-Watchdog mit healthy / degraded / no_signal / recovering / down
• 💾 RAM + Root-Disk Monitoring mit Fokus auf Schonung des internen Root-Filesystems
• 🧾 Strukturierte Reject- und Candidate-Summaries für Debugging und Telegram/OpenClaw-Orchestrierung

ICT Konzepte

Der Server analysiert folgende Inner Circle Trader Konzepte:

• Order Blocks (Bullish/Bearish OB)
• Fair Value Gaps (FVG)
• Liquidity Sweeps (Buy/Sell Side Liquidity)
• Market Structure (HH, HL, LH, LL)
• Displacement (starke Preisbewegungen)

MCP Tools

Tool	Beschreibung
get_crypto_price	Aktueller Preis eines Coins
get_historical_prices	Historische Preise + Technische Analyse
get_ohlc_data	OHLC Kerzen + ICT Analyse
get_crypto_sentiment	Umfassende Sentiment Analyse
generate_trading_signal	ICT Scalping Signal (Cornix Format)
get_market_overview	Gesamte Marktübersicht
compare_coins	Multi-Coin Vergleich
scanner_health	Voller strukturierter Health-Block inkl. Watchdog, Ressourcen, Rejects, Candidates
scanner_watchdog_status	Kompakter Watchdog-/Alarm-Block für /scanhealth
scanner_logs_tail	Letzte Scanner-Logzeilen
scanner_config_effective	Effektive Scanner-Konfiguration ohne Secrets
scanner_recent_summary	Kompakte Scanner-Zusammenfassung
scanner_last_rejections	Letzte Rejects + häufigste Block-Gründe
scanner_last_candidates	Near-Miss-Kandidaten mit strukturierter Begründung
scanner_system_resources	RAM- und Root-Disk-Status
scanner_status_text	Telegram-tauglicher Klartext-Status für /scanner
scanner_test_telegram	Testnachricht an das Scanner-Telegram-Ziel

CLI Surfaces / Slash-Command-Alignment

Operational semantics used by OpenClaw/Benny:

• /scanner / /scanner status
  • operational state only
  • based on scanner health/log/status surfaces
  • answers: healthy?, sending?, blocked?, degraded?
• /scanner live
  • GPT-5.4 live operator view
  • not just a raw alias for scan:once
  • should combine fresh scanner output with operator judgment/explanation
• /scanner verify
  • stricter second opinion / re-validation
  • asks whether the latest setup still holds right now

Für OpenClaw-/Telegram-nahe Aufrufe gibt es jetzt schlanke CLI-Entrypoints:

npm run scanner         # kompakter Textstatus ähnlich /scanner
npm run scanhealth      # strukturierter Watchdog-Block ähnlich /scanhealth
npm run scannerlogs     # Log-Tail ähnlich /scannerlogs
npm run scannerconfig   # effektive Config ähnlich /scannerconfig

npm run scanner:health
npm run scanner:watchdog
npm run scanner:summary
npm run scanner:rejections
npm run scanner:candidates
npm run scanner:resources
npm run scanner:logs
npm run scanner:config
npm run scanner:test-telegram

Oder direkt:

node src/scanner-cli.js status
node src/scanner-cli.js watchdog --text
node src/scanner-cli.js logs --limit 80 --text
node src/scanner-cli.js config --text
node src/scanner-cli.js rejections --limit 10 --text
node src/scanner-cli.js candidates --limit 10 --text
node src/scanner-cli.js resources --text

Watchdog / Health-Modell

scanner_health und die CLI-Surfaces liefern jetzt ein strukturiertes Modell mit:

• State: healthy, degraded, critical, no_signal, recovering, down
• Conditions: konkrete Warn-/Kritisch-Gründe (stale scans, no-signal, API-Fehler, RAM, Root-Disk)
• Recovery: ob sich der Scanner nach jüngeren Problemen wieder erholt hat
• Reject-Reason Stats: aggregierte Hauptblocker
• Candidate Summaries: strukturierte Near-Miss-Setups
• Storage Advice: Hinweis, /mnt/apps für Logs und Runtime-Daten zu bevorzugen

Installation & Konfiguration

1. Server starten (manuell testen)

cd cryptomcpserver
npm install
npm run mcp

1b. Auto-Scanner (15m Scalping → Telegram)

cd cryptomcpserver
npm run scan

Der Scanner unterstützt jetzt einen hybriden Watchlist-Modus:

• Core-Liste: feste Majors, die möglichst in jedem Lauf geprüft werden
• Dynamic-Liste: zusätzliche Coins aus einem tieferen Top-100-Universum nach SCAN_TOP_COINS_ORDER
• Ziel: nicht mehr nur die momentane kleine Top-Liste abgrasen, aber trotzdem die Last auf kleinen Hosts wie dem Dell Wyse begrenzen

Docker/Compose auf diesem Host:

cd cryptomcpserver

# Produktiver Dauerscanner
docker-compose up -d --build scanner
docker-compose logs --tail=80 scanner

# Optional: MCP-Server separat starten (stdio-basiert, für Tool-Zugriffe/Debug)
docker-compose up --build mcp

Hinweis: Auf diesem Host sollte docker-compose verwendet werden, nicht docker compose.

Wichtig zur Rollenverteilung:

• scanner = produktiver Auto-Scanner/Telegram-Worker
• mcp = MCP-Toolserver über stdio (src/index.js)
• Der Scanner hängt nicht davon ab, dass der MCP-Prozess mitläuft. MCP ist für strukturierte Tool-Zugriffe, Debug und externe Clients gedacht.

Optionale Scanner-/Watchdog-Umgebungsvariablen

Scanner:

• SCAN_TOP_COINS_LIMIT (Default 18 on small hosts; how many coins are actually scanned per run)
• SCAN_WATCHLIST_MODE (Default hybrid; hybrid = fixed core list + dynamic picks, anything else falls back to plain top-list slicing)
• SCAN_WATCHLIST_SOURCE_LIMIT (Default 100; dynamic picks are sourced from this deeper market universe)
• SCAN_CORE_COINS (Default BTC,ETH,SOL,XRP,BNB,DOGE,ADA,LINK,AVAX,SUI)
• SCAN_WATCHLIST_DYNAMIC_SLOTS (Default auto-derived from SCAN_TOP_COINS_LIMIT - coreCount; recommended 8 when limit is 18)
• SCAN_TOP_COINS_ORDER (Default volume_desc)
• SCAN_INTERVAL_MINUTES (Default 15)
• SCAN_TIMEFRAME (Default 15m)
• SCAN_DELAY_BETWEEN_COINS_MS (Default 1000, recommended 1200 on weaker boxes)
• SCAN_MIN_CONFIDENCE (Default MEDIUM)
• SCAN_MIN_RULES_HIGH (Default 8)
• SCAN_MIN_RULES_MEDIUM (Default 9)
• SCAN_MIN_VOLUME_24H (Default 30000000)
• SCAN_SCORE_RATIO_MIN (Default 4, e.g. 3 for more throughput)
• SCAN_REQUIRE_KILLZONE (Default true, set false to make killzone advisory only)
• SCAN_FAKE_THRESHOLD (Default 2, higher = less strict fake blocking)
• SIGNAL_COOLDOWN_MINUTES (Default 120)
• SCAN_STRUCTURE_RECENCY_HOURS (Default 36)
• SCAN_OB_HARD_MAX_DISTANCE_PCT (Default 1.5)
• SCAN_OB_SOFT_MAX_DISTANCE_PCT (Default 2.2, only with extra confluence)
• SCAN_KILLZONE_LONDON_START_HOUR / SCAN_KILLZONE_LONDON_END_HOUR (Defaults 8 / 11)
• SCAN_KILLZONE_NEWYORK_START_HOUR / SCAN_KILLZONE_NEWYORK_END_HOUR (Defaults 14 / 17)
• SCAN_KILLZONE_GRACE_MINUTES (Default 45, allows strong setups close to session edges)
• SCAN_KILLZONE_SOFT_CONFLUENCE_MIN (Default 2, extra confluence needed for soft pass)
• DATA_SOURCE (Default binance)

Recommended Dell Wyse defaults

• SCAN_WATCHLIST_MODE=hybrid
• SCAN_TOP_COINS_LIMIT=18
• SCAN_WATCHLIST_SOURCE_LIMIT=100
• SCAN_CORE_COINS=BTC,ETH,SOL,XRP,BNB,DOGE,ADA,LINK,AVAX,SUI
• SCAN_WATCHLIST_DYNAMIC_SLOTS=8
• SCAN_INTERVAL_MINUTES=15
• SCAN_DELAY_BETWEEN_COINS_MS=1200
• SCAN_MTF_MIN_AGREE=2

Watchdog:

• WATCHDOG_NO_SCAN_MINUTES (Default max(45, SCAN_INTERVAL_MINUTES*3))
• WATCHDOG_NO_SIGNAL_MINUTES (Default max(180, SIGNAL_COOLDOWN_MINUTES))
• WATCHDOG_API_ERROR_WARN_COUNT (Default 4)
• WATCHDOG_API_ERROR_CRIT_COUNT (Default 8)
• WATCHDOG_RAM_WARN_BYTES (Default 1gb)
• WATCHDOG_RAM_CRIT_BYTES (Default 512mb)
• WATCHDOG_ROOT_DISK_WARN_BYTES (Default 2gb)
• WATCHDOG_ROOT_DISK_CRIT_BYTES (Default 512mb)
• WATCHDOG_RECOVERY_ENABLED (Default true)

Für Telegram + KI:

• TELEGRAM_BOT_TOKEN
• TELEGRAM_CHAT_ID
• OPENAI_API_KEY oder OpenRouter-kompatible Variablen
• CRYPTOPANIC_API_KEY (optional)
• CRYPTOPANIC_CACHE_TTL_MS (Default 3600000 = 1h per coin)
• CRYPTOPANIC_ERROR_CACHE_TTL_MS (Default 600000 = 10m backoff after 429/error)

Storage-Hinweis

Dieser Repo läuft idealerweise unter /mnt/apps. Das Watchdog-/Config-Modell zeigt explizit an, ob Projekt und Logs bereits auf /mnt/apps liegen, damit das interne Root-Filesystem geschont wird.

⚠️ Disclaimer

Dies ist keine Finanzberatung. Kryptowährungen sind hochvolatil. Handeln auf eigenes Risiko. DYOR!

Orchestrator pre-send gate

The scanner can now pause before Telegram send and wait for an explicit orchestrator decision. On this host the intended path is: scanner -> Benny/OpenClaw HTTP endpoint -> live market plausibility check -> final APPROVE/VETO/HOLD.

Env flags:

• SCAN_ORCHESTRATOR_GATE=true enables the gate
• SCAN_ORCHESTRATOR_WAIT_MS how long to wait for a decision
• SCAN_ORCHESTRATOR_TIMEOUT_ACTION=HOLD|VETO|APPROVE fallback on timeout

Pending signals are written to runtime/orchestrator-gate/pending/*.json. Decisions are read from runtime/orchestrator-gate/decisions/*.json.

Helper CLI:

npm run scanner:gate
npm run scanner:gate-live-check -- runtime/orchestrator-gate/pending/<id>.json
node src/orchestrator-gate-cli.js approve <id> "looks good"
node src/orchestrator-gate-cli.js veto <id> "skip this one"
node src/orchestrator-gate-cli.js hold <id> "wait for next candle"