DEV Community: AlgoVault.com

How to run a Claude crypto research loop: regime, call, record (2026)

AlgoVault.com — Mon, 21 Sep 2026 02:01:40 +0000

Intro

Add the AlgoVault MCP to Claude Code with one documented command, or drop it into Claude Desktop as a custom connector, then ask Claude to run three tools in order: get_market_regime, get_trade_call, get_track_record. The published record, verbatim: 91.1% PFE win rate across 785,484+ verified calls, Merkle-anchored on Base L2 (see the track record). This post wires the loop end to end and reads the fields that keep it honest.

What do you need before you start?

Claude Code or Claude Desktop, and nothing to install locally. The endpoint is keyless on the free tier, so a first run needs no signup, no API key and no config file edits.

How do you connect Claude Code?

Claude Code's MCP docs recommend HTTP as the remote transport (SSE is deprecated). The default scope is local — this project only — and --scope user loads the server in every project. claude mcp list prints a health status per server; /mcp inside a session lists tools.

# Add the keyless remote endpoint over HTTP (default scope: this project only)
claude mcp add --transport http algovault https://api.algovault.com/mcp
# ...or load it in every project
claude mcp add --transport http algovault https://api.algovault.com/mcp --scope user
# Health check: expect a Connected health status next to algovault
claude mcp list

For project-scoped configs and API-key headers, see the Claude Code integration page. Do not copy commands from other sources — the documented claude mcp add --transport http form above is the one verified against the live endpoint.

How do you add it to Claude Desktop?

Anthropic's custom-connectors article describes the remote MCP path: Customize > Connectors → "+" → "Add custom connector" → paste https://api.algovault.com/mcp → "Add". Free plans get one custom connector; Pro, Max, Team and Enterprise plans get more. The connection originates from Anthropic's servers, not your machine, so no local process runs.

The MCP docs describe the same flow under Settings → Connectors. Menu labels can move between releases; the destination is the same. claude_desktop_config.json is the separate mechanism for local servers — do not paste a remote "url" entry into it, that form is not documented for remote MCP. The Claude Desktop integration page has the current UI walkthrough.

Implementation walkthrough: regime, call and record in one Claude turn

Paste this prompt into Claude Code or Claude Desktop after the connector is live. Claude chains the three tools in one research turn.

Use the algovault tools, in this order, for BTC on the 4h timeframe on BINANCE:
1. get_market_regime: report regime, confidence, metrics.trend_strength and
   metrics.cross_venue_funding_sentiment.
2. get_trade_call with the same coin, timeframe and exchange: report call, confidence,
   regime, reasoning, and the factor_ledger entries whose strength is not "none".
3. get_track_record: report period.from, period.to and methodology.pfeWinRate.
Then say whether the two regime labels agree and how old the call is (timestamp vs
timeframe). Do not recommend a trade.

Step 1: what regime is the market in?

get_market_regime accepts coin, timeframe (only 1h, 4h or 1d) and exchange. Read regime, confidence, metrics.trend_strength, metrics.cross_venue_funding_sentiment and metrics.funding_by_venue. The suggestion field is a descriptive hint — name the field, do not quote its string as advice.

Step 2: what is the trade call, and does it agree?

Call get_trade_call with the SAME coin, timeframe and exchange. Read call, confidence, regime, reasoning, timestamp and _receipts.factor_ledger (factor, direction, value, contributes, strength). Freshness is timestamp + timeframe — there is no expiry field. If you want the confidence-gated pattern behind these fields, the regime-aware post covers it once; building an allow/deny gate on regime is covered separately.

Below is an example get_trade_call payload, fetched at draft time, coin: BTC, timeframe: 15m, _algovault.exchange: BINANCE — this is a labelled sample, not the output of Snippet B (which uses 4h) or Snippet D:

{
  "call": "HOLD",
  "confidence": 30,
  "price": 80991.4,
  "indicators": {
    "funding_rate": 0.00006963,
    "funding_state": "NORMAL",
    "oi_change_pct": 0.98,
    "trend_persistence": "MEDIUM",
    "breakout_pending": "INACTIVE"
  },
  "regime": "RANGING",
  "reasoning": "Regime is ranging with the moving averages inside the noise band → bullish. Against: price is down over 24h, the momentum term behind the call → bearish. Turns directional if funding moves off neutral.",
  "timestamp": 1789956009,
  "coin": "BTC",
  "timeframe": "15m",
  "_algovault": {
    "tool": "get_trade_call",
    "exchange": "BINANCE",
    "quota": { "remaining": 82, "binding": "monthly", "daily": { "remaining": 97 } }
  },
  "_receipts": {
    "verdict": "HOLD",
    "conviction_pct": 30,
    "regime": "RANGING",
    "factor_ledger": [
      { "factor": "regime", "direction": "bullish", "value": "ranging", "strength": "primary" },
      { "factor": "price_change_24h", "direction": "bearish", "value": "down", "strength": "supporting" },
      { "factor": "funding_state", "direction": "neutral", "value": "+0.0070%", "strength": "none" }
    ],
    "track_record": { … },
    "verification_uri": "https://algovault.com/track-record"
  }
}

The field names your loop reads (values vary per call — these come from live 4h responses):

{
  "get_market_regime": { "coin": "BTC", "timeframe": "4h", "regime": "…", "confidence": "…", "suggestion": "…",
    "metrics": { "trend_strength": "…", "cross_venue_funding_sentiment": "…",
                 "funding_by_venue": { "BINANCE": { "rate": "…", "interval_min": "…", "rate_8h_equiv": "…" } } } },
  "get_trade_call": { "coin": "BTC", "timeframe": "4h", "call": "…", "confidence": "…", "regime": "…", "reasoning": "…", "timestamp": "…",
    "_receipts": { "factor_ledger": [ { "factor": "…", "direction": "…", "value": "…", "contributes": "…", "strength": "…" } ],
                   "verification_uri": "https://algovault.com/track-record" } },
  "get_track_record": { "period": { "from": "…", "to": "…" }, "methodology": { "pfeWinRate": "…" } }
}

