LuxAlgo MCP

Creates a Custom Alert in the signed-in member's account from an indicator's condition on one market and timeframe: either a Vela built-in indicator (`indicator`: RSI crosses above 70, MACD crosses above its signal line, price crosses below the lower Bollinger Band…) or an open-source LuxAlgo Library indicator (`library`: its slug, from library_search, firing on one of its alert conditions or on its alerts). It first replays the alert over recent history and says how often it would have fired ("12 times, about 0.4 per day"); with `preview_only` it stops there and creates nothing, which is the way to try a condition before the member decides. Paid Library indicators cannot run as alerts. It notifies the member in-app when the account has that channel; the result says plainly which channel it notifies, or that it notifies no one. Previews are limited to about 10 a minute. Use alerts_create_price for a plain price level. How many alerts the member may have on comes from their LuxAlgo plan: at a limit the call answers with the limit and where to upgrade, and nothing is created. It changes the member's account, so the chat app may ask the user to confirm first. Requires signing in with a LuxAlgo account (OAuth).

Creates a Price Alert in the signed-in member's account: it fires when a market's price crosses, crosses above, crosses below, is above or is below a level the member chose, as often as `frequency` says. It notifies the member in-app (Vela on the web and on their phone) when the account has that channel; the result says plainly which channel it notifies, or that it notifies no one. With `chart_id` from chart_open it also draws the level on that chart. Use alerts_create_custom for an indicator's condition instead. How many alerts the member may have on comes from their LuxAlgo plan: at a limit the call answers with the limit and where to upgrade, and nothing is created. It changes the member's account, so the chat app may ask the user to confirm first. Requires signing in with a LuxAlgo account (OAuth).

When the signed-in member's alerts fired, newest first (kept 90 days): the alert, the market, the time, and whether each notification was delivered; the price it fired at only for crypto markets fed by an exchange's public feed (Hyperliquid, Binance). Optionally for one alert (`alert_id`). Paged with `cursor`. Use alerts_list for the alerts themselves. Requires signing in with a LuxAlgo account (OAuth).

The signed-in member's LuxAlgo Alerts, Price Alerts and Custom Alerts, as Vela shows them: each alert's id, name, market, what it waits for (a Price Alert's level is the member's own), how often it fires, whether it is on, paused, fired or held back, whether it notifies anyone, and a Vela chart link for its market; plus how many of each kind are on against what the member's plan allows. Use it to answer what alerts the member has and to get an id for alerts_pause, alerts_resume or alerts_history. Requires signing in with a LuxAlgo account (OAuth).

Pauses one of the signed-in member's alerts (Price Alert or Custom Alert, its id from alerts_list): it stays saved and stops firing until alerts_resume. Returns the alert in words. It changes the member's account, so the chat app may ask the user to confirm first. Requires signing in with a LuxAlgo account (OAuth).

Turns one of the signed-in member's alerts back on (paused, fired, expired or held back by the plan; its id from alerts_list). Returns the alert in words. How many alerts the member may have on comes from their LuxAlgo plan: at a limit the call answers with the limit and where to upgrade, and nothing is created. It changes the member's account, so the chat app may ask the user to confirm first. Requires signing in with a LuxAlgo account (OAuth).

Edits or reads a chart already open in the chat (from chart_open): switch market or timeframe, add or remove a native indicator, draw a level or a zone, clear drawings, or zoom to a date range; {op: "read"} changes nothing and returns what the chart shows now. Ops apply in order. Usually waits a few seconds for the chart to confirm and returns what it shows, in words, with the numbers the user sees on it: the last price, the change since the day's open (00:00 UTC), the high and low of the visible range and each indicator's latest value (e.g. "RSI 38.2"). Quote those as of the moment of the reply; it never returns candles. {op: "read", image: true} also sends a picture of the chart as the user sees it into your context, where the chat app accepts images from the chart (it arrives with the next message). If the chart is idle it may answer at once that the edits are queued and when the chart applies them; if it is not on screen, edits stay queued and apply when it is shown again, and a read returns its last report without live numbers. Use chart_open instead to show a new chart.

