Call this FIRST when you don't know which FLOX MCP tool to use. Returns a Markdown narrative of the toolkit organised by category (discovery, building a backtest, live engine inspection, calibration), with canonical workflows for the most common tasks and a recent-additions section. No arguments. Cheap; pure bundled text. Cuts the AI-agent cycles spent rediscovering what the surface is on every fresh session.

List every indicator exposed by the FLOX Python binding with its class signature, batch function (if any), and shape (single-input scalar, OHLC tuple, multi-output, …). Use this when the user asks 'what indicators does FLOX support' or before suggesting an indicator name.

Resolve a FLOX error code (e.g. 'E_SYM_001') to its full Markdown documentation page — fix recipe, common causes, diagnostics. Use whenever a FloxError is raised in user code; never guess at a fix from the message alone.

Search the FLOX C-API surface from the committed ABI snapshot. Returns name + return type + parameter types for every exported flox_* function. Use when the user is writing FFI code (Codon, QuickJS, Rust cgo, ctypes) or asks 'what C symbols can I call'.

Static-analysis check on a Python FLOX strategy: AST parses, expected hooks present (on_trade / on_bar), no forbidden patterns (eval, exec, import tricks). Use this before running user-authored strategy code. Does NOT execute the code.

Describe the fields of a FLOX event struct. Accepts a type name ('FloxTradeData', 'FloxBookData', 'FloxBarData', 'FloxSymbolContext', 'FloxSignal') OR a raw event dict; returns each field's name, type, units, and human description. Use when the user asks 'what's in this event'.

Resolve a FLOX symbol across every binding (C-API, Python, Node, Codon). Returns the local name, kind, and signature for each binding that exports it. Use this whenever the user names a struct, function, or indicator and you need to know what it's called in their language — never guess at the cross-language spelling. Accepts any spelling the user knows ('FloxBarData', 'BarData', 'flox_indicator_ema', 'ema', 'Ema'). Filter to one language with the language arg if the user is writing in a specific binding. When the symbol has hand-curated semantic gotchas (silent quantization, ordering preconditions, subscribed-vs-registry distinctions), they appear under a ## Gotchas section in the response.

Enumerate the public exports of one FLOX binding surface (C-API / Python / Node / Codon / QuickJS). Use this when the user asks 'what does the {Python|Node|Codon} binding expose?' or when they want to browse a binding before picking a symbol. Substring filter is case-insensitive.

Return canonical FLOX example code for a topic, filtered optionally by language. Use this when the user asks 'show me how to {backtest|connect to ccxt|wire an indicator}' BEFORE writing fresh code from memory — the bundled examples are CI-validated, your generated code is not. Topics: strategy, connector, indicator, event-handler, risk, backtest. Languages: python, node, codon, cpp.

Return a starter FLOX strategy class that compiles and passes validate_strategy. Use this as the first thing you write when the user asks to 'build a new strategy' — start from this canonical shell, then edit the indicator + signal logic, instead of writing the FLOX bookkeeping (constructor, hook names, signal builder) from memory. language is required — FLOX is polyglot and picking the binding for the user is wrong; ask which language they want first. Supported: python, node, codon, quickjs. Three kinds: bar-driven (TA on bar close), trade-driven (tick-by-tick), hybrid (both). The result includes a Next steps section with docs_search queries for the recording / backtest / layout follow-ups; follow them in order.

Create a new FLOX project from a bundled template. Thin wrapper around the canonical flox new CLI — the CLI stays the source of truth, this tool only makes it discoverable from MCP. Use when the user asks 'set up a new flox project' / 'I want to scaffold a research notebook' / 'start a live trading bot'. Three templates ship with flox-py: research (notebook + sample data + main.py), live (CCXT broker + dry-run safety harness), indicator-library (standalone indicator package with tests). Result includes the CLI output and a Next steps section with docs_search queries.

Capture market data into a .floxlog tape. Wraps the canonical recording paths — for mode=live shells out to the flox tape record CLI; for mode=historical shells out to scripts/backfill_to_tape.py which uses ccxt's fetch_ohlcv / fetch_trades. Use this when the user asks to 'record some BTC data' / 'pull a month of klines for backtest' / 'tape the last hour of trades'. The result is a .floxlog directory drivable by BacktestRunner.run_tape.

Run a Python FLOX strategy against a CSV dataset in a sandboxed subprocess (rlimits on CPU / memory / output size + a wall-clock timeout). Use this when the user asks 'try this strategy on my data' or 'does this code actually work'. Treat as MVP sandbox: it caps resources but does NOT isolate the filesystem or network — never aim it at untrusted code outside a developer's own machine. Returns the backtest stats dict as JSON plus any stdout the strategy printed.

Dispatch routing: the worker introspects the strategy class. If on_bar is overridden the dataset is dispatched as real BarEvents through run_bars (CSV columns: ts,open,high,low,close,volume); otherwise the rows are synthesised into trades for on_trade via run_csv. A strategy that overrides neither hook fails loudly.

Run a single FLOX indicator over a list of floats and return the output. Use this to sanity-check an indicator's behaviour on a small price array BEFORE wiring it into a strategy — especially when the indicator has window / period / smoothing parameters whose effect isn't obvious from the name. Input is capped at 1 MiB. Requires the optional flox-py dependency.