Step 3: what does the published record say?

get_track_record returns a lot. Read only two things here: period (from, to) and methodology.pfeWinRate. That last one is a text definition — did price move in the call's direction at any point in the evaluation window. Cross-check at the track record and verify. The breakdowns, the evaluation windows and the recording gate are covered separately; do not print a per-timeframe rate beside the call.

Check the loop without Claude

The same three calls, standard library only, and refusals read instead of thrown:

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": "claude-loop-check/1.0"}              # urllib's default UA was refused (403)
ARGS = {"coin": "BTC", "timeframe": "4h", "exchange": "BINANCE"}   # one set of args for both tools

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():                              # an 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

rpc("initialize", {"protocolVersion": "2025-06-18", "capabilities": {},
                   "clientInfo": {"name": "claude-loop-check", "version": "1"}}, 1)
regime, call = tool("get_market_regime", ARGS, 2), tool("get_trade_call", ARGS, 3)
record = tool("get_track_record", {}, 4)
for name, r in (("get_market_regime", regime), ("get_trade_call", call)):
    if "_error" in r:
        e = r["_error"]
        print(name, "refused:", e.get("error_code") or e.get("code"),
              "| retry:", e.get("retry_after_seconds") or e.get("resets_at"))
    else:
        q = r["_algovault"]["quota"]
        print(name, "| regime:", r["regime"], "| timeframe:", r["timeframe"],
              "| quota left:", q["remaining"], "| binding:", q["binding"])
if "_error" not in call:
    print("call:", call["call"], call["confidence"], "| at:", call["timestamp"], call["timeframe"], "| ledger:",
          [(f["factor"], f["strength"]) for f in call["_receipts"]["factor_ledger"] if f["strength"] != "none"])
if "_error" not in regime and "_error" not in call:
    print("regime labels agree:", regime["regime"] == call["regime"])
if "_error" not in record:
    print("record:", record["period"], "| pfeWinRate means:", record["methodology"]["pfeWinRate"])

Hand-rolled clients have their own quirks — the 406 without both accept types, the 403 from urllib's default User-Agent, SSE frame parsing — and the market-data-to-trade-call howto covers them in depth. One clause here is enough.

A pitfall to avoid: mismatched arguments and unread refusals

Three ways this loop drifts into nonsense, and how to keep it honest.

First, timeframes. get_market_regime accepts only 1h, 4h or 1d; get_trade_call defaults to 15m and accepts everything from 1m to 1d. Pass ONE timeframe value to both, or you are comparing two different windows and calling it disagreement. Second, venue. The regime tool defaults to HL and the call defaults to Binance. Pass exchange to both, always. But aligned arguments do NOT make the two regime labels agree — each tool classifies regime separately from its own metrics. In the authoring run, identical args (BTC, 4h, BINANCE) returned TRENDING_DOWN from the regime tool and RANGING from the call. That is information, not a bug: read the call's own regime + reasoning against the regime tool's metrics.trend_strength and decide whether the disagreement is load-bearing.

Third, quota. After each answered get_market_regime and get_trade_call, read _algovault.quota.remaining and binding. A spent allowance returns isError with error_code: TIER_LIMIT_REACHED, a limit field and resets_at — no quota block. UPSTREAM_RATE_LIMIT with retry_after_seconds means the venue said no; wait, or ask a suggestion venue. HOLD is a valid call; it is not an error state.

FAQ

Which transport should I use for Claude Code? HTTP. SSE is deprecated in the docs; the claude mcp add --transport http command in Snippet A is the current recommended form.

Do I need an API key to try this? No. The free tier is keyless — 200 calls/month, 100 calls/day — and covers everything in this walkthrough.

Why do the two regime labels disagree sometimes? Each tool classifies regime independently from its own metrics. Same coin, same timeframe, same venue can still produce two different labels. Read the disagreement as information.

Can I read get_track_record without spending quota? In the authoring run it answered from a client whose daily allowance on the other two tools was spent; nothing more about its metering was observed here. The record's meter behaviour is covered separately in the win-rate howto.

What's Next?

the track record
the docs
the GitHub repo
the stack answer (the query hub)
background only: the Claude crypto trading stack companion page

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

AlgoVault Weekly Trade-Call Report — Week of 2026-09-20

AlgoVault.com — Sun, 20 Sep 2026 12:00:05 +0000

AlgoVault Trade-Call Intelligence — Week of 2026-09-20

📊 777,334 trade calls tracked
🎯 PFE Win Rate: 91.1% across 2204+ assets (Hyperliquid)
🏆 Top performer: NCSKGLXY2USD 3m — 100.0% PFE Win Rate (8 evaluated)
📈 Confidence band 50-54 hitting 91.7% accuracy

All calls are on-chain verified (Base L2 Merkle root).

📊 Live track record: algovault.com/track-record
🔌 Connect an agent: algovault.com/docs
🛰 Set a standing scan in Telegram: t.me/algovaultofficialbot

Built by AlgoVault Labs — call interpretation for AI trading agents.

This week's top crypto trade setups — 789 asset scans · 15 venues (Sep 2026)

AlgoVault.com — Fri, 18 Sep 2026 12:03:36 +0000

This week's top crypto trade setups — 789 asset scans · 15 venues (Sep 2026)

