WhaleScope MCP

WhaleScope MCP — Binance Futures 市場インテリジェンス

🇮🇩 Bahasa Indonesia | 🇬🇧 英語

Binance USDS-M Futures の公開データ（ファンディングレート、 建玉、ロング／ショート比率、テイカー出来高、ローソク足、オーダーブック、 ボラティリティ）に加え、Binance Spot との比較データ（価格、オーダーブック、ローソク足、 CVD）を、Claude から呼び出せるツールとして提供する MCP サーバーです。提供されるデータはすべて 公開・読み取り専用です。注文や取引は行わず、個人アカウントのデータにもアクセスしません。

クイックデプロイ

このボタンを押すと、リポジトリをクローンし、あなた自身の Cloudflare アカウントに Worker を作成します。 KV ネームスペースと D1 データベースも自動で新規プロビジョニングされます（Cloudflare があなたのアカウント用に新しい id／database_id を生成するため、手動で作成する必要はありません）。 完全なゼロタッチではありません。手動で必要な作業について、正直に説明します。 クリック後、シークレットは必ず設定する必要があります（Cloudflare は外部サービスの値を推測できません）。必要なものの一覧は、このリポジトリの .dev.vars.example を確認するか、以下の Vercel プロキシのセットアップを参照してください。PROXY_URL／PROXY_SECRET は必須です（46 個すべてのツールで必要です）。

目的

Binance Futures 市場におけるポジション状況を把握できるようにします。価格だけでなく、誰がどんなポジションを持っているのか（個人トレーダーかトップトレーダーか）、レバレッジがどれほど混み合っているか、流動性がどの価格に集中しているかを、別の取引所ダッシュボードを開かずに、Claude との会話で直接確認できます。

メリット

• 多くのシグナルを一か所で確認できます。 ファンディングレート、建玉、オーダーブック、 オーダーフローを、タブを切り替えることなく、一つの MCP コネクターから確認できます。
• 個人トレーダーと大口トレーダーを区別できます。 binance_get_top_trader_ratio では、 トップトレーダーのみの内訳を取得できます（binance_get_long_short_ratio の全体集計とは別です）。 個人トレーダーと大口トレーダーのポジションが乖離しているかを確認するのに役立ちます。
• 重要なデータは Binance のネイティブデータを使用します。 価格、ファンディングレート、ローソク足、 オーダーブックはすべて Binance のネイティブ経路から取得するため、特に小規模または流動性の低いペアでも精度を保てます。
• 個人利用は無料です。費用のセクションを参照してください。

特長

• 29 個のツールで、5 つの分析視点をカバーします。市場の方向性の偏り、重要な価格帯 （オーダーブック）、約定の確認（オーダーフロー／アグレッサー）、Futures と Spot の比較 （レバレッジ主導の動きと実需の比較）、市場全体のスキャン（全ペアにわたる極端なファンディングレートの検出や、 複数ペアの指標の比較）に対応します。さらに、複数のツール呼び出しをせずに概要を素早く確認できる 複合ツール（binance_analyze_pair）と、Workers KV に保存される設定／履歴（ペアごとのしきい値、ベーシス時系列）も備えています。
• Binance の市場データに対して読み取り専用です。注文や取引は行いません。状態を書き込む唯一のツール （binance_set_pair_threshold）も、Workers KV にあなた自身のしきい値設定を保存するだけで、 Binance アカウントや外部データには一切触れません。
• 各ツールの制限を明確に示しています（以下のセクションを参照）。すべてのデータが完璧であるかのように装うことはありません。
• 個人利用なら無料枠のインフラ（Cloudflare Workers と Vercel Hobby）で十分です。100％ Binance ネイティブで、 サードパーティのアグリゲーターへの依存もありません。

欠点

• ほとんどのツールはリクエスト／レスポンス方式です。 Funding／OI／ローソク足／オーダーブック／比率はすべて、スナップショットまたは定期的な履歴データです。利用可能なストリーミングデータは限られています。 binance_get_realtime_liquidations と binance_get_contract_events（ストリームゲートウェイ VPS 経由。下記を参照）のみで、価格やオーダーブックのティックごとのプッシュ配信はありません。
• 清算データは完全なものではなく、サンプリングされています。 2026-08-28 以降、binance_get_realtime_liquidations を利用できます。WebSocket !forceOrder@arr（dstream.binance.com）を Oracle Singapore の VPS 上で常時バッファリングしています（stream-gateway/。Cloudflare の外部にあり、Cloudflare Worker 自体は引き続き Binance の WAF にブロックされています）。Binance はこのストリームを最大で 1 シンボルあたり毎秒 1 イベントに制限しているため、取得できるのは清算のサンプルであり、すべての清算ではありません。それでも、binance_detect_mm_activity のストップ狩りクラスターを確認するには十分です（3 つ目のプロキシ指標で、価格を基準に狩りの方向を判定します）。過去にさかのぼれる清算履歴はありません（バッファは 24 時間分です）。
• 初期セットアップには Vercel プロキシが必要です（必須）。インストールするだけですぐに使えるわけではなく、最初に一度だけ手動で設定する必要があります。
• オンチェーンのウォレットデータや、Binance Futures USDS-M 以外の取引所のデータはありません。

データソース：単一経路で、100％ Binance ネイティブです。

• Binance ネイティブデータを Vercel プロキシリレー経由で取得します。 Binance のドメイン（fapi.binance.com）は、Cloudflare Workers からのトラフィックを WAF レベルでブロックします（403、全社規模のブロック。この Worker から直接テスト済みで、推測ではありません）。Vercel は異なる IP プールを使用するため、同じブロックの影響を受けません。Cloudflare Worker は proxy/ の小さなプロキシ（別の Vercel プロジェクト。proxy/README.md を参照）を経由してリレーします。この経路は、Funding Rate（現在値と履歴）、ローソク足／OHLCV、複数時間足のバイアス、実現ボラティリティ、24 時間統計、オーダーブックの深さ、アグリゲート取引、未決済建玉（現在値と履歴）、ロング／ショート比率（全体およびトップトレーダー）、テイカーの買い／売り出来高比率、スポット価格に使用されます（market=spot パラメーターを指定すると、プロキシは Binance Spot API api.binance.com にもリレーします。proxy/README.md を参照）。

そのため、この Worker は PROXY_URL／PROXY_SECRET を必要とします（Vercel プロキシ。46 個すべてのツールで必須です）。下記のセットアップのセクションを参照してください。

