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
Top comments (0)