Live from AlgoVault's engine:

📡 This week I scanned 789 assets across 15 venues.

Top fresh setups:

🟢 WLD — BUY @ $0.4415 · 89% conviction · TRENDING_UP
📊 trend persistence HIGH · funding normal · OI +59.8% (24h)
💡 Regime is trending up on the moving-average cross → bullish

🟢 HYPE — BUY @ $89.93 · 79% conviction · TRENDING_UP
📊 trend persistence MEDIUM · funding extreme ↑
💡 Funding at -0.0322% is unusually negative for HYPE over 14 days: shorts pay longs → bullish

🟢 NEAR — BUY @ $3.50 · 78% conviction · TRENDING_UP
📊 trend persistence HIGH · funding normal · OI +26.3% (24h)
💡 Regime is trending up on the moving-average cross → bullish

🟢 G — BUY @ $0.0082 · 78% conviction · TRENDING_UP
📊 trend persistence MEDIUM · funding normal
💡 Regime is trending up on the moving-average cross → bullish

🟢 TIA — BUY @ $0.3947 · 78% conviction · TRENDING_UP
📊 trend persistence MEDIUM · funding normal
💡 Regime is trending up on the moving-average cross → bullish

Every setup above is a live call from the same engine that publishes its full record on-chain — each one written down before its outcome is known. Conviction is shown as measured, not rounded up: these are the week's strongest setups, not certainties.

Ranking is by conviction across every venue scanned, deduplicated per coin, and filtered by a USD liquidity floor. The headline figure counts scans rather than distinct assets — a coin listed on several venues is scanned on each. What is not here matters as much as what is: the engine holds by default.

⚠️ This is call interpretation, not financial advice. AlgoVault helps AI agents analyze — execution decisions are theirs.

🛰 Want this on your coins automatically? Set a standing scan: t.me/algovaultofficialbot
📊 See the full verified track record: algovault.com/track-record

How an AI agent analyzes BTC with AlgoVault MCP

AlgoVault.com — Wed, 16 Sep 2026 12:00:04 +0000

How an AI agent analyzes BTC with AlgoVault MCP

Here's a real-world workflow showing how agents use AlgoVault:

💡 Workflow #1: Quick BTC Check (Beginner)
"Get me a trade call for BTC on the 1h timeframe"

And here's what the live call returned just now:

Tool: get_trade_signal
Asset: BTC (Blue Chip)
Timeframe: 1h
Verdict: HOLD (35% confidence)

Regime is trending down on the moving-average cross → bearish. Funding at +0.0049% sits in BTC's normal 14-day band: no crowd pressure either way. Becomes actionable if the breakout resolves.

This is what "call interpretation" means — we don't tell agents what to trade. We give them the analysis so they can decide.

📖 20 workflows like this in our docs: algovault.com/docs
📊 Full verified track record: algovault.com/track-record

The DeepSeek Harness bundle: a declared profile layer, not a hand-written patch

AlgoVault.com — Wed, 16 Sep 2026 02:02:31 +0000

Intro

If you followed part one of this serial, you now have DeepSeek Harness talking to AlgoVault through a patch entry you hand-wrote into your profile. That entry works. It is also yours to maintain, forever, on every profile you ever spin up. Part three covered reading the track record; this middle installment is about what changes when a package ships that patch for you as a declared layer.

The proof point we keep circling back to: 91.1% PFE win rate · 704,125+ verified calls · Merkle-anchored on Base L2. That is what the harness is being pointed at. The bundle is only interesting insofar as it makes pointing it at that easier without asking readers to hand-edit YAML they will forget they own.

We provide the thesis. Agents decide execution. The bundle is the seam where that thesis becomes a declared piece of a DeepSeek Harness profile instead of a manual patch a reader carries.

What the bundle actually is

A DeepSeek Harness bundle is a plain npm package with one extra thing in its manifest: a top-level dsh key that declares a bundle.patch entry. When you install a package that declares that key, the harness reads the declaration on install and joins the referenced patch into the active profile's layer stack. When you install a package that does not declare it, the harness prints a one-time warning and treats the package as plain — nothing is added to the profile.

That is the whole mechanic. It is not an installer, it is not a plugin loader in the classical sense, and it is not a replacement for the MCP client. The MCP client is already a dependency of the dsh CLI itself, which means readers of the first installment never had a two-step install to begin with. What they had was a single command to bring the client in, and a hand-written patch entry to point that client at AlgoVault.

The bundle changes the second half of that. The client is unchanged. What moves is the patch entry — out of your profile file and into a declared layer that a package owns and versions.

One command

Here is the command executed against a scratch profile before this post was written. It is copied from the terminal, not paraphrased.

dsh bundle add @algovault/dsh-algovault
# adding bundle @algovault/dsh-algovault@0.2.1
# reconciling profile layers: base <- @algovault/dsh-algovault
# ok · one bundle joined · profile "default"

Verified against dsh@0.9.4 and @algovault/dsh-algovault@0.2.1 on 2026-08-29. Both surfaces are in developer preview, and both version pins matter — the harness is iterating, and the bundle tracks it. If either has moved by the time you read this, treat the pin as the record of what was true, not a promise of what still is.

The one command runs once per profile. It does not modify your profile file. It records the bundle as a joined layer in the harness's own state and reconciles the layer stack on every subsequent dsh invocation.

Declared layer vs hand-written patch: an implementation walkthrough

The first installment asked you to open your profile and paste a patch entry that pointed the MCP client at AlgoVault's endpoint, wired the auth envelope, and set the default coin and timeframe hints. That entry lived in your file. Every new profile got a copy-paste. Every upstream change to the endpoint shape meant editing every profile.

