# XTester MCP usage scenarios

Below are **conceptual** capability-level scenarios. Exact tool calls will be added after the release catalog is verified; the status of these examples is `conceptual`, not `verified`. The approvals mentioned are the expected workflow, not proof of technical enforcement.

## Scenario 1. Verify an existing strategy

1. discover environment capabilities;
2. confirm the workspace;
3. inspect the project and spec;
4. validate data coverage;
5. compile;
6. run a backtest;
7. inspect the summary, trades and equity curve;
8. report assumptions and limitations.

## Scenario 2. Build a strategy from a brief

1. read the environment and API docs;
2. create strategy files through MCP, not the OS filesystem;
3. validate and format;
4. compile;
5. download a bounded history range;
6. backtest;
7. present the first result without claiming profitability.

## Scenario 3. Compare parameters

1. freeze the source and data range;
2. run controlled variants;
3. compare metrics, trade count, drawdown and turnover;
4. state what was held constant;
5. avoid cherry-picking a best run after the fact.

## Scenario 4. Walk-forward / research

1. define training and test windows;
2. set token and compute budgets;
3. launch a long-running job;
4. poll status;
5. preserve the holdout;
6. report dependent tests and limitations.

## Scenario 5. Porting a strategy from another platform (conversion)

Conceptual sequence (exact names and order are reconciled with the release's machine catalog):

1. import the source and confirm the right to use it (`confirm_rights`);
2. begin the conversion run and read the source;
3. get the XTester context — API and environment limits;
4. record the behaviour model and the decisions for incompatibilities;
5. hand the port files to the project and compile;
6. pass the semantic audit and, when a reference report exists, the diff-test;
7. finalise with an honest status and a final report.

Core pipeline tools: `convert_import_source`, `convert_begin`, `convert_read_source`, `convert_get_xtester_context`, `convert_submit_behavior_model`, `convert_submit_decisions`, `convert_submit_files`, `convert_compile`, `convert_submit_semantic_audit`, `convert_finalize`; service tools — `list_conversion_runs`, `convert_get_manifest`, `convert_status`, `get_conversion_report`, `convert_cancel`.

Only source is accepted (`.ex4`/`.ex5`/`.dll` — no). A successful compile does not confirm behavioural correctness. Without a reference report the result is "not confirmed"; identity with the original's results is not claimed.

Each scenario implies a user prompt, a recommended capability sequence, approvals, expected artifacts, failure paths and result interpretation.