Shows an interactive live chart from Vela, our next-generation charting platform, inside the chat: crypto candles streamed from Hyperliquid or Binance in the user's browser, with optional native indicators, horizontal levels, shaded zones and a date range. Use it when the user wants to see or discuss a crypto market visually. Returns a chart_id; change or read the open chart afterwards with chart_command rather than opening a new one. This result describes the chart in words and carries no prices; once the chart is on screen, chart_command (including its read op) also returns the last price, the day's change, the visible high and low and each indicator's latest value. It never returns candles. Symbols: "BTC" or "hyperliquid:BTC" (Hyperliquid perpetuals), "binance:BTCUSDT" (Binance spot); a bare pair ending in USDT/USDC goes to Binance.

A picture of the chart the signed-in member has open right now in Vela, our next-generation charting platform, in their browser, as they see it, with the market, timeframe and indicators in words and a Vela link (chart_url). Use it when the member asks about the chart they have open in Vela ("look at my chart", "what do you see here?"). To show a market inside the chat instead, use chart_open. Works for crypto charts fed by an exchange only (Binance, Binance.US, Coinbase, Hyperliquid); for any other market it says so and sends no picture. The member's Vela tab must be open and visible; a first ask after a quiet spell can say no chart is open, and asking again a minute later works. The result carries no prices beyond what the picture shows. chart_index picks one chart of a multi-chart layout (0 is the first); without it, the chart the member is working on. Requires signing in with a LuxAlgo account (OAuth).

Used by the chart view itself, not by the model: acknowledges applied changes, reports the chart's state in words and fetches pending changes.

The catalog of session-statistics questions the hosted store precomputes nightly — gap fills, opening-range breakouts, day-of-week effects, event-day behavior, and more. Each preset states in plain language what its number means. Returns preset ids for edge_report.

One precomputed session-statistics result: P(outcome | conditions) for a preset on a hosted symbol, in the engine's full honesty envelope — the estimate with N and a Wilson 95% confidence interval, minimum-sample guards, a first-half vs second-half stability split, per-year counts, the value distribution where the outcome is continuous, and the disclaimer. Historical conditional frequencies, not predictions. Preset ids come from edge_presets; symbols from edge_symbols. `chart_url` opens the symbol on a Vela chart at an interval that suits the preset.

What the hosted Edge Stats store covers: the symbols, their session calendars, coverage windows, session counts, and when the nightly build last ran. Session statistics (how often a setup actually worked, with sample sizes and confidence intervals) come from the open-source edge-stats engine over free market data. Start here, then edge_presets for the questions you can ask, then edge_report for a result. Each symbol carries `chart_url`, the link that opens that market on a Vela chart.

Log a trade by adding its fills to a `manual` or `import` journal account (never a broker-synced one — the sync owns those). The journal derives trades from fills: a long round trip is a buy fill then a sell fill, a short is sell then buy, scale-ins and partial exits are just more fills, and a lone fill opens a position. Times are ISO 8601 instants with offset; fees are per fill. Fills identical to existing ones are skipped as duplicates. Returns the insert counts and the trade(s) the fills now belong to, with `key`s for journal_update_trade. Correcting or removing an existing fill is done in the app, not here. Requires signing in with a LuxAlgo account (OAuth).

Where the P&L actually comes from: closed trades in the window grouped nine ways — weekday, time of day, hold time, symbol, side, position size, tag, rating and asset class — each group with trade count, wins, losses, net P&L, average net P&L and win rate (breakevens excluded). Defaults to all time, since groups need sample size; narrow with `range` or `from`/`to`. The tool for 'what am I good or bad at' questions; journal_overview has the headline numbers. Requires signing in with a LuxAlgo account (OAuth).

One month of the P&L calendar: week rows of day cells (net and gross P&L, fees, trade/win/loss/breakeven counts, volume; null for days with no trades), each week's net P&L and trade count, and the month's net P&L, trade count, trading days and winning days. Days are in the journal timezone. Omit `month` for the current month. Drill into one day with journal_get_day. Requires signing in with a LuxAlgo account (OAuth).

A single trading day: its stats (null when nothing traded), its trades (closed that day, or opened that day and still open) as summaries, and the day's notes with their ids. `date` is a YYYY-MM-DD day key in the journal timezone. Use it for 'how did Tuesday go', and to find note ids for journal_update_note. Requires signing in with a LuxAlgo account (OAuth).

One trade in full: the summary fields plus its fills (each with the effective values, what the source reported, the user's corrections and whether it is hidden), per-exit gross P&L, hidden fills inside the trade's span, and every annotation — notes, tags, mistakes, playbook id, stop loss, profit target, review time. Use after journal_list_trades or journal_get_day when the user asks about a specific trade or before annotating it. Requires signing in with a LuxAlgo account (OAuth).

The signed-in user's trade-journal accounts — id, name, broker, kind (`sync` mirrors a live broker connection, `import` came from statements, `manual` is hand-entered), currency, initial balance, P&L lot method, last broker sync, archived state — plus `timeZone`, the journal timezone every date in the journal tools is expressed in. Call this first: every other journal tool's `accounts` filter takes these ids and rejects unknown ones, and journal_add_trade needs a `manual` or `import` account. An empty list means no journal yet. Requires signing in with a LuxAlgo account (OAuth).

The user's annotation vocabulary: every tag, mistake and playbook id they have put on any trade (open or closed), most-used first with the number of trades carrying each. Check it before journal_update_trade so new annotations reuse the user's own words instead of minting near-duplicates. Per-trade tags are on each trade summary, not here. Requires signing in with a LuxAlgo account (OAuth).

Trade summaries — `key`, account, symbol, asset class, direction, status (open/win/loss/breakeven), open and close times, quantity and open quantity, average entry/exit, gross and net P&L, fees, fill count, duration, realized R, tags, rating, reviewed flag, hasNotes — newest-opened first by default. `sort` orders by any of openedAt, closedAt, netPnl, grossPnl, durationMs, quantity, symbol or rating (names match the response fields); `order` is desc unless set, except symbol which defaults to asc. Trades lacking the sort value (open trades for closedAt/durationMs, unrated for rating) come last in either order; netPnl is after fees, grossPnl before. Filter by account ids, open-day window (`from`/`to` are inclusive YYYY-MM-DD day keys in the journal timezone, applied to the trade's open day; open positions are always listed), symbol, direction, status or one exact tag. Keyset-paginated: pass `nextCursor` back as `cursor` with the same sort, order and filters. Examples: biggest winners this month = from/to + sort netPnl; worst by gross = sort grossPnl, order asc, status loss; longest holds = sort durationMs. Summaries carry no fills or note text: journal_get_trade with the `key` has those. Requires signing in with a LuxAlgo account (OAuth).

The journal dashboard in one call for a window: performance metrics (net/gross P&L, fees, win rate, day win rate, profit factor, expectancy, average win/loss and their ratio, largest win/loss, streaks, max drawdown, recovery factor, profit concentration, average realized R), the Edge Score with its six components, per-day P&L stats, the cumulative equity curve, open positions, and the accounts and settings the numbers cover. Closed trades bucket by close day in the journal timezone; open positions count toward any window that reaches today. `compare: true` adds `previous` — the equal-length window just before. Defaults to the last 30 days; pass `range: 'all'` or explicit `from`/`to` for more. Null metrics are not computable yet (e.g. no losses → `profitFactorIsInfinite`). Use journal_breakdown for where the P&L comes from and journal_list_trades for the trades themselves. Requires signing in with a LuxAlgo account (OAuth).

Search the notes feed — day notes and trades that carry notes — newest first as one stream split by kind: `notes` (day notes, with ids for journal_update_note) and `tradeNotes` (the trade summary with its note text; annotate via journal_update_trade). Filter by case-insensitive text (`q`), day-key window, symbol (trade notes only — day notes have no symbol and drop out) and account ids; keyset-paginated via `cursor`/`nextCursor`. Omit every filter for the latest notes. Requires signing in with a LuxAlgo account (OAuth).

Replace a day note's text and/or move it to another day, by note id (from journal_get_day or journal_search_notes). The body is replaced whole — to append, read the current text first and send the full new version. Trade notes are edited with journal_update_trade, not here. Returns the updated note. Day notes in the LuxAlgo journal: https://docs.luxalgo.com/platform/workspaces/journal/notes Requires signing in with a LuxAlgo account (OAuth).

Annotate a trade — the user-owned fields only: `notes` (free text about this trade), `tags`, `mistakes`, `playbookId`, `rating` 1–5, `stopLoss` and `profitTarget` (price levels; the stop is what realized R is measured against) and `reviewed`. `tags`/`mistakes` replace the whole list; use `addTags`/`removeTags`/`addMistakes`/`removeMistakes` to change a few entries without clobbering the rest (check journal_list_tags for the user's existing words). Pass null to clear a field. Does not touch fills, prices or P&L — those derive from the fills. Returns the updated trade in full. Requires signing in with a LuxAlgo account (OAuth).

Add a new note to a trading day — any day, traded or not; `date` is YYYY-MM-DD in the journal timezone. Days hold any number of notes, so this never overwrites: to change an existing note use journal_update_note, and for a note about one specific trade use journal_update_trade's `notes`. Returns the note with its id. Day notes in the LuxAlgo journal: https://docs.luxalgo.com/platform/workspaces/journal/notes Requires signing in with a LuxAlgo account (OAuth).

The signed-in member's saved Vela layouts (workspaces), newest first: each one's name, id, when it was last saved, whether it has a share link, and its Vela link (chart_url) that opens that layout. Use it when the member asks for their saved charts or layouts or wants one opened. Read only: it cannot save, rename, share or delete a layout. For a single market on a chart, give that market's chart_url instead. Requires signing in with a LuxAlgo account (OAuth).

Explain a trading concept: the Library's full write-up as markdown — definition, formula, how traders read it, and its indicator implementations. Use for any 'what is X / how does X work' question. Needs the exact slug — find it with library_search or library_list_concepts. `indicators` lists the concept's Library implementations, each with `chart_url` (opens it on a Vela chart) when it runs on Vela.

A family's hub page as markdown — the written overview of that school of analysis plus its complete concept roster. Use after library_list_families, or when the user asks about a whole area like 'SMC' or 'Wyckoff'.

Details for one indicator: what it does, how to read it, family, concept links, preview image — plus whether its source code is available (fetch the code itself with library_get_source_code). Use when the user asks about a specific indicator. `chart_url`, present when the indicator runs on Vela, opens it on a Vela chart.

The Pine Script® source code of a Library indicator. Kept separate from library_get_indicator because sources are long — call it only when the user wants the code itself. For some indicators the app returns only the start of the source to a signed-out user (`complete: false`, with the line counts): signing in to a LuxAlgo account, free included, returns all of it. `chart_url`, present whenever the indicator runs on Vela, opens it on a Vela chart, whether the source is complete, partial or not served.

Browse every trading and technical-analysis concept in the Library — paginated, optionally one family. Use to enumerate a topic area or find slugs for library_get_concept and the concept filter of library_list_indicators; for keyword lookup prefer library_search.

The Library's top-level taxonomy: 17 families of trading concepts (trend, momentum, SMC/ICT, statistics, …) with concept counts and hub links. The natural first call for orientation.

Browse the indicator catalog with filters and server-side sorting (newest first by default). The Library is organized by family and concept: filter by family (keys from library_list_families) or by concept slug (that concept's implementations; slugs from library_list_concepts or library_search), and optionally by trading platform or plan tier. Use for structured browsing — 'latest indicators', 'everything in the volatility family', 'indicators implementing liquidity sweeps'; for keyword discovery prefer library_search. Each indicator that runs on Vela carries `chart_url`, the link that opens it on a Vela chart.

Search the LuxAlgo Library — the encyclopedia of trading and technical analysis. One query over 800+ concepts (alias-aware: 'stochastics' finds Stochastic Oscillator) and 800+ ready-to-use indicators. Start here whenever you have a name, informal term, or topic; results carry slugs for the get tools plus canonical URLs for citation. Indicator hits that run on Vela carry `chart_url`, the link that opens the indicator on a Vela chart.

The signed-in user's LuxAlgo account: plan tier, entitlements (limits such as alerts, historical bars, AI credits) and profile basics. Use it to tailor answers to what the user's plan actually allows, or when the user asks what plan they are on. Requires signing in with a LuxAlgo account (OAuth).

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

Simulate the SAME trader across several challenges (directory references and/or inline specs, up to 12) under identical options and seed, and return one row per challenge sorted by expected value. THIS IS NOT A RANKING: rows are ordered by EV for the caller's specific inputs - trader stats, risk sizing, and options - and a different trader profile reorders them. The tool computes data for the user's own decision; it implies no endorsement, league table, or recommendation of any firm, and results should be presented that way ('best EV for these inputs', never 'best firm'). Each row carries perAttemptPassProbability, fundedProbability, expectedAttempts, expectedCost, evTotal, pEvPositive, daysToFundedP50, and the challenge's flagsNotSimulated - challenges with more unsimulated rules have optimistic numbers, so compare flags alongside EV, not EV alone. Consistency rules and funded payout gating ARE simulated (engine v1), so EV already reflects them where a ruleset has them. For full per-challenge distributions run propfirms_simulate on the interesting rows. 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.

One prop firm's full dossier by slug: general profile (platforms, markets, payments, Trustpilot, restricted countries), every challenge with its rules, live offers with promo codes and affiliate links, and the written overview (about, rules, payout policy, FAQ). Find slugs with propfirms_search. Uncaptured (null) fields are omitted; challenges reference applicable offers via offerIds into the firm-level offers list. For simulated pass odds on this firm's challenges (reference archetypes, same engine as luxalgo.com/prop-firms), use propfirms_pass_rates.

List the prop firms in the live LuxAlgo directory together with every simulatable challenge (challengeId, display name, account size, currency, price, and its rule-semantics provenance). Call this first to discover the firmId + challengeId pairs accepted by propfirms_challenge_rules, propfirms_simulate, propfirms_optimal_risk, propfirms_compare and propfirms_simulate_trades. Challenges whose loss-rule semantics cannot be established are listed under notSimulatable instead of being guessed. The listing is data, not endorsement: firms are alphabetical - no recommendation or ranking is implied, and none should be presented. DATA SOURCE & PROVENANCE: firm data comes live from LuxAlgo's public, keyless prop-firm directory API - the data behind luxalgo.com/prop-firms. 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. Without firmId the result is one line per firm (simulatable challenge count, account-size range, challenges that are not simulatable); with firmId it lists that firm's challenges with their ids. NOTE: this lists only the firms and challenges whose rules the engine can encode honestly. The full directory — every visible firm with platforms, prices, payout terms, and live offers/promo codes — is served by propfirms_search, propfirms_search_challenges, and propfirms_search_offers.

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. Results describe simulated outcomes of the user's own inputs under stated assumptions; they are not financial advice or a recommendation of any risk level.

Reference challenge pass rates computed live from the directory's encoded rules with the same engine, seed (42), path count (10,000) and reference archetypes luxalgo.com/prop-firms uses — per challenge and per archetype (developing 45% win rate / consistent 48% / proven edge 52%, all risking conservatively). Returns per-attempt pass probability with 95% CI, P(funded), expected attempts and total cost, EV, payout probability, funded-blowup probability, each cell's assumption flag ids, and the ruleset's provenance (structured directory columns vs fields inferred from listing text — always relay inferred fields). Deterministic per ruleset and cached — cheap to call. These are REFERENCE odds for orientation and comparison, not the user's personal odds: for their own statistics use propfirms_simulate (summary stats) or propfirms_simulate_trades (their real trade series). Not a ranking; a firm's page is authoritative for current rules (check lastVerified). Expected costs use the directory's listed challenge prices; full firm profiles and live offers are directory data (propfirms_get, propfirms_search_offers). Without challengeId the result is a firm overview: one account size per rules program (up to 3 programs) with every other simulatable challenge listed by id; a challengeId gives that challenge's exact numbers.

Search LuxAlgo's prop-firm catalog (proprietary trading firms offering funded accounts). Combine firm filters (platforms, markets, payment/payout methods, country availability, Trustpilot, year founded) with nested challenge filters (account size, price, steps, profit split, trading rules) and offer filters — a firm matches when at least one of its challenges/offers matches all of them. Omit every filter to list all firms. Use include to nest the matching challenges, live offers, and the written overview; for one firm's full dossier prefer propfirms_get. Uncaptured (null) fields are omitted from results; nested challenges reference offers via offerIds into the firm-level offers list. This tool returns directory data (what exists and on what terms), not outcomes: for simulated pass odds on a challenge found here, use propfirms_pass_rates or propfirms_simulate with its firm and challenge ids.

Search funded-account challenges across all visible prop firms. Filter by challenge rules (account size, fee, steps, profit split, drawdown mode, news/copy/auto trading, weekend holding, …) and by parent-firm properties. Pass propfirmId to list one firm's challenges, or challengeId to fetch specific ones. include=['offers'] returns a deduplicated top-level offers list, with each challenge referencing its applicable offers via offerIds (firm-wide offers included). Uncaptured (null) rule fields are omitted from results and never match filters. This returns each challenge's listed rules and terms, not outcomes: to simulate a challenge found here pass its ids to propfirms_simulate or propfirms_pass_rates, and to screen one strategy across many challenges at once use propfirms_validate_strategy.

Search promotional offers (discounts and promo codes) across prop firms — defaults to live (active, unexpired) offers only. propfirmId narrows to one firm; challengeId resolves the offers that apply to a challenge (firm-wide offers included). Every offer carries the promo code, discount, end date, and affiliate link.

Monte Carlo-simulate a trader with the given statistics through a prop-firm challenge and (by default) a funded horizon. Answers: "What is my chance of passing per attempt, and of ever getting funded? How many attempts and how much total money should I expect? Is this challenge positive expected value for me, and which rule actually kills my attempts?" 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. The trader is described by flattened parametric fields (one clean design used across all tools): winRate (a FRACTION 0-1), avgWinR/avgLossR and optional winStdR/lossStdR in R-multiples (sizes relative to the amount risked per trade), tradesPerDay with a 'fixed' or 'poisson' day model, and risk sizing via riskMode + riskValue (percent units for percent modes). If you have the user's raw trade series rather than summary stats, prefer propfirms_simulate_trades - it preserves streaks. Returns structuredContent with the full SimResult: perAttempt.passProbability with a Wilson 95% CI and per-step pass rates plus a failure breakdown by rule (daily-loss vs max-loss vs time-limit - which tells the user WHAT to fix); journey.fundedProbability, attempts and cost distributions (cost includes prices, resets, monthly billing, activation, minus refunds), costGivenFunded and daysToFunded; perAttempt.avgDaysWhenPassed/avgDaysWhenFailed and perAttempt.stagnationDays (the longest run of days without a new equity high per attempt - the dead time between progress, which grows sharply as risk per trade shrinks); funded-stage payout distributions plus funded.payoutProbability (P(at least one payout | funded)) and funded.daysToFirstPayout - with payout gating these can be the deciding numbers, since getting funded is not the same as getting paid; ev.evTotal (mean payouts minus costs) with evStandardError and pPositive; drawdown stats; and assumptions (the fully-resolved spec/profile/options the engine actually ran, plus flags and disclaimer). Histogram arrays are omitted unless includeHistograms=true. A compact human summary is returned as text alongside. SIMULATED RULES (engine v1): consistency rules (steps[].consistency) and funded payout gating (funded.payoutRules) are actually SIMULATED, not merely flagged. Consistency uses a rational stop rule (the trader stops a day once more profit cannot help and keeps trading until the best-day share complies - flag 'consistency-stop-rule'); payouts follow a maximum-withdrawal model (withdraw everything the rules allow above buffer/caps, never below the loss floor; balances and floors carry across payouts - flag 'funded-withdrawal-model'); a funded consistency gate is checked per payout window (flag 'funded-consistency-window-approximated'). 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. DATA SOURCE & PROVENANCE: firm data comes live from LuxAlgo's public, keyless prop-firm directory API - the data behind luxalgo.com/prop-firms. 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.

Simulate a challenge by resampling the trader's OWN R-multiple trade series with a stationary block bootstrap instead of a win-rate model. Why resampling matters: challenge rules are breached by streaks, not by averages - a daily-loss limit dies to a cluster of losses inside one day, and a trailing drawdown dies to a losing streak right after an equity peak. Real trade series are streaky (autocorrelation, volatility clustering, edge that comes and goes), and the stationary bootstrap resamples contiguous blocks of the actual series (geometric length, mean blockMeanLength, default 5 trades), so the trader's real streak structure survives into every simulated day. A parametric model with identical summary statistics shuffles trades independently and therefore understates breach risk for streaky traders. Use propfirms_simulate when only summary stats are available; use this whenever the actual trades are. Provide the series as rSeries (array of R-multiples: each trade's P&L divided by the amount risked on it), rSeriesText (pasted JSON/CSV/whitespace text, optional 'R' suffix per value), or one of the timestamped-log inputs below; exactly one of the four, at least 10 trades, 100+ strongly recommended. Returns the same full SimResult as propfirms_simulate (structuredContent, histograms off by default) plus a text summary that also reports the sample's win rate and mean R. TIMESTAMPED LOGS: tradeLogText accepts a pasted CSV/TSV trade log with a header row (open time and R required; close time and direction optional; loose header names are matched; timestamps without an offset are read as UTC). The R-series and, unless tradesPerDay is passed, the trades-per-day rate are derived from the log, and parse warnings are surfaced in the text output. NEWS WINDOWS: with a timestamped input, newsFilter runs the simulation TWICE on the same seed and options, once on the full history and once without the trades opened inside configurable windows around scheduled releases (a built-in recurring-template calendar of high- and medium-impact events across USD, EUR, GBP, JPY, AUD, CAD, CHF, NZD, plus optional custom event times). The returned SimResult is the news-avoided scenario; structuredContent.newsComparison carries both scenarios' pass probability, funded probability and EV, the excluded-trade count, and a calendar caveat that must be relayed verbatim. PORTFOLIO MODE: tradeLogTexts (2 to 5 logs) merges several timestamped histories into one chronological series and simulates the combined account, so cross-strategy loss clustering survives. Overlap across the histories is ALWAYS analyzed and attached as structuredContent.portfolioOverlap; the text summary carries the audit-risk verdict, and a 'high' verdict is an explicit warning that a prop firm may audit or refuse payouts for correlated accounts. SIMULATED RULES (engine v1): consistency rules (steps[].consistency) and funded payout gating (funded.payoutRules) are actually SIMULATED, not merely flagged. Consistency uses a rational stop rule (the trader stops a day once more profit cannot help and keeps trading until the best-day share complies - flag 'consistency-stop-rule'); payouts follow a maximum-withdrawal model (withdraw everything the rules allow above buffer/caps, never below the loss floor; balances and floors carry across payouts - flag 'funded-withdrawal-model'); a funded consistency gate is checked per payout window (flag 'funded-consistency-window-approximated'). 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.

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

The Market Trackers catalog: every dataset of US public-record market data the LuxAlgo pipeline publishes as CC0 dumps — congressional trades, insider (Forms 3/4/5) transactions, 13F holdings, federal contracts and grants, lobbying filings, FINRA short-sale volume, granted patents, clinical trials, FDA drug events, CFTC positioning, federal bills, FEC campaign finance, hearing transcripts, Federal Reserve communications, committee assignments, Wikipedia pageviews. Returns each dataset's row count, freshness, the years with data (live tree vs deep-history archives), and whether it is ticker-searchable. Pass dataset for the full field roster, filterable paths, caveats, per-year coverage, source health, and dump URLs — read it before composing trackers_query filters.

What the last daily publish added to one dataset — the newest ingestion day's rows (the dumps' latest.json), optionally narrowed by ticker or text. The cheapest way to see what is new: today's insider filings, this week's congressional disclosures, the latest lobbying registrations. Not available for snapshot-only bulk datasets (patents); use trackers_query there.

Search one Market Trackers dataset by ticker, free text, exact field values, and event-date range, with paging and newest/oldest ordering. Data is read from year-sharded CC0 dumps: pass years (or since/until) to choose which years to read — default is the newest year with data. Deep-history years (see archiveYears in trackers_datasets) can be tens of MB compressed each, so read them one or two at a time; the tool refuses selections over its byte budget and says how to narrow. Every row carries provenance.sourceUrl (the SEC filing, disclosure, award, or record it came from). Examples: insider purchases at NVDA in 2024 → dataset insider-transactions, ticker NVDA, years [2024], where {code: 'P'}; a member of Congress's trades → congress-trades, text set to their name; who lobbied on a bill → lobbying-filings, text 'H.R.1234'.

One ticker across every ticker-bearing Market Trackers dataset for one year (default: the current year): insider transactions, congressional trades, 13F holdings, federal contracts and grants, lobbying filings by the company, short-sale volume, clinical trials, FDA events, patents, Wikipedia pageviews. Returns per-dataset match counts with the newest rows of each — a public-record dossier from primary sources. Deep-history archive years too large for one fan-out are listed under skipped with the trackers_query call that reads them.

Adds markets to one of the signed-in member's watchlists (its id from watchlists_list), at the end of the list or in a named section; a market already in the list is left as it is. Returns the list as saved, in words, with a Vela chart link per added market. How many watchlists and symbols per list the member may have comes from their LuxAlgo plan: at a limit the call answers with the limit and where to upgrade, and nothing is saved. It changes the member's account, so the chat app may ask the user to confirm first. Requires signing in with a LuxAlgo account (OAuth).

Creates a new watchlist in the signed-in member's account, optionally with its first symbols; it shows up in Vela on the web and in the Vela apps. Use watchlists_add_symbols to add to a list that exists. How many watchlists and symbols per list the member may have comes from their LuxAlgo plan: at a limit the call answers with the limit and where to upgrade, and nothing is saved. It changes the member's account, so the chat app may ask the user to confirm first. Requires signing in with a LuxAlgo account (OAuth).

The signed-in member's watchlists, the same lists Vela shows on the web and in the Vela apps: each list's id and name with every symbol in it, as the market it streams (source:TICKER), its category and section, and a Vela chart link (chart_url). Use it to answer what the member watches, and before watchlists_add_symbols or watchlists_remove_symbols to get a list's id. It carries no prices. An empty answer means the member has no watchlist yet (watchlists_create makes one). Requires signing in with a LuxAlgo account (OAuth).

Removes markets from one of the signed-in member's watchlists (its id from watchlists_list). Name each one as watchlists_list shows it (source:TICKER) or by its bare symbol ("AAPL", "BTCUSD"), which removes every row of that symbol. The list itself stays; this server cannot delete a watchlist. Returns what was removed and what was not found. It changes the member's account, so the chat app may ask the user to confirm first. Requires signing in with a LuxAlgo account (OAuth).