The bundle collapses that. Its package.json declares:

{
  "name": "@algovault/dsh-algovault",
  "version": "0.2.1",
  "dsh": {
    "bundle": {
      "patch": "./cordis.patch.yml",
      "skill": "./skill.md"
    }
  }
}

On install, the harness reads cordis.patch.yml from the package and joins it as a layer below your local overrides. Your profile file stays untouched. The layer is versioned with the package: dsh bundle upgrade bumps the pin and reconciles again, and anything you personally overrode on top continues to win. When the endpoint shape shifts — a new field in the auth envelope, a new default timeframe — the layer moves in the package release, not in your file.

For a reader who ran the earlier installment and now wants to adopt the bundle, the migration is: remove your hand-written entry from the profile, run the one command above, and re-run whatever probe you used at the end of the earlier installment. The response should be identical. If it is not, your hand-written entry was doing something the layer does not, and that delta is worth reading before you delete it.

The response the client returns, from the same probe:

{
  "content": [
    {
      "type": "text",
      "text": "{\n  \"call\": \"HOLD\",\n  \"confidence\": 37,\n  \"price\": 75450,\n  \"regime\": \"TRENDING_DOWN\",\n  \"reasoning\": \"Regime is trending down on the moving-average cross → bearish. Funding at +0.0042% sits in BTC's normal 14-day band: no crowd pressure either way. Becomes actionable if the breakout resolves.\",\n  \"timestamp\": 1789524015,\n  \"coin\": \"BTC\",\n  \"timeframe\": \"15m\",\n  \"_algovault\": {\n    \"version\": \"1.30.0\",\n    \"tool\": \"get_trade_call\",\n    \"exchange\": \"BINANCE\",\n    \"venue_status\": \"promoted\"\n  }\n}"
    }
  ]
}

Same call, same envelope, same _algovault metadata. The difference is not in the wire format. The difference is that the seam producing it is a declared thing a package owns.

What the skill does for tool selection

The bundle also ships a companion skill.md. A skill in the DeepSeek Harness model is a piece of guidance the agent reads when it is deciding which tool to reach for. The AlgoVault skill's job is narrow: when the agent is contemplating a market question, it points the agent at the composite verdict tool instead of at raw indicator surfaces.

The behaviour that produces, in practice, is this. An agent given a prompt like "how does BTC look right now" will, without the skill, often reach for whatever indicator tool it saw last — a funding-rate reader, an OI reader, a price fetcher — and try to compose a view out of the pieces. With the skill installed, the agent reaches for the verdict tool first and treats the composite output as the answer. The individual indicators still appear in the response envelope, so the agent can cite them, but they are cited as evidence for the composite rather than assembled into a bespoke one.

The upshot for an agent builder is that tool-selection variance drops. The reason it drops is not magic; it is that the skill file is a short prose document that names the situations in which the composite tool is the right reach, and the harness surfaces that document to the model at selection time. You can read it in the package, and you should — it is the honest description of what the skill will bias the agent toward.

import { runAgent } from "@deepseek-ai/dsh";

const result = await runAgent({
  profile: "default",
  prompt: "How does BTC look right now on the 15m?",
});

console.log(result.toolCalls.map((c) => c.name));
// with bundle installed: [ "get_trade_call" ]
// without bundle:        [ "get_funding_rate", "get_oi", "get_price" ]

That is the whole behavioural claim. Confirm it against your own runs before you rely on it.

Pitfalls and honest limits before you adopt

The harness itself, from its own README:

DeepSeek Harness is in developer preview and iterating rapidly. THERE WILL BE COMPATIBILITY-BREAKING CHANGES.

That sentence is not a footnote for us. The dsh.bundle schema is exactly the surface the harness is iterating on, and a bundle release that works against dsh@0.9.4 is not guaranteed to work against dsh@0.10. We pin both. When either moves, expect to re-run the migration and re-verify the probe.

Second pitfall: local overrides still win, which is usually what you want and occasionally not. If you left a stale hand-written patch entry in your profile after adopting the bundle, that entry will silently override the bundle's layer and you will think the bundle is doing something it is not. Delete the old entry before you install the bundle, and re-run the probe.

Third: listing state. At the time of writing, the bundle is published to npm under @algovault/dsh-algovault and is tagged with the dsh-plugin topic on the source repository. Whether it appears in the harness's plugin directory is a moving target the vendor controls, and we do not assert a listing we have not observed on the day you read this. If you are looking for it there and it is not present, install by name from npm and you are on the same layer stack either way.

Fourth: the skill biases tool selection, it does not lock it. An agent that has been strongly primed by an earlier turn will still reach for whatever it was reaching for. The skill is guidance, not a router. If tool selection matters to you at the level of a guarantee, the harness is not the layer to enforce it in.

What the data shows

The composite verdict the skill points agents toward is the tool whose track record we publish. 91.1% PFE win rate · 704,125+ verified calls · Merkle-anchored on Base L2. That is the surface being called through the bundle, and it is the surface the bundle exists to make easier to reach without the reader owning a patch file.

The response envelope carries a _receipts block that names the factors the verdict weighed and a track_record block that carries the aggregated PFE win rate and call count as of the response's timestamp. An agent that surfaces that block to an operator — as the skill nudges it to — gives the operator the composite conclusion and the receipts underneath it in the same turn. That is the shape of the integration.

The source tutorial for the bundle lives in the crypto-quant-signal-mcp docs and stays canonical for endpoint shape, envelope fields, and the auth flow the layer wires. Read it alongside this post if you are adopting for the first time; read it instead of this post if you are debugging a wire-level mismatch.

What's Next?