追加の認証情報なしで、キャッシュと状態を管理します。 上流からのレスポンス（Funding Rate、ローソク足、OI など。ただし、鮮度が厳密に求められるオーダーブックとアグリゲート取引を除く）は、エンドポイントに応じて 5 秒～1 時間の階層キャッシュに保存されます。Cloudflare Workers に組み込まれた Cache API を使用するため、設定は不要です。ペアごとのカスタムしきい値は Workers KV（バインディング CONFIG_KV）に保存されます。時系列データ（ベーシス＋Funding＋OI、および binance_detect_mm_activity の 6 つのシグナルスコア）は D1（バインディング DB）に保存されます。固定の 50 ペアのウォッチリスト（src/shared.ts の SNAPSHOT_WATCHLIST。時価総額順。例：BTCUSDT、ETHUSDT、SOLUSDT、BNBUSDT、XRPUSDT など）に対し、Cron Trigger によって 5 分ごとに自動でデータが追加されます。

追加のプロキシなしで、複数の取引所を比較できます。 whalescope_compare_funding_across_exchanges は Worker から Bybit／OKX／Hyperliquid に直接アクセスします（実際の Cloudflare エッジからテスト済みで、Binance のように WAF や地域ブロックの影響を受けません）。これら 3 つの取引所について、認証情報や追加のセットアップは不要です。

提供機能

ツール	用途	ソース
binance_get_funding_rate	最新のファンディングレート＋ベーシス（マーク価格とインデックス価格の乖離）	Binance ネイティブ
binance_get_funding_rate_history	ファンディングレートの経時的な推移	Binance ネイティブ
binance_get_spot_price	Binance のスポット価格＋先物マーク価格に対する実際のベーシス（上記のインデックス価格に対するベーシスとは異なります）。先物のみのペア（スポットに上場されていないもの）の場合は、明確なエラーを返します	Binance ネイティブ（スポット）
binance_scan_funding_extremes	すべての先物ペアのファンディングレートを一括スキャン（1 回の一括呼び出し）し、ロング／ショートの偏りが最も大きい上位ペアを返します	Binance ネイティブ
binance_get_open_interest	最新の OI スナップショット	Binance ネイティブ
binance_get_open_interest_history	OI の増減傾向	Binance ネイティブ
binance_get_long_short_ratio	集計されたロング対ショート比率（全トレーダーを合算）＋傾向	Binance ネイティブ
binance_get_top_trader_ratio	トップトレーダーに限定したロング／ショート比率（アカウント別またはポジションサイズ別の純粋な内訳）	Binance ネイティブ
binance_get_order_book_depth	オーダーブックのスナップショット（買い／売り）、スプレッド、最大のウォール	Binance ネイティブ
binance_get_order_book_imbalance	深さ 5／10／20 における買いと売りの出来高の不均衡。バイアスのラベル（強気／弱気／均衡）付き	Binance ネイティブ
binance_get_agg_trades	吸収の検出に使う、粒度の細かい個々の取引（買い／売りアグレッサー）	Binance ネイティブ
binance_get_taker_volume_ratio	積極的な買い／売り圧力（テイカー出来高）。Binance の公式統計	Binance ネイティブ
binance_get_klines	時間足ごとのローソク足 OHLCV。startTime／endTime に対応（過去の長期間の履歴を取得してバックテストに利用可能。1 回の呼び出しにつき最大 1500 本）	Binance ネイティブ
binance_get_multi_timeframe_bias	5 つの時間足（1m/5m/15m/1h/1d）における強気／弱気／横ばいのバイアス	Binance ネイティブ
binance_get_realized_volatility	グリッド幅の調整に使う、対数リターンから算出した過去の実現ボラティリティ（15m/1h）	Binance ネイティブ
binance_get_24hr_ticker	24 時間の統計概要（公式ローリングウィンドウ）	Binance ネイティブ
binance_get_spot_ticker_24hr	スポット版の 24 時間統計（価格、変化率、VWAP、出来高、取引数）。上記の先物版と比較できます	Binance ネイティブ（スポット）
binance_get_spot_book_ticker	スポットのリアルタイム最良買い／売り気配＋数量。フルオーダーブックより軽量です	Binance ネイティブ（スポット）
binance_get_spot_order_book	スポットのオーダーブックの深さ（買い／売り、スプレッド、最大のウォール）	Binance ネイティブ（スポット）
binance_get_spot_klines	時間足ごとのスポットローソク足 OHLCV。startTime／endTime に対応（1 回の呼び出しにつき最大 1000 本）	Binance ネイティブ（スポット）
binance_get_spot_agg_trades	粒度の細かい個々のスポット取引（レバレッジを含まない実際の CVD）	Binance ネイティブ（スポット）
binance_get_spot_avg_price	スポットの移動平均価格（数分間のウィンドウ。直近の取引価格より安定しています）	Binance ネイティブ（スポット）
binance_check_spot_listing	ペアが Binance スポットに上場されているか、および取引ステータスを確認します。上場状況が不明なペアについて、他のスポットツールを呼び出す前に使用します	Binance ネイティブ（スポット）
binance_analyze_pair	1 ペアの概要を素早く取得（複合分析）：ファンディング、OI の傾向、トップトレーダーの傾向、テイカー出来高、オーダーブック、価格バイアスを 1 回の呼び出しで 6 つのツールを使って分析します	Binance ネイティブ
binance_compare_symbols	2～10 ペアについて、1 つの指標（ファンディングレート、24 時間変化率、OI、トップトレーダー比率、テイカー比率）を一括比較し、極端なものから順に並べます	Binance ネイティブ
binance_set_pair_threshold	ペアごとにファンディング／ベーシスのカスタムしきい値を設定します（デフォルトの ±0.03%／±0.05% を上書き）。Workers KV に保存されます	Workers KV
binance_get_pair_threshold	ペアに設定済みのカスタムしきい値を確認します	Workers KV
binance_get_basis_history	ベーシス＋ファンディング＋OI の時系列履歴（Cron による 5 分ごとの D1 スナップショット）。常時固定の 50 ペアのウォッチリストで利用可能です。他の頻繁にクエリされるペアではベストエフォートで取得できます。何度も手動確認することなく、「ベーシスが拡大してから戻る」動きを検出できます	D1 + Cron Trigger
binance_get_orderbook_delta	約 1～2 秒間隔のオーダーブックの 2 つのスナップショットを比較し、スナップショット間のウォールを比較して、実際のスプーフィングを検出します（その水準を価格が通過せずにウォールが消失）。1 つのスナップショットのみを取得する binance_get_order_book_depth とは異なります	Binance ネイティブ
binance_detect_mm_activity	6 つの MM／クジラシグナル（吸収、実際の 2 スナップショットによるスプーフィング、対称型ストップハント＋OI 減少プロキシ＋取引出来高集中プロキシ、ベーシス裁定、OI ダイバージェンス、極端なファンディング）からスコア＋ティア（弱／中程度／強／極端）を算出します。手動での 5～6 回のツール呼び出しに代わります。実際の清算データがないため、ストップハントの検出は引き続き利用できません（恒久的に削除済み）。既知の制限を参照してください	Binance ネイティブ
binance_market_regime	ADX(14)、OI の傾向、CVD、ボラティリティ／出来高の急増を使って、市場の状態（TRENDING_UP/DOWN、RANGING、BREAKOUT、ACCUMULATION、DISTRIBUTION）を分類します	Binance ネイティブ
binance_backtest_signal	binance_detect_mm_activity のシグナルを実証的に検証します。D1 のシグナル履歴（固定ウォッチリスト）から勝率／平均リターン／最大ドローダウンを算出し、フォワードリターンは過去の klines からオンデマンドで計算します	D1 + Binance ネイティブ
whalescope_backtest_pipeline_decisions	pipeline_decision_log に保存された full_pipeline の判断（Phase 2 のエントリーアラート＋persist=true）をフォワードテストします。判断（TRADE/WATCH/NO_TRADE）ごと、およびスコア区分（lt_40／40_55／gte_55）ごとに、勝率／平均リターン／SL 到達率を算出します。フォワードリターンは klines からオンデマンドで計算され、事前計算済みの列は使いません。また、重みの自動調整も行いません	D1 + Binance ネイティブ
binance_analyze_smart_money	5 つの変数（トップトレーダー比率、グローバルアカウント比率、OI の変化量、ファンディングレート、オーダーブックの不均衡）から、スマートマネー（トップトレーダー）と個人投資家（グローバルアカウント）の乖離スコアを算出します。LONG_LIQUIDATION_RISK/BULLISH_ACCUMULATION/SHORT_SQUEEZE_RISK/NEUTRAL の状態と confidenceScore を返します。吸収／スプーフィング／ストップハント／ベーシス裁定の 6 シグナルを使う binance_detect_mm_activity とは異なり、トップトレーダー対個人投資家に特化しています	Binance ネイティブ
whalescope_compare_funding_across_exchanges	Binance/Bybit/OKX/Hyperliquid の 1 ペアについて、ファンディングレート、直近価格、オープンインタレスト、24 時間変化率を比較して乖離を検出します。取引所間で MM 検出シグナルを相互検証します。Binance 専用ではない唯一のツールです	Binance ネイティブ + Bybit + OKX + Hyperliquid
binance_get_tool_catalog	すべてのツールの一覧を、カテゴリ／トークンコスト／ユースケースとともに取得します。カテゴリごとのフィルターにも対応します。個別ツールを多数呼び出す前に、まずこれを確認してください。名前と説明はツールレジストリから自動取得されるため常に正確ですが、カテゴリとトークンコストは手動管理です	半自動
binance_get_adl_risk	ペアごとの自動デレバレッジ（Auto-Deleveraging）リスクを評価（LOW/MEDIUM/HIGH）します。30 分ごとに更新されます	Binance ネイティブ
binance_get_insurance_fund_balance	証拠金資産ごとの保険基金残高の過去スナップショット	Binance ネイティブ
binance_get_mark_price_klines	取引価格ではなく、清算／ファンディングの基準となるマーク価格のローソク足	Binance ネイティブ
binance_get_index_price_klines	複数のスポット取引所価格を合成したインデックス価格のローソク足。プレミアムインデックス／ファンディングの基準です	Binance ネイティブ
binance_get_premium_index_klines	マーク価格とインデックス価格の比率であるプレミアムインデックスのローソク足。ファンディングレートの主要な構成要素です	Binance ネイティブ
binance_get_continuous_klines	原資産ペアごとの PERPETUAL/CURRENT_QUARTER/NEXT_QUARTER 契約のローソク足	Binance ネイティブ
binance_get_quarterly_settlement_price	四半期契約の受渡し／決済価格の履歴（永久契約には適用されません）	Binance ネイティブ
binance_get_composite_index_info	複合インデックスシンボル（例：BTCDOMUSDT）の構成ベース資産＋ウェイト	Binance ネイティブ
binance_get_index_constituents	ペアのインデックス価格を構成する取引所＋価格＋ウェイトの一覧	Binance ネイティブ
whalescope_full_pipeline	Grid Bot Futures の完全な意思決定チェーン（最上位の複合分析）：ハードスクリーニング → Tier-1 インテリジェンス（スマートマネー、MM 複合分析、1h+4h のレジーム、オーダーブック）→ Compass 相当のグリッド範囲を算出（ATR＋スイング高値／安値）→ 各レバレッジ設定について損失予算（risk_usd）に正確に合わせた資金計算 → TRADE/WATCH/NO_TRADE の判断＋コピー＆ペーストですぐ使える Grid Bot パラメーター。1～20 シンボルを一括処理できます。persist=true（任意）を指定すると、コンパクトな行を pipeline_decision_log に書き込みます（source=manual または dropstab＋persist_ref のタブ用スラッグ）。トークンコストが高いため、docs/full_pipeline_framework.mdを参照してください	Binance ネイティブ

