Skip to main content
Glama
Sign In

LuxAlgo MCP

by io.github.LuxAlgo
OverviewDiscussionsAdmin

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

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 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."
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. Changed3 schema fields changed
    • 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"
+  }
+]
  2. Changed3 schema fields changed
    • 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"
+]
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/non-destructive, but the description discloses determinism per seed, one full simulation per challenge (cost scales with scope), a hard 40-challenge refusal, fees taken from listed prices with discounts NOT applied, flags making numbers optimistic, and honest exclusion of unencodable challenges. This is substantial behavioral context well beyond the annotations.

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

Conciseness3/5

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

Front-loaded with the core question and scope, but it is a very long run-on paragraph packing in assumptions, honesty framing, and caveats. Every clause carries content, yet the wall-of-text form hurts scannability for a 25-parameter 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?

No output schema exists, and the description compensates by enumerating the returned fields (pass probability with 95% CI, P(funded), expected attempts/cost, EV, P(EV>0), assumption flags). For a high-complexity screening tool it is complete enough to call correctly.

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 is already documented, so the baseline is 3. The description still adds interpretive value: it explains the two strategy-input modes and that rSeries is preferred, clarifies the minPassPerAttempt bar default and the 'always state the bar' convention, and notes that numbers move with risk sizing.

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?

States a specific verb+resource+scope ('simulate the given strategy through every simulatable challenge in the live directory') and frames it as answering a concrete question. It is clearly distinguishable from single-challenge siblings like propfirms_simulate and propfirms_optimal_risk, which it explicitly names.

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?

Gives strong routing guidance: 'sweep one challenge with propfirms_optimal_risk afterwards', refuses scopes above 40 challenges ('narrow the scope instead'), and points to directory siblings (propfirms_search_challenges/get/search_offers). It stops short of stating when NOT to use this versus propfirms_simulate or simulate_trades, so it is clear context rather than a full when/when-not map.

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

All LuxAlgo MCP toolsInspect
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.

Resources