Skip to main content
Glama
LuxAlgo

LuxAlgo Library MCP

Official
by LuxAlgo

Find pass- and EV-optimal risk per trade

propfirms_optimal_risk

Sweep risk-per-trade across a grid, simulate full prop firm journeys at each point, and compare two optima: the risk maximizing pass probability versus the risk maximizing expected value.

Instructions

Sweep risk-per-trade over a grid, run the full journey simulation at every point, and report two optima separately: bestByPassProbability (the risk that maximizes a single attempt's chance of passing) and bestByEv (the risk that maximizes expected value across attempts, fees and funded payouts). They usually differ (diverges=true) - and that divergence is the insight: lower risk survives loss limits more often, but EV also weighs the cost of extra attempts and the size of funded payouts, which can favor a different risk. Never present one number as THE optimal risk; report both optima and the trade-off, and let the user choose. The sweep uses common random numbers (the same seed at every grid point), so curves are smooth and the argmax is signal, not Monte Carlo noise. Grid units follow riskMode: percent units for percent modes (default grid 0.1 to 3 in steps of 0.1, i.e. 0.1%-3% per trade), currency per trade for 'fixed-amount' (set min/max/step explicitly). Parametric trader only (riskValue is not a parameter here - the grid supplies it). Cost scales with grid size: one full simulation per point, so ~30 points at the default 10,000 paths takes roughly 10 seconds; use fewer paths or a coarser grid for a first pass, then refine around the optima. UNITS: every *Pct rule field and every percent-mode risk value is in PERCENT UNITS (5 = 5%, 0.5 = 0.5%). The one exception is winRate, which is a FRACTION in [0, 1] (0.55 = 55% winners). Probabilities in results are fractions in [0, 1]. DETERMINISM: identical inputs including seed reproduce byte-identical results on any platform. Include the seed and path count when reporting numbers so users can reproduce them exactly; re-run with a few different seeds to gauge Monte Carlo spread. ASSUMPTIONS: every result carries assumptions.flags - dataset-declared rules the engine does NOT simulate (e.g. scaling plans or soft daily lockouts, which make real odds worse than simulated) plus engine simplifications - and assumptions.disclaimer. These are material: always surface the flags and the disclaimer to the user alongside the numbers, never just the headline probability. Results are distributions under stated assumptions, not promises.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maxNoGrid end, same units as min. Default 3 (= 3% per trade for percent modes).
minNoGrid start, in the risk units of riskMode (percent units for percent modes, currency for 'fixed-amount'). Default 0.1 (= 0.1% per trade for percent modes).
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.
specNoInline challenge ruleset, for challenges not in the directory or for what-if rule edits. Mutually exclusive with firmId/challengeId. Identify the challenge EITHER by directory reference (firmId + challengeId, discovered via propfirms_list_simulatable; firmId accepts the directory id or the firm's name) OR by a full inline `spec` object - the exact shape propfirms_challenge_rules returns, so you can fetch a directory entry, change one rule, and re-simulate to model rule variations. Provide exactly one of the two forms; providing both or neither is an error. Directory references need network access; inline specs are fully offline.
stepNoGrid step, same units. Default 0.1. The sweep runs one full simulation per grid point, so (max - min) / step + 1 simulations in total - keep the grid coarse or paths low for a first pass.
pathsNoMonte Carlo paths (independent simulated trader journeys). Default 10,000 (well under a second); capped at 100,000 per tool call. Confidence intervals shrink roughly with the square root of paths.
firmIdNoDirectory firm id or firm name (e.g. 'ftmo' or 'FTMO'); discover with propfirms_list_simulatable. Must be paired with challengeId. Mutually exclusive with `spec`.
avgWinRYesAverage winning trade in R-multiples, i.e. multiples of the amount risked per trade (1.5 = winners average 1.5x the risk).
winRateYesProbability 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.
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.
attemptCapNoMaximum challenge attempts per path before that path gives up. Default 25. Journey statistics (expected attempts/cost, P(funded)) are censored at this cap.
challengeIdNoDirectory challenge id; discover with propfirms_list_simulatable. Must be paired with firmId. Mutually exclusive with `spec`.
tradesPerDayYesAverage trades per simulated trading day. More trades per day means more ways to hit the daily loss limit within a single day.
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.
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.
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.6/5.0
Behavior5/5

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

With no annotations, the description carries the full transparency burden and meets it well. It discloses cost (one full simulation per point, ~30 points at 10,000 paths takes ~10 seconds), common random numbers for smooth curves, byte-identical determinism with the same seed, the mandatory surfacing of assumptions flags/disclaimer, and the caveat that results are distributions, not promises.

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

Conciseness4/5

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

The description is long, but the tool is complex (19 parameters, nested spec, no output schema) and each section earns its place: purpose, divergence insight, CRN, units, determinism, performance, assumptions. It is front-loaded with the core purpose and then layered with necessary operational detail. Slightly repetitive in warnings, but justified for a high-stakes optimization tool.

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?

Given the tool's complexity, 19 parameters, nested spec object, and no output schema, the description is remarkably complete. It covers the two result optima, the diverges flag, assumptions flags/disclaimer, unit conventions for all risk and probability values, reproducibility requirements, and cost/performance trade-offs. An agent has enough context to select and invoke this tool correctly and interpret its headline results.

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% and each parameter already has rich descriptions, so the baseline is 3. The description adds value beyond the schema by explaining grid defaults (0.1 to 3 in steps of 0.1), grid units relative to riskMode, the winRate fraction exception, and performance implications of grid/path choices — going beyond what the schema alone provides.

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: 'Sweep risk-per-trade over a grid, run the full journey simulation at every point, and report two optima separately'. It clearly distinguishes this from single-point simulation tools by noting 'riskValue is not a parameter here - the grid supplies it' and by naming the two output optima, bestByPassProbability and bestByEv.

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

Usage Guidelines4/5

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

The description gives strong contextual guidance: report both optima rather than one, use coarse grids or fewer paths for a first pass, refine around the optima, and re-run with different seeds to gauge Monte Carlo spread. It does not explicitly name sibling tools like propfirms_simulate as alternatives, but the 'Parametric trader only' and grid-supplies-risk statements imply the boundary. Clear context, but no direct when-not-to-use comparison.

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