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.