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