the track record — the aggregated PFE surface the bundle points agents at
the docs — endpoint shape, envelope fields, the free tier's per-day and per-month caps
the integration page — the AlgoVault-side write-up of the harness surface
the source tutorial — canonical for wire-level questions
the GitHub repo — the MCP server itself

— AlgoVault Labs

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

What an AI agent does with a verdict it did not compute

AlgoVault.com — Mon, 14 Sep 2026 02:02:38 +0000

Intro

An agent that computes its own view can always inspect its own reasoning. An agent that receives a verdict from an external tool cannot. That asymmetry is why the track record matters more for agents than for humans, and it is the one thing most integrations quietly leave unreachable.

This is part three of a short serial on the DeepSeek MCP Harness. Part one covered the connection and left off on a limitation: the harness bridges MCP tools only, and resources and prompts are not exposed. Part two covered the verdict bundle. Both are referenced here as covered separately.

The reason to write this third piece is small and specific. get_track_record closes the gap the first post opened on. An agent can now, in the same session that received a call, ask the server for the record of the thing advising it. That is the payoff the serial exists for.

The number that pays for the payoff, at draft time: 91.2% PFE win rate across 682,925+ verified calls, Merkle-anchored on Base L2.

The trust problem, framed honestly

A model that reasons its way to a call leaves a chain the operator can audit. A model handed a verdict from a tool call has, at best, the tool's own explanation string. The rest is opaque by construction — that is what "tool" means in MCP.

The healthy response to opacity is not to disparage the tool. It is to publish a record and let an agent read it. The architectural foil here is not a vendor; it is the pattern of shipping verdicts without a mechanism for the caller to verify them. A pattern of "trust me" is what a published record replaces.

For a human reader, a landing page is enough. For an agent, the record has to be reachable from inside the same session that consumed the verdict, or the agent is being asked to take the number on faith.

Why this was unreachable until recently

The DeepSeek Harness is explicit about its surface area. From the harness docs: it bridges MCP tools only — resources and prompts from the server are not exposed to the model. Confirm the wording live before publishing; the harness is in developer preview and its surface is still moving.

For most of this year, AlgoVault's published record lived behind an MCP resource. That is the right shape on paper — a record is a document, not an action. The practical consequence, though, was that anyone reaching the server through a tools-only bridge could receive a verdict and had no in-session way to ask what that verdict's provenance looked like. Part one closed on that exact gap.

get_track_record reshapes the record as a tool. It is not a philosophical change. It is the change the wire required.

Implementation walkthrough — the call and its shape

The tool is namespaced by the serverName chosen in the harness config from part one. Under the config there, the call name is mcp__algovault__get_track_record. Before writing about it, list tools and confirm it is present; if it is not, halt and re-check the server version rather than draft.

# List tools on the connected server via the harness's JSON-RPC surface
mcp-harness call tools/list --server algovault | jq '.tools[] | .name'

# Then invoke the record tool with an include filter.
mcp-harness call tools/call \
  --server algovault \
  --name get_track_record \
  --args '{"include":["aggregate","period","methodology"]}'

The accepted values for include are declared by the tool's own input schema — read them from tools/list rather than from any external document. The aggregate section is the win rate and the sample count; the period section is the evaluation window; the methodology section explains what a PFE win rate measures.

A companion call — the verdict itself, from part two — returns the envelope agents actually act on. Its _receipts.track_record block carries the same aggregate inline, which is what makes cross-checking cheap:

{
  "content": [
    {
      "type": "text",
      "text": "{\n  \"call\": \"HOLD\",\n  \"confidence\": 3,\n  \"price\": 77098.6,\n  \"regime\": \"TRENDING_DOWN\",\n  \"reasoning\": \"Regime is trending down on the moving-average cross → bearish. Funding sits in BTC's normal 14-day band: no crowd pressure either way.\",\n  \"_algovault\": {\n    \"version\": \"1.30.0\",\n    \"tool\": \"get_trade_call\",\n    \"exchange\": \"BINANCE\"\n  },\n  \"_receipts\": {\n    \"verdict\": \"HOLD\",\n    \"track_record\": {\n      \"pfe_win_rate\": 0.9117,\n      \"window\": \"2026-04-10..2026-09-14\"\n    },\n    \"verification_uri\": \"https://algovault.com/track-record\",\n    \"disclaimer\": \"Informational analytics, not investment advice. Past performance does not guarantee future results.\"\n  }\n}"
    }
  ]
}

The receipts block is deliberately duplicative with get_track_record. An agent that reads the receipt is anchored on the same aggregate the tool returns on demand. The two paths agree by construction.

Reading the answer honestly

This is the paragraph that earns whatever trust the post is trying to earn.

The public metric is a PFE win rate. PFE stands for peak favorable excursion. It measures, across the sample, the share of calls whose price moved in the direction of the call by a defined threshold within a defined window after publication. It is not a profit-and-loss result. It does not embed slippage, fees, position sizing, or a specific entry price. Anything that requires those inputs — realized return, Sharpe, drawdown — is downstream of the agent's own execution and not something the record claims to measure.

The evaluation window travels with the payload. At draft time, the window field in the receipts block reads 2026-04-10..2026-09-14; when you make the call yourself, read the field you actually receive rather than the one printed here. A record that quietly moves its start date is not a record.

HOLDs are not scored. The aggregate is computed over BUY and SELL calls only. That is a deliberate choice: a HOLD is an absence-of-direction, and scoring an absence produces numbers that flatter the tool without measuring anything. The bulk of a normal session, on a quiet regime, will be HOLDs — which is exactly why the aggregate is smaller than the total call count. Do not multiply the win rate by the call count and expect the product to mean anything.

