事前準備
MCPクライアントに設定済みのCryptohopper MCP。 セットアップ概要を参照してください。
Cryptohopperアカウントに少なくとも1つのAPIキー。 Cryptohopper MCP APIキーの取得方法を参照してください。
セットアップ
MCPクライアントを開きます。
クライアントに直接使用状況を尋ねてください。
以下のいずれかのプロンプトで、MCPの使用状況確認ツールにルーティングされます。今週、Cryptohopper MCPのクォータをどれくらい使用しましたか？
現在のCryptohopper MCPのティアとAPIコール使用状況は？
Cryptohopper MCPの使用状況を表示してください：ティア、使用済みコール数、残りコール数、次回のリセット時間。応答には以下が含まれます。
アクティブなサブスクリプション ティア（Pioneer、Explorer、Adventurer、Hero）
毎分の使用状況：使用済みコール数、制限、および現在の分での残り
週次予算：使用済みコール数、週次上限、残り、および使用率（パーセント）
次回の週次リセットのタイムスタンプ（
resets_at— 常に金曜日 00:00 UTC）
典型的な応答は次のようになります。
{
"tier": "explorer",
"minute": {
"used": 1,
"limit": 600,
"remaining": 599
},
"week": {
"used": 4215,
"limit": 30000,
"remaining": 25785,
"percent_used": 14,
"resets_at": "2026-05-29T00:00:00.000Z"
},
"historical_days": 365,
"allowed_exchanges": null
}注意すべき2つの制限があることです。1つではなく：短い毎分のレート制限と、より長い週次予算です。重い並列ワークフローは毎分制限に達しやすく、持続的な毎日の使用は週次予算を消費しがちです。
継続的な監視のため、スケジュールされたワークフローに使用状況チェックを追加します。各実行の最後に、以下を含めます。
上記完了後、Cryptohopper MCPの使用状況エンドポイントをクエリし、レポートに「クォータ使用状況：X / Y (週次上限のZ%)」を追加します。これにより、スケジュールされた各レポートには独自のクォータフットプリントが付きます。
複数のエージェントを異なるキーで実行している場合は、ログにキーの識別子または名前を含めることで、キーごとの使用状況を追跡します。クォータはアカウントのすべてのキーで共有されることに注意してください — サブスクリプションティアを参照してください。キーごとの識別は、個別の予算ではなく、属性のためです。
アラートの設定
使用状況が上限に近づいたときに自動アラートを設定するには、使用状況チェックをスケジュールされたスクリプトでラップします。MCPはすでにpercent_usedを返しますが、自分で計算する必要はありません — ただし、希望する場合はusedとlimitから導出できます。擬似コード：
usage = mcp_client.get_usage()
pct = usage["week"]["percent_used"] # MCPから直接提供
if pct > 80:
send_telegram(f"警告：MCP使用状況は週次上限の{pct:.0f}%です")
if pct > 95:
send_telegram(f"緊急：MCP使用状況は{pct:.0f}%です — ワークフローが失敗する可能性があります")
ワークフローの重さに応じて、これを1時間ごとまたは毎日実行します。スケジュールについては、Cryptohopper MCPワークフローのスケジュール方法を参照し、配信についてはMCPレポートのTelegram、Discord、またはメールへの送信方法を参照してください。
コスト削減
使用状況が常に上限に近い場合、最も安価な方法は以下の通りです。
キャンドルルックバックを減らします。ほとんどのインジケーターには1,000ではなく100〜200バーが必要です。Explorer/Adventurerでは、長履歴のキャンドルコールはベースラインコールの最大20倍のコストがかかります。レート制限の説明およびキャンドルに関する実践ガイドを参照してください。
スキャンのためにオーダーブックの代わりにティッカーを使用します。オーダーブックコールは同様の単価ですが、はるかに多くのデータを転送し、実行クリティカルな決定にのみ意味があります。広範な市場スキャンには、ティッカーが適切なツールです。
スケジュールされたジョブの頻度を広げます。毎時スキャンは過剰かもしれません。ほとんどのワークフローでは、毎日または1日2回で十分です。
対象範囲を狭めます。 200ペアのスキャンは、50ペアのスキャンの4倍のコストがかかります。実際に気にかけているペアに焦点を当てます。
上記すべてがすでにタイトな場合はアップグレードします。 Explorerの30,000コール/週は、Pioneerの5倍です。サブスクリプションティアで完全な比較を確認してください。
トラブルシューティング
使用状況の応答が空または不正な形式で返ってくる。
これは通常、クライアントが接続されているが、モデルが質問を使用状況ツールにルーティングしなかったことを示します。より具体的にしてください：「Cryptohopper MCP使用状況ツールを呼び出し、生の結果を返してください。」ツールがクライアントのツールリストにまったく表示されない場合は、MCP接続を再確認してください — セットアップ概要を参照してください。
使用状況が二重にカウントされているように見える。
クォータはツール呼び出しごとにカウントされます。エージェントに50ペアをスキャンするように依頼した単一の会話ターンは、それぞれ個別にカウントされる50の個別のティッカーコールにつながります。これは期待される動作であり、二重カウントではありません。
リセット時間が過去になっている。
返されたresets_atが現在の時刻よりも前の場合、クライアントまたはエージェントが古い応答をキャッシュしている可能性があります。MCP接続を再起動するか、新しいコールを発行してください。
予想よりも使用状況が低い。
ほとんどの使用状況監視は正しく解釈されます。まれに、クライアントが短時間応答をキャッシュします。不明な場合は、新しいコールを行って比較してください。
エージェントごとの支出の可視性を希望する。
MCPはアカウントレベルで使用状況を報告します。キーごとまたはエージェントごとの属性については、各コンシューマーで独自のログを維持します（各スケジュールされた実行にキー名とコール数を追加します）。複数のAPIキーで複数のエージェントを実行する方法を参照してください。
使用状況ツールが呼び出される前に、クォータまたはレート制限エラーが発生する。 アカウントがすでに週次上限に達している場合、使用状況コール自体も拒否される可能性があります。リセットを待つか、ティアをアップグレードしてください。毎分制限に達している場合は、コールの間隔を空けてください — その制限は1分以内にクリアされます。エラーリファレンスを参照してください。