Automate

Connect an external agent (MCP)

If you already work in an AI coding agent of your own, you can point it at VeriRun Lab over MCP (the Model Context Protocol) and drive your research from there — read runs, size a data window, launch and poll backtests, and stage workspace edits. Crucially, it gets exactly the capabilities you grant it and not one more: every platform gate is enforced on the server, so an external agent is never a way around the rules.

What this is (and isn't)

This is the same read → propose → check philosophy as the in-app AI Assistant, exposed to a client you run yourself. It is a research surface: your agent can look at a lot and it can propose changes and launch runs, but it cannot approve spend, accept its own proposals, or touch entitlements — those verbs simply do not exist on this interface. Anything that would cost money or change state still needs a human in the app.

No MCP client? There is a simpler round trip: the workspace's Download runnable .zip export packs an AI_INSTRUCTIONS.md with the working rules and the strategy contract an external AI needs to edit the code, plus the exact re-package steps — so any assistant can work on the zip and hand it back for Import .zip from AI, where it lands as a reviewable import, not an applied change.

Setup

1. Mint a machine token. In the app, go to Settings → Agent access and issue a token. It requires a fresh code from your authenticator, and it is scoped: you choose which permissions it carries and which projects it can see. The token value is shown once — copy it then.
2. Give it to your agent. Store the token as the VERIRUNLAB_MACHINE_TOKEN environment variable in your MCP client's config. Most MCP-capable coding agents read a small JSON config; a typical entry looks like:

{
  "mcpServers": {
    "verirunlab": {
      "command": "uv",
      "args": ["run", "--package", "verirunlab-mcp", "verirunlab-mcp"],
      "env": {
        "VERIRUNLAB_MACHINE_TOKEN": "vrl_…",
        "VERIRUNLAB_API_URL": "https://api.verirunlab.com"
      }
    }
  }
}

That runs the connector as a local subprocess your agent talks to over stdio — the usual local-config model. It can also run as a shared HTTP service if you'd rather host it once for a team. Either way, authentication, the available tools, and every server-side gate are identical; only the wire changes.

Finding the IDs your agent needs

The tools address things by ID — a project_id, workspace_id or run_id. Usually the only one you have to hand over is the project id: from there the agent can discover the rest itself with list_workspaces(project_id) (the project's workspaces) and list_plugin_versions(workspace_id) (each workspace's cut strategy versions, with their approval state — what run_backtest needs — and the same declaration warnings the version card shows in the app, e.g. a declared feature key the run mount will exclude). Those same warnings also come back on every code proposal your agent submits, so it sees them the moment it writes the code, not first on the dashboard.

To read an ID manually: the app URL — a project lives at /app/projects/<id>, a workspace at /app/workspaces/<id>, and a run at /app/runs/<id>. The project and workspace headers also carry a Copy ID button, so you can grab one without parsing the address bar. And because every /agent response carries a resolvable dashboard_url deep link, once your agent has touched something it can hand the exact page — ID and all — straight back to you.

The read surface — never spends

A broad set of read-only tools lets your agent gather context before it does anything that costs credits. None of these consume anything:

• Runs & results — list and poll runs (filterable by grading basis), read a run's scorecard summary, manifest, artifact index, and the regime, stress and price-path robustness views; compare runs and read the cross-run comparison table. Every result read names its grading basis and its unit, and every meeting surface carries the mismatch block, so an agent never reads a dollar figure as R or two bases as like for like.
• Prior research — optimization studies, their leaderboards and trials; screener sweeps and the instruments a sweep can fan across.
• Data sizing — the instrument list, dataset coverage, and stored data quality reports, so an agent can judge whether a window is trustworthy before it enqueues a run.
• Context — prop-firm rules and evaluations, your journal trades, and the community leaderboard.
• Prop-firm replays and order tests — replay your journal, one of your backtest runs, or a list of trades, through a prop firm's rules with your saved rule edits and options: the prop-firm panel's own calculation, so your agent gets exactly the numbers the panel shows — every account path, the fees the firm doesn't state, and the trade-by-trade ledger on request — and the panel's order test (the same trades in other random orders, at the panel's seed and your admin's number of orders). A journal source also needs the journal-read permission, a run the runs-read permission.
• Catalogs — the feature primitives and workspace templates, plus a read of any workspace file.

The acting surface — gated, and cheap-first

The tools that do something follow the same validate-before-you-spend rhythm the app encourages:

• Run the checks in order — tests, then a significance preview, then a preview, then a full backtest — polling each with the backoff the response suggests. Tests and previews are free; backtests are metered. Plugin-version launches take an explicit session window (window_start/window_end, YYYY-MM-DD) and optional params for the version's settings (an engine-native version's settings fields; a template's own parameters) — omitted keys keep their defaults, and unknown keys are refused at enqueue. The run's options — the hours, the session's end, how the exchange fills it — travel as run_options, the launch dialog's own override layer. A strategy that reads several markets is launched with symbols — the markets in order, the primary first (usually the one the orders go on — a strategy may order on any of its markets) — on the preview, the backtest and the optimization study alike, under the same limits as the dialog; get_data_coverage(symbols=…) sizes a window for the whole set, and get_run reads back which markets ran, which received orders and how many sessions every market held.
• Propose edits as drafts. A workspace write lands as an inert draft proposal, exactly like the in-app Assistant. It collects in the AI-drafts inbox (/app/drafts), where a human opens it and accepts it per scope: a button appears for each kind of change the proposal actually contains — production code, test content, and the test setup that runs around the tests — one decision each, and the draft stays in the inbox until every scope it contains has been decided. The agent can never assume acceptance.
• Write conclusions back to a run's notes, and request a shareable report bundle for a finished run (a packaging step that derives no new evidence), or ask for one session's chart to be built when the run did not store it.
• Keep your own prop firms (the Write your firms permission): enter a firm you describe, save a firm's rules as your own copy with your changes, and edit a firm field by field — with the same checks and messages as the app. An edit never changes the rules an evaluation you track started with: it is saved as a new version instead. Deleting or archiving a firm stays yours, in the app.
• Change your settings (the Write your settings permission): change your saved settings key by key through the same route the app uses — starting with the prop-firm panel's rule edits — and a change made from an older read is refused rather than overwrite yours. Journal settings need the journal permissions; appearance, progress and chart settings stay yours, in the app, for now.

Every response carries a resolvable dashboard_url deep link back into the dashboard, so anything your agent did is one click away in the UI — and agent-launched runs are stamped so you can tell them apart from your own.