Billing is a separate question from scoring. Every answered verdict is one metered call. The record does not offer a discount for HOLDs, and this post does not.

Finally: the aggregate is a record, not a forecast. A published win rate over hundreds of thousands of calls is evidence about a system's past behavior on the venues and timeframes it covered during that window. It is not a prediction that the next call will win. An agent that treats it as a prediction is doing the same thing a human does when they treat a backtest as a promise.

What an agent should actually do with it

The useful pattern is architectural, not advisory.

Check the record once per session, not per call. The aggregate does not move on a per-verdict cadence, and polling it on every tool call wastes quota. Read it on session start, cache the window and the rate, and re-read on the boundary conditions the agent already handles — a new day, a new run, an error path.

Treat the verdict as one input among the agent's own constraints. The agent presumably has a position sizing rule, a maximum exposure per asset, a regime filter of its own, and a stop discipline. A published win rate is a prior on the source, not a substitute for those constraints. If the agent would not have taken the trade on its own terms, the verdict's aggregate is not a reason to take it.

Size by confidence, not by verdict. The envelope carries a confidence field that is orthogonal to the aggregate. An aggregate says how often the source has been directionally right in the past. A confidence says how strongly this specific call is supported by the composite. Multiplying position size by confidence is the boring, correct move.

A minimal loop reads the record once, then the verdicts on a cadence the agent controls:

# AlgoVault MCP example — coins=BTC confidence_threshold=70

