Point your agent at your own trading platform

Research → Test → Watch → Act

The whole loop, in one conversation. Each tool below is a real tool the server serves; the grouping is how a session actually moves through them.

Watch also answers as 2 resources — vike://node/snapshot and vike://backtest/last — which route into the same implementations the tools use rather than being a second source. That is why a withheld tool cannot be reached through a URI instead.

You are always in control

An agent that can place orders is only as safe as what stands between its intent and the wire. Here is everything that does — stated as mechanism, because a promise is not a control.

A real session, end to end

Captured from the end-to-end harness that builds the real binaries and drives the real CLI, a real MCP client and a real paper node in one process tree. Nothing below is retyped, reordered or tidied — including the parts that are less flattering.

The agent, over MCP

Follow the three write calls: the first returns will_execute: false with a token, the second quotes that token and is accepted, and the identical confirmation replayed afterwards is refused — a token fires once.

# Vike Trader over MCP — a real stdio session, captured verbatim.
#
# Captured by scripts/cli_mcp_smoke.sh (the CLI+MCP end-to-end smoke) on Linux, from binaries built
# out of this repository. The server is `vike-cli mcp --node <host:port>`, speaking newline-delimited
# JSON-RPC 2.0 over stdin/stdout, pointed at a real vike-tradehub node running in the same throwaway
# project directory. That project holds no venue credentials, so the node's mount is PAPER and the
# order placed below rests in a paper book. No venue is contacted at any point. The symbol the order
# names, CLI_MCP_SMOKE_TOKEN, is that throwaway mount's own token id — it resolves against nothing.
#
# FRAMING. `client →` is the exact line that was written to the server's stdin, as sent. `server ←`
# is that request's response, shown formatted with `jq`; where a `jq` FILTER was applied it is
# NAMED on the line, and the filter is the only reason a response is ever not shown whole. No field
# is added, removed or altered. The one thing routinely not repeated is `result.content[0].text`,
# which on a successful tool call is `result.structuredContent` rendered for a human to read.
#
# Nothing here is retyped or paraphrased. Every id, every preview token and the client order id are
# the real ones this session produced. Absolute paths of the throwaway directory are shown as
# <project>; ANSI is stripped. Lines beginning with `#` are this header and nothing else.

──── 1. handshake

The client opens the server over stdio and declares the protocol version it speaks.

client → {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"vike-transcript","version":"1"}}}
server ← the whole response, formatted with `jq .`
{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "capabilities": {
      "prompts": {},
      "resources": {},
      "tools": {}
    },
    "protocolVersion": "2024-11-05",
    "serverInfo": {
      "name": "vike-cli",
      "version": "0.1.0"
    }
  }
}


──── 2. what this server serves

One request. Two views of its one response: the tool names, then in full the entry for the
tool the rest of this session uses. The response as received carries every tool's JSON Schema,
which is why the first view is a filter rather than the whole thing.

