kdraigo_mcp

Model Context Protocol server for the kdraigo algorithmic trading platform. Drop one binary into your mcpServers config and Claude Code (or any MCP client) can scaffold strategies, run backtests, fetch analytics, and iterate end-to-end against the kdraigo backend.

Two ways to use it:

• Hosted at https://mcp.kdraigo.com/mcp: add that URL to claude.ai, ChatGPT, Gemini CLI or Claude Code as a remote MCP server, sign in on kdraigo.com (Google or wallet), and nothing runs on your machine. See Hosted server.

• Local, over stdio: the binary is launched as a subprocess by your MCP client. No hosting, no port, no public surface. It signs each outbound request to kdraigo.com with your Ed25519 key.

Install

go install github.com/kdraigo/kdraigo_mcp/cmd/kdraigo-mcp@latest

go install reports the installed release tag automatically. From a clone, use make install (or make build) to stamp the version from your local git tag.

Verify (prints the release tag):

kdraigo-mcp version

Related MCP server: tradingrearchagents

Configure

You need an Ed25519 API key: create one on kdraigo.com under Account → API keys (kdraigo.com/account/api-keys). It gives a key_id (UUID) and a hex-encoded private_key, shown once.

Create ~/.kdraigo/config.yaml:

auth:
  key_id: "00000000-0000-0000-0000-000000000000"
  private_key: "<128-hex-char-ed25519-private-key>"
endpoint: "https://kdraigo.com"   # optional; this is the default

Override the config path with KDRAIGO_CONFIG if you need a non-default location.

Wire into Claude Code

claude mcp add --scope user kdraigo -- kdraigo-mcp

