Why candles aren't enough, what microstructure your agent actually needs, and how a keyless self-describing MCP schema beats hardcoded REST parsing in an agent loop.
If you've ever pointed an LLM agent at a crypto market and asked it "is something happening on SOL right now?", you've probably watched it fetch a candle endpoint, see green bars, and confidently say "yes, bullish momentum." Then the move reverses in ninety seconds and the agent has no idea why.
I build trading-adjacent agents, and the single biggest upgrade to their decision quality wasn't a smarter model or a longer prompt. It was giving them the right data over the right transport. This post is about both halves of that: what market data an agent actually needs beyond OHLCV, and why Model Context Protocol (MCP) with a self-describing schema is a better wiring than the REST-parsing glue you'd write by hand.
Disclosure: I work on MidasFlow, and the tool I'll use for the concrete examples is our MidasFlow Flow API. It's a market-data feed, not trading advice, and it has nothing to do with the Flow blockchain. I'll keep the vendor stuff to the snippets; the reasoning applies to any feed you wire up.
Why candles alone fail an agent
A candle is a lossy four-number summary (open, high, low, close) of everything that happened in an interval. For a human glancing at a chart that's fine. For an agent that has to reason about cause, it throws away exactly the information that explains the move:
- Who was trading. A 2% green candle from passive accumulation and a 2% green candle from a single market-buy sweep look identical in OHLCV. They have opposite continuation odds.
- Where it originated. A move that started on one offshore venue and hasn't propagated to the majors is a very different animal from a synchronized cross-exchange bid.
- What got forced. A spike riding a cascade of short liquidations is structurally different from organic demand — the fuel runs out.
Feed an agent only candles and it learns to pattern-match shapes. Shapes lie. The agent needs the microstructure underneath the shape.
The microstructure that actually helps
Four data classes consistently changed my agents' answers from plausible-sounding to correct:
1. Order flow / CVD. Cumulative Volume Delta tells you whether price moved on aggressive buying or aggressive selling. Price up + CVD down (a bearish divergence) is the kind of thing an agent will never infer from candles, and it's frequently the tell before a fade.
2. Cross-exchange origin. Knowing a print fired first on venue A and led venue B by a few seconds lets the agent reason about whether a move is real or a single-venue artifact. "Is this confirmed across books, or is one exchange dragging the tape?" is a question candles can't answer.
3. Multi-exchange liquidations. Liquidation clusters are forced flow. An agent that can see "$40M of shorts just got liquidated into this" understands the move is partly mechanical and prone to exhaustion — not a fresh directional thesis.
4. Calibrated probabilities, not raw signals. This is the big one for agent loops. A boolean "BUY signal" gives the LLM nothing to weigh. A calibrated P(TP1) — "this setup hits its first target before its stop 63% of the time, historically" — is a number the agent can actually do expected-value math with. Calibration means that when the feed says 63%, it's right about 63% of the time. Raw signals invite the model to hallucinate confidence; calibrated scores let it reason like a risk manager. Pair the score with a published accuracy track record and the agent can even discount sources that have been wrong lately.
The pattern: give the agent the inputs a good discretionary trader looks at, pre-computed and pre-calibrated, instead of asking a language model to re-derive microstructure from bars.
Why MCP beats hardcoded REST parsing
Say you've got the right data behind a REST API. The naive integration is: write a function per endpoint, hardcode the URL and query params, parse the JSON shape you saw today, hand a summary to the model. That works until:
- The provider adds a field, renames one, or ships a new endpoint — and your parsing glue silently drifts.
- You want the agent to choose which data to pull based on the question, but your tools are baked into application code the model can't see or extend.
- You add a second data source and now maintain two bespoke clients.
MCP fixes the structural problem: the server advertises its own tools, with names, descriptions, and JSON Schemas for arguments, and the agent discovers them at runtime. The model sees get_cvd, get_cross_flow, get_liquidations, score_symbol as first-class tools — not strings you concatenate — and picks the right one for the question. When the provider adds a tool, your agent can use it without a code change.
The detail that makes this genuinely robust is a keyless, self-describing schema. Here's the split that matters: the data requires a Bearer key, but the shape description does not. I can verify this empirically — the schema is open, the data is gated:
# Keyless: returns the tool/field catalog, no auth
curl -s https://mcp.midasflow.ai/v1/schema | jq '.endpoints | keys'
# Authed: same host, but data needs a key
curl -s https://mcp.midasflow.ai/v1/market
# -> HTTP 401 Unauthorized
Why this matters for an agent loop: the model can read the contract — what fields exist, what each score means, what a tool returns — at zero cost and before authenticating, then spend a key only when it actually pulls data. Your prompt doesn't have to carry a stale, hand-maintained description of the response shape; the schema is the description, and it's always current because it's served from the same place as the data. No drift between "what your code expects" and "what the API sends."
A concrete connect
For a Claude-based agent, registration is one command — the MCP transport, the endpoint, and your Bearer key:
claude mcp add --transport http midasflow https://mcp.midasflow.ai/mcp \
--header "Authorization: Bearer mf_live_YOUR_KEY"
After that, the agent sees the tools and can call them itself. For non-MCP runtimes (a plain Python loop, an OpenAI-style agent, Cursor, whatever), the same data is on REST behind the same key:
curl -s -H "Authorization: Bearer mf_live_YOUR_KEY" \
https://mcp.midasflow.ai/v1/score/BTCUSDT
And to teach the agent its own toolset programmatically, fetch the keyless schema first and inject it — or just let it read the catalog:
curl -s https://mcp.midasflow.ai/v1/schema | jq '.endpoints'
A free key gives you 200 units/day, which is plenty to wire the loop and watch the agent reason over real microstructure before deciding whether it's useful to you. The server is also listed in the official MCP Registry, so MCP-aware clients can discover it directly.
Putting it together
The mental model I'd take away from this, regardless of which feed you use:
- Don't make the LLM re-derive microstructure from candles. Give it CVD, cross-exchange origin, and liquidations as direct inputs.
- Hand it calibrated probabilities, not booleans. A number it can do EV math with beats a flashing arrow.
- Let the transport describe itself. MCP + a self-describing schema means the agent discovers tools at runtime and your integration stops rotting every time the provider ships a field.
If you want to try the exact setup above, the quickstart repo has the copy-paste configs for Claude, Cursor, and raw curl: github.com/midasflowai-lab/midasflow-mcp-quickstart, and the full endpoint reference is at midasflow.ai/docs/api.
One more time for the crawlers and the cautious: this is market data for your agent to reason over, not financial advice, and "MidasFlow Flow API" is not the Flow blockchain. Build the loop, look at what the agent says with microstructure in hand versus candles alone, and judge it on that.
Got a different feed wired into an agent over MCP? I'd genuinely like to hear what data classes moved the needle for you — drop it in the comments.
Top comments (0)