StockSharp Odysseus

Odysseus

An MCP server that turns any AI agent into a quantitative researcher — and holds it to the discipline that makes a result mean something.

The C# namespaces are rooted at StockSharp.Odysseus. The MCP server reports StockSharp.Odysseus as its name and StockSharp Odysseus as its display title; the client configuration below uses odysseus.

For MCP Registry publication and Claude Desktop extensions, see MCP distribution.

You run it locally beside your own agent. It downloads real market history into one StockSharp storage every project shares, measures what is actually in it, translates a formal hypothesis into a real StockSharp Strategy class, compiles it, backtests it with costs, searches its parameters, and reports what every run came to.

It measures. It does not judge. There is no score in it, no threshold, no accept-or-reject. Whether a drawdown is bearable or a return is worth having depends on what you are researching, and that is your call, not a server's.

Why an MCP server

Because the agent is the researcher, and it already exists.

A backtesting product with a chat window has to ship a model, a conversation, an interface, and an opinion about what a good strategy is. This ships none of them. Your agent brings the reasoning; this brings the parts an agent is bad at on its own — real data that cannot quietly change under a result, a translator that turns a hypothesis into the same code every time, an emulator that charges for the spread, and a slice of history it is not allowed to look at until the end.

That last one is the point. An agent asked to find a profitable strategy will find one. The only thing that separates a finding from a search is data the search could not reach.

What it does

create_project

→ import_history real bars, into the shared storage → analyze_market what the instrument does, before you propose anything for it → propose_spec the hypothesis, as a formal document → build_candidate translated to C#, compiled, hashed → evaluate_candidate six fixed runs, reported in full → measure_on_closed_data once, against data nobody was allowed to see → complete_strategy you decide; the server keeps the code and every number behind it

Forty-eight tools in all: projects, connectors, data, instrument lookup, hypotheses, candidates and a check of whether one gives the same answer twice, backtests, evaluations, a seeded genetic search and a walk-forward over it, the closed-data measurement, paper trading against a broker's paper account, the record of what you completed, and — off unless an operator turns it on — installing StockSharp products on the machine the server runs on.

analyze_market measures the project's dataset — how much the instrument moves, whether its moves continue or come back, and what followed the events a strategy would trade. Read it before proposing anything: a breakout hypothesis on an instrument whose breakouts led nowhere costs a generation of candidates to disprove, and these numbers say so beforehand.

The data discipline

Bars live in one StockSharp market-data storage that every project shares — a folder of its own, ODYSSEUS_MARKET_DATA (./market-data by default). A project does not copy them: its dataset is a symbol list, a candle length and a range, and runs read that range out of the shared storage. A run is recorded by what it read — instrument, candle length, from and to — so importing the same range again finds every run already made over it.

A dataset is cut by time into three parts: the first 60% of the range to form a hypothesis on, the next 20% to measure it on, and the last 20% closed. describe_split says where each part lies; what keeps the closed part closed is that no tool hands out its bars and that it is measured once — not once per project, but once per stretch of history, recorded in a ledger beside the projects, because starting a second project and importing the same dates does not make the answer unseen. The ledger checks and records a measurement in one step, so two projects asking at the same moment cannot both get through.

What a measurement looks like

Six runs, always the same six: the development slice, the validation slice, the validation slice again with costs half again as high, and the development slice cut into three consecutive windows run with the same numbers. Profit, drawdown, trade count, win rate, exposure, what share of the result rests on a single trade, the spread between the windows, what survived the higher costs. No verdict — that part is yours.

The three windows ask whether the result is spread over the history or made in one stretch of it. They do not choose numbers per window; run_walk_forward does that — it searches the declared numbers on one stretch, tests the choice on the stretch after it, and steps forward window by window.

A signal is acted on when its bar closes, and the order fills at the price the market stood at then. Whether a result survives an entry that lands a bar later — what it is worth without the price the signal was seen at — is asked separately, by running run_backtest under the entryOneBarLater scenario beside the baseline and costsX15 ones.

Running it

From NuGet

With the .NET 10 SDK, install either tool from NuGet:

dotnet tool install --global StockSharp.Odysseus.Mcp

dotnet tool install --global StockSharp.Odysseus.Cli

Each package includes the worker and runner in their own folders, so either tool can be installed independently. The MCP connection below can use "command": "odysseus-mcp" instead of a path to the server executable.

From a release

You need the .NET 10 runtime. Download the archive for your system from the releases - Windows x64, Linux x64 or macOS on Apple silicon - and unpack it. The folder holds the server as Odysseus.Server and the command line as odysseus, with the worker and the runner they start in folders beside them, so it is moved and removed as one. On macOS, clear the flag the browser puts on a download before the first start: xattr -dr com.apple.quarantine odysseus.

From source

You need the .NET 10 SDK.

git clone https://github.com/StockSharp/StockSharp.git "StockSharp (GitHub)"

git clone https://github.com/StockSharp/Odysseus.git cd Odysseus dotnet build -c Release

The trading platform is built from source, so its repository is cloned beside this one, into the folder the build looks for it in. To keep it somewhere else, name that place as StockSharpSource in a Directory.Build.local.props beside Directory.Build.props.

That produces src/Odysseus.Server/bin/Release/net10.0/Odysseus.Server.exe, and the command line beside it as src/Odysseus.Cli/bin/Release/net10.0/odysseus.exe.

Connecting an agent

Point your agent at the server over stdio:

{

"mcpServers": { "odysseus": { "command": "path/to/Odysseus.Server.exe", "env": { "ODYSSEUS_PROJECTS_ROOT": "path/to/where/projects/should/live", "ODYSSEUS_MARKET_DATA": "path/to/the/shared/market-data/storage" } } } }

Then ask it to import_demo_dataset and work through a hypothesis. The bundled dataset is generated, so nothing measured on it says anything about any market — it is there to prove the machinery runs without an account.

Workspace files

One MCP process owns one workspace, set by ODYSSEUS_PROJECTS_ROOT. Stop that process before using research commands in the CLI against the same folder. Independent workspaces can run independently. Requests within one process are serialized when they update metadata.

Projects, budgets, candidates, runs, measurements and audit events are readable JSON files. Record file names include their insertion order; updates keep the same name. Scoped operation keys live in operations.json, and spent closed history in closed-history.json, beside the project folders. These journals survive restarts, so restarting the server or creating another project does not reset research limits or make a closed stretch available again. No database service or native SQLite library is needed.

Specifications, generated source, assemblies and completed strategies remain files inside their project. Market history stays in StockSharp's file storage at ODYSSEUS_MARKET_DATA; it is not copied into project metadata. Each trading runner keeps its own files and can outlive the MCP process.

For a workspace created by an older SQLite version, see the one-time migration.

With real data

Real data comes through a StockSharp connector, and the server is not compiled against one. It cannot be: a running server cannot compile itself, so the connector arrives as a published NuGet package that the server downloads and loads into a context of its own. Which one is yours to say.

Put the credentials that connector takes in a file:

key: ...

secret: ...

and point ODYSSEUS_BROKER_KEYS at it. A path rather than the values themselves, because a value in the environment is inherited by every child process — including the worker that runs candidates — and shows up in a process listing.

Then say which connector, either in a file that ODYSSEUS_BROKER_CONNECTOR points at:

{ "packageId": "StockSharp.Binance", "settings": {} }

or, while the server runs, with list_connectors, describe_connector and select_connector. describe_connector reports every setting a package accepts and the values each one allows, so a choice can be written from what the connector says about itself rather than from documentation.

Two more variables bound what may be downloaded, because all three of those tools run downloaded code — what a connector is for and whether it can be told it is on a paper account are properties of an instance, so reading a package builds the adapter inside it: ODYSSEUS_CONNECTOR_SOURCES (the feeds, https://api.nuget.org/v3/index.json by default) and ODYSSEUS_CONNECTOR_ALLOW (the package name prefixes, StockSharp. by default). Both are start-up decisions and neither is reachable from a tool. An allow-list that was set and came out empty allows nothing rather than everything. A server started with --hosted refuses all three tools: its connector is chosen when the process starts.

Without a connector everything else still works: the demo dataset, analyze_market, every backtest, the closed-data measurement and complete_strategy all read history that is already imported. describe_server says which half of the product you have.

History can also come from a remote StockSharp storage server (Hydra) instead of the broker. Name it in a file that ODYSSEUS_REMOTE_STORAGE points at:

{ "address": "10.0.0.5:5002", "login": "...", "password": "..." }

import_history then reads bars from that server into the shared local storage, and every run reads them locally from there. The server is reached through the `StockSharp.F