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

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