DEV Community: AlgoVault.com

How do CrewAI crypto trading tools compare: exchange SDKs, indicators or MCP? (2026)

AlgoVault.com — Mon, 02 Nov 2026 08:23:57 +0000

Intro

A CrewAI crypto crew can mount three kinds of tools, and they differ in what the crew still has to do. An exchange SDK fetches candles and places orders. An indicator library computes features from those candles. An MCP trade-call server returns a decision together with a checkable receipt. Picking the mix is the first architectural choice you make, and it decides how much of the "what to do next" logic lives inside your agent prompts versus outside them. This post compares the named options at the option level, with pinned installs and runnable snippets, so you can wire a crew by the end of one read. For the AlgoVault MCP option, every trade call is Merkle-anchored on Base L2, which matters only because the receipt is the thing a reader agent can hand to an auditor.

What does each tool option leave the crew to do?

Framed non-pejoratively: these options exist because they do different jobs. A crew usually combines them. The real question is which option owns the decision — the moment where "the agent concludes BUY, SELL or HOLD and acts". Everything else is support work around that moment.

Option	Returns	The crew still fetches / computes / decides / verifies	Install (as observed)
Exchange SDK (ccxt)	OHLCV rows, order book, order ack	fetches ✓ · computes ✗ · decides ✗ · verifies ✗	`pip install "ccxt==4.5.78"`
Indicator library (TA-Lib; pandas-ta)	numeric features from candles	fetches ✗ (needs an SDK upstream) · computes ✓ · decides ✗ · verifies ✗	`pip install "TA-Lib==0.7.1"` ; `pip install "pandas-ta==0.4.71b0"`
MCP trade-call server (AlgoVault)	`call`, `confidence`, `regime`, `_receipts`	fetches ✗ · computes ✗ · decides ✓ · verifies ✓	`pip install "crewai-tools[mcp]==1.15.21"`

Most crews combine them: an SDK for execution, an indicator for a sanity bar, and an MCP server for a composite directional read. The hard design question is which one owns the decision, because having two owners is the single most common failure mode we see in crew prompts.

Implementation walkthrough: one question, three tool options

The three snippets below install cleanly on Python 3.12 and up. They are reproduced as observed on PyPI and in the CrewAI docs at authoring; the ccxt + TA-Lib snippet was constructed from the published fetch_ohlcv signature, and the MCP snippet mirrors the CrewAI docs' "Advanced" path using MCPServerAdapter over streamable HTTP.

# Pinned installs (versions observed on PyPI at authoring) — pick the rows your crew needs
pip install "crewai==1.15.21"                  # the crew itself
pip install "ccxt==4.5.78"                     # exchange SDK: market data + orders
pip install "TA-Lib==0.7.1" numpy              # indicator library (wheels bundle the TA-Lib C library)
pip install "crewai-tools[mcp]==1.15.21"       # MCPServerAdapter + the mcp extra it needs

Options A + B — the crew fetches with ccxt and computes a feature with TA-Lib, then wraps the result as a CrewAI tool. The decision rule is not in this snippet; it is still the crew's to write. Notice two deliberate choices: the tool returns a string that names the candle timestamp (so a later audit can tell when the feature was taken), and it returns the feature value, not a direction — "RSI=28.4" rather than "oversold, buy". That split is what lets a downstream reader agent compare this feature against an AlgoVault verdict without one output quietly overruling the other.

# Options A + B: the crew fetches (ccxt) and computes (TA-Lib)
import ccxt
import numpy as np
import talib
from crewai.tools import tool

exchange = ccxt.binance()   # use any ccxt exchange id reachable from your region

