Skip to content
Stratifyre Docs

MCP Server

Stratifyre exposes a Model Context Protocol (MCP) server from the API server. MCP-compatible clients can authenticate with OAuth and then use Stratifyre tools to work with strategies, backtests, market data, scanners, walk-forward analysis, and a small set of user/billing discovery resources.

The current server module registers 52 tools across 5 tool providers, plus 5 static resources, 1 resource template, and 4 prompts:

  • Tool providers: StrategyTools, BacktestTools, MarketDataTools, ScannerTools, WalkForwardTools
  • Resources: user-profile, billing-reconciliation, billing-spending-cap, mcp-scopes, system-status, and the strategy resource template
  • Prompts: strategy-optimization, backtest-comparison, scanner-analysis, operations-triage

Transport and Authentication

Section titled “Transport and Authentication”

Stratifyre protects MCP access with OAuth 2.1 bearer tokens and scope-based authorization.

  • HTTP transport: https://<api-host>/mcp
  • SSE transport: https://<api-host>/sse
  • Server name: stratifyre

Request the narrowest scopes your client needs. The current scope families are:

  • stratifyre:strategies:read, stratifyre:strategies:write
  • stratifyre:backtests:read, stratifyre:backtests:write
  • stratifyre:marketdata:read
  • stratifyre:scanners:read, stratifyre:scanners:write
  • stratifyre:walkforward:read, stratifyre:walkforward:write
  • stratifyre:billing:read
  • stratifyre:user:read

Use the mcp://stratifyre/mcp/scopes resource to inspect the scope registry from the server itself.

The same scope registry is also the source of truth for OAuth scopes_supported in the well-known metadata documents. Tool scopes and protected-resource scopes stay aligned with the advertised OAuth surface.

Current write scopes are intentionally coarse-grained within each domain. A granted *:write scope covers that domain’s full mutation surface, including create/update/start/stop/delete style actions and helpers such as clone, rerun, or AI conversion where exposed. Some of those writes are billable or destructive, so client consent UX should treat write scopes as high-trust.

Admin behavior is also not fully isolated from MCP tokens. If a platform admin authorizes an MCP client, backtest and walk-forward direct-ID paths currently inherit service-level admin bypasses, which can preserve cross-tenant visibility or actions where the backing services allow them. Treat that as an operational/admin-client concern rather than a default trust model for general end-user clients.

Future hardening could split lifecycle, delete, and admin/operator scopes instead of keeping all domain writes bundled into *:write.

Resources

Section titled “Resources”

These resources are registered today:

  • mcp://stratifyre/user/profile: Current user profile, subscription state, entitlements, limits, usage, and reset windows.
  • mcp://stratifyre/billing/reconciliation: Billing-period reconciliation snapshot including Stripe drift details.
  • mcp://stratifyre/billing/spending-cap: Spending cap amount, current overage, percent used, and enforcement state.
  • mcp://stratifyre/mcp/scopes: Static listing of available MCP OAuth scopes.
  • mcp://stratifyre/system/status: Connectivity/status check with version and timestamp.
  • mcp://stratifyre/strategies/{strategyId}: Resource template for fetching one owned strategy and its configuration.

Notes:

  • user-profile requires stratifyre:user:read.
  • billing-reconciliation and billing-spending-cap require stratifyre:billing:read.
  • mcp://stratifyre/strategies/{strategyId} requires stratifyre:strategies:read and enforces ownership.
  • mcp-scopes and system-status are discovery resources and do not require an additional domain scope.

Prompts

Section titled “Prompts”

These prompts are registered today:

  • strategy-optimization: Guided workflow for reviewing a strategy and iterating with backtest and walk-forward tools.
  • backtest-comparison: Guided workflow for comparing two backtests with performance and Monte Carlo analysis.
  • scanner-analysis: Guided workflow for reviewing scanner configuration and trigger quality.
  • operations-triage: Runbooks for usage reconciliation, spending-cap issues, and MCP write-scope failures.

Tool Inventory

