Why this matters
Agents that run in loops have two costs that add up fast. Quota cost: every MCP tool call counts against your weekly allowance. Token cost: every piece of data in the context window increases processing cost and degrades reasoning quality.
A thin context block addresses both: one small ticker sweep, summarized into a few lines, injected once at the start of the conversation. The agent has situational awareness without the tool-call storm or the token inflation.
Prerequisites
Cryptohopper MCP configured in an MCP client — see the setup overview.
An agent workflow that runs periodically or continuously. Single-shot prompts don't benefit from this technique.
Pioneer tier is sufficient — ticker calls are cheap on all tiers. See subscription tiers.
Setup steps
Define what goes in the block
Four to six lines, all ticker-derived — around 100 tokens. A typical block covers: price and 24h change for your anchor tokens, the top gainer and loser across your sweep universe, any pair with unusual volume, and a one-word market regime label.
BTC 66,120 (+1.1%, vol normal)
ETH 3,240 (+2.8%, vol elevated)
SOL 148.50 (+1.9%, vol normal)
Top gainer: ARB +8.2% (vol 2.4x)
Top loser: DOGE -3.5% (vol normal)
Unusual volume: LINK (flat price, vol 3.1x)
Market regime: risk-on, moderate breadthGenerate the block with a per-symbol loop
There is no bulk-ticker tool — every ticker is a single MCP call. The function below makes one call per symbol. A 3-anchor + 10-symbol sweep costs 13 calls per run.
def build_thin_context() -> str:
exchange = "binance"
# Fixed anchor tickers — one call each
anchors = ["BTC/USDT", "ETH/USDT", "SOL/USDT"]
anchor_tickers = [mcp.get_ticker(exchange, pair) for pair in anchors]
# Sweep universe — one call per symbol
sweep_pairs = [
"ARB/USDT", "OP/USDT", "AVAX/USDT", "LINK/USDT", "AAVE/USDT",
"UNI/USDT", "DOGE/USDT", "MATIC/USDT", "SEI/USDT", "TIA/USDT",
]
sweep_tickers = [mcp.get_ticker(exchange, pair) for pair in sweep_pairs]
# Derive summary fields
all_tickers = anchor_tickers + sweep_tickers
top_gainer = max(all_tickers, key=lambda t: t.change_24h_pct)
top_loser = min(all_tickers, key=lambda t: t.change_24h_pct)
unusual = [t for t in all_tickers if t.volume_ratio_vs_baseline > 2.5]
return format_as_context(anchor_tickers, top_gainer, top_loser, unusual)
# Total calls = len(anchors) + len(sweep_pairs) = 13 per runInject the block at the top of the agent's opening message
Place the block before the task instruction with a timestamp. The agent reads the context first and should not re-fetch anything already listed.
[CONTEXT AS OF 2026-04-24 08:00 UTC]
BTC 66,120 (+1.1%, vol normal)
ETH 3,240 (+2.8%, vol elevated)
SOL 148.50 (+1.9%, vol normal)
Top gainer: ARB +8.2% (vol 2.4x)
Top loser: DOGE -3.5% (vol normal)
Unusual volume: LINK (flat price, vol 3.1x)
Market regime: risk-on, moderate breadth
Your task: [the actual thing you want the agent to do]Let the agent escalate from the thin block when it needs more
The block is the summary. When something looks interesting, the agent calls the MCP for candles or orderbook depth on that specific pair. Most runs end without any escalation — that is the correct behaviour.
Refresh at a cadence that matches the workflow
Hourly agent → rebuild at the start of each hour.
Daily digest → once per day.
On-demand assistant → once per session.
Do not reuse a block across cadence boundaries — stale context is worse than no context.
The math
An agent running hourly, 16 hours/day, 5 weekdays/week, with a 13-symbol sweep:
Approach | Per-run calls | Weekly calls |
Naive (agent pulls from scratch) | 20–100 (varies wildly) | 1,600–8,000 |
Thin context + selective escalation | 13 baseline + ~10–30 on escalation | 1,840–5,040 (stable) |
The thin context isn't always cheaper in aggregate — what it buys is predictability. You know what the worst-case week looks like. On Pioneer's 6,000 calls/week, it keeps a light hourly agent feasible on the free tier.
When not to use this pattern
Situation | Why thin context doesn't help |
Single-shot conversational research | Just ask the question — the assistant handles it |
Workflows that always need deep data | A grid-bot parameter generator already needs candle history; the thin context is redundant |
Slippage-sensitive execution flows | These should never reason from cached context — always pull fresh data |
Use thin context when the workflow is repeated, predictable, and mostly-awareness-based. The savings compound; without those properties, the overhead isn't worth it.
Troubleshooting
The agent ignores the thin context and re-pulls the same data
Prompt it explicitly: "The context block above is the current state — do not re-fetch tickers for BTC, ETH, SOL, or anything listed. Only pull new data if you need something not in the block." Once framed as a constraint, the agent respects it.
The block is out of date by the time the agent uses it
For short-cadence workflows (minute-level), the block goes stale quickly. Either refresh more often, or mark the block timestamp clearly so the agent knows to re-check before making decisions based on old numbers.
The block format is inconsistent run to run
Fix the format as a template and fill in values — don't let the model write the block. A deterministic generator produces consistent output.
You want more data in the block
Resist the urge. Every line costs tokens on every run. If a data point isn't referenced by most runs, it belongs in an on-demand call, not the block.
The block includes numbers the agent ignores
Cut them. A block that's 100% used is better than one that's 60% used.
Multi-exchange context makes the block too big
Use one primary exchange (usually Binance) for the block. Have the agent fetch other venues only when comparison is needed — don't pre-populate multi-venue context for the general case.
You want a thin context covering multiple timeframes
Use one block per agent purpose instead of trying to unify them. The TA-focused agent gets a block with 4h trend; the scan-focused agent gets a block with 24h deltas.