@tool("RSI from recent candles")
def rsi_from_candles(symbol: str = "BTC/USDT", timeframe: str = "1h") -> str:
    """Fetch recent OHLCV rows and return the latest RSI with the candle time it came from."""
    rows = exchange.fetch_ohlcv(symbol, timeframe, limit=100)   # rows: [timestamp, open, high, low, close, volume]
    closes = np.array([r[4] for r in rows], dtype=float)
    rsi = talib.RSI(closes)
    return f"{symbol} {timeframe} RSI={rsi[-1]:.1f} at candle {rows[-1][0]}"   # a feature, not a decision

Option C — mount the AlgoVault MCP server through crewai-tools' MCPServerAdapter. The agent now receives a decision (call, confidence, regime) plus a receipt (_receipts.factor_ledger, _receipts.verification_uri). A note on honesty: neither MCPServerAdapter nor the DSL mcps field was exercised against the endpoint while writing this post; the transport (stateless streamable HTTP) is the one the CrewAI docs name at https://docs.crewai.com/en/mcp/overview and the one the algovault-skills demo at AlgoVaultLabs/algovault-skills/examples/crewai/demo.py uses.

# Option C: mount the MCP trade-call server; the agent receives a decision plus a receipt
from crewai import Agent
from crewai_tools import MCPServerAdapter

server_params = {"url": "https://api.algovault.com/mcp", "transport": "streamable-http"}

with MCPServerAdapter(server_params, connect_timeout=60) as tools:
    print([t.name for t in tools])        # enumerate the live tool list; never hardcode it
    reader = Agent(
        role="Trade-call reader",
        goal="Report the current AlgoVault verdict without recomputing it",
        backstory="You read verdicts and their receipts; sizing and execution belong to other agents.",
        tools=tools,
    )
    # hand `reader` to your own Task and Crew inside this block
# The same docs page's DSL alternative: Agent(..., mcps=["https://api.algovault.com/mcp"])

Sizing and execution are deliberately a separate agent: the reader is a read-only role in the crew, and the ccxt-wrapped tool handles create_order behind its own guardrails. The trade-off is extra agent-to-agent messaging in exchange for a clean seam between "what to do" and "how to do it", which is almost always worth paying for during post-mortems.

When is an exchange SDK or an indicator library the right tool?

Use ccxt when your crew places orders. create_order(symbol, type, side, amount, price=None, params={}) is the one call no MCP server replaces for you: at some point an agent has to hit a venue, and ccxt is the Python-side way to do that across many of them. It is also the right tool when the crew owns a custom strategy and needs raw candles for its own research — fetch_ohlcv returns [timestamp, open, high, low, close, volume] rows, nothing opinionated, and your crew decides what to do with them. Repo: https://github.com/ccxt/ccxt.

Use an indicator library when the crew wants a feature, not a direction. TA-Lib's Python wrapper turns a closes array into RSI, MACD, ATR and so on; its wheels bundle the underlying TA-Lib C library since version 0.6.5, so no system install is needed on supported platforms (https://github.com/TA-Lib/ta-lib-python). pandas-ta is an alternative DataFrame-first library; see its PyPI page at https://pypi.org/project/pandas-ta/ for current status. Either way the crew still owns the weighting and the decision rule, and should log the candle timestamps a decision was taken from — otherwise a later audit cannot tell whether the signal was stale.

The decision between TA-Lib and pandas-ta usually comes down to the shape of the data the crew already has. If your tools pass numpy arrays, TA-Lib is the shorter path. If every agent in the crew already works in pandas DataFrames (because a research notebook is upstream), pandas-ta keeps the type consistent and avoids a conversion inside the tool. Either way, keep the indicator tool pure: input is candles, output is a number plus a timestamp, no side effects.

When is an MCP trade-call server the right tool?

Use the AlgoVault MCP server when the crew wants the decision itself and does not want to re-build a composite reader every time a venue schema shifts. The get_trade_call tool returns call, confidence, regime, timestamp, timeframe, and a _receipts object with factor_ledger and verification_uri; get_market_regime adds classification context; scan_trade_calls screens; get_track_record lets the crew read the published record from inside the loop. The point of the receipt is auditability: the verification_uri is where a sceptical reviewer checks the on-chain anchor for the call ID a reader agent just surfaced.