Section titled “Tool Inventory”

The current source registers 52 tools across five domains: 10 strategy, 17 backtest, 9 market data, 9 scanner, and 7 walk-forward.

Response Conventions

Section titled “Response Conventions”

The MCP surface now uses a few consistent response shapes:

  • Paginated/list responses return {data, page, limit, total, pageCount}.
  • Derived artifacts that do not exist yet return {available: false, data: null, reason} instead of an empty list.
  • Mutations and async starts return resourceUri, status, and nextActions; async jobs also return pollTool when applicable.

Strategy Tools

Section titled “Strategy Tools”

The CRUD and conversion tools in this group require strategy read or write scopes and operate on user-owned strategies. The two rule-authoring helpers are authenticated, read-only discovery/validation tools.

  • strategy_rule_capabilities: Return the rule-authoring grammar, enum values, expression examples, and safe payload examples for MCP clients.
  • strategy_validate_rules: Validate strategy or scanner rule payloads without mutating anything. Returns valid, rulesValidated, and field-level errors.
  • strategy_list: List strategies with pagination. Useful params: page, limit, optional search, sortBy, sortDir.
  • strategy_get: Fetch one strategy in full. Param: strategyId.
  • strategy_create: Create a strategy. Useful params: name, instruments or baskets, optional instrumentSelectionMode, rules, naturalLanguageStrategyText, notes, aiNotes.
  • strategy_update: Partially update a strategy. Param: strategyId plus any mutable strategy fields.
  • strategy_delete: Delete one owned strategy. Param: strategyId.
  • strategy_clone: Clone one owned strategy. Param: strategyId.
  • strategy_convert_nl: Start async natural-language-to-strategy conversion. Param: text. Returns a jobId.
  • strategy_convert_nl_status: Poll NL conversion status. Param: jobId.

Notes:

  • Strategy creation requires a name.
  • If instrument selection is ticker-based, the source enforces a non-empty instruments array.
  • Instrument IDs use the AssetClass:Exchange:Symbol pattern.
  • Recommended MCP authoring flow is strategy_rule_capabilities -> build payload -> strategy_validate_rules -> strategy_create or strategy_update.

Backtest Tools

Section titled “Backtest Tools”

These tools cover job lifecycle, analytics, and runtime inspection for visible backtests.

  • backtest_list: List visible backtests. Useful params: page, limit, strategyId, status, sortBy, sortDirection.
  • backtest_get: Return the persisted job record. Param: jobId.
  • backtest_start: Start a backtest from a structured engine config. Key params include strategyId, date range, instruments or baskets, sizing/risk fields, time step, and optional Monte Carlo settings.
  • backtest_rerun: Rebuild and rerun from an existing job with overrides. Param: jobId plus any override fields accepted by start.
  • backtest_status: Return condensed job status and summary metrics. Param: jobId.
  • backtest_performance: Return headline performance metrics for a completed backtest. Param: jobId.
  • backtest_trades: List completed trades with pagination. Params: jobId, page, limit.
  • backtest_monte_carlo: Return stored Monte Carlo summary statistics. Param: jobId.
  • backtest_stop: Stop a queued or active job. Param: jobId.
  • backtest_delete: Delete a backtest and related runtime artifacts. Param: jobId.
  • backtest_equity_curve: Return equity-curve points. Params: jobId, optional maxPoints for downsampling.
  • backtest_performance_segments: Return segmented performance metrics. Params: jobId, optional segmentType.
  • backtest_monte_carlo_iterations: Return paginated per-iteration Monte Carlo rows. Params: jobId, page, limit.
  • backtest_monte_carlo_compare: Compare Monte Carlo outcomes across backtests. Param: jobIds array of 2 to 10 jobs.
  • backtest_snapshots: Return paginated snapshot data. Params: jobId, page, limit, optional label, instrumentId, from, to, at.
  • backtest_runtime_events: Return paginated runtime events. Params: jobId, page, limit, optional eventType, instrumentId, startTime, endTime.
  • backtest_runtime_event_summary: Return runtime event counts by type. Param: jobId.

