Scope note. The Cryptohopper MCP is stateless by design — each tool call is independent, and the server persists nothing between requests. Memory lives client-side or in storage you control. This guide is about that layer.
Prerequisites
An MCP client with a working Cryptohopper MCP connection. See setup overview.
A place to store data. This can be a local file, a SQLite database, a cloud-stored JSON blob, or a tool like Notion. No infrastructure required to start.
What counts as "memory"
Three layers, each useful for different reasons:
Layer | Example | Typical location |
Session memory | Within one conversation, the model recalls what you said earlier | The model's context window (built-in) |
Cross-run memory | Today's agent run remembers what last week's run observed | File, database, Notion, etc. |
User profile | The agent knows your watchlist, preferred exchange, risk preference | Same as cross-run; loaded at session start |
Session memory is free and automatic. Cross-run and user-profile memory require you to set up storage.
Setup — user profile
Write a short markdown file describing yourself as a crypto user. Keep it under a page:
About the user
Trades primarily on Binance.
Watchlist: BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
Holds spot; runs grid bots on SOL and AVAX via Cryptohopper.
Cares about drawdown risk more than missing upside.
Does not trade perpetuals.
Defaults
Exchange: Binance
Quote: USDT
TA timeframe: 4h (200 bars)
Risk tolerance: moderate
Prompting preferences
Prefer concrete numbers over adjectives.
Flag speculation as speculation.
If a ticker is ambiguous, ask rather than guess.Load it at the start of every agent conversation. Two approaches:
Manual paste: first thing in each session, paste the file.
Client-integrated: use your client's persistent-memory feature (Claude desktop Projects, Cursor rules, Zed context) to auto-inject.
Keep the file small. Anything over ~300 lines becomes noise the model skips past. The point is the constraints, not an autobiography.
Version it. When you change your watchlist or preferences, commit the change to git (or Notion history). Your agent's behaviour will change with the profile; you'll want to see why.
Setup — cross-run memory (simple)
The simplest cross-run memory is a single markdown file the agent reads at the start and appends to at the end:
Create memory.md with a skeleton:
Agent memory Recent observations (Append entries here after each run.) Outstanding items to watch (Things the agent flagged for future attention.) Past decisions (Notable decisions and their reasoning.)
At the start of each agent run, inject the file content:
[AGENT MEMORY] {contents of memory.md} [TASK] Today's task: run the daily digest.At the end of each run, append new observations. Ask the agent to produce them explicitly:
After completing the task, write 2-4 lines summarising anything notable that's worth remembering for next time. Use this format: [YYYY-MM-DD] {observation} Examples: [2026-05-27] SOL volume elevated 3 days running; holding a range of roughly 83-87. [2026-05-27] Watchlist: flagged LINK as quiet but worth checking in 7 days. I'll append these to memory.md manually.Review and prune periodically. Once a week or so, trim
memory.md— delete stale entries, consolidate patterns. An unmanaged memory file grows indefinitely and becomes noise.
Setup — cross-run memory (structured)
For agents that benefit from queryable history, a small SQLite database works well. Schema suggestion:
sql
CREATE TABLE observations (
id INTEGER PRIMARY KEY,
run_at TEXT NOT NULL, -- ISO-8601
agent_name TEXT NOT NULL, -- e.g., "daily-digest"
category TEXT, -- e.g., "volume-spike", "trend-change"
token TEXT, -- e.g., "SOL"
content TEXT NOT NULL, -- the observation text
metadata JSON -- any structured fields
);
CREATE INDEX idx_run_at ON observations(run_at);
CREATE INDEX idx_agent_token ON observations(agent_name, token);
This lets you ask queries like: "what observations did we make about SOL in the last 14 days?" — and feed the answer to the agent as context for today's run.
The agent writes to this table via a small Python helper:
python
def log_observation(agent_name: str, category: str,
token: str, content: str) -> None:
conn.execute(
"INSERT INTO observations (run_at, agent_name, category, token, content) "
"VALUES (?, ?, ?, ?, ?)",
(datetime.utcnow().isoformat(), agent_name, category, token, content),
)
conn.commit()
Use this sparingly. Structured memory is only worth the setup if you'll actually query it; for a simple digest, the markdown file is usually enough.
What to remember, what not to
Good memory candidates:
"SOL has been trending sideways in an 83–87 band for 5 days" — range context that a single day's candle won't show on tomorrow's run.
"We flagged LINK for a volume anomaly yesterday; follow up today."
"User asked about grid bots for AVAX on 2026-05-20; parameters were X, Y, Z."
Not good memory candidates:
Raw market data. It changes — re-pull from the MCP instead of trusting a stale cache.
Full conversation transcripts. Signal-to-noise ratio is too low.
Automatic summaries of every run. Without curation, these become mostly useless.
A good test: "if I delete this memory entry, does the agent behave worse next week?" If no, delete it.
Troubleshooting
The agent cites memory that's contradicted by current data.
This is the fundamental risk of cached context. The agent "remembers" SOL was trending up, but it has since reversed. Fix: instruct the agent to always verify memory claims against current MCP data before using them as fact. "Before relying on a memory entry, check current data and flag if the memory is out of date."
Memory files grow unmanageably large.
You're appending without pruning. Set a hard rule: once a week, review the last week's entries and delete / merge. Or rotate memory files monthly (memory-2026-04.md, memory-2026-05.md).
The agent ignores the memory block.
The prompt doesn't demand the agent use it. Be explicit: "review the memory block above before answering. Reference specific entries where relevant. If an entry contradicts fresh data, flag that explicitly."
Memory introduces confident-but-wrong answers.
The agent is treating memory as authoritative. Frame memory as hints, not truth: "memory contains past observations; treat as context, not fact. Always verify against current data."
You want the agent to update memory without your intervention.
Possible but risky — unmonitored append-only memory grows bad entries as fast as good ones. If you automate it, always pair with a weekly review step. Never let memory grow for a month without being read.
Multi-agent memory gets confused.
If multiple agents share one memory file, use the agent_name field to namespace entries. Each agent reads only its own entries, or reads the full file but knows which agent wrote which line.
The user-profile file becomes stale. Preferences change. If you notice the agent defaulting to a timeframe or exchange you no longer use, update the profile — don't work around it with per-prompt overrides.