Skip to main content
Glama
LuxAlgo

LuxAlgo Library MCP

Official
by LuxAlgo

Screen a strategy across all challenges

propfirms_validate_strategy

Wondering which prop firm challenges your strategy would pass? Simulate it across live challenges to get pass probabilities, expected attempts, costs, and EV per challenge.

Instructions

Answer 'which challenges would MY strategy actually pass?' in one call: simulate the given strategy through every simulatable challenge in the live directory (optionally scoped by productType, account-size range, priceMax, or firm) and split the results by an explicit, caller-stated bar. Describe the strategy EITHER as real trades (rSeries/rSeriesText R-multiples, preferred: the stationary block bootstrap preserves streaks, which is what breaches loss limits) OR as summary stats (winRate + avgWinR, optional spreads), plus tradesPerDay and risk sizing (riskMode + riskValue). The bar is minPassPerAttempt (a fraction, default 0.5) with optional requirePositiveEv; always state the bar when relaying results. Returns per challenge: pass probability per attempt with 95% CI, P(funded), expected attempts and total cost, EV over the funded horizon, P(EV>0), assumption flag ids, and which rule semantics were inferred from listing text. HONESTY FRAME: this is a screen of distributions for the caller's inputs and bar, NOT a ranking or endorsement; challenges whose rules cannot be encoded honestly are excluded and counted, never guessed; flagged (unsimulated) rules make numbers optimistic, so relay flags. One full simulation runs per challenge (default 5,000 paths each; results are deterministic per seed), and scopes above 40 challenges are refused rather than silently truncated: narrow the scope instead. Numbers move with risk sizing; sweep one challenge with propfirms_optimal_risk afterwards. Fees and expected costs use the directory's listed prices (live discounts are NOT applied); prices, firm profiles, and current offers are directory data (propfirms_search_challenges, propfirms_get, propfirms_search_offers).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
firmNoRestrict to one firm by propfirmId or name (e.g. 'ftmo').
seedNoRNG seed (integer or string). Default 42. Same inputs + seed reproduce byte-identical results — include the seed when reporting so users can reproduce the numbers.
pathsNoMonte Carlo paths PER CHALLENGE. Default 5,000 here (one full simulation runs per challenge in scope, so this tool costs number-of-challenges times one simulation); raise it to tighten confidence intervals on a narrowed scope.
avgWinRNoAverage winning trade in R-multiples, i.e. multiples of the amount risked per trade (1.5 = winners average 1.5x the risk).
rSeriesNoThe strategy's real trades as R-multiples in chronological order (P&L divided by amount risked; +1.8 = won 1.8x risk, -1 = lost the risk). At least 10 trades, 100+ recommended. When given, the screen uses the stationary block bootstrap (streaks preserved) instead of winRate/avgWinR.
winRateNoProbability a trade is a winner, as a FRACTION in [0, 1] (0.55 = 55% winners) — NOT percent units. The most impactful input: traders routinely overestimate it by a few points, which can flip EV negative, so prefer measured stats over self-reported ones.
winStdRNoStandard deviation of winner sizes in R (0 = every winner is exactly avgWinR). Default 0. Adding spread makes streak damage more realistic.
avgLossRNoAverage losing trade in R, as a POSITIVE number. Default 1 (losers lose exactly the risked amount, i.e. stops are honored). Raise above 1 to model slippage or blown stops.
lossStdRNoStandard deviation of loser sizes in R (0 = every loser is exactly avgLossR). Default 0.
priceMaxNoOnly challenges costing at most this.
riskModeNoHow riskValue is interpreted. 'percent-of-balance' (default): risk compounds with the current balance. 'percent-of-initial': constant currency risk derived from the initial account size — how most prop traders size, since loss limits are fixed in currency. 'fixed-amount': explicit currency risked per 1R.
riskValueYesRisk per trade — the value of 1R. PERCENT UNITS for percent modes (0.5 = 0.5% risked per trade; a typical prop range is 0.25-2), or a currency amount for 'fixed-amount'. NOT a fraction.
attemptCapNoMaximum challenge attempts per path before that path gives up. Default 25. Journey statistics (expected attempts/cost, P(funded)) are censored at this cap.
productTypeNoRestrict the screen to one instrument class.
rSeriesTextNoThe same series as pasted text (JSON, CSV, or whitespace separated, optional 'R' suffix). Mutually exclusive with rSeries.
tradesPerDayYesAverage trades per simulated trading day. More trades per day means more ways to hit the daily loss limit within a single day.
accountSizeMaxNoOnly challenges with at most this account size.
accountSizeMinNoOnly challenges with at least this account size.
simulateFundedNoWhether to simulate the funded stage (payouts, blowup risk) after passing. Default true — EV is only meaningful with it on; set false to study the evaluation alone.
blockMeanLengthNoBootstrap mean block length in trades. Default 5. Only used with rSeries/rSeriesText.
fundedHorizonDaysNoFunded-stage horizon in trading days for the payout/EV simulation. Default 90 (about 4 calendar months). EV scales with this choice — state it when reporting EV.
minPassPerAttemptNoThe pass bar as a FRACTION in [0, 1]: a challenge counts as passing when the simulated per-attempt pass probability is at least this. Default 0.5. State the bar when relaying results.
requirePositiveEvNoAdditionally require expected value (payouts minus all fees over the funded horizon) above zero. Default false.
tradesPerDayModelNo'fixed' (default): the same count every day. 'poisson': daily count drawn Poisson(tradesPerDay); days can then have zero trades, which do not count as trading days.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden, and it exceeds it: it discloses that this is a screen, not a ranking/endorsement; that flagged rules make numbers optimistic; that results are deterministic per seed; that one full simulation runs per challenge; and that fees use listed prices without live discounts. It also warns about risk-sizing sensitivity and the need to state the bar when relaying results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place given the tool's complexity and 24 parameters. It front-loads the core purpose and bar concept, then packs behavioral caveats, parameter semantics, and sibling routing without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 24-parameter tool with no output schema and no annotations, the description is remarkably complete: it specifies the return fields per challenge, the simulation methodology and defaults, refusal behavior, fee assumptions, reproducibility, and related tools. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description adds value on top: it explains which strategy inputs are alternatives (rSeries/rSeriesText vs winRate/avgWinR), why rSeries is preferred (streak preservation), and emphasizes that riskValue is percent units not a fraction. It also frames minPassPerAttempt as the caller-stated bar and clarifies that funded-horizon EV scales with fundedHorizonDays.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'simulate the given strategy through every simulatable challenge in the live directory' and answers a direct caller question ('which challenges would MY strategy actually pass?'). It clearly distinguishes itself from sibling tools like propfirms_simulate and propfirms_optimal_risk by framing this as an all-challenges screen with an explicit bar.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use context: use it to screen across challenges, and use propfirms_optimal_risk to sweep one challenge afterwards. It also states exclusions and limits (challenges whose rules cannot be encoded honestly are excluded and counted, scopes above 40 challenges are refused) and points to sibling tools for directory data, so an agent can choose correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.