Notes:

  • Start and rerun both validate date ordering.
  • backtest_list supports first-class status, strategyId, sortBy, and sortDirection filters.
  • Several backtest tools return paginated data to keep responses bounded.
  • Snapshot and runtime-event queries accept optional time filters using ISO-8601 strings.

Market Data Tools

Section titled “Market Data Tools”

These tools are read-only and require stratifyre:marketdata:read.

  • marketdata_search: Search instruments and return usable instrumentId values. Params: query, limit.
  • marketdata_available_symbols: List supported symbols, optionally by asset class. Params: optional assetClass, limit.
  • marketdata_ohlcv: Return OHLCV bars over a date range. Key params: instrumentId, timeframe, startDate, endDate, limit, optional eth, adjustTo.
  • marketdata_crypto_metadata: Return the server’s crypto metadata map. No params.
  • marketdata_trades: Return raw trade ticks over a date range. Params: instrumentId, startDate, endDate, limit.
  • marketdata_benchmark: Return daily benchmark index close prices. Params: symbol, startDate, endDate.
  • marketdata_latest_price: Return the latest available OHLCV bar. Params: instrumentId, optional resolution of 1m, 5m, 15m, 1h, or daily.
  • marketdata_freshness: Return freshness metadata for one instrument. Param: instrumentId.
  • marketdata_treasury_rates: Return US Treasury par-yield rates. Params: optional startDate, endDate, limit.

Notes:

  • Instrument IDs are validated as AssetClass:Exchange:Symbol.
  • marketdata_ohlcv enforces startDate < endDate and a source-level earliest date of 2018-05-01.
  • marketdata_search is the best first step before calling tools that require an instrumentId.
  • Calendar-date inputs use strict YYYY-MM-DD validation.

Scanner Tools

Section titled “Scanner Tools”

These tools manage user-owned market scanners and their trigger history.

  • scanner_list: List scanners with pagination. Params: page, limit.
  • scanner_get: Fetch one scanner in full. Param: scannerId.
  • scanner_create: Create a scanner. Key params include name, ruleSource, useStrategyInstrumentSelectionMode, and optional rules, strategyId, instruments, baskets, status, updateFrequency, naturalLanguageStrategyText, aiNotes.
  • scanner_clone: Clone a scanner into a new disabled scanner. Param: scannerId.
  • scanner_update: Partially update a scanner. Param: scannerId plus mutable scanner fields.
  • scanner_start: Start a scanner. Param: scannerId.
  • scanner_stop: Stop a scanner. Param: scannerId.
  • scanner_delete: Delete a scanner. Param: scannerId.
  • scanner_triggers: Return recent trigger history. Params: scannerId, optional page, limit.

Notes:

  • Creating or updating to ACTIVE runs billing/spending-cap checks in source.
  • Scanner payloads can either embed rules directly or point at a linked strategy, depending on ruleSource.
  • Scanner rule payloads use the same schema and validation path as strategy rule payloads.

Walk-Forward Tools

Section titled “Walk-Forward Tools”

These tools manage walk-forward analyses and their fold/result artifacts.

  • walkforward_list: List owned analyses with pagination. Params: page, limit.
  • walkforward_start: Start a walk-forward analysis. Key params include engineConfig, optimizationMethod, objectiveFunction, mode, capitalMode, isLengthMonths, oosLengthMonths, and optional optimization, noneMode.
  • walkforward_get: Return one analysis and its stored config. Param: analysisId.
  • walkforward_folds: Return generated fold records. Param: analysisId.
  • walkforward_result: Return the aggregated result summary. Param: analysisId.
  • walkforward_stop: Stop a queued or active analysis. Param: analysisId.
  • walkforward_delete: Delete an analysis and fold artifacts. Param: analysisId.

Notes:

  • walkforward_start validates date ordering inside engineConfig.
  • If optimizationMethod is not none, the source requires an optimization payload.
  • Starting an analysis also runs entitlement and spending-cap checks.