MCP tools and their effects
Tools are labelled read or write and state their effects. The server check rejects missing or inconsistent labels.
Stochastly / stochastly-mcpPublicThe MCP launcher, open source under MIT. It connects Claude, Cursor or VS Code to the engine running in the desktop app; the engine itself stays in the app.View the source on GitHub ↗Run Stochastly's agents with your own model
Call list_agents and get_agent, then give each brief to a Claude Code or Codex sub-agent. Start a local session with research_start, send each returned turn prompt to its named agent, and submit the answer with research_turn. Repeat until you receive the debrief prompt, then have your own model write it. Pass as_agent and session_id with agent actions so the server enforces permissions. The workflow does not use the hosted LLM relay or its credits. Research turns require Atelier or Portfolio. Sessions are saved on your computer and never expire; up to 15 can be open at once, and research_close archives one.
Read the paper tool contract
Inspect the paper tools exposed by the local MCP server before calling them. Their descriptions identify the output document and required inputs.
Open full sizeCounted from the server self-test
A thin client over loopback, on the app's own engine
The server is a client of the app's engine, and holds no engine of its own. A running app publishes its local engine to sidecar.json in its home directory (~/.stochastly on Windows, ~/Library/Application Support/Stochastly on macOS) — a loopback address and a per-launch token — and the MCP reads that file and calls 127.0.0.1 with the token (stochastly_mcp.py:71-117). The traffic stays on the loopback interface, and the trust model is the app's own. With the source checkout and no app running, it falls back to an in-process engine.
What the agent drives is therefore the same anti-overfit pipeline the GUI drives, on the same catalogue, with the same costs declared in the graph.
Two commands: register the server, then self-test it
$ claude mcp add stochastly -- python "%LOCALAPPDATA%\Stochastly\mcp\stochastly_mcp.py" $ python "%LOCALAPPDATA%\Stochastly\mcp\stochastly_mcp.py" --selftest
The client script ships inside the install, next to the app resources. The self-test walks the server source and stops on the first tool that carries no read/write class, then prints one line: how many tools were registered and how many of them write. It is the same command the count above comes from. It needs an interpreter on the PATH carrying the mcp package, which declares requires_python >= 3.10. That requirement comes from the package itself, and it is the reason the version is stated at all: nothing in this repository pins it.
Tools that change something name their effect
The server declares the effect of each write tool and quotes that effect when refusing a request. A tool without an effect declaration fails the server self-test. The public export workflow uses papers and strategy code.
Open full sizeA licence check first; the read class then opens wide
MCP is included in both plans, Atelier and Portfolio. An active licence is required. Within the licensed workspace, the read class needs nothing further: the catalogue and the registries (node_catalog, registries, crypto_registry, data_sources), the runs already computed (v9_list_runs, v9_get_run, v9_tail_log, v9_protocol_a, backtest_status, paper_sections), the live surface (app_info, live_state, tail_app_log) and the verdict surface (red_flag_check, adversarial_check, diagnostic_explain, diagnostics_catalog, reality_check_profiles).
compose_graph is one of them. It turns a plan into a runnable spec and counts its configuration space without running anything, so a graph can be prepared and inspected before any engine time is spent.
Autonomous sessions run under the judge
An agent can hold a long research session on the desk: backtest_graph with background: true returns a run id at once, backtest_status polls it, and two guided prompts (research_under_the_judge, robustness_battery) carry the loop the desk expects.
Every finished run is recorded in a per-day session registry, readable as the resource bluxt://session-registry, and every result carries a multiplicity block with the session totals for runs and configurations. These counts make the search history visible. A new lever needs paired gain, placebo and positive control in development, then one preregistered reading of sealed data; the count alone does not tighten its threshold. The engine runs on your machine: an unattended session spends your CPU and your hours, at your pace.
One dictionary draws the boundary the guard enforces
Two boundaries, both from the same source. Tools, resources and prompts are wrapped alike, and each one requires an edition listed in MCP_EDITIONS_ACCES (stochastly_mcp.py:718): the three kinds are wrapped at build time, so a licence outside those editions gets a refusal rather than data. Within them, the write class requires one of MCP_EDITIONS_ECRITURE (stochastly_mcp.py:668), and the read class requires no further check. Both checks fail closed, so an edition the server cannot read is neither a reading nor a writing one. The classification that draws that boundary is the same object the public contract prints — one dictionary, one guard — so a tool's docstring and its guard state the same boundary.
Two tools can end up running your own Python
backtest_graph executes a custom/Custom strategy node itself; pilot_app(run=True) requires the manually placed .mcp_pilot flag before the app executes one through a .stly document. Both pass the provenance guard, and the self-test checks that on the AST, with the tool name playing no part. The engine runs that code with your privileges, so run code you trust.
One command prints the registration and the classes
$ python stochastly_mcp.py --selftest
The self-test is at stochastly_mcp.py:1246, the registration sites at stochastly_mcp.py:614,628 and the resources at stochastly_mcp.py:1069-1085.