Recommend FLOX indicators for an English description of the user's intent ('trend filter', 'momentum oscillator', 'volatility band', 'mean revert', 'regime test'). Use this when the user describes what they want without naming an indicator — the tool maps phrasing to a ranked shortlist of real FLOX indicators. Pure keyword heuristic; no LLM call. Always confirm shape with list_indicators after picking one.

Top-k full-text search over the FLOX documentation (how-to guides, reference pages, tutorials, error codes, bindings overviews, explanations). Use this to ground answers about FLOX behavior, configuration, or APIs in the actual docs instead of relying on training data — call it whenever the user asks 'how do I X' / 'what does Y do' / 'where is Z documented'. The index is built from a strict allowlist; private tracker / strategy / author files are NEVER indexed.

Query syntax: plain word lists are AND-matched (every token must appear). Wrap a phrase in double quotes for exact match: "walk forward". FTS5 operators (OR, NEAR, *, parens) pass through.

Canonical workflow queries (run these instead of guessing the canonical path from training data): • User wants to record market data → docs_search('record tape'). Covers live capture and the ccxt.fetch_ohlcv historical-backfill pattern. • User asks 'how should I structure a flox project' → docs_search('project layout'). • User mentions an exchange / live data → docs_search('ccxt'). • User wants to backtest a strategy on a recorded tape → docs_search('backtest'). • User mentions strategy traces, signals, or .floxrun → docs_search('floxrun').

Read positions from a running flox engine via its runtime state snapshot. Use this when the user asks 'what's in my positions' / 'show me the BTC position' / 'is strategy X long or short'. Returns a JSON object {snapshot_age_ms, data:[{account, strategy, symbol_id, symbol_name, qty, avg_price, unrealized_pnl}, ...]}. Snapshot path is FLOX_RUNTIME_STATE env var or the passed state_path; the user app is responsible for writing the snapshot. When no engine has written a snapshot yet, returns {engine: 'not_running', data: [], hint: ...} instead of an error — that's a normal pre-engine state, not a problem to surface to the user. Read-only — never modifies state.

Read in-flight orders from the runtime state snapshot. Use this for 'what orders are pending' / 'do I have anything sitting on Bybit'. Optional substring filter matches against symbol_name or strategy. Returns the engine_not_running idle response when no snapshot is present yet (no error). Read-only.

Read PnL totals plus per-strategy breakdown from the runtime state snapshot. Use this for 'what's my PnL' / 'how is strategy X doing today'. Returns realized + unrealized + fees per strategy. Returns the engine_not_running idle response when no snapshot is present yet (no error). Read-only.

Read kill-switch state from the runtime state snapshot. Returns {active, reason, since_ns}. Use this for 'is trading halted' / 'why was the kill switch tripped'. When no engine has written a snapshot, returns the idle response with active=false (there is no live trading to halt). Read-only — to flip the switch use set_kill_switch.

Place an order through the user's running flox engine. Talks HTTP to the local ControlServer the user app embeds; reads URL + bearer token from FLOX_CONTROL_URL and FLOX_CONTROL_TOKEN. Default dry_run=true; the server simulates acceptance without dispatching to the executor. live tier additionally requires an approve_token issued out of band by the operator. Use this for manual hedges or operator-driven order entry.

Cancel one open order by id. Talks HTTP to the local ControlServer. Default dry_run=true. Useful for operator-driven cleanup or panic stop.

Cancel every open order, optionally filtered by symbol. Default dry_run=true. The most common 'panic stop' primitive after set_kill_switch.

Close every open position with opposite-side market orders, optionally filtered by symbol. Default dry_run=true. Use for 'close everything' operator actions or end-of-day flatten.

Set the engine's kill-switch state. active=true halts all trading; active=false resumes. Default dry_run=true; explicit dry_run=false applies the change. Use for emergency halt and for resuming after manual review.

List the strategies the running flox engine knows about, with name, status, and the symbols each one subscribes to. Read-only. Use when the user asks 'what's running' / 'which strategies are active'.

Return one strategy's current state as a JSON dict — params, position view, last decisions. Read-only. Use when the user asks 'what does strategy X think right now' / 'show me state for ema-trend'.

Return the live values of indicators inside a strategy. Optional name filter narrows to one indicator. Read-only. Use for 'what's the EMA reading' / 'is the RSI overbought now'.

Query the engine event log (signals emitted, orders placed, fills received, risk checks). Filters AND-compose. Read-only. Use for 'what happened in the last 5 minutes' / 'show me all the signals from ema-trend'. Default limit 100.

Walk an event's causal-parent chain back toward the root. Returns the chain in order from the requested event to its root. Use when the user asks 'why did this fill happen' / 'trace the cause of order 42' — the chain shows which signal produced the order, which event triggered the signal, etc.

Run a sandbox replay over a time window. The engine side decides what 'replay' means: typical setups use the bundled tape primitives to drive a SimulatedExecutor over a tape slice. Read-only (sandbox-only mutations). Use for 'replay the last hour' / 'rerun this period in sandbox'.

Counterfactual replay: same as replay_window plus a strategy-name filter and required param_overrides. Use for 'what if EMA period was 50 instead of 21' / 'show me the PnL if I had used a wider stop'.

Static-analysis check for the most common backtest bug: lookahead bias. Walks the strategy code's AST and flags negative .shift(N), forward-index arithmetic like df.iloc[i+1], open-upper slices inside per-bar callbacks, and attribute names that look future-dated (next_, future_, lookahead_*). Heuristic, not a proof — false negatives are possible. Run before trusting any backtest result.