Skip to main content
Glama

luxalgo-mcp-server

by io.github.LuxAlgo

Screen a strategy across all challenges

propfirms_validate_strategy

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).
contextYesExplain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization."
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.

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 the full behavioral burden, and it does: deterministic per seed, one simulation per challenge, exclusion/counting of non-encodable rules, optimism flags, refusal above 40 challenges, no live discounts applied, and the honesty frame that this is a screen, not an endorsement. This is model-level transparency.

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 dense but every sentence carries real decision-relevant content, with the core question and default bar front-loaded. It is a single monolithic paragraph rather than structured sections, which slightly hurts scannability, but for a 25-parameter tool with no annotations, this length is justified.

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?

No output schema exists, yet the description enumerates the return fields per challenge: pass probability with 95% CI, P(funded), expected attempts/cost, EV, P(EV>0), assumption flag ids, and inferred rule semantics. Combined with the honesty frame, scope limits, follow-up routing, and schema-covered parameter details, nothing critical is missing for correct invocation.

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

Parameters5/5

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

Schema coverage is 100%, so baseline is 3, but the description adds substantial meaning beyond the schema: the stationary block bootstrap preserves streaks that breach loss limits, winRate overestimation can flip EV negative, average loss 1 means stops are honored, EV scales with fundedHorizonDays, and the bar must always be stated. These are exactly the semantics that change how an agent selects and interprets parameters.

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 opens with the exact question the tool answers ('which challenges would MY strategy actually pass?') and names a specific verb/resource: simulate a strategy through every simulatable challenge in the live directory. It clearly distinguishes this all-challenges screening tool from the single-challenge optimization mentioned afterward.

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 context: when to use it (one-call screening across challenges), refuses scopes above 40 challenges instead of truncating, and routes follow-up single-challenge sweeps to propfirms_optimal_risk. It does not explicitly contrast with sibling tools like propfirms_simulate or propfirms_pass_rates, but the screening purpose is clear enough.

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

All luxalgo-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

The domain prefixes (edge_, library_, propfirms_, trackers_) cleanly separate four distinct areas, and within most clusters each tool has a specific job (search vs get vs list vs simulate). The propfirms cluster is the only strain: propfirms_simulate, propfirms_simulate_trades, propfirms_pass_rates, propfirms_compare, and propfirms_validate_strategy all overlap in the broad sense of 'running simulations,' though the descriptions do differentiate them by input type and scope.

Naming Consistency4/5

Each domain follows its own consistent pattern: library_get_*/library_list_*, propfirms_* with an action verb, edge_* and trackers_* as noun-style resources. The convention is recognizable and predictable per domain, with only minor deviations like propfirms_challenge_rules and propfirms_pass_rates being noun-first rather than verb-first.

Tool Count3/5

At 28 tools the server is heavy, but the count is justified by four large, distinct product surfaces (Library, Edge Stats, prop-firm simulation, and market trackers). Each individual cluster is reasonably scoped; the propfirms cluster alone accounts for 12 tools, which pushes the total into the 'too many' range even though the breadth is real.

Completeness5/5

Each domain feels complete: edge stats has catalog, symbol discovery, and report retrieval; the Library has search, browse, get, and source-code access; propfirms has search, get, rule encoding, simulation, trade-series simulation, comparison, optimization, and validation; trackers has dataset discovery, query, latest-publish, and cross-dataset ticker dossiers. There are no obvious dead ends or missing lifecycle steps within the read-only/analysis scope the server targets.

Resources