Skip to main content
Glama
LuxAlgo

LuxAlgo Library MCP

Official
by LuxAlgo

Get a challenge's full ruleset

propfirms_challenge_rules

Retrieve a prop trading firm challenge's complete ruleset—evaluation steps, drawdown modes, consistency, fees, funded terms—to review or re-simulate with modified rules.

Instructions

Fetch one directory challenge's complete ruleset (ChallengeSpec), adapted from the live LuxAlgo directory: evaluation steps (profit targets in percent units of the initial account, minimum trading days, time limits); the daily-loss rule with its exact semantics (basis = measured from prior-day balance vs prior-day equity; limitBasis = whether a pct limit is a fixed allowance of the initial balance or recomputed daily from the anchor; evaluation = breached on an intraday touch vs only at the close; includesOpenPnl = whether floating P&L can breach it); the max-loss rule and its drawdown mode (How the max-loss floor behaves - the single most consequential rule difference between firms. 'static-initial': floor fixed at initial balance minus the limit; never moves (classic CFD two-step). 'trailing-realized-eod': floor ratchets up with end-of-day balance highs; intraday highs do not move it. 'trailing-intraday-unrealized': floor trails the peak unrealized equity intraday and never stops trailing (futures-style; the most-miscalculated rule in the industry: it cuts pass probability dramatically). 'trailing-locks-at-initial': trails intraday peak equity until the floor reaches the initial balance, then freezes (common futures variant). Locking is also composable: locksAtInitial adds the same lock to an EOD trail, and lockOffsetAmount shifts the lock level to initial balance + that amount (e.g. 100 models 'stops trailing $100 above the start').); per-step consistency rules (steps[].consistency.maxBestDayProfitPct - SIMULATED: one outsized day effectively raises the target until the best-day share complies); fees (price, one-time vs monthly billing, reset fee, activation fee, refundable-on-pass); funded terms (profit split percent, payout frequency, first-payout minimum days, and funded.payoutRules - SIMULATED payout gating: minWinningDays, winningDayMinProfit, per-payout caps maxPayoutPctOfProfit/maxPayoutAmount, bufferAmount, and a windowed consistencyMaxBestDayPct gate); flagsNotSimulated (rules the entry declares but the engine does not simulate - material caveats to relay to the user); and sources (the firm-page citation when the directory serves one). The result also carries provenance and inferredFields - every rule read from free text instead of a structured column is named there; relay them and treat the firm's page as authoritative. The returned challenge object is exactly the shape the simulation tools accept as inline spec: copy it, change a rule, and re-simulate to quantify how a rule variation moves pass probability and EV. 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]. DATA SOURCE & PROVENANCE: firm data comes live from LuxAlgo's public, keyless prop-firm directory API - the data behind luxalgo.com/prop-firms (origin overridable via the LUXALGO_APP_ORIGIN env var). Rule semantics are used verbatim where the directory serves structured rule columns; where it serves only free text, semantics are inferred ONLY when one reasonable reading exists, and every inferred field is disclosed in inferredFields (provenance 'directory+inferred') - relay those to the user next to any numbers. Challenges whose loss rules cannot be established are refused as not simulatable rather than guessed. Firms change rules; each firm's own page is always authoritative. NOTE: this returns the simulatable encoding of one challenge's rules; the directory listing with every captured field, plus live offers, is propfirms_get and propfirms_search_challenges.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
firmIdYesDirectory firm id or firm name from propfirms_list_simulatable, e.g. 'ftmo'.
challengeIdYesDirectory challenge id from propfirms_list_simulatable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers extensively: refusal behavior, provenance disclosure via `inferredFields`, data-source attribution with env-var override (LUXALGO_APP_ORIGIN), authority caveats ('Firms change rules; each firm's own page is always authoritative'), and a precise units convention. It even distinguishes simulated rules from declared-only ones via `flagsNotSimulated`.

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 front-loaded with the core purpose and organized via labeled sections (UNITS, DATA SOURCE & PROVENANCE, NOTE), which aids navigation in a very long text. However, it is exceptionally verbose, and the provenance/authoritative-page point is made roughly three times, so it does not fully meet 'every sentence earns its place.'

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?

There is no output schema and no annotations, yet the description documents the full return shape (evaluation steps, daily-loss and max-loss semantics, fees, funded terms, flagsNotSimulated, sources, provenance), the units convention, the data origin, and edge/refusal cases. An agent can call this tool and interpret its result accurately without any additional lookups.

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

Parameters3/5

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

Schema description coverage is 100% and both parameter descriptions already name the source listing (propfirms_list_simulatable) and give an example ('ftmo'). The main description reinforces the origin of the IDs but adds no new syntax, defaults, or formats for firmId/challengeId beyond what the schema provides, so baseline 3 applies.

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 states a specific verb and resource: 'Fetch one directory challenge's complete ruleset (ChallengeSpec)'. The closing NOTE explicitly distinguishes it from propfirms_get and propfirms_search_challenges, removing any ambiguity with the closest siblings.

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

Usage Guidelines5/5

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

The end of the description gives explicit routing: 'the directory listing with every captured field, plus live offers, is propfirms_get and propfirms_search_challenges.' It also explains the integration path with simulation tools ('copy it, change a rule, and re-simulate') and states a refusal condition ('Challenges whose loss rules cannot be established are refused as not simulatable').

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