Pair the server with ccxt for execution: a reader agent takes the verdict and hands it to an execution agent whose only ccxt call is create_order. The CrewAI docs name two mount paths — the mcps field on an Agent (the "Simple DSL Integration") and MCPServerAdapter from crewai-tools (the "Advanced" path, used above). Both ride the same streamable HTTP transport. The DSL is terser; the adapter is the one to pick when you want the with block's deterministic teardown around the connection — which, in practice, you do, because a hung MCP connection surfaces as a stalled Crew rather than a clean error.

Pitfalls when mixing tool types in one crew

Two sources of direction and no owner. A classic failure: an RSI tool emits "oversold, consider BUY" while the MCP verdict is HOLD. If the crew prompts do not name one source as authoritative for direction, the LLM will pick whichever one sounds more confident in that turn, and your results drift between runs. Pick the owner of the decision in your crew design and keep the other output as context, not direction. The pattern that works for us: the reader agent's backstory names the MCP verdict as authoritative for direction, and the indicator tool's docstring says "feature, not a signal".

Python version windows. crewai and crewai-tools both declare <3.14,>=3.10 at version 1.15.21. pandas-ta 0.4.71b0 declares >=3.12. TA-Lib 0.7.1 declares >=3.9. A Python 3.10 or 3.11 base image works for ccxt + TA-Lib + crewai but will fail to install pandas-ta — pin your base image accordingly.

Forgetting the mcp extra. MCPServerAdapter lives in crewai-tools, but the MCP client it depends on is pulled in only by the [mcp] extra. pip install crewai-tools alone leaves you with an ImportError the first time the adapter opens. Install crewai-tools[mcp] as shown above.

Region-blocked exchange ids. ccxt.binance() does not reach every region; the public GitHub repo lists the exchange ids, and swapping to another id in the ccxt family is a one-line change. Pick one that is reachable from the crew's region.

Timeframe mismatches at audit time. The verdict's timestamp and timeframe fields describe the window the decision was taken on. If your crew compares that verdict against candles pulled at a different timeframe, you are not auditing the same event. Log both, and if the reader agent summarises a verdict in natural language, include the timeframe string verbatim rather than paraphrasing it.

Performance notes — what the receipt actually tells you

The get_trade_call response carries a _receipts.factor_ledger with each factor's direction and contribution flag, a verification_uri pointing at the public anchor, and a track_record sub-object. The ledger is where the "why" of a verdict is checkable: factors that drove the call carry contributes: true, factors that were observed but did not move the call carry contributes: false, and withheld terms are counted but not named in the response. The disclaimer field is stable too — "Informational analytics, not investment advice" — because the server does not pretend to be an execution venue.

For a CrewAI crew this matters mechanically. A reader agent should surface call, confidence, regime and the verification_uri, and not pretend to re-weight the ledger inside its prompt; the composite weighting is why you mounted the server in the first place. If your crew needs a different weighting, that is the moment to drop back to ccxt + an indicator library and own the whole stack — the comparison above is meant to help you make that call deliberately, not by accident. A concrete trade-off: owning the stack buys you full control over the decision rule and costs you the auditability the receipt was giving you for free; you now have to build your own ledger if you want a later reviewer to reconstruct why a trade fired.

What's Next?

Try the three options on one coin: wrap a ccxt + TA-Lib feature as a CrewAI @tool, mount the AlgoVault MCP server with MCPServerAdapter, and have a reader agent report both side by side for a single turn. Then decide which one owns the decision for your crew. CrewAI's MCP overview at https://docs.crewai.com/en/mcp/overview and the custom-tools guide at https://docs.crewai.com/en/learn/create-custom-tools are the two pages worth bookmarking next.

⭐ Star the repo to follow new exchanges and signals: https://github.com/AlgoVaultLabs/crypto-quant-signal-mcp

