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 coding agent, 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.
Setup
- 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.
-
Give it to your agent. Store the token as the
VERIRUNLAB_MACHINE_TOKENenvironment 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://app.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.
Scopes decide what a token can do
When you issue a token you pick from a fixed list of permissions — read runs, launch runs, read workspace files, propose edits, write run notes — and at least one project. Read permissions never move money or change state. Tokens can carry an optional expiry and can be revoked at any time from the same settings page; a revoked token stops working within a minute.
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, read a run's scorecard summary, manifest, artifact index, and the regime, stress and price-path robustness views; compare runs.
- 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.
- 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.
- Propose edits as drafts. A workspace write lands as an inert draft proposal, exactly like the in-app agent. A human opens it in the app and accepts it per scope (production and tests separately). 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).
Every response carries a 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.
Refusals are the system working
If the connector returns a refusal — tests aren't green yet, a proposal is still waiting on a human, a spend needs approval, a daily quota is reached — that is a gate doing its job, enforced on the server where a token can't talk its way past it. The right response is to report it and adapt, never to retry-hammer or route around it.