Other MCP clients (or a project's .mcp.json) take the usual entry:

{
  "mcpServers": {
    "kdraigo": {
      "command": "kdraigo-mcp"
    }
  }
}

Restart the client. The tools below appear under the kdraigo server: 78 by default, 80 with the replay switch.

The two replay tools, create_backtest_session and run_backtest_stream, are off unless the server runs with KDRAIGO_MCP_ENABLE_REPLAY=1. They step candles through a session without running any strategy code, so they are not how a strategy is backtested. A strategy runs as its own program through dev_sdk: locally with go run ., or in the cloud workspace with workspace_run. A replay left parked also holds one of the account's session slots for up to an hour.

Install the skills

kdraigo-mcp install-skill                    # ~/.claude/skills/<name>/SKILL.md
kdraigo-mcp install-skill --project <dir>    # <dir>/.claude/skills/<name>/SKILL.md

The skills are built into the binary, so they always match its tools. Restart Claude Code to load them. Releases before v1.1.0 wrote flat ~/.claude/skills/<name>.md files that Claude Code never loaded; the installer names any it finds so you can delete them.

• kdraigo-strategy — open the research lab → write the hypothesis → check what was already done → run (go run . or the cloud workspace) → report → drill down → record → hand off, how to judge a result, and the pitfalls.

• kdraigo-indicators — choose the right technical indicator by intent and wire it via the SDK.

Tools

Results come back as a few header lines and tab-separated tables, with no JSON, so a page of rows fits the client's tool-output limit. A result stops at about 60 KB and its last line says how to get the rest (offset, or save_to for orders).

Cloud workspace

The workspace_* tools write, build and run a strategy on the platform: no local Go, checkout or keys. The workspace service compiles it offline on a sandbox machine (the caller's own on pro and admin accounts, shared with other users' runs, each in its own container, on verified ones), then runs it with a key minted for that run alone, which can only open backtest sessions and is revoked when the run ends. Under gVisor the program can reach nothing but the platform API. get_sdk_docs section="cloud workspace" has the rules (flat .go files, allowed imports, env, limits). It is in beta for admin accounts first.

Research labs

A lab is one line of research (a futures trend strategy, a spot accumulation idea) kept apart from the others: a brief, notes in Markdown with [[links]], experiments that go draft → registered (frozen and hashed) → a verdict, the runs of its workspaces, and handoffs between sessions. research_service keeps it; the website's Lab shows it.

Runs of a workspace in a lab are recorded by the platform as they end: the code's hash, the declared values, exchange, pairs, timeframe and window. That is what lab_check matches for an exact repeat, since the engine is deterministic. The run's figures are read from its first session the next time lab_open or lab_runs lists it, and kept with the run. Local go run . runs are not recorded; name their sessions in the experiment's verdict.

Syndicates and the library

A syndicate is a group that shares labs: in every lab tool a shared lab is named syndicate:lab, members and their AIs write it, viewers read it. Runs of a member's workspace in a shared lab are recorded there as theirs, and lab_check finds a repeat across every lab the user can read.

The library holds frozen snapshots of decided experiments: hypothesis, protocol and verdict, the notes chosen, one result card per cited run, and optionally the code a run ran (refused unless it hashes to what the run ran). The platform reads each card's figures from the engine's record and signs them; the key is public (kdraigo.com/research/api/v1/public/card-key). A snapshot can be a draft, go to a syndicate, or (from the website, by a Verified or Pro account, citing only the author's own runs) go to everyone.

What other people wrote reaches the AI marked as data, never instructions. Anything that changes who sees what (invites, roles, sharing a whole lab, publishing to everyone) is the user's own click on the website, so a note written to steer an agent can't make it leak research.

Boards

A board is the user's arrangement of widgets on the website (kdraigo.com/boards): price charts with lines and panes (volume, and the collected market data: delta, CVD, large trades, buy and sell volume, and on perpetuals funding, open interest, long/short and liquidations) and optionally a backtest's trades, the live order book, a watchlist, trade flow, positioning, open interest and liquidations widgets, session stats, equity curves, a P&L calendar, a research lab at a glance, notes. A widget is data the website draws, never code: {type, title, params, at}, checked on every write against the catalog (widget_types). A refusal names the field (widgets[1] (w2).params.exchange: "binance_futures" is not one of binance, bybit); fix it and call again. The widget tools apply to the newest version of the board, and a board open on the website updates within seconds. Moving a board into a syndicate is the user's click on the website.

Chart scripts

A chart script is an indicator the AI writes in kdscript, kdraigo's own language in the shape of Pine Script v6 (script_reference is the whole guide; what it leaves out is listed there). The guide is also public, as plain Markdown, at kdraigo.com/kdscript.md and on the docs: an AI without the MCP can read it there. A price_chart widget draws scripts: params.scripts: [{"script": "my-rsi", "inputs": {"len": 21}}], by slug in the board's space (a syndicate's board draws the syndicate's scripts; sharing a board copies the scripts it draws). The data includes what TradingView doesn't give scripts: taker-buy volume, trade count, quote volume and funding.

kdscript 1.1 adds higher timeframes (request.security on the chart's pair, closed bars only), colours that change per bar, bgcolor, barcolor, plotchar, switch, string inputs with options and arrays. Every save is kept as a version (the newest 50), and the script library holds scripts people shared, to read and fork. kdscript 1.2 adds ta.linreg, ta.correlation and ta.percentrank, and plot.style_linebr lines stop at na bars. kdscript 1.3 adds alertcondition(cond, title, message): armed with alert_create, the platform checks it on each closed bar and sends the message to the user's Telegram. kdscript 1.4 adds drawn objects (line, box, label, made and changed anywhere, kept in arrays, up to 500 of each) for order blocks, gaps and structure breaks; strings (+, str.tostring, str.format, …) for label text; plot offsets (a pivot drawn on the bar where it formed); and 64 plots instead of 16. script_preview lists the objects a script leaves drawn.

The loop: script_reference → script_save (problems come back as line 4:12: …; nothing is saved until it passes) → script_preview on a pair to check the numbers → widget_add / widget_update a price chart with the script. Saving checks a script and never runs it. A preview runs it on the platform in an isolated runner (no network, capped memory and CPU, a step budget and 2 s); the website runs it in the user's browser in a background worker, so a broken script fails only in its own tile.

Vault (Obsidian)

A lab can live as a folder of markdown files on your machine, so Obsidian opens it with its graph and Claude Code reads it like any repo:

kdraigo-mcp vault pull --lab btc-trend --dir ~/vaults/btc-trend   # the first time, into an empty folder
kdraigo-mcp vault pull                                            # later, in the folder
kdraigo-mcp vault status                                          # what a push would send
kdraigo-mcp vault push [--delete]                                 # your edits back to the lab

Files are named by title, so [[Funding drag]] opens Notes/Funding drag.md. Each file goes back over the version it was pulled at: a note your AI changed since is refused, never overwritten. A pull never overwrites your edits either; when both sides changed a note, the platform's text lands in .kdraigo/conflicts/ for you to merge, and the push after that sends the merge. Renaming a file in Obsidian renames the note (its links follow, on both sides); a new file in Notes/ becomes a new note; a deleted one is deleted on the platform only with --delete. In Claude Code the same works through vault_pull and vault_push.

Hosted server

kdraigo-mcp serve --http is the same tool set as a remote MCP server (streamable HTTP, stateless), as run at mcp.kdraigo.com. It leaves out scaffold_strategy, vault_pull and vault_push, which write to the caller's disk, and the replay tools; strategies run in the cloud workspace.

• Sign-in is OAuth 2.1 against the platform's authorization server (users_service), per the MCP authorization spec: an unauthenticated request gets 401 with WWW-Authenticate: Bearer resource_metadata=…, and the server serves its protected-resource metadata (RFC 9728) at /.well-known/oauth-protected-resource[/mcp]. Apps register with a Client ID Metadata Document or Dynamic Client Registration, use PKCE S256, and get tokens bound to the server's URL.

• Each request's token is introspected on users_service's internal port (cached for a minute) and must name this server as its audience.

• Platform calls are signed with an API key minted for that connected app (24 h, renewed): the app's token never leaves the server. Disconnecting the app on kdraigo.com's Account page revokes both.

• Limits per account: 120 tool calls a minute (bursts of 30), across all the account's connected apps, and 4 long calls (runs, builds, reports: the tools with the 180 s deadline) at once. Over a limit, the call answers with a tool error that says how long to wait, never an HTTP error, so the agent waits or tells the user why. KDRAIGO_MCP_CALLS_PER_MINUTE and KDRAIGO_MCP_LONG_CALLS change them. The gateway in front counts requests per sign-in token from the AI providers' published addresses and per address otherwise.

• Configuration: KDRAIGO_MCP_RESOURCE, KDRAIGO_MCP_ISSUER, KDRAIGO_MCP_USERS_INTERNAL_URL, KDRAIGO_MCP_INTERNAL_TOKEN, KDRAIGO_MCP_ADDR (see cmd/kdraigo-mcp/serve.go). The Dockerfile builds the image; the image workflow publishes it on a release tag.

Authentication model

Requests are signed with signing version 2, the only version the platform accepts since 2026-10-11 (kdraigo-mcp v1.0.9+, dev_sdk v1.3.0+). Every signed request carries:

• X-Key-ID: your Ed25519 key UUID

• X-Timestamp: Unix seconds, within 5 minutes of the server clock

• X-Nonce: 32 hex characters, new for every request

• X-Signature: hex(ed25519(KDRAIGO-SIG-V2\nMETHOD\nPATH\nCANONICAL_QUERY\nTIMESTAMP\nNONCE\nhex(sha256(BODY))))

Each signature is accepted once, so a retry signs again. The backtester_engine uses uppercased variants (X-API-KEY / X-SIGNATURE / X-TIMESTAMP, with the same X-Nonce), and its WebSocket sends them as headers on the upgrade, not in the URL. The binary handles all of this.

Layout

kdraigo_mcp/
  cmd/kdraigo-mcp/         CLI entry, install-skill subcommand
  internal/
    config/                config.yaml loader
    auth/                  Ed25519 signer
    client/                signed HTTP + WS clients
    hosted/                the remote server: OAuth resource, introspection, per-app keys
    render/                header + TSV rendering under the output cap
    tools/                 the MCP tools, embedded SDK + indicator docs
    vault/                 a research lab as a folder of markdown (pull, push)
  skills/                  the skills, embedded into the binary

Templates

The example_strategy repo holds three starter templates: basic, with-indicators, with-risk-manager. They're cloned at scaffold time so updates to templates ship without binary releases.

License

See LICENSE.