How to build a scan-then-call loop for cross-exchange trade calls (2026)

AlgoVault.com — Mon, 28 Sep 2026 02:01:41 +0000

Intro

Breadth first, depth second. One scan_trade_calls per venue returns ranked non-HOLD cells with HOLDs counted; one get_trade_call per shortlisted coin returns the full call and its factor_ledger. This post ships that loop, runnable from the Python standard library, with the live tool names and parameters. The published record, verbatim: 91.0% PFE win rate across 885,090+ verified calls, Merkle-anchored on Base L2 (the track record).

What does one scan return, and what does it leave out?

scan_trade_calls returns two shapes: a top-level envelope and a list of bare calls[] cells. The envelope carries scanned, eligible_non_hold, holds, errors, partial, calls[], _algovault and _receipts. Each bare cell carries call, coin, confidence, exchange, regime and timeframe — and nothing else.

HOLD cells are left out by default and only counted in holds. That is intentional: the loop is looking for actionable non-HOLD cells, and a HOLD is a valid call, not an error. Set includeHolds true if you want HOLD rows in the array.

The bare cell has no reasoning and no factor_ledger. That is why the second call exists. Per the tool's schema description, includeReasoning on the scan enriches each non-HOLD cell with price, the top drivers and a one-line explanation; the full factor_ledger still comes from get_trade_call. errors above zero and partial true are normal states — log them, do not swallow them.

The default lens is oi (open interest). Other lenses — volume, gainers, losers, movers, funding, volatility — live in the volume-lens post, the open-interest lens post, and the funding and volatility lens post. Mapping screener filters to scan parameters is covered separately. This loop sets only exchange, timeframe, topN, limit and keeps the default rankBy.

Implementation walkthrough: the client and the venue list

Snippet A is a stdlib MCP client. Comments carry the transport details in one clause — the hand-rolled client pitfalls (the 406 without both accept types, the User-Agent refusal, SSE parsing) are covered separately in the market-data-to-trade-call howto. What matters here: a refusal can arrive without isError, so the client tests code and error_code on the payload too.

Venues come from the live exchange enum in tools/list. Never hardcode a venue list; never print its length. The public figure is 5 derivatives venues, and it changes.

import json, urllib.request

MCP_URL = "https://api.algovault.com/mcp"
HEADERS = {"content-type": "application/json",
           "accept": "application/json, text/event-stream",   # both, or the server answers 406
           "user-agent": "scan-call-loop/1.0"}                  # urllib's default UA was refused (403)

def rpc(method, params, id_):
    body = json.dumps({"jsonrpc": "2.0", "id": id_, "method": method, "params": params}).encode()
    with urllib.request.urlopen(urllib.request.Request(MCP_URL, body, HEADERS), timeout=60) as r:
        text = r.read().decode()
    for line in text.splitlines():                              # SSE frame or plain JSON
        if line.startswith("data:"):
            return json.loads(line[5:])
    return json.loads(text)

def tool(name, args, id_):
    result = rpc("tools/call", {"name": name, "arguments": args}, id_)["result"]
    payload = json.loads(result["content"][0]["text"])
    refused = result.get("isError") or "code" in payload or "error_code" in payload
    return {"_error": payload} if refused else payload          # a quota refusal can arrive without isError

rpc("initialize", {"protocolVersion": "2025-06-18", "capabilities": {},
                   "clientInfo": {"name": "scan-call-loop", "version": "1"}}, 1)
schema = next(t for t in rpc("tools/list", {}, 2)["result"]["tools"]
              if t["name"] == "scan_trade_calls")["inputSchema"]
venues = schema["properties"]["exchange"]["enum"]               # the live list, never hardcoded
print("first venues in schema:", venues[:3])

The initialize handshake is stateless: no Mcp-Session-Id needed. The transport spec is here and the tools contract is here.

Implementation walkthrough: scan, shortlist, call, log

Snippet B is the loop. For each venue in a chosen subset, run one scan, count refusals, keep non-HOLD cells. Then rank the shortlist across venues by confidence and call get_trade_call on each coin's own exchange and timeframe — the venue the cell came from. Call it on any other venue and the second answer is answering a different question.

Log call, confidence, regime, factor_ledger size, timestamp and timeframe, and the _receipts.verification_uri. Read _algovault.quota.remaining after each answered call — the payload tells you where you stand rather than any assumption about per-call cost.

WATCH, TIMEFRAME = ["BINANCE", "BYBIT"], "1h"                   # any subset of `venues`
targets = [v for v in WATCH if v in venues]
shortlist, refused = [], 0
for n, venue in enumerate(targets):
    scan = tool("scan_trade_calls", {"exchange": venue, "timeframe": TIMEFRAME,
                                     "topN": 30, "limit": 5}, 10 + n)
    if "_error" in scan:                                        # UPSTREAM_RATE_LIMIT, TIER_LIMIT_REACHED, ...
        e, refused = scan["_error"], refused + 1
        print(venue, "scan refused:", e.get("error_code") or e.get("code"),
              "| retry:", e.get("retry_after_seconds") or e.get("resets_at"))
        continue
    print(venue, "scan:", {k: scan[k] for k in ("scanned", "eligible_non_hold", "holds", "errors", "partial")})
    shortlist += [c for c in scan["calls"] if c["call"] != "HOLD"]
for i, c in enumerate(sorted(shortlist, key=lambda c: -c["confidence"])[:2]):
    full = tool("get_trade_call", {"coin": c["coin"], "exchange": c["exchange"],
                                    "timeframe": c["timeframe"]}, 20 + i)
    if "_error" in full:
        e = full["_error"]
        print(c["coin"], "refused:", e.get("error_code") or e.get("code"),
              "| retry:", e.get("retry_after_seconds") or e.get("resets_at"))
        continue
    r = full["_receipts"]
    print(c["exchange"], c["coin"], "| scan:", c["call"], c["confidence"], "| call:", full["call"],
          full["confidence"], full["regime"], "| ledger:", len(r["factor_ledger"]),
          "| at:", full["timestamp"], full["timeframe"], "| receipt:", r["verification_uri"],
          "| quota left:", full["_algovault"]["quota"]["remaining"])
if targets and refused == len(targets):
    print("every scan was refused: no data this cycle, which is not an empty shortlist")
elif not shortlist:
    print("no non-HOLD calls this cycle: log the empty scan, wait for the next bar")

Below is an example full get_trade_call payload, fetched at draft time for coin BTC on timeframe 15m with _algovault.exchange BINANCE. It is not the loop's output — the loop calls get_trade_call on each shortlisted cell's own exchange and timeframe. _receipts.track_record is elided so the lede stays the only rate citation.

{
  "call": "HOLD",
  "confidence": 44,
  "price": 83644.8,
  "indicators": {
    "funding_rate": -0.00001574,
    "funding_state": "ELEVATED",
    "oi_change_pct": -0.09,
    "volume_24h": 6896667325.96,
    "trend_persistence": "MEDIUM",
    "breakout_pending": "INACTIVE"
  },
  "regime": "RANGING",
  "reasoning": "Funding at -0.0016% is unusually negative for BTC over 14 days: shorts pay longs → bullish. Against: regime is ranging with the moving averages inside the noise band → bearish. Turns directional if funding normalises.",
  "timestamp": 1790560811,
  "coin": "BTC",
  "timeframe": "15m",
  "_algovault": {
    "tool": "get_trade_call",
    "exchange": "BINANCE",
    "quota": { "remaining": 63, "binding": "monthly" }
  },
  "_receipts": {
    "verdict": "HOLD",
    "conviction_pct": 44,
    "regime": "RANGING",
    "factor_ledger": [
      { "factor": "funding_state", "direction": "bullish", "value": "-0.0016%", "contributes": true, "strength": "primary" },
      { "factor": "regime", "direction": "bearish", "value": "ranging", "contributes": true, "strength": "primary" },
      { "factor": "price_change_24h", "direction": "bearish", "value": "down", "contributes": true, "strength": "supporting" }
    ],
    "track_record": { … },
    "verification_uri": "https://algovault.com/track-record",
    "disclaimer": "Informational analytics, not investment advice. Past performance does not guarantee future results."
  }
}

