luxalgo-mcp-server

Screen a strategy across all challenges

propfirms_validate_strategy

Read-only

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

Name	Required	Description
`firm`	No	Restrict to one firm by propfirmId or name (e.g. 'ftmo').
`seed`	No	RNG seed (integer or string). Default 42. Same inputs + seed reproduce byte-identical results — include the seed when reporting so users can reproduce the numbers.
`paths`	No	Monte 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.
`avgWinR`	No	Average winning trade in R-multiples, i.e. multiples of the amount risked per trade (1.5 = winners average 1.5x the risk).
`context`	Yes	Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
`rSeries`	No	The 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.
`winRate`	No	Probability 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.
`winStdR`	No	Standard deviation of winner sizes in R (0 = every winner is exactly avgWinR). Default 0. Adding spread makes streak damage more realistic.
`avgLossR`	No	Average 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.
`lossStdR`	No	Standard deviation of loser sizes in R (0 = every loser is exactly avgLossR). Default 0.
`priceMax`	No	Only challenges costing at most this.
`riskMode`	No	How 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.
`riskValue`	Yes	Risk 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.
`attemptCap`	No	Maximum challenge attempts per path before that path gives up. Default 25. Journey statistics (expected attempts/cost, P(funded)) are censored at this cap.
`productType`	No	Restrict the screen to one instrument class.
`rSeriesText`	No	The same series as pasted text (JSON, CSV, or whitespace separated, optional 'R' suffix). Mutually exclusive with rSeries.
`tradesPerDay`	Yes	Average trades per simulated trading day. More trades per day means more ways to hit the daily loss limit within a single day.
`accountSizeMax`	No	Only challenges with at most this account size.
`accountSizeMin`	No	Only challenges with at least this account size.
`simulateFunded`	No	Whether 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.
`blockMeanLength`	No	Bootstrap mean block length in trades. Default 5. Only used with rSeries/rSeriesText.
`fundedHorizonDays`	No	Funded-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.
`minPassPerAttempt`	No	The 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.
`requirePositiveEv`	No	Additionally require expected value (payouts minus all fees over the funded horizon) above zero. Default false.
`tradesPerDayModel`	No	'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.

Changed3 schema fields changedSep 8, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / context / description

Previous value: -"Explain 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.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""

changedInput schema / properties / seed / anyOf

Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "string"
-  }
-]New value: +[
+  {
+    "maximum": 9007199254740991,
+    "minimum": -9007199254740991,
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  }
+]

Changed3 schema fields changedAug 31, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / context

Added value: +{
+  "description": "Explain 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.\"",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "tradesPerDay",
-  "riskValue"
-]New value: +[
+  "tradesPerDay",
+  "riskValue",
+  "context"
+]

AddedAug 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say readOnly and openWorld; the description adds a wealth of behavioral detail beyond that: the honesty frame (not a ranking, excluded challenges counted, flags relayed), deterministic per-seed results, refusal of scopes >40 challenges, and that live discounts are not applied. This fully covers the safety and reproducibility profile the annotations omit.

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 every sentence earns its place. It front-loads the purpose and strategy-input options, then covers the honesty frame and performance notes. It is well-paragraphed and dense; for 25 parameters it avoids redundancy and stays focused. A minor deduction for length, but not wasteful.

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 no output schema, the description details the returned fields (pass probability, CI, P(funded), expected attempts/cost, EV, P(EV>0), assumption flags, rule semantics). It also explains scoping, simulation cost, determinism, and related tools. An agent has everything needed to call it correctly and interpret 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%, so the baseline is 3. The description adds real value beyond the schema: it explains the bar's semantics and reporting requirement, recommends preferring rSeries over winRate, and warns that winRate is easily overestimated. It also clarifies interaction effects (risk sizing moves numbers) and mentions the funded horizon scaling EV. These are meaningful additions.

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 a direct answer to the user's question ('which challenges would MY strategy actually pass?') and states the resource (every simulatable challenge in the live directory) and the action (simulate and split by a bar). It explicitly names sibling tools (propfirms_optimal_risk, propfirms_search_challenges, etc.) for differentiation, making the purpose unmistakable.

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?

It clearly frames the tool as a multi-challenge screening tool and points to propfirms_optimal_risk for a focused sweep afterwards. It also gives practical guidance like 'scopes above 40 challenges are refused' and 'narrow the scope instead.' It does not explicitly state 'when not to use this,' but the alternative and the condition are implied strongly 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 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Screen a strategy across all challenges

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources