BackTest_MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QUANTFORGE_DB_PATH | No | Path to SQLite database file | quantforge_mcp/storage/quantforge.db |
| QUANTFORGE_SSE_PORT | No | Port for SSE transport | 8001 |
| QUANTFORGE_TRANSPORT | No | Transport method (stdio or sse) | stdio |
| QUANTFORGE_DATA_SOURCE | No | Data source for stock data | yfinance |
| QUANTFORGE_DOCKER_IMAGE | No | Docker image for sandbox worker | quantforge-worker:latest |
| QUANTFORGE_ARTIFACTS_DIR | No | Directory for backtest artifacts | quantforge_mcp/storage/artifacts |
| QUANTFORGE_DOCKER_ENABLED | No | Enable Docker sandbox for backtest workers | true |
| QUANTFORGE_SANDBOX_CPU_QUOTA | No | Sandbox CPU quota | 100000 |
| QUANTFORGE_SANDBOX_MEM_LIMIT | No | Sandbox memory limit | 512m |
| QUANTFORGE_SANDBOX_TIMEOUT_SEC | No | Sandbox timeout in seconds | 120 |
| QUANTFORGE_ENABLE_EXPERIMENTAL_ML | No | Enable experimental ML module (set to 1 to enable) | |
| QUANTFORGE_ALLOW_SYNTHETIC_FALLBACK | No | Allow synthetic data fallback | true |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_stock_dataA | Fetch and cache OHLCV bars for one or more symbols from local DB or remote source. Args:
symbols: Non-empty list of ticker codes; pass a single symbol as Returns:
|
| list_cached_symbolsA | List stock symbols that already have OHLCV data in the local SQLite cache. Returns:
|
| run_backtest_dynamicA | Run a dynamic Strategy backtest in an isolated sandbox and persist artifacts. Args:
code: Python source with exactly one Returns:
On success: |
| get_backtest_resultA | Fetch status and summary for a backtest job stored in SQLite. Args:
job_id: Job identifier returned by Returns:
|
| list_backtest_jobsA | List recent backtest jobs from SQLite, newest first. Args:
limit: Maximum number of jobs to return (default 50).
status: Optional filter, e.g. Returns:
|
| generate_backtest_reportA | Build a Markdown tearsheet report from a completed backtest's equity curve. Args:
job_id: Completed backtest job (must have an Returns:
On success: |
| get_backtest_artifactsA | List on-disk artifact paths for a backtest job. Args:
job_id: Backtest job identifier.
kind: Optional filter: Returns:
|
| scan_strategy_signalsA | Scan the latest bar for live strategy signals from a saved backtest job. Loads Args:
job_id: Backtest job whose artifacts contain the strategy and config.
warmup_days_override: Optional calendar days of history to fetch; overrides
the default warmup-based window when set.
notify: When true and signals exist, send email via configured SMTP
( Returns:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| compute_modules_index | |
| strategies_index | Built-in strategy examples index. |
| codegen_spec | |
| symbol_guide | |
| nvda_example |
TDQS
Scored across 8 tools
Each tool has a clearly distinct purpose: data fetching, cache listing, running backtests, retrieving results, listing jobs, generating reports, accessing artifacts, and scanning live signals. No two tools overlap in function, even though several relate to backtests but target different aspects (results vs artifacts vs jobs).
The naming follows a verb_noun pattern with prefixes like get_, list_, run_, generate_, and scan_. The mix of get_backtest_result and get_backtest_artifacts vs list_backtest_jobs and list_cached_symbols is syntactically consistent, though get vs list could be unified. Overall it is predictable and readable.
Eight tools is ideal for a backtesting MCP server. The scope is tightly focused on data retrieval, backtest execution, result inspection, artifact access, reporting, and live signal generation—each tool addresses a distinct step in the workflow with no redundancy or bloat.
The tool surface covers the full lifecycle: fetching market data, running dynamic backtests, retrieving results and artifacts, listing historical jobs, generating reports, and scanning live signals. There are no obvious missing operations for the domain; the set is comprehensive and self-contained.