detail の規約：summary と full（トークン節約）

上記のうち、配列／履歴データ（klines、agg trades、order book、open interest／funding／basis history、long-short および top-trader ratio）を返すすべてのツールには、任意のパラメーター detail: "summary" | "full" があり、デフォルトは "summary" です。これは2026-08のトークン効率化アップデートで意図的に変更された唯一のデフォルト動作です。パラメーターを削除したのではなく、デフォルトを変更しただけです。

• detail: "summary"（デフォルト）— 派生指標（bias、trend、CVD、dominance など、ツールがすでに算出しているもの）と、最新データ最大10件のみを返します。detail をまったく指定しない場合に使用されます。このパラメーターの存在を知らない従来の呼び出し元にも適用されます。
• detail: "full" — 生の配列／レベルデータをすべて返します。今回のアップデート以前と同じ動作です。

複合ツール（binance_analyze_pair、binance_analyze_smart_money、binance_detect_mm_activity、analyze_futures_grid_risk、whalescope_full_pipeline）も整理されています。テキストは約8～12行に短縮され、structuredContent が短くフラットなキーを持つ主要ペイロードになり、空のフィールド（null／undefined）は除外されます。シグナルや指標が失われることはありません。すべて structuredContent または detail: "full" から引き続き利用できます。

詳細と、名前が変更されたフィールドの対応表： docs/tool_response_reference.md。

分析フレームワーク：マーケットメーカーとクジラの検出

マーケットメーカー（MM）／クジラの個別の身元やポジションを直接確認できるツールはありません。Binance の公開データには、そうした情報が含まれていないためです。このフレームワークでできることは、上記の複数のツールを組み合わせて彼らの活動の痕跡を読み取り、現れたパターンから兆候スコアを算出することです。

検出する4つのシグナルカテゴリ：

