There's a conversation we keep having with people who've just set up the Cryptohopper MCP. It goes something like this: "Okay, this is great, it can read the market. But can I actually get it to place trades?"
The honest answer is: the Cryptohopper Market Data MCP is read-only. It does not place trades. A dedicated trade-execution MCP is on our roadmap — but it's not live yet.
But you can absolutely build end-to-end trading agents with Cryptohopper today. The pattern is simple and it's actually better than having everything in one MCP — clean separation of concerns, clearer audit trail, more defensible architecture. The two pieces of the puzzle are:
- The Cryptohopper Market Data MCP for the thinking: research, scans, analysis, decisions.
- The Cryptohopper REST Trading API for the doing: placing orders, managing positions, controlling bots.
This article is the blueprint. What the architecture looks like, why it's a good idea, what you can build today, and how to plan for the day the trade-execution MCP ships.
The mental model: thinking vs. doing
Most professional trading systems, human or automated, already separate thinking from doing. A quant's research lives in one place (notebooks, dashboards, indicators); the execution engine lives in another (low-latency gateways, tested order logic, strict guardrails). Nobody sensible lets the exploratory side touch the production order book directly.
MCP-plus-REST is the AI-agent version of that split.
The MCP handles:
- Reading the market — tickers, orderbooks, candles across exchanges.
- Reasoning — trend, volatility, regime, relative strength.
- Deciding — "yes, I want to buy 0.5 ETH on Binance right now."
The REST API handles:
- Authenticating against your Cryptohopper account.
- Sending the order to the exchange with correct parameters.
- Managing positions, open orders, balances.
- Running and controlling your Cryptohopper bots (grid, DCA, trailing, etc.).
The model is good at reasoning. Your code is good at determinism. They should not be the same layer — not today, not when the execution MCP ships, not ever. Keeping them separate is the feature, not the workaround.
Why this is actually a better architecture
Three reasons this split beats a single all-in-one MCP, even conceptually:
Deterministic execution. When an agent decides to place a $10,000 trade, you want the order step to be exactly what you told it to be. No reasoning in between. No model picking a slightly different order type. The REST layer enforces that: your code receives the decision, validates it, and sends it to the exchange. What the agent said is what the exchange sees.
Clear audit trail. Every order has a source (the reasoning log from the MCP session) and an action (the REST call). When something goes wrong — and it will, at some point — you can reconstruct exactly what the agent was looking at when it decided, and exactly what the order engine did in response. Good luck doing that cleanly with a single call that does both.
Guardrails in the right place. Size limits, stop-loss enforcement, maximum drawdown caps, blacklisted pairs — these belong in your execution layer, not in the AI reasoning layer. A model can be told "don't trade over $10k" and usually listens. Your execution code can enforce it, unconditionally. When real money is on the line, the difference matters.
Testability. You can unit-test a REST client. You can integration-test it against a sandbox. You can dry-run it without touching real capital. Testing a pure AI workflow is a different, harder problem. Keeping the execution layer separate means that the part that actually touches money is the part that can be fully tested.
None of this goes away when the execution MCP ships. It's the right architecture even when you have the option to put everything in one server.
The basic shape of an end-to-end agent
In pseudocode:
# 1. RESEARCH — driven by MCP
# The agent reads the market through the MCP and produces
# a structured decision.
decision = run_agent_with_mcp(
prompt="Analyse the top 50 Binance pairs by volume, find the "
"best swing-trade setup for a $5k position, and output "
"your decision in JSON."
)
# decision looks like:
# {
# "action": "buy",
# "pair": "SOL/USDT",
# "exchange": "binance",
# "size_usd": 5000,
# "reasoning": "4h trend up, RSI 58, volume above baseline, ..."
# }
# 2. GUARDRAILS — enforced by your code
# Your code validates the decision against hard limits.
validate_decision(decision) # raises if outside allowed params
# 3. EXECUTION — via Cryptohopper REST API
# Your code places the order. The model is not involved.
response = cryptohopper_api.place_order(
exchange=decision["exchange"],
pair=decision["pair"],
side=decision["action"],
size_usd=decision["size_usd"],
)
# 4. LOGGING — for audit
# Save the reasoning alongside the order result.
log_decision_and_execution(decision, response)
This is the skeleton. Real agents dress it up — they might loop, they might react to fills, they might hand off to a Cryptohopper bot for management after entry. But the three pillars are always the same: research via MCP, validate with guardrails, execute via REST.
The step-by-step walkthrough, with runnable Python code, is in pattern: research via MCP, execute via the Cryptohopper API. This article is the architecture; that article is the recipe.
What you can build today
Five patterns that work right now, using only what's shipping:
The thesis trader
The agent runs a research pass every morning on a specific market segment (say, the top 20 L1s). It looks for setups matching a thesis you defined — e.g. "find pairs in clean uptrends on the 4h with RSI between 50 and 65 and volume above the 7-day average". For any matches, it outputs a decision. Your REST layer opens a position. A separate process — or a Cryptohopper bot you already run — manages the exit.
This is the cleanest entry pattern. Research is LLM-heavy; execution is code-simple.
The opportunistic swing agent
Similar to the thesis trader, but running on a shorter cadence — every few hours — and looking for short-lived setups like volume spikes, cross-exchange gaps that might be executable, or breakouts from defined ranges.
The agent's output is either "nothing today" or a specific entry plan. Most days: nothing. The days something flags: your REST layer acts on it. The discipline comes from the agent being willing to do nothing.
The cross-exchange execution router
A question the MCP answers very cleanly: "where is it cheapest to buy $20k of BTC right now?" The agent checks spreads and orderbook depth across exchanges and tells you the best venue. Your REST layer places the order on that specific exchange. Over many trades, the execution savings add up.
See A practical guide to crypto orderbook data and how to estimate slippage before placing a trade for the slippage-aware version of this.
The risk-off circuit breaker
The agent doesn't enter positions — it just watches. If conditions change (realised volatility spikes, BTC breaks a level, your portfolio is down more than X%), it outputs a "risk off" signal. Your REST layer reads this signal and closes positions, reduces bot sizes, or halts new entries.
This is one of the highest-value patterns because it shortens your reaction time dramatically. Humans notice market stress late. An agent watching continuously catches it the moment it starts showing up in the data.
The Cryptohopper bot conductor
Cryptohopper's existing bots — grid, DCA, trailing — are already great at execution. The agent's job is to decide when to use them, and how to configure them. Research via MCP, push a new grid configuration via REST, let the bot take it from there.
This is the pattern that closes the loop with Cryptohopper's existing product. See how to build a grid-bot parameter generator for the concrete recipe.
Guardrails worth baking in
Since you're writing the execution layer yourself, you choose the guardrails. A non-exhaustive list worth considering:
- Maximum position size. Per trade, per day, per week.
- Maximum drawdown. If portfolio is down X% from peak, refuse new entries.
- Pair whitelist. The agent can suggest anything; your code only acts on pairs you've pre-approved.
- Exchange whitelist. Same idea, per venue.
- Time-of-day limits. Some strategies shouldn't run during low-liquidity hours.
- Sanity checks on the decision. If the agent's size suggestion differs wildly from your usual range, refuse and alert.
- Confirmation for large trades. Above a threshold, require human approval before the REST call fires.
The point is not to constrain the agent's creativity — it's to make sure no decision the agent proposes can bypass your risk rules. The more of these you encode in code, the safer you can let the agent explore.
What the execution MCP will change (and what it won't)
When the trade-execution MCP ships, the REST step can migrate to an MCP call. In theory. In practice, we expect most serious users will still keep an intermediate validation layer:
- Before: agent → REST execution
- After: agent → validation layer → execution MCP
The validation layer — where your guardrails live — stays. It's the only part of the system where rigid rules make more sense than fluid reasoning.
What the execution MCP will make easier:
- Simpler setups where guardrails are minimal.
- More conversational flows where the agent can place, monitor, and adjust orders in a single reasoning loop.
- Access to the full suite of order types directly from any MCP client.
What it won't change:
- The case for an audit trail.
- The case for deterministic execution on anything that matters.
- The fact that risk management is too important to live inside an LLM.
If you build the split architecture today, you're not building a stopgap. You're building the shape of the system you'll want to run anyway.
A note on which bots to use
If you're already running Cryptohopper bots — grid, DCA, trailing-stop, signal-based — the pattern extends naturally. The agent does research, decides a bot should be configured a certain way, and the REST API updates the bot. You don't have to build exit logic from scratch; Cryptohopper already has it.
For anyone considering this path: it's the pattern we think will be the most common in 2026. MCP-driven research, Cryptohopper-bot-driven execution. The two pieces are designed for each other even before the execution MCP arrives.
Where to start
If you want to build the split architecture today:
- Get the MCP set up. The complete setup guide walks through every supported client.
- Get a Cryptohopper REST API key. Separate from your MCP key — it's generated and managed in your Cryptohopper account and governs which exchanges and which actions the key can perform. The developer documentation is the source of truth.
- Build a minimal agent. Start with the thesis trader or the execution router. Don't aim for autonomy on day one — aim for proposing trades you approve before they fire. Take the humans-in-the-loop version seriously.
- Add guardrails as you remove humans. Every guardrail you encode in code is a human approval you can safely automate.
The full working example lives in the companion how-to.
The honest summary
Every time someone asks us "when can my agent actually trade?", the answer is "today, if you build the right architecture — and that architecture will still be the right one after the execution MCP ships." Data layer and execution layer, split cleanly. Reasoning in the model, rules in the code.
It's slightly more work than a magic one-MCP answer would be. It's also how the systems you'd actually want to trust with real capital end up structured. Build for that shape today, and the next shipping milestone just makes one piece easier — it doesn't rearrange the whole stack.
_webp.webp&w=1920&q=75)
_webp.webp&w=1920&q=75)