Skip to main content
Glama
LuxAlgo

LuxAlgo Library MCP

Official
by LuxAlgo

Compare challenges for one trader

propfirms_compare

Compare prop firm challenges by simulating the same trader profile across them under identical options and seed, returning per-challenge expected value, costs, and funded probability.

Instructions

Simulate the SAME trader across several challenges (directory references and/or inline specs, up to 12) under identical options and seed, and return one row per challenge sorted by expected value. THIS IS NOT A RANKING: rows are ordered by EV for the caller's specific inputs - trader stats, risk sizing, and options - and a different trader profile reorders them. The tool computes data for the user's own decision; it implies no endorsement, league table, or recommendation of any firm, and results should be presented that way ('best EV for these inputs', never 'best firm'). Each row carries perAttemptPassProbability, fundedProbability, expectedAttempts, expectedCost, evTotal, pEvPositive, daysToFundedP50, and the challenge's flagsNotSimulated - challenges with more unsimulated rules have optimistic numbers, so compare flags alongside EV, not EV alone. Consistency rules and funded payout gating ARE simulated (engine v1), so EV already reflects them where a ruleset has them. For full per-challenge distributions run propfirms_simulate on the interesting rows. 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
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 (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.
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.
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.
challengesYesThe challenges to simulate this trader across (1-12 entries; 2+ for a meaningful comparison). Mix dataset references and inline specs freely.
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.7/5.0
Behavior5/5

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

With no annotations, the description carries full disclosure and does so thoroughly: EV ordering is input-dependent and not a ranking, unsimulated rules make numbers optimistic, consistency and payout gating ARE simulated, results are deterministic given seed, and outputs are distributions under assumptions, 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.

Conciseness5/5

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

The description is long but every section earns its place, with clear CAPITALIZED signposts (UNITS, DETERMINISM, ASSUMPTIONS) and front-loaded behavior/scope before caveats. Given the tool's complexity, this density is appropriate rather than bloated.

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 Monte Carlo tool with no output schema and no annotations, the description is complete: it names the output row fields, explains assumptions/disclaimer handling, gives units, determinism, input forms, caps, and routes to propfirms_simulate for deeper analysis. Nothing essential to 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; the description adds value by establishing global unit conventions (percent units vs winRate as a fraction), explaining determinism/seed reporting, and warning that probabilities in results are fractions. It does not need to restate each field.

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 opening sentence names a specific verb and resource — 'Simulate the SAME trader across several challenges' — and clarifies the return shape (one row per challenge sorted by expected value). It also distinguishes itself from propfirms_simulate by deferring per-challenge distributions to that sibling.

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 clear context: compare the same trader across up to 12 challenges and states an explicit alternative ('For full per-challenge distributions run propfirms_simulate on the interesting rows'). It does not enumerate when-not conditions against every sibling, but the routing advice is unambiguous.

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