シグナル	主なツール	パターンの例
吸収	order book depth、agg trades（futures および spot）、open interest	CVD が横ばい／上昇しているのに価格が停滞＝売り圧力が吸収されている（accumulation）；OI が急上昇して価格が横ばい＝大口ポジションが新たに建てられた
スプーフィング	order book depth、binance_get_orderbook_delta（2-snapshot）	大きな Wall が現れた後、約定される前に消える。その間、価格はそのレベルを実際に越えていない；スプレッドが突然広がり、数秒で元に戻る
ストップ狩り	open interest、agg trades、klines	長い Wick（方向は問わない）＋反転するローソク足の小さな実体。OI-drop proxy と価格ごとの積極的な取引の集中が補助となります。実際の清算による確認は引き続きありません（恒久的に削除済み。「制限事項」を参照）
ベーシス・アービトラージ	spot price、funding rate、open interest	spot-futures basis が広がった後、すぐに戻る；funding が極端で OI が上昇（futures のショート／spot のロングによるヘッジの兆候）

目安： 同じ時間枠内で3つ以上のシグナルが一致していれば、MM の活動を示す十分に強い兆候として、さらに調査する価値があります。これはチェックリスト形式のヒューリスティックです（詳細ドキュメントの信頼度 tier を参照）。統計的に較正された確率ではありません。

詳細ドキュメント：docs/mm_detection_framework.md（v4、最終版）。各シグナルの詳細な基準、ステップごとのワークフロー、ライブ用チェックリスト、ツールとシグナルの対応表が記載されています。

フレームワーク：Grid Bot のフルパイプライン（whalescope_full_pipeline）

このリポジトリで最も包括的な複合ツールです。Grid Bot Futures の意思決定チェーン全体を、1回のツール呼び出しで、1つまたは複数のシンボルに対して一度に実行します（1回の呼び出しにつき最大20シンボル）。約8回の手動ツール呼び出し（binance_market_regime ×2、binance_analyze_smart_money、binance_detect_mm_activity、binance_get_order_book_imbalance、analyze_futures_grid_risk など）に加え、それまで対応するツールがなかったグリッド境界の計算も置き換えます。

処理段階（2-wave fetch、reject-early）：

┌───────────────────────────────────────────────────────────────┐
│ WAVE 1 (semua symbol, paralel): ticker24hr, funding, klines    │
│ 1h+4h, OI+histori, agg trades, market context                  │
├───────────────────────────────────────────────────────────────┤
│ HARD SCREEN: tradable? volume >= minimum? |funding| <= maks?   │
│ regime 1h/4h != BREAKOUT?                                       │
│   → GAGAL = NO_TRADE, Wave 2 TIDAK PERNAH DIPANGGIL             │
├───────────────────────────────────────────────────────────────┤
│ WAVE 2 (survivor saja, paralel): top-trader ratio, global      │
│ account ratio, OI histori 24 titik, order book depth 50        │
├───────────────────────────────────────────────────────────────┤
│ TIER-1 SCORING: smart money divergence + 6 skor MM composite   │
│ + order book imbalance + CVD + regime → rankingScore 0-100     │
├───────────────────────────────────────────────────────────────┤
│ GRID BOUNDS (Compass-equivalent): ATR + swing high/low →       │
│ upper/lower/SL/TP/gridCount/gridType                            │
├───────────────────────────────────────────────────────────────┤
│ CAPITAL SOLVE: exact (bukan iteratif) per opsi leverage, pilih  │
│ leverage tertinggi SAFE/MODERATE dengan likuidasi aman          │
├───────────────────────────────────────────────────────────────┤
│ KEPUTUSAN: TRADE / WATCH / NO_TRADE + Grid Bot config siap-pakai│
└───────────────────────────────────────────────────────────────┘

詳細ドキュメント（段階ごとの説明、実例、既知の制限事項）： docs/full_pipeline_framework.md。

実証検証の結果

このフレームワークの技術的な主張はすべて、最終版に含める前に、仮定ではなくデプロイ済みのワーカーで直接検証しています。初期の想定を修正することになった主な検証結果は次のとおりです。

初期の主張	検証結果
リフレッシュレートのスプーフィング検出には500ms未満のポーリングが有効	❌ ワーカー→Vercel→Binanceのプロキシチェーンを経由すると、実際のレイテンシーは1回あたり298～898ms（平均約485ms）であり、この用途には信頼性がありません
トップトレーダー比率の乖離に対するしきい値は共通して適用できる（固定値15％超、または段階的な3～15％）	❌ 一度もトリガーされませんでした。テストした4つのペア（SOLUSDT、BNBUSDT、LINKUSDT、AVAXUSDT）の2時間のウィンドウ内における実際の変動はわずか0.40～2.35ポイントで、いずれのしきい値も大きく下回っていました
トップトレーダー比率の過去データは「30～90日」保持される	⚠️ 修正しました。Binanceでは90日分のデータは一切利用できません。30日分のデータが利用できるのは粗い時間解像度（4時間／1日）のみで、15分解像度のデータは約5日前までしか遡れません
市場が平穏な状態（BTCUSDT）では過剰にトリガーされない	✅ 確認済み。市場が横ばいのときのスコアは約1～1.5/6（弱いティア）で、通常の状態ではフレームワークが誤警報を出しません

詳細（各主張の生データを含む）：セクション10、 docs/mm_detection_framework.md。

知っておくべき正直な制限事項