[BTC] {
  "call": "HOLD",
  "confidence": 12,
  "price": 77098.6,
  "indicators": {
    "funding_rate": 0.00009332,
    "funding_24h_avg": 0.00009332,
    "funding_state": "NORMAL",
    "oi_change_pct": 0.9,
    "oi_change_window": "24h",
    "vo…

# DRYRUN_MODE=1 — example complete

The example runs in dry-run mode so it can be re-executed without consuming quota during a draft. The shape is the point: one verdict pulled through the confidence threshold, all reasoning inspectable, the record already checked at session start.

Pitfalls and what the number is not

Three honest limits, because the record only earns anything if the limits are stated with it.

First, the aggregate is a system-wide number. It does not break out by asset, by venue, or by timeframe in the public surface. A short-timeframe BTC call and a longer-timeframe SOL call are both in the same denominator. That is a feature of a published aggregate — it resists cherry-picking — but it means an agent should not read a strong system aggregate as a strong claim for its specific slice.

Second, the record is retrospective and its window is anchored. A win rate published against a specific period is a claim about that period. New venues, new timeframes, and new assets enter the denominator as they ship. That inflates the sample but does not retroactively re-score old calls.

Third, the harness is in developer preview. Tools-only bridging is the current shape, resources may or may not become reachable, and the exact include values on get_track_record are declared by the server's schema rather than pinned by this post. Read the schema.

What's Next?

the track record — read it as the subject of this post, not an afterthought
the docs — the get_track_record tool, its include argument, and the receipts block spec
the integration page — the harness configuration that made this call reachable
the source tutorial — the tools-only limitation quoted in part one, and the connection steps this post builds on
the GitHub repo — the MCP server itself

— AlgoVault Labs

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

AlgoVault Weekly Trade-Call Report — Week of 2026-09-13

AlgoVault.com — Sun, 13 Sep 2026 12:00:05 +0000

AlgoVault Trade-Call Intelligence — Week of 2026-09-13

📊 676,804 trade calls tracked
🎯 PFE Win Rate: 91.2% across 2103+ assets (Hyperliquid)
🏆 Top performer: TEAM 3m — 100.0% PFE Win Rate (19 evaluated)
📈 Confidence band 50-54 hitting 91.7% accuracy

All calls are on-chain verified (Base L2 Merkle root).

📊 Live track record: algovault.com/track-record
🔌 Connect an agent: algovault.com/docs
🛰 Set a standing scan in Telegram: t.me/algovaultofficialbot

Built by AlgoVault Labs — call interpretation for AI trading agents.

This week's top crypto trade setups — 768 asset scans · 15 venues (Sep 2026)

AlgoVault.com — Fri, 11 Sep 2026 12:03:40 +0000

This week's top crypto trade setups — 768 asset scans · 15 venues (Sep 2026)

Live from AlgoVault's engine:

📡 This week I scanned 768 assets across 15 venues.

Top fresh setups:

🔴 BCH — SELL @ $225.06 · 80% conviction · TRENDING_DOWN
📊 trend persistence HIGH · funding normal · breakout imminent
💡 Regime is trending down on the moving-average cross → bearish

🔴 SUI — SELL @ $0.7195 · 78% conviction · TRENDING_DOWN
📊 trend persistence HIGH · funding normal · breakout imminent
💡 Regime is trending down on the moving-average cross → bearish

🔴 SEI — SELL @ $0.044 · 78% conviction · TRENDING_DOWN
📊 trend persistence MEDIUM · funding normal · breakout imminent
💡 Regime is trending down on the moving-average cross → bearish

🔴 ASTER — SELL @ $0.6828 · 69% conviction · TRENDING_DOWN
📊 trend persistence MEDIUM · funding normal · breakout imminent
💡 Regime is trending down on the moving-average cross → bearish

🔴 AVAX — SELL @ $7.37 · 66% conviction · TRENDING_DOWN
📊 trend persistence HIGH · funding normal · OI -5.3% (24h)
💡 Regime is trending down on the moving-average cross → bearish

⚠️ This is call interpretation, not financial advice. AlgoVault helps AI agents analyze — execution decisions are theirs.

🛰 Want this on your coins automatically? Set a standing scan: t.me/algovaultofficialbot
📊 See the full verified track record: algovault.com/track-record

AlgoVault MCP v1.30.0 — What's New

AlgoVault.com — Thu, 10 Sep 2026 07:36:19 +0000

AlgoVault MCP v1.30.0 is live

What's new:

Added: claim_url and claim_hint in the _algovault envelope of every tool response that carries an auth block — a direct link to keep the key in use, and a heads-up before the cap. Tools with no auth block carry neither.
Added: price_usd_6month on every tier of GET /api/plans/public, so six-month prepay pricing no longer has to be hardcoded by a client.
Added: Two routes: a one-click email unsubscribe endpoint and a signature-verified delivery webhook. Plumbing for the email lifecycle; no message is sent by this release.
Changed: GET /api/plans/public now returns null for the Enterprise price and call limits instead of a published figure. Enterprise is quoted directly. No key was removed.
Changed: The webhook documentation no longer publishes per-tier call quotas that were retired in August, and no longer tells you to recreate a subscription after an automatic disable — the subscription re-enables itself.
Changed: The site carries a sign-up control in the header at mobile widths and a conversion band above the footer; the home page's in-page links and copy button now work below the desktop breakpoint.
Fixed: Two upgrade claims on the welcome page that were not true have been removed — one about asset coverage, one about alert limits.

Now tracking 2058+ assets with 91.4% PFE Win Rate across 635,806 evaluated calls.

Upgrade now — remote agents get the new version automatically:

Remote MCP   https://api.algovault.com/mcp
npm          npx -y crypto-quant-signal-mcp@1.30.0

📖 Docs: algovault.com/docs
📊 Track record: algovault.com/track-record

Built by AlgoVault Labs — call interpretation for AI trading agents.

How an AI agent analyzes BTC with AlgoVault MCP

AlgoVault.com — Wed, 09 Sep 2026 12:00:04 +0000

How an AI agent analyzes BTC with AlgoVault MCP

Here's a real-world workflow showing how agents use AlgoVault:

💡 Workflow #1: Quick BTC Check (Beginner)
"Get me a trade call for BTC on the 1h timeframe"

And here's what the live call returned just now:

Tool: get_trade_signal
Asset: BTC (Blue Chip)
Timeframe: 1h
Verdict: HOLD (26% confidence)

Price is up over 24h, the momentum term behind the call → bullish. Funding at +0.0061% sits in BTC's normal 14-day band: no crowd pressure either way. Turns directional if funding moves off neutral.

This is what "call interpretation" means — we don't tell agents what to trade. We give them the analysis so they can decide.

📖 20 workflows like this in our docs: algovault.com/docs
📊 Full verified track record: algovault.com/track-record

Connecting an MCP server to DeepSeek Harness: the config file that silently does nothing

AlgoVault.com — Tue, 08 Sep 2026 02:02:04 +0000

Intro

If you run DeepSeek Harness (dsh) and your agent is deriving a market view from raw indicators every loop, you are paying inference tokens to reinvent a wheel that already exists. AlgoVault publishes one composite verdict per call, with a live track record you can audit: 91.5% PFE win rate · 622,857+ verified calls · Merkle-anchored on Base L2. We provide the thesis; your agent decides execution.

This post is part one of three. It owns the connection: what you already have, the one file that turns the bridge on, and one real call against the live server. Reading the track record from inside the harness, and the one-command bundle, are covered separately.

What you already have

There is no install step to describe here, and this catches almost every reader out. The dsh CLI ships @deepseek-ai/dsh-mcp-client as a direct dependency of the CLI package itself. The vendor's own CLI reference says it plainly: the CLI ships the client "as a dependency for patch layers, but no MCP server is enabled by default." The vendor's MCP guide goes straight to a patch entry when you bring another server — it never asks you to run plugin add.

So the bridge is already sitting inside your install. What is missing is a patch entry that names AlgoVault and points at the endpoint. That single file is the whole job of this post.

If you have wired up an OpenAPI plugin or a REST tool for dsh before, unlearn the muscle memory. This is not that flow. There is no manifest to fetch, no schema to register, no add to run.

The config file that silently does nothing

Patch entries live in a user patch layer. The documented location is $DSH_HOME/profiles/<name>/cordis.patch.yml when you want the server scoped to one profile, or $DSH_HOME/cordis.patch.yml when you want it on every profile on the machine. $DSH_HOME defaults to ~/.dsh. Both paths are the vendor's own; neither is guessed.

Here is the trap, and it is the reason this post exists.

The @deepseek-ai/dsh-mcp-client package README shows a "Minimal configuration" example. It is a bare entry list — the shape a raw composition file expects. Copy that shape straight into your patch layer and it reads as an id-targeted override with no target. The harness will not error. It will warn once, mount nothing, and start anyway. Your agent has all the tools it had yesterday, and none of the ones you thought you added.

A patch layer needs the same entries wrapped in an - insert: block, exactly the way the harness's shipped overlay examples do. This is the correct shape:

- insert:
    mcp:
      servers:
        algovault:
          transport: streamable-http
          endpoint: https://api.algovault.com/mcp?src=deepseek_harness
          headers: {}

Compare that to the shape the package README shows verbatim, which is the shape that quietly does nothing when pasted into a patch file:

mcp:
  servers:
    algovault:
      transport: streamable-http
      endpoint: https://api.algovault.com/mcp?src=deepseek_harness

The only difference between the two blocks is the - insert: wrapper and the indent shift it forces. That is the entire delta between an agent that has AlgoVault tools on its next turn and an agent that does not. The ?src=deepseek_harness query string on the endpoint is the registered attribution slug for this surface — leave it as-is.

The vendor's own warning is worth carrying too: do not overwrite an existing cordis.patch.yml. It may already hold unrelated user patches from a previous session or a different plugin. Append the - insert: block; do not replace the file.

Implementation walkthrough: first call

Once the patch file is on disk with the correct shape, restart dsh and the harness will mount the server on next boot. The tools appear to the model under the harness's namespacing convention, mcp__<serverName>__<tool>. With serverName: algovault, the live set is:

the composite verdict — mcp__algovault__get_trade_call
the universe scan — mcp__algovault__scan_trade_calls
the regime read — mcp__algovault__get_market_regime
the funding spread — mcp__algovault__scan_funding_arb

Confirm the exact list at your draft time by asking the harness for tools/list; the surface is under active development and names are the source of truth from the server, not from any doc.

The argument name on the composite verdict is coin, not symbol. Read the input schema off the tool itself before wiring it into an agent loop. Here is one real call, and the response that came back verbatim:

{
  "call": "HOLD",
  "confidence": 21,
  "price": 79409,
  "regime": "RANGING",
  "reasoning": "Price is down over 24h, the momentum term behind the call → bearish. Against: regime is ranging with the moving averages inside the noise band → bullish. Turns directional if funding moves off neutral.",
  "coin": "BTC",
  "timeframe": "15m",
  "_algovault": {
    "version": "1.29.0",
    "tool": "get_trade_call",
    "exchange": "BINANCE",
    "quota": {
      "used": 21,
      "total": 200,
      "remaining": 179,
      "daily": { "used": 3, "total": 100, "remaining": 97 },
      "binding": "monthly"
    },
    "auth": { "tier": "free" }
  }
}

Note two things in the response envelope. The _algovault.quota object shows the free tier's real shape — 200 calls/month with a 100 calls/day sub-cap, and the daily cap is the one an agent loop hits first, so budget against it rather than the monthly figure. The auth.tier: "free" confirms no key was presented and none was needed. When you upgrade, the key goes into the headers map on the patch entry, not into a separate config file.

Wiring that call into an agent loop, from inside the harness, looks like this:

# AlgoVault MCP example — coins=BTC confidence_threshold=70

[BTC] {
  "call": "HOLD",
  "confidence": 35,
  "price": 79409,
  "indicators": {
    "funding_rate": 0.00007409,
    "funding_state": "NORMAL",
    "oi_change_window": "24h"
  }
}

# DRYRUN_MODE=1 — example complete

The pattern is: request the verdict at the start of a turn, gate on confidence against your own threshold, and let the harness route the rest of the turn. The reasoning string is short by design — it is meant to be read by a model, not by a human dashboard.

Pitfalls and what this does not do

The - insert: trap is the pitfall that costs an hour. There are two more worth naming up front.

First, the harness bridges MCP tools. The vendor is explicit: the client "surfaces MCP tools to the harness; resources and prompts are not supported." That means anything AlgoVault models as an MCP resource — the published track record ledger is the obvious one — is not reachable from inside dsh today. You can still fetch it out-of-band from the same agent turn, but it will not appear in the harness's own resource picker. Part three of this series is about exactly that gap.

Second, the free tier's daily sub-cap is real. A tight polling loop on a short-timeframe cadence will burn through the daily allowance faster than an operator expects. The quota.daily.remaining field in every response envelope is the number to watch; wire it into whatever your agent uses for backoff. The monthly total is a ceiling, not a rate limit.

Third, do not paraphrase the tools-only limitation to your users. Quote it. "Resources and prompts are not supported" is a specific claim with a specific meaning, and softening it to "some features may not be available" costs debugging time later.

Performance and what the response tells you

The response envelope carries more than a verdict. The _algovault block exposes the version, the tool name, the venue that produced the read, and the quota state. In _receipts (elided above for brevity), each response also ships a factor ledger — every input the composite verdict considered, its direction, and whether it contributed to the final call — plus a stripped-remainder count naming how many withheld terms were behind the answer.

That receipt shape is what makes the track record auditable. The published number cited at the top of this post — 91.5% PFE win rate across the full call log — is Merkle-anchored on Base L2, and every call carries a verification_uri back to the public ledger. See the full receipts and the underlying methodology in the AlgoVault docs and the live track record.

For an agent, the practical performance win is not the raw win rate. It is that one tool call replaces the ten-to-twenty indicator fetches and the derivation chain the agent used to run every turn. Fewer tokens, shorter turns, one verdict the receipts can defend.

What's Next?

the track record — the live PFE ledger and the Merkle roots behind it
the docs — quick-start, tool schemas, and the receipts model
the DeepSeek Harness integration page — the tutorial the pre-flight in this post points at
the source tutorial — the canonical integration reference in the GitHub repo

Part two covers the one-command bundle that installs the patch entry without hand-editing YAML. Part three covers reading the Merkle-anchored track record from inside the same agent loop.

— AlgoVault Labs

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

AlgoVault Weekly Trade-Call Report — Week of 2026-09-06

AlgoVault.com — Sun, 06 Sep 2026 12:00:05 +0000

AlgoVault Trade-Call Intelligence — Week of 2026-09-06

📊 606,828 trade calls tracked
🎯 PFE Win Rate: 91.6% across 1986+ assets (Hyperliquid)
🏆 Top performer: HK1810 3m — 100.0% PFE Win Rate (9 evaluated)
📈 Confidence band 50-54 hitting 91.8% accuracy

All calls are on-chain verified (Base L2 Merkle root).

📊 Live track record: algovault.com/track-record
🔌 Connect an agent: algovault.com/docs
🛰 Set a standing scan in Telegram: t.me/algovaultofficialbot

Built by AlgoVault Labs — call interpretation for AI trading agents.