Skip to main content
Glama

luxalgo-mcp-server

by io.github.LuxAlgo

Find pass- and EV-optimal risk per trade

propfirms_optimal_risk

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).
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."
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.

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and delivers extensively: it discloses common random numbers across grid points, byte-identical determinism from seed, compute cost (~10 seconds at default grid/paths), the typical divergence between the two optima and what it means, and the mandatory surfacing of assumptions.flags and the disclaimer. It also instructs agents to never present one number as THE optimal risk, which is behavioral guidance no annotation could express.

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 well organized, front-loaded with the core sweep behavior and the dual-optima distinction, and broken into labeled sections (UNITS, DETERMINISM, ASSUMPTIONS). For a 20-parameter tool with no annotations and no output schema, nearly every sentence carries load-bearing information; only minor redundancy (e.g., the full-simulation-per-point idea stated twice, default grid values also present in the schema) keeps it from a 5.

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 tool with 20 parameters, nested spec objects, no annotations, and no output schema, the description covers what the tool returns (both optima plus a diverges flag), how to interpret the divergence, unit conventions, reproducibility, compute cost, and the requirement to surface assumption flags and disclaimers. The only gap is a full enumeration of the result shape, but the named output fields and extensive risk-context guidance make that unnecessary for correct invocation.

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, and the description earns the extra point by clarifying unit traps the schema leaves implicit (winRate is a fraction while everything else is percent units) and by explaining the grid/riskMode relationship and the compute trade-offs among min, max, step, and paths. It reinforces the schema's seed-reproducibility note and adds useful new advice to re-run with several seeds to gauge Monte Carlo spread.

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 names a specific verb and resource: 'Sweep risk-per-trade over a grid, run the full journey simulation at every point,' and it precisely defines the two outputs (bestByPassProbability and bestByEv). This clearly distinguishes the tool from siblings like propfirms_simulate and propfirms_pass_rates, which evaluate single scenarios or pass rates rather than optimizing over a risk grid.

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

Usage Guidelines3/5

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

The description gives strong operational guidance: parametric trader only, use a coarse grid or fewer paths for a first pass then refine around the optima, and adjust grid units via riskMode. However, it never explicitly contrasts with sibling tools or states when NOT to use this tool in favor of a single-point simulator, so the selection context is implied rather than explicit.

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