Prerequisites
The Cryptohopper MCP configured in an MCP client. See setup overview.
At least one API key on your Cryptohopper account. See how to get a Cryptohopper MCP API key.
Setup
Open your MCP client.
Ask the client directly for usage.
Any of the following prompts will route to the MCP's usage-inspection tool:
How much of my Cryptohopper MCP quota have I used this week?
What's my current Cryptohopper MCP tier and call usage?
Show me my Cryptohopper MCP usage: tier, calls used, calls remaining, and the next reset time.The response includes:
Active subscription tier (Pioneer, Explorer, Adventurer, or Hero)
Per-minute usage: calls used, limit, and remaining in the current minute
Weekly budget: calls used, weekly limit, remaining, and percent used
Timestamp of the next weekly reset (
resets_at— always a Friday at 00:00 UTC)
A typical response looks like this:
{
"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
}Note that there are two limits to watch, not one: a short per-minute rate limit and a longer weekly budget. Heavy parallel workflows tend to hit the per-minute limit; sustained daily use tends to consume the weekly budget.
For ongoing monitoring, add a usage check to your scheduled workflows. At the end of each run, include:
After completing the above, query the Cryptohopper MCP usage endpoint and append: "Quota used: X / Y (Z% of weekly limit)" to the report.This way, every scheduled report carries its own quota footprint.
If you are running multiple agents on different keys, track usage per key by including the key's identifier or name in the logs. Note that quota is shared across all keys on the account — see subscription tiers. Per-key identification is for attribution, not for separate budgets.
Setting up alerts
For automated alerting when usage approaches the limit, wrap the usage check in a scheduled script. The MCP already returns percent_used, so you don't need to compute it yourself — but you can derive it from used and limit if you prefer. Pseudocode:
usage = mcp_client.get_usage()
pct = usage["week"]["percent_used"] # provided directly by the MCP
if pct > 80:
send_telegram(f"Warning: MCP usage at {pct:.0f}% of weekly limit")
if pct > 95:
send_telegram(f"CRITICAL: MCP usage at {pct:.0f}% — workflows may fail")
Run this hourly or daily depending on how heavy your workflows are. See how to schedule Cryptohopper MCP workflows for the scheduling side and how to send MCP reports to Telegram, Discord, or email for delivery.
Reducing spend
If your usage is consistently near the limit, the cheapest levers to pull:
Reduce candle lookback. Most indicators need 100–200 bars, not 1,000. On Explorer/Adventurer, long-history candle calls cost up to 20× a baseline call. See rate limits explained and a practical guide to candles.
Use tickers instead of orderbooks for scans. Orderbook calls carry a similar unit cost but transfer far more data and are only meaningful for execution-critical decisions. For broad market scans, tickers are the right tool.
Widen the cadence of scheduled jobs. Hourly scans may be overkill. Daily or twice-daily is usually sufficient for most workflows.
Narrow the universe. A 200-pair scan costs 4× a 50-pair scan. Focus on the pairs you actually care about.
Upgrade if all of the above are already tight. Explorer's 30,000 calls/week is 5× Pioneer's. See subscription tiers for the full comparison.
Troubleshooting
The usage response comes back empty or malformed.
This usually indicates the client is connected but the model did not route the question to the usage tool. Be more explicit: "Call the Cryptohopper MCP usage tool and return the raw response." If the tool does not appear in the client's tool list at all, re-check the MCP connection — see setup overview.
Usage appears to be counted twice.
Quota is counted per tool invocation. A single conversation turn that asks the agent to scan 50 pairs results in 50 individual ticker calls, each counted separately. This is expected behaviour — not double-counting.
The reset time is in the past.
If the returned resets_at is before the current time, your client or agent may be caching an old response. Restart the MCP connection or issue a fresh call.
You see usage lower than you expected.
Most usage monitoring is interpreted correctly. Occasionally, clients cache the response for a short period. If in doubt, make a fresh call and compare.
You want per-agent spend visibility.
The MCP reports usage at the account level. For per-key or per-agent attribution, maintain your own log at each consumer (append the key name and a call count to every scheduled run). See how to run multiple agents with multiple API keys.
You hit a quota or rate-limit error before the usage tool is called. If the account is already at the weekly limit, even the usage call itself may be rejected. Wait for the reset, or upgrade the tier. If you're hitting the per-minute limit instead, space your calls out — that limit clears within the minute. See error reference.