Intro
Which crypto signal providers publish a track record an autonomous agent can actually audit before trusting a call? Most don't. Most publish a screenshot or an unaudited win-rate dashboard that an LLM agent has no way to verify. AlgoVault answers the question by exposing the record as data: the signal-performance MCP resource returns an aggregated PFE win rate, and every underlying call is anchored in a Merkle tree published on Base L2. An agent reads one resource, or resolves one call through /verify, and gets a tamper-evident answer.
The live proof line as of this post: 91.8% PFE win rate across 330,364+ verified calls, Merkle-anchored on Base L2. We publish the thesis; agents decide execution. That is the wedge — verifiability, not marketing.
How do you verify a crypto signal provider's track record on-chain?
You verify by reading a resource, not by trusting a screenshot. In AlgoVault's model, the signal-performance MCP resource is a first-class primitive an agent can call the same way it calls a tool. The response carries the aggregated PFE win rate across every verified call the platform has ever emitted. Because each call is committed into a Merkle batch anchored on Base L2, the aggregate is a claim you can back-check against on-chain state through /verify.
Public numbers are aggregate PFE only. There is no exposure of per-trade return metrics, no per-call profit field, no marketing-inflated snapshot. That constraint matters: it means the number a provider publishes is the number an agent can reason against, without inheriting a metric that was cherry-picked for optics. The on-chain anchor removes the "trust me" step. If a batch drifts, you'd see it. If a call resolves, /verify returns proof.
For agent builders in the ICP that AlgoVault targets — quant/systematic, rule-based bots, LLM multi-agent — the auditability is the wedge. You do not need to believe the vendor. You read the resource.
How do I read the verified record from an agent?
Reading the record from an agent is one MCP call. There is no auth to set up on the free tier, no API key handshake, and no proprietary SDK. The AlgoVault MCP server is a remote endpoint at https://api.algovault.com/mcp, and any MCP-compliant client — Claude Desktop, Cursor, a custom LangGraph loop — connects, lists tools, and invokes get_trade_call. The verdict is composite; the classifier runs server-side; the response includes the regime label and the factor breakdown the composite is built on.
The minimum viable snippet, verified against the live tool shape:
// Connect the AlgoVault MCP server, then one call returns a composite verdict.
// Remote MCP endpoint (keyless free tier — 100 calls/month):
// https://api.algovault.com/mcp
const result = await mcp.callTool("get_trade_call", { coin: "BTC", timeframe: "4h" });
// -> { verdict: "BUY" | "SELL" | "HOLD", confidence, regime, factors }
Behind the same server, the signal-performance resource returns the aggregated record without a separate integration. One read; one aggregate; one anchor to check. Full framework wiring and streaming examples live in the integrations catalogue and the docs. See also the Model Context Protocol specification for how tools and resources are surfaced across clients.
Why on-chain verifiability matters for an autonomous agent
An autonomous agent that acts on signals it cannot audit is inheriting somebody else's marketing team. That is a real risk for anything above hobby-tier capital. A Merkle anchor on a public L2 turns the record from a claim into an artifact. The batch commitment is immutable; the leaves are the calls; the leaves resolve at their timeframe horizon; the aggregate is derived from resolved leaves, not from imagined ones.
That property matters most for the LLM multi-agent segment. A router agent evaluating multiple signal sources needs a machine-readable, tamper-evident record to weight them against each other. A screenshot cannot be weighted. A JSON aggregate anchored on Base L2 can. The track record page is human-readable; the MCP resource is the same data an agent should consume programmatically. Both point at the same underlying commitment.
Implementation walkthrough
The end-to-end integration is short. You install nothing local for the free tier — the MCP server is remote. You point your client at the endpoint, list tools, and read the resource. This walkthrough is the honest, minimal path from zero to a verifiable verdict inside an agent loop.
Step one is the client-side connection. Any framework with MCP support — the reference SDK, LangGraph adapters, or the built-in Claude Desktop config — accepts a remote endpoint. The keyless tier is 100 calls/month, enough to prototype every path in this walkthrough without any signup flow. The docs enumerate the exact per-framework wiring; the Anthropic MCP quickstart covers the client side.
Step two is invoking the tool. The tool is get_trade_call, not get_trade_signal — the canonical shape uses the verdict key. This matters because older examples on the internet used the pre-latest schema; do not paste those into a live agent, or you will get a validation error. Here is the shape a mis-called version returns, which is instructive because it shows the server enforces the schema strictly:
{
"content": [
{
"type": "text",
"text": "MCP error -32602: Input validation error: Invalid arguments for tool get_trade_signal: [\n {\n \"code\": \"invalid_type\",\n \"expected\": \"string\",\n \"received\": \"undefined\",\n \"path\": [\n \"coin\"\n ],\n \"message\": \"Required\"\n }\n]"
}
],
"isError": true
}
That error is the correct behavior — the server rejects malformed input at the boundary. Fix the call by naming the coin and timeframe explicitly, and the response is a verdict with confidence, regime, and factor breakdown.
Step three is the agent loop. The pattern is: pull the current verdict, filter on confidence, act only on non-HOLD verdicts, and log every decision against the aggregate record for later audit. A minimal dry-run of that loop prints the exchange contact + gating behavior:
# AlgoVault MCP example — assets=BTC confidence_threshold=70
[BTC] ERROR: HTTP 406
# DRYRUN_MODE=1 — example complete
The 406 in the dry-run is the server telling the client the requested content negotiation did not match — an intentional gating step during dry-run rehearsal. Handle it the same way you'd handle any HTTP contract violation: log, back off, retry with correct headers. The point of showing the raw failure is that the surface is honest — the client sees real server responses, not synthetic mock output. In production the loop pulls verdicts, gates by confidence, and calls into your execution layer.
A pitfall to avoid — and the design decision behind it
The most common mistake teams make when integrating a track-record-backed signal source is reimplementing scoring client-side. Do not do this. The composite verdict is a stateful function of live venue data, regime state, and factor weights that shift with the classifier. If you cache the factor breakdown and recompute the verdict locally, your agent will drift out of sync within hours. The server keeps the verdict current; your job is to consume it.
The second pitfall is treating HOLD as an error. HOLD is a valid verdict and a deliberate design choice. Selectivity is a feature: an agent that acts only when the composite says BUY or SELL trades less and, empirically, better. Free-tier calls include HOLD verdicts at the same 100/month allowance — you are not being rate-limited by holding. Treat HOLD as "the model has an opinion, and it is inaction."
The third pitfall is confusing venue coverage with venue count. Composite verdicts are computed across the full asset coverage of live derivatives venues in the integration set — Binance, Bybit, OKX, Bitget, Hyperliquid — and the composite adapts as venues are added. Do not hardcode a venue count into your agent's assumptions; ask the resource, not the constant.
Why a verifiable record matters more than a bigger number
A provider claiming a high win rate without an anchor is a marketing artifact. A provider publishing a lower verifiable win rate is a data artifact — and the data artifact is what an agent should reason against. That is why the aggregate is public PFE only, why the anchor is a public Base L2 Merkle commitment, and why the surface is an MCP resource an LLM can read as easily as a human can read the track record page.
Verifiability compounds. Every additional resolved call adds a leaf; every batch adds an anchor; every read of the aggregate reflects the same underlying commitment. That is the loop that separates a signal provider from a signal advisor — we provide the thesis, agents decide execution, and the record of every thesis is queryable by the agent that consumed it. See the live verifier for the resolution flow end-to-end.
What's Next?
- the track record — verify the live PFE aggregate and the Merkle anchors on Base L2.
- the docs — quickstart for the MCP endpoint and per-framework wiring.
- the GitHub repo — reference implementation of the MCP client.
- Every framework + demo — Claude, Cursor, LangGraph, custom loops.
Run get_trade_call free — 100 calls/month →
— Mr.1, AlgoVault Labs
⭐ Star the repo to follow new exchanges and signals: https://github.com/AlgoVaultLabs/crypto-quant-signal-mcp
Top comments (0)