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