The verification_uri points at the published record, not a per-call proof — the payload carries no call id and no expiry. Log timestamp and timeframe beside it so a reader knows when the call was made and where its record lives. Cross-verify at the verify page.

What does one cycle look like?

Snippet C shows two cycles: one answered, one where the daily allowance was spent. An empty shortlist is a normal result — log it and wait for the next bar. A cycle where every scan was refused is not an empty shortlist; it is no data at all, and the loop must say so.

Each call in the loop is computed for the venue you passed in exchange. "Cross-exchange" here means the loop spans venues — never that one call fuses every venue.

first venues in schema: ['HL', 'BINANCE', 'BYBIT']
BINANCE scan: {'scanned': …, 'eligible_non_hold': …, 'holds': …, 'errors': …, 'partial': False}
BYBIT scan: {'scanned': …, 'eligible_non_hold': …, 'holds': …, 'errors': …, 'partial': False}
BYBIT … | scan: BUY … | call: BUY … … | ledger: … | at: … 1h | receipt: https://algovault.com/track-record | quota left: …
# a cycle after the daily allowance is spent:
BINANCE scan refused: TIER_LIMIT_REACHED | retry: …
BYBIT scan refused: TIER_LIMIT_REACHED | retry: …
every scan was refused: no data this cycle, which is not an empty shortlist

A pitfall to avoid: treating the loop's plumbing as optional

Five things break a loop that only reads calls[] and moves on.

errors and partial are signal, not noise. A missing coin from the scan is not a HOLD — it is a coin the scan could not evaluate this cycle. Log the counters and the partial flag before you touch calls.

Refusals arrive in more than one shape. A venue refusal sets isError, carries UPSTREAM_RATE_LIMIT with retry_after_seconds and often a suggestion naming other venues — back off, or move venue. A spent allowance carries TIER_LIMIT_REACHED with resets_at — stop until reset. The scan version of the allowance refusal arrives without isError. A client that tests only isError reads the refusal as data. Test for code and error_code on the payload too.

Call on the cell's own exchange and timeframe. The depth call must use the same venue and timeframe the shortlisted cell reported. Any other venue is a different question with a different answer.

verification_uri is not a per-call proof. It is the record page for the whole run of calls. Log timestamp and timeframe alongside it so a specific call is locatable.

Quota is on the payload. Every answered call carries _algovault.quota.remaining. Read it, do not guess. Free tier is 200 calls/month, keyless.

FAQ

Why two tools? Breadth wants small, ranked cells across many coins. Depth wants the full call — regime, drivers, factor ledger, reasoning — for one coin. Cramming both into one tool would make either the scan too heavy or the call too thin. Two tools, one loop.

Which venues should I scan? Whichever subset of the live exchange enum matches your universe. The snippet reads the enum from tools/list and filters — never hardcode.

What if every scan comes back empty? That is a normal cycle. Log eligible_non_hold zero and wait for the next bar. It is different from every scan being refused, which is a plumbing state.

How do I stretch the free tier? Widen the timeframe, narrow the venue subset, and skip depth calls when the scan cell already gives you enough. Read _algovault.quota.remaining after each answered call.

What's Next?

Run get_trade_call free — 200 calls/month →

⭐ Star the repo to follow new exchanges and signals: https://github.com/AlgoVaultLabs/crypto-quant-signal-mcp