• ロング／ショート比率（binance_get_long_short_ratio）は、集約された BLENDED 比率であり、「グローバルアカウント（個人投資家）」と「トップ トレーダー（クジラ）」を個別に分類したものではありません。トップトレーダー のみの内訳には、binance_get_top_trader_ratio（Binance ネイティブの機能で、 このツールとは別）を使用してください。
• 小規模または新規上場ペアでは、資金調達率のベーシスがノイズを含む場合が あります。Binance のインデックス価格は複数の現物取引所の加重平均であり、 そのようなペアでは、そのうちの一つが流動性の低い取引所である可能性があります。
• オーダーブックの深さ（binance_get_order_book_depth）は一時点のスナップ ショットです。大きなウォールは数秒で消えることがあります（見せ玉の可能性が あります）。単一のスナップショットを過度に解釈しないでください。実際の スプーフィング検出（2 スナップショット）には、binance_get_orderbook_delta または binance_detect_mm_activity（以下を参照）を使用してください。
• 「トップトレーダー」のしきい値はBinanceから正確に公表されておらず、 データは定期的なスナップショットで、リアルタイムのティックごとのデータでは ありません。
• OI 履歴データ（binance_get_open_interest_history）は、Binance の公式 エンドポイント（/futures/data/openInterestHist）の保持期間によって制限 されています。長期間のデータが必要な場合は、直接確認してください。
• オンチェーンのウォレットデータはありません。
• 清算データはニアリアルタイムかつサンプリング済みで、長期間の履歴は ありません。 binance_get_realtime_liquidations は、VPS 上のストリーム ゲートウェイから24時間分のバッファーを読み込みます（dstream.binance.com 経由の !forceOrder@arr。VPS の IP からは fstream.binance.com への アクセスがブラックホール化されています）。Binance は1シンボルあたり毎秒 1イベントに制限するため、完全なデータではなくサンプルです。過去データを 遡及取得するための、パブリックな市場全体向け REST API はありません。 Cloudflare Worker 自体も、WAF によりBinanceへの WebSocket 直接接続が まだできません。
• binance_detect_mm_activity：スプーフィング検出は現在、実際の2スナップ ショット方式です（他のツールより約1～2秒遅くなります。そのため、2回の 取得の間に明示的な1500msの間隔を設けています。binance_get_orderbook_delta を参照）。以前の1スナップショット方式のヒューリスティックではありません。 ストップハント検出は現在、上下対称です（上ヒゲと下ヒゲの両方を確認します。 以前は上ヒゲのみで、旧バグでした）。さらに、独立した2つのプロキシを使用します （既存の取得データを再利用し、新たな取得は行いません）：ローソク足にヒゲが あるのと同時に OI が2％以上下落していること、および／または、ヒゲの価格帯に 成行注文の出来高が30％以上集中していること（直近100件の aggTrades から算出。 CVD に使うものと同じデータです）。信頼度は段階的に上昇します。プロキシが 0個ならベース、1個ならより高く、2個同時なら最も高くなります。ただし、実際の 価格別清算データは引き続きありません（恒久的な制約。上記を参照）。ストップ ハントの信頼度は、同じツール内の他のシグナルより低いままです。各レスポンスの evidence テキストに記載されます。
• binance_market_regime：ボラティリティ／出来高の急増は、取得した同じ ウィンドウ内で相対的に算出されます（直近10本のローソク足と、その前の10本 を比較）。長期的な過去データのベースラインとの比較ではありません。
• D1 時系列データ（market_snapshots。binance_get_basis_history が読み 込みます）は、固定ウォッチリストの50ペアでは常に利用可能で、その他のペアでは ベストエフォートです。ウォッチリスト外のペアの履歴が記録されるのは、約24時間 内に3回以上クエリされ、かつクエリ頻度が最も高いウォッチリスト外のペア上位5件に 入った場合です（KV カウンター、src/queryFrequency.ts）。この条件を満たすと、 5分ごとの cron が該当ペアのスナップショットを開始します。signal_history （binance_backtest_signal が読み込みます）は引き続きウォッチリストのペア のみが対象で、対象は拡大されません。
• 先物のみのペア（HYPEUSDT、1000PEPEUSDT、PUMPUSDT など）では、Binance Spot に上場されていないため、market_snapshots の spot_price と basis は NULL です。 資金調達率と Open Interest は通常どおり記録されます。そのような ペアで空になるのは basis 列のみです。
• D1 の行にはプルーニング／保持期間の設定がまだありません。時間の経過とともに 行は無制限に増え続けます（50ペア × 約6,048行／日の両テーブル合計です。D1 の 無料枠は1日500万回の書き込みと5GBのストレージで、長期間は余裕がありますが、 恒久的な解決策ではありません）。
• KV から D1 への移行（basis history）では、過去データのバックフィルは 行われません。移行前に Workers KV に保存されていた basis の履歴は失われます。 直近24時間分のデータは、デプロイ後数時間で自然に再蓄積されます。
• binance_backtest_signal：フォワードリターンは過去の klines からオンデマンドで 算出されます（目標時刻に最も近い1時間足のローソク足の終値）。実際の注文執行 シミュレーションではありません。スリッページ／手数料／部分約定は計算されません。 サンプル数が少ない（約20シグナル未満）場合、信頼度は低くなります。少量の過去 データだけでシグナルが「信頼できる」と結論付けないでください（この機能がデプロイ された時点から蓄積されたデータであり、遡及的なものではありません）。
• pipeline_decision_log ＋ whalescope_backtest_pipeline_decisions： Phase 2 のエントリーアラートのシンボルごとの判断（および persist=true）は、 コンパクトな形式で90日間保存されます。フォワードリターン／SL 到達は klines からオンデマンドで算出され、事前計算ではなく、重み 35/30/20/15 やしきい値 55 の自動調整も行いません。entry_alert_skip_log の保持期間は30日です。
• whalescope_compare_funding_across_exchanges：4取引所間で、Open Interest は ライブデータとの突合検証がまだ行われていません（OKX が oiCcy フィールドを 使用する場合も含め、すべての取引所でベース資産建てであるべきですが、直接確認 できていません。数値が不自然に見える場合は再確認してください）。Binance から 他の取引所へのシンボルマッピングはベストエフォートです（USDT サフィックスを 削除）。Bybit／OKX／Hyperliquid に上場されていない小規模ペアは、その行に 「失敗」と表示されますが、ツール呼び出し全体が失敗するわけではありません。
• Binance プロキシへのレート制限による自己スロットリングはベストエフォートで、 ハードなグローバル制限ではありません。カウンターは isolate ごとのメモリー上に あります（src/rateLimiter.ts）。同じ isolate が連続するリクエストに再利用 されている間は有効ですが、この Worker はリクエストごとにステートレスであるため、 isolate をまたいだ確実な制限ではありません。しきい値は毎分200リクエストで、 Binance 本来の制限のようなエンドポイントごとの weight ベースではなく、件数ベース です。
• binance_get_tool_catalog は半自動です。名前と説明はツールレジストリから 取得され、常に正確です（古くなることはありません）。一方、カテゴリ／トークン コスト／依存関係は引き続き手動で管理されます（src/tools/catalog.ts の CATALOG_METADATA）。キュレーションされていない新しいツールは、カテゴリが "uncategorized" として表示されます。ひそかに省略されることはありませんが、 カテゴリ分けはまだ適切ではありません。
• binance_analyze_smart_money は固定しきい値を使用します（ペアごとの統計的な キャリブレーションによるものではありません）。トップトレーダー比率に絶対値の しきい値を使う際の注意点については、docs/mm_detection_framework.md の Section 4.2 と 12 を参照してください。出力の confidenceScore が示すのは しきい値を上回るマージンであり、統計的にキャリブレーションされた確率では ありません。

Vercel プロキシのセットアップ（必須、1 回のみ）

上の表にある「Binance native」とラベル付けされたツールには、Vercel 上のプロキシリレーが必要です。 Cloudflare ワーカーは Binance の WAF に直接ブロックされるためです。プロキシのデプロイ方法の詳細は proxy/README.md をご覧ください。概要は次のとおりです。

1. proxy/ フォルダーを別個の Vercel プロジェクトとしてデプロイします（Root Directory = proxy）。Vercel で PROXY_SECRET 環境変数を設定します（自分で生成したランダムな文字列を使用します。例：openssl rand -hex 32）。
2. Cloudflare ワーカーに次の 2 つのシークレットを設定します。

   npx wrangler secret put PROXY_URL
   npx wrangler secret put PROXY_SECRET
   

   PROXY_URL = Vercel プロジェクトの URL（例：https://whale-pearl.vercel.app）、 PROXY_SECRET = Vercel に設定したものと完全に同じ文字列。

これら 2 つのシークレットがないと、「Binance native」とラベル付けされたツールは、明確なエラーメッセージ（「PROXY_URL または PROXY_SECRET がワーカーに設定されていません」）とともに失敗します。