client → {"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}
server ← 17 tools — `jq '[.result.tools[].name]'`
[
  "validate_strategy",
  "discover_params",
  "list_templates",
  "list_indicators",
  "run_backtest",
  "run_sweep",
  "run_walk_forward",
  "list_strategies",
  "list_series",
  "node_snapshot",
  "submit_order",
  "cancel_order",
  "modify",
  "flatten",
  "market_exit",
  "mass_cancel",
  "set_trading_state"
]

server ← `jq '.result.tools[] | select(.name == "submit_order")'`
{
  "annotations": {
    "destructiveHint": true,
    "idempotentHint": false,
    "openWorldHint": true
  },
  "description": "Submit an order on the vike-tradehub node. WITHOUT confirm:true this only PREVIEWS (executes nothing). Requires --node + VIKE_TRADEHUB_CONTROL_KEY.",
  "inputSchema": {
    "properties": {
      "confirm": {
        "description": "must be true AND accompanied by a valid `preview_token` to execute; either one missing returns a preview instead",
        "type": "boolean"
      },
      "order_type": {
        "description": "market | limit | stop | take_profit (default market)",
        "type": "string"
      },
      "preview_token": {
        "description": "the `preview_token` returned by this tool's preview call. Fires ONCE, expires after 60s, and is BOUND to the exact command it previewed — confirming a different command with it is refused.",
        "type": "string"
      },
      "price": {
        "type": "number"
      },
      "qty": {
        "type": "number"
      },
      "reason": {
        "description": "optional rationale — WHY this command is being issued. Recorded in the node's audit trail (control characters stripped, capped at 512 chars); never reaches the order, the core, or the venue.",
        "type": "string"
      },
      "reduce_only": {
        "type": "boolean"
      },
      "side": {
        "description": "1 buy / -1 sell",
        "type": "integer"
      },
      "symbol": {
        "type": "string"
      },
      "trigger_price": {
        "type": "number"
      },
      "venue": {
        "type": "string"
      }
    },
    "required": [
      "venue",
      "symbol",
      "side",
      "qty"
    ],
    "type": "object"
  },
  "name": "submit_order"
}


──── 3. a READ tool

`node_snapshot` asks the live node what it currently holds. Reads need no confirmation:
nothing changes, so there is nothing to gate.

client → {"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"node_snapshot","arguments":{}}}
server ← `jq '.result.structuredContent'` (isError: false)
{
  "balance": 0.0,
  "bars": [],
  "equity_total": 0.0,
  "fault": null,
  "held_exits": [],
  "identity": {
    "build": "git f7e6f2f9 dirty, built 2026-09-06T08:57:10Z, rustc 1.97.1 (8bab26f4f 2026-07-14), x86_64-unknown-linux-gnu",
    "live": false,
    "name": "tradehub",
    "params": "qty=20 tick_size=0.01 min_half_spread_ticks=0 max_half_spread_ticks=0 round_trip_fee_rate=None kappa_default=50 tau_hold_ms=3600000 price_domain=UnitInterval variance_mode=LocalCapped horizon_mode=TimeToResolution spread_model=AvellanedaStoikov gamma=0.1 resolution_ts=None",
    "strategy": "spread_maker"
  },
  "orders": [],
  "positions": [],
  "recent_events": [],
  "seq": 0,
  "symbol": "CLI_MCP_SMOKE_TOKEN",
  "trading_state": "Active",
  "venue": "polymarket",
  "venues": []
}


──── 4. a WRITE tool, first call — THE MANDATORY PREVIEW

The same request an agent would make to place an order. It carries no `confirm`, and the
server does not execute it. Read three fields: `will_execute` is false, `node_verdict` is the
NODE's own dry-run against the real limits, and `preview_token` is the single-use token the second
call must quote back. `wire_command.Submit.client_order_id` was minted HERE — it is the id that
will be sent, so it is known before anything is.

client → {"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"submit_order","arguments":{"venue":"polymarket","symbol":"CLI_MCP_SMOKE_TOKEN","side":1,"qty":12,"order_type":"limit","price":0.42,"reason":"transcript capture: the two-call preview gate"}}}
server ← `jq '.result | {isError, structuredContent}'`
{
  "isError": false,
  "structuredContent": {
    "guardrail": {
      "max_notional": null,
      "max_qty": null,
      "notional": 5.04,
      "qty": 12.0,
      "within_limits": true
    },
    "node_verdict": {
      "accepted": true,
      "checked_by": "node",
      "reason": null
    },
    "note": "PREVIEW ONLY — nothing was sent. `node_verdict` is the NODE's own dry-run against the real ControlLimits + RiskGate; it is the verdict that counts. To execute, call again with BOTH \"confirm\": true AND this exact \"preview_token\". The token fires once, expires after 60s, and is bound to THIS command — confirming a different command with it is refused. For submit_order, `wire_command.Submit.client_order_id` was minted here and is the id that will be sent. Any `reason` is recorded in the node's audit trail (sanitized) and never reaches the order.",
    "preview_token": "pv-1",
    "reason": "transcript capture: the two-call preview gate",
    "tool": "submit_order",
    "verified_by_node": true,
    "will_execute": false,
    "wire_command": {
      "Submit": {
        "client_order_id": "95106ad40",
        "order_type": "limit",
        "price": 0.42,
        "qty": 12.0,
        "reduce_only": false,
        "side": 1,
        "symbol": "CLI_MCP_SMOKE_TOKEN",
        "trigger_price": null,
        "venue": "polymarket"
      }
    }
  }
}


──── 5. the WRITE tool, second call — CONFIRMED

The same arguments again, plus `confirm: true` and that exact token. Only now is anything
sent. The answer is the node's: `sent: true`, `outcome: accepted`, and the client order id is the
one the preview already showed.

client → {"jsonrpc":"2.0","id":5,"method":"tools/call","params":{"name":"submit_order","arguments":{"venue":"polymarket","symbol":"CLI_MCP_SMOKE_TOKEN","side":1,"qty":12,"order_type":"limit","price":0.42,"reason":"transcript capture: the two-call preview gate","confirm":true,"preview_token":"pv-1"}}}
server ← `jq '.result | {isError, structuredContent}'`
{
  "isError": false,
  "structuredContent": {
    "client_order_id": "95106ad40",
    "note": "the node ACCEPTED this command (empty client_order_id = an account-wide verb); call node_snapshot to observe the result. The node's server-side ControlLimits + RiskGate are the enforcing gate.",
    "outcome": "accepted",
    "sent": true
  }
}


──── 6. the order is at the node

The same read tool as step 3, against the same node. The node folds a command and republishes
on its own thread, so the client POLLS this tool until the order appears rather than sleeping — the
request below is the poll that answered, and its `id` is therefore how many polls it took.

client → {"jsonrpc":"2.0","id":6,"method":"tools/call","params":{"name":"node_snapshot","arguments":{}}}
server ← `jq '.result.structuredContent.orders'`
[
  {
    "avg_fill_px": 0.0,
    "client_order_id": "95106ad40",
    "filled_qty": 0.0,
    "order_type": "limit",
    "price": 0.42,
    "qty": 12.0,
    "side": 1,
    "status": "Accepted",
    "symbol": "CLI_MCP_SMOKE_TOKEN",
    "trigger_price": null,
    "venue": "polymarket",
    "venue_order_id": "95106ad40"
  }
]


──── 7. the token has already fired

The confirming call again, byte for byte. A preview token is single-use: it is removed before
the command executes, so a duplicated or replayed confirmation cannot place a second order.

client → {"jsonrpc":"2.0","id":7,"method":"tools/call","params":{"name":"submit_order","arguments":{"venue":"polymarket","symbol":"CLI_MCP_SMOKE_TOKEN","side":1,"qty":12,"order_type":"limit","price":0.42,"reason":"transcript capture: the two-call preview gate","confirm":true,"preview_token":"pv-1"}}}
server ← isError: true, and `.result.content[0].text` reads:

preview_token "pv-1" is unknown or already used — a token fires at most once. Call this tool WITHOUT `confirm` to get a fresh preview, then confirm with the `preview_token` it returns.

The same engine, from the command line

# vike-cli — a real terminal session, captured verbatim.
#
# Captured by scripts/cli_mcp_smoke.sh (the CLI+MCP end-to-end smoke) on Linux, from binaries built
# out of this repository. It runs inside a throwaway project directory holding no venue credentials
# at all, so every venue is PAPER and no venue is contacted: absent credentials ARE the live gate.
#
# Nothing below is retyped, reordered or paraphrased. The only rewriting: the throwaway directory's
# absolute path is shown as <project>, and ANSI colour codes are stripped (the site renders this as
# a code block). Lines beginning with `#` are the capture harness annotating — a shell prints no
# such line — and carry each command's exit code and wall-clock time. Everything else is the
# binary's own output, stdout and stderr merged the way a terminal merges them.

$ vike-cli --version
vike-cli 0.1.0 (git f7e6f2f9 dirty, built 2026-09-06T08:57:10Z, rustc 1.97.1 (8bab26f4f 2026-07-14), x86_64-unknown-linux-gnu)
# exit 0 — 0.010s

$ vike-cli --help
vike-cli — the unified vike command-line surface

usage: vike-cli <command> [args…]

commands:
  backtest     run a backtest on a remote vike-datahub server and print the report
  sweep        run a parameter-grid search on a remote vike-datahub server and print the ranked grid
  walkforward  run an anchored walk-forward validation on a remote vike-datahub server
  data         get market data into the hist store: fetch real bars, or seed the demo tape
  config       settings provenance (`show`) and a validating pre-flight (`check`) for this box
  mcp          serve the create+backtest tools over stdio MCP (for Claude / an agent)
  trade        interactive REPL to observe + control a running vike-tradehub node (for a human)
  strategy-status ask a running vike-tradehub node what it is running (read-only; --json for machines)
  secrets      inspect the credential store <project>/settings/secrets.env, and set ONE key in it (list | path | template | set)
  init         create <project>/user_data — strategies, profiles, results — with examples
  indicators   print the indicators a Rhai strategy can call, with their parameters

run `vike-cli <command> --help` for a command's own options
run `vike-cli --version` to print this build's version
# exit 0 — 0.009s

$ vike-cli data seed-demo --store <project>/data/demo
2026-09-06T08:57:30.000626Z  INFO vike_backtest::binutil: hist store root resolved: stated for this run (--store / store = / store_root) store=<project>/data/demo rung="explicit"
seeded SYNTHETIC demo bars (venue `demo` — a closed-form curve, NOT market data) into <project>/data/demo
  demo/BTCUSDT 1h  4344 bars
  demo/BTCUSDT 1m  10080 bars
# exit 0 — 2.664s

$ vike-cli backtest --local --profile user_data/profiles/backtest.toml --script user_data/strategies/rhai/sma_cross/sma_cross.rhai --store <project>/data/demo
2026-09-06T08:57:32.680918Z  INFO vike_backtest::binutil: hist store root resolved: stated for this run (--store / store = / store_root) store=<project>/data/demo rung="explicit"
name:          sma_cross — demo BTCUSDT 1h
final_equity:  40757.94
total_return:  307.5794%
n_trades:      155
win_rate:      32.9032%
sharpe:        3.3616
max_drawdown:  36.5717%
per_symbol_pnl:
  BTCUSDT: 50240.95
backtest: run saved to <project>/user_data/runs/1788685052-2741260-0
# exit 0 — 2.695s

What this session is and is not:

• The bars are the shipped SYNTHETIC demo tape, not market data — the engine says so inside the transcript, and that line was deliberately left in. Read the equity and Sharpe figures as a demonstration that the pipeline runs end to end, never as a result.
• The order is PAPER. `outcome: accepted` is the node accepting it, not a venue filling it — visible as `identity.live: false` earlier in the same session.
• `CLI_MCP_SMOKE_TOKEN` is the throwaway mount's own token id. It is real rather than prettified, which is the point.

Three ways in — and the local one leads

Local is not the fallback here; it is the design. The server runs beside your platform, on your hardware, and talks only to services you are already running.

The command line, verb by verb

Everything an agent can do, a human or a script can do the same way.

• vike-cli backtest — run a backtest on a remote data service and print the report
• vike-cli sweep — run a parameter-grid search and print the ranked grid
• vike-cli walkforward — run an anchored walk-forward validation
• vike-cli data — get market data into the store: fetch real bars, or seed the demo tape
• vike-cli config — settings provenance, and a validating pre-flight for this box
• vike-cli mcp — serve the tools over stdio MCP, for an agent
• vike-cli trade — interactive REPL to observe and control a running node, for a human
• vike-cli strategy-status — ask a running node what it is running — read-only
• vike-cli secrets — inspect the credential store, and set one key in it
• vike-cli init — create the project's strategies, profiles and results directory
• vike-cli indicators — print the indicators a strategy can call, with their parameters

Why 17 tools, and not eighty

An agent choosing among dozens of thin, near-identical endpoints chooses wrong, and it does so confidently. Fewer tools that each answer a whole question is not a smaller surface — it is the same surface, arranged so the choice is obvious.

Connect your client

Each one is a single entry in that client's own config. The setup pages carry the exact block, and the trap specific to that client.

Full reference: the agent surface documentation · the server and its flags · every command-line verb · every supported client.