重要：シークレットの VALUE を NAME として Cloudflare に設定することは絶対に避けてください（たとえば、wrangler secret put のあと、名前の入力プロンプトに誤って value を貼り付けること）。wrangler secret list で表示されるのはシークレット名のみで、value が表示されることはありません。この間違いをすると、本来安全なコマンドを通じて実際の value が漏えいします。

セカンダリプロキシ／フェイルオーバー（任意）

プライマリプロキシが WAF ブロック、レート制限、5xx エラーに遭遇した場合、ワーカーはセカンダリプロキシを自動的に試します。ただし、設定されている場合に限ります。設定しない場合の動作は従来どおり（プロキシ 1 台のみで、失敗するとエラーがそのまま返されます）です。

1. 同じ proxy/ フォルダーから Vercel の 2 つ目のインスタンスをデプロイします（必要に応じて異なるリージョンを使用します。例：香港とシンガポール）。PROXY_SECRET は独自に設定してください（プライマリと異なっていてもかまいません）。
2. 追加のシークレットを 2 つ設定します。

   npx wrangler secret put PROXY_URL_2
   npx wrangler secret put PROXY_SECRET_2
   

フェイルオーバーは、ティアの健全性や認証情報に関するエラー（シークレットの誤りによる 401、WAF ブロックによる 403、レート制限による 429、5xx）に対してのみ機能します。リクエスト自体に起因するエラー（誤った symbol による 400、404）には適用されません。これらはどのティアでも同じように失敗するためです。401 を含めているのは意図的です（以前のバージョンとは異なります）。各プロキシティアには独自のシークレットがあるため、プライマリのシークレットが間違っていても、セカンダリのシークレットも間違っているとは限りません。

直接フォールバック（最後のティア、自動的に有効）

プライマリとセカンダリ（設定されている場合）の両方が失敗すると、ワーカーはプロキシを一切経由せず、最後の手段として fapi.binance.com／api.binance.com に直接アクセスします。セットアップは不要です（デフォルトで有効）。無効にする場合は、ワーカーの環境変数に DISABLE_DIRECT_FALLBACK=true を設定してください（シークレットではなく、通常の変数です）。詳細と、現時点の本番環境ではこのティアも WAF にブロックされる可能性が高い理由については、src/binanceProxyClient.ts の「DIRECT FALLBACK」コメントをご覧ください（この Cloudflare ワーカーは Binance に直接ブロックされることがすでに確認されています）。ただし、ローカルの wrangler dev では有用です（IP プールが本番の Cloudflare エッジとは異なります）。また、ブロックポリシーが変更された場合の安全策にもなります。

Workers KV のセットアップ（必須、1 回のみ — このリポジトリをフォーク／デプロイする場合）

このリポジトリの wrangler.toml にある KV namespace の id は、作成した Cloudflare アカウントに紐付いています。フォーク／クローンして自分のアカウントにデプロイする場合は、新しい namespace を作成する必要があります。

npx wrangler kv namespace create WHALESCOPE_CONFIG

表示された id を wrangler.toml の [[kv_namespaces]] にコピーし、古い id の value を置き換えます（binding は CONFIG_KV のままにしてください。ワーカーのコードは id ではなく、この binding 名を参照します）。これを行わないと、binance_set_pair_threshold と binance_get_pair_threshold は、明確なエラー（「CONFIG_KV がワーカーにバインドされていません」）とともに失敗します。

Workers D1 のセットアップ（必須、1 回のみ — このリポジトリを自分でフォーク／デプロイする場合）

上記の KV と同様に、このリポジトリの wrangler.toml にある D1 の database_id は、作成元の Cloudflare アカウントに紐付いています。自分のアカウントにフォーク／デプロイする場合：

npx wrangler d1 create whalescope-mcp-db

表示された database_id を wrangler.toml の [[d1_databases]] にコピーして（binding は DB のままにします）、migration を実行します：

npx wrangler d1 migrations apply whalescope-mcp-db --remote

これを行わないと、binance_get_basis_history と binance_backtest_signal は明確なエラー（「D1 database (binding DB) belum ke-bind di worker」）で失敗し、MM の basis＋シグナルのスナップショットを取得する Cron Trigger（5 分ごと）は各 tick でひっそり失敗します（Workers Logs に記録されますが、他の /mcp エンドポイントには影響しません）。

管理者：使用状況ログ（任意）

公開 Worker は見つけられやすいため（MCP Server Registry に登録されています）、誰が接続しているかを確認する小さなエンドポイントがあります。これは MCP ツールではありません（意図的に独立した HTTP エンドポイントとしており、tools/list に表示されることはありません）。通常のツールにすると、このサーバーに接続できる人なら誰でも他の訪問者の IP を見られるようになり、目的に反するためです。

1. シークレットを設定します（設定しない場合、エンドポイントは常に 403 を返します。デフォルトでは機能が無効になっているため、安全です）：

   npx wrangler secret put ADMIN_SECRET
   

2. アクセスします：

   curl "https://<worker-url>/admin/usage?key=<ADMIN_SECRET>&hours=24"
   

   JSON で、リクエスト総数、ユニーク IP 数、上位 20 件の IP（国、件数付き）、直近 20 件の生のリクエストを返します。デフォルトの期間は 24 時間で、hours で変更できます。

監視とアラート

このバックエンドには、ひっそり発生する障害ポイントがいくつかあります（Vercel／VPS のプロキシ停止、WS stream gateway の切断、Cron Trigger のプラットフォームによる Cancel）。現在、すべて Telegram 経由です（TELEGRAM_BOT_TOKEN と TELEGRAM_CHAT_ID の設定が必要です。未設定の場合、アラートは Workers Logs にのみ記録されます）。

チェック	Cron	アラート条件
checkHeartbeat（heartbeatCron.ts）	1 日 3 回（07/15/23 WIB）	TRADE／WATCH シグナルが 8 時間ゼロの場合 — 「市場が静かでバックエンドは正常」「各 tick で 30% 超のペアが失敗＝バックエンドに問題」「データがゼロ＝cron 停止」を区別する 1 件のメッセージ
checkEntryAlertCronFreshness（heartbeatCron.ts）	*/5 に付随	40 分間、完了した entry-alert の tick がゼロの場合（プラットフォームによる tick の Cancel を検知）— クールダウン 1 時間
checkStreamGatewayHealth（infraHealthCron.ts）	*/5 に付随	VPS stream gateway の :8081/health に到達できない、Binance への WS が切断、またはバッファが 5 分超古い場合 — クールダウン 1 時間
checkMarketSnapshotFreshness（infraHealthCron.ts）	*/5 に付随	20 分間、新しい market_snapshots 行がゼロの場合（スナップショットの */5 cron が書き込みを停止）— クールダウン 1 時間
checkD1Capacity（infraHealthCron.ts）	1 日 3 回（HEARTBEAT_CRON と同時に実行）	market_snapshots と signal_history（どちらも pruning されないテーブル）の合計が 500 万行を超えた場合 — クールダウン 24 時間

すべてのチェックは KV によって制御されます（条件が続く間、クールダウン中のアラートは最大 1 回）。5 分ごとに実行しても安全です。

まだ対応していない項目（コードではなく、ダッシュボードでの作業です）：

• Worker の / と relay の https://<vps>/health を対象とする外部稼働状況モニター — UptimeRobot／Cloudflare Health Checks を使います（無料、5 分間隔）。VPS／relay の完全停止を最も早く検知できます。上記の内部チェックは遅延のあるバックストップにすぎません。
• Workers のエラー率急増／CPU 制限に対するCloudflare 通知 — observability（[observability] enabled = true）はデータを収集するだけで、アラートルールはありません。

セキュリティ：DNS リバインディング対策（任意）

/mcp エンドポイントはリクエストを処理する前に Origin ヘッダーを検証します。 デフォルトでは、https://claude.ai／https://claude.com と、Origin ヘッダーがまったくないリクエスト（このワーカーをカスタムコネクターとして使う場合を含め、サーバー間の MCP クライアントの大半が該当します）を許可します。許可されていない別の Origin を持つリクエストには 403 を返します。 これは、@modelcontextprotocol/sdk で @deprecated となった SDK の組み込みオプション（enableDnsRebindingProtection／allowedHosts／allowedOrigins）の代替です。SDK は現在、外部ミドルウェアの使用を推奨しており、ここではそれを使用しています。

ブラウザーから /mcp を直接呼び出す必要がある独自の Web アプリがある場合は、そのオリジンを追加してください。

npx wrangler secret put ALLOWED_ORIGINS
# contoh value: https://app-kamu.com,https://staging.app-kamu.com

（カンマ区切りです。カンマの後にスペースがあっても構いません。自動的にトリミングされます。）

データは D1（request_log）に保存され、30 日を超えた行は Cron の実行ごとに自動的に削除されます （このテーブルには market_snapshots／signal_history のような固定ウォッチリストの制限がないため、実際に外部からのトラフィックがあれば増加する可能性があります）。

自動デプロイの設定（GitHub Actions → Cloudflare Workers）

このリポジトリには .github/workflows/deploy.yml にワークフローがあり、main ブランチにプッシュするたびに wrangler deploy を自動実行します。

設定手順（初回のみ）

1. Cloudflare API Token を作成する

1. https://dash.cloudflare.com/profile/api-tokens を開きます
2. 「Create Token」をクリックします
3. **「Edit Cloudflare Workers」**テンプレートを使用します
4. アカウントを対象にして、トークンを作成します
5. 表示されたトークンをコピーします（一度しか表示されません）

2. GitHub Secret としてトークンを追加する

1. GitHub でこのリポジトリを開き、Settings → Secrets and variables → Actions の順に移動します
2. New repository secret をクリックします
3. Name：CLOUDFLARE_API_TOKEN
4. Value：手順 1 で取得したトークン
5. 保存します

3. デプロイを実行する

main に新しいプッシュがあると、デプロイが自動的に実行されます。新しいプッシュなしで手動実行するには、GitHub リポジトリの Actions タブを開き、ワークフロー「Deploy to Cloudflare Workers」を選択して、Run workflow をクリックします。

4. デプロイ結果を確認する

ワークフローの完了後（Actions タブで確認できます）、ワーカーは次の URL で稼働します。

https://whalescope-mcp.<subdomain-cloudflare-kamu>.workers.dev

この URL を開くと、"ok" のステータスを示す JSON が表示されます。

カスタムドメインの設定（whalescope-mcp.jaringan.dev）

これは GitHub Actions では実行できません。Cloudflare ダッシュボードで一度だけ手動で設定する必要があります。

1. https://dash.cloudflare.com を開き、アカウントを選択します
2. Workers & Pages を開き、ワーカー whalescope-mcp を選択します
3. Settings タブを開き、Domains & Routes を選択します
4. Add → Custom Domain をクリックします
5. whalescope-mcp.jaringan.dev を入力します
6. ドメイン jaringan.dev が同じ Cloudflare アカウントのゾーンにある場合、Cloudflare が必要な DNS レコードを自動的に作成します。 ドメインが別のアカウント／レジストラーに登録されている場合は、Cloudflare に表示されるターゲットを指定する CNAME レコードを手動で追加する必要があります。

カスタムドメインが有効になると、ワーカーには https://whalescope-mcp.jaringan.dev からアクセスできます（.workers.dev ドメインではなくなります）。

Claude にカスタムコネクターとして登録する

1. Claude（claude.ai）を開き、Settings → Connectors の順に移動します
2. Add custom connector を選択します
3. URL を入力します：https://whalescope-mcp.jaringan.dev/mcp （カスタムドメインをまだ設定していない場合は、https://whalescope-mcp.<subdomain>.workers.dev/mcp を使用します。末尾のパス /mcp は必須です）
4. 保存し、使用したい会話でそのコネクターを有効にします

使用例

コネクターが有効になったら、あとは通常の会話で依頼するだけです。質問に応じて、Claude が呼び出すツール（および呼び出し回数）を判断します。

• 「現在のBTCUSDTのファンディングレートはどう？混み合っている兆候はある？」 → binance_get_funding_rate
• 「現在、マーケット全体でファンディングが最も極端なペアは？」 → binance_scan_funding_extremes
• 「ETHUSDTの全体像をチェックして。ファンディング、OI、オーダーブック、価格のバイアスを確認して」 → binance_analyze_pair（複合ツール。個別の6つのツールを1回の呼び出しに置き換えます）
• 「最近、SOLUSDTでマーケットメーカーの活動の兆候はある？」 → 複数のツール（オーダーブック、agg trades、OI、klines）を組み合わせて、 上記の分析フレームワーク に従います。ペアを指定すれば、Claude が検出ワークフローを実行します。
• 「BTC、ETH、SOL、BNBのファンディングレートを比較して」 → binance_compare_symbols
• 「現在、BTCUSDTとETHUSDTでGrid Bot Futuresを始めるのは妥当？損失予算は$20」 → whalescope_full_pipeline（最も高度な複合ツール。1回の呼び出しで ハードスクリーニング → Tier-1情報分析 → グリッド範囲の算出 → リスク量の調整 → TRADE/WATCH/NO_TRADEの判断を行い、両方のペアに対応する すぐにコピー＆ペーストできるGrid Botパラメーターを生成します）

すべてのツールは読み取り専用なので、市場データについて何を尋ねても、 注文や取引が実行されるリスクはなく、安全に試せます。このワーカーには、 そのような操作を行う機能は一切ありません。

Claude に登録する前の手動テスト（推奨）

npm test（vitest）とnpm run typecheckは、このリポジトリの自動チェックです。 ただし、どちらも純粋なロジック（スコアリング関数、D1/KV ラッパー、偽のMcpServerを介したツールハンドラー）のみを対象としており、 実際のWorkersのfetch／scheduledハンドラーは対象外です（@cloudflare/vitest-pool-workersはありません）。 新規または変更したツールの検証には、引き続きwrangler devとcurlによる JSON-RPCを使った手動テストが必要です。

npm install
npx wrangler dev

別のターミナルで、Binanceネイティブツールを試す例です：

curl -X POST http://localhost:8787/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "binance_get_funding_rate",
      "arguments": { "symbol": "BTCUSDT" }
    }
  }'

これによって有効なBTCUSDTのファンディングレートとベーシスのデータが返された場合、 Vercelプロキシの経路は正常に動作しています。

監査と結果

トークン効率

MCP ツールのレスポンスは Claude のコンテキストウィンドウに直接入ります。レスポンスのサイズが比較的「無料」である通常の REST API とは異なります。このリポジトリには、気づかないうちに大量のトークンを消費するツールがいくつかありましたが、修正してライブワーカーで検証済みです（2026-08-12）。

発見事項	修正前	修正後
binance_get_klines/spot_klines — structuredContent.candles に常に全配列が含まれる	limit=500 で約14,400トークン（57.7KB）、最大のlimit=1500では約43,000トークン	includeCandles パラメーターでオプトイン（デフォルトはfalse）。デフォルトではサマリーのみ（バイアス、スイング高値／安値、直近15本のローソク足）
6つの履歴ツール（OI history、long/short ratio、top trader ratio、funding rate history、taker volume ratio、liquidation history）— 行数制限のないテキストテーブル	limit=500で1回あたり20～29KB（約5,000～7,250トークン）	テキスト内の直近15行に切り詰め。サマリー（平均／トレンド／優勢）は、表示されたデータだけでなく、取得した全データから引き続き算出
最長のツール説明5件（funding_rate、top_trader_ratio、spot_price、klines、spot_klines）	合計16,869文字	15,671文字（約7％削減、セッションごとの初回ツール一覧読み込みで約300トークン節約）
binance_scan_funding_extremes — structuredContent.crowdedLong/crowdedShort にテキストテーブル内の配列と重複する配列が含まれる	limit=50（最大）で約2.9KB	topSymbolLong/topSymbolShort（各側で最も極端な1シンボル）のみ。完全なテーブルは引き続きテキスト内に含まれる

いつでも再検証できます。

npm run token-audit

デプロイ済みワーカーを直接呼び出し、ツールスキーマのサイズ、limitを変えた場合のレスポンスサイズ、代表的な複数のツールの「Information Density Ratio」（データと定型文の比率）を測定し、現実的な複数ターンの会話も1つシミュレーションします。npm test／CI の一部ではありません（実行時にライブワーカーへアクセスするため）。ツールの説明やレスポンス形式を変更した際のトークン消費への影響を確認するため、手動で使用します。トークン数の推定にはchars/4のヒューリスティックを使用します（Claude の公式トークナイザーはパッケージとして公開されていないため）。そのため数値は概算であり、正確なトークン数ではなく、相対比較（変更前と変更後）に役立ちます。

セキュリティ

• ペアシンボルの入力検証。 symbolSchema（symbolパラメーターを必要とするすべてのツールで使用）は最大20文字に制限され、[A-Z0-9_]のみを受け付けます。以前は制限がありませんでした。シンボルは Workers KV のキーの一部（threshold:${symbol}、basis_history:${symbol}）として直接使用されるため、長さや文字に制限のない入力は、KV キーの512バイト制限を超えたり、キーの構築を乱す文字（コロン、改行）を挿入したりするリスクがありました。20文字の上限は実データで検証済みです（現在の Binance Futures で最長のシンボルは17文字）。また、日付付き／四半期契約（例：BTCUSDT_260925）を引き続き有効にできるよう、正規表現では意図的にアンダースコアを許可しています。
• アカウントに対する読み取り専用。 注文／取引を実行したり、個人アカウントのデータにアクセスしたりするツールはありません。状態を書き込む唯一のツール（binance_set_pair_threshold）は、ワーカー自身が所有する Workers KV にしきい値の設定を保存するだけです。
• 認証情報は常に Wrangler secret 経由で設定され、ハードコードしたり、wrangler.toml／git に含めたりすることはありません。 secret を安全に設定する方法については、Vercel プロキシのセットアップの明示的な警告を参照してください。
• このリポジトリは手動でスキャンし、API キー、secret、実際の認証情報がコミットされていないことを確認しています。含まれているのはプレースホルダー／例のみです（たとえば、セットアップ手順のプロキシ URL whale-pearl.vercel.app は例としての名前であり、実際のエンドポイントではありません）。

費用

• Cloudflare Workers：無料枠は1日あたり100,000リクエストです。個人での取引分析用途であれば、十分に余裕があります。
• Vercel（プロキシリレー）：無料のHobbyプランには、サーバーレス関数の月間数百万回の呼び出しが含まれており、個人利用で費用が発生することはありません。 注意：PROXY_SECRET は必ず秘密にしてください。URLとシークレットを知っている人なら誰でも、あなたの名義でこのプロキシの利用枠を使えるためです。

個人利用であれば、どちらのプラットフォームでも費用が発生することはまずありません。

免責事項

このプロジェクトはオープンソースで公開されています。ソースコード、アーキテクチャ、ドキュメント（docs/ の分析フレームワークを含む）は、このGitHubリポジトリを通じて誰でも閲覧、クローン、変更できます。個人アカウントのデータが保存または処理されることはありません。すべてのツールは、Binanceの公開APIに対して読み取り専用で動作します。

• 金融に関する助言ではありません。 すべてのデータと解釈（ファンディングレート、OI、オーダーブック、MM検出フレームワークなど）は情報提供のみを目的としています。公開データを処理した結果であり、取引の推奨ではありません。データの正確性、完全性、適時性は保証されません。このデータに基づいて判断する前に、各ツール固有の制限について事前に知っておくべき正直な制約をご確認ください。
• ユーザーの責任。 このワーカーをデプロイ、使用、または変更する人は、その使用による結果と影響について全責任を負います。これには、これらのツールの出力に基づいて行う取引の判断も含まれます。
• Binance API利用規約の遵守。 このワーカーはBinanceの公開エンドポイント（FuturesおよびSpot）を呼び出します。個人利用または非営利利用は、一般的なBinanceの利用規約に沿ったものです。データを商用目的で再配布する場合、または大規模に利用する場合は、事前にBinance API Terms of Useをご確認ください。これは本プロジェクトの責任範囲外です。
• ライセンス：MIT。 著作権表示とMITライセンスの表記を含める限り、商用目的を含め、自由に使用、変更、再配布できます。ソフトウェアは「現状有姿」で提供され、いかなる保証もありません。上記の免責事項もあわせてご確認ください。