The flox-mcp server gives AI agents grounded, tool-driven access to the FLOX trading framework—covering discovery, strategy development, backtesting, live engine control, and DeFi analytics—without relying on training data.
Discovery & Documentation
flox_overview – High-level toolkit orientation and canonical workflows
docs_search – Full-text search across all FLOX documentation
list_indicators / suggest_indicator – Browse or find indicators by description
lookup_symbol – Resolve symbols across all language bindings (Python, Node, C-API, etc.)
list_bindings / list_capi_functions – Browse exports and C-API surface
lookup_error_code / explain_event – Resolve error codes and event struct fields
Strategy Development & Validation
scaffold_strategy – Generate starter strategy classes (bar-driven, trade-driven, or hybrid) in Python, Node, Codon, or QuickJS
init_project – Create a new FLOX project from a template
get_example – Retrieve CI-validated example code (backtest, connector, indicator, etc.)
validate_strategy – Static AST analysis for hooks and forbidden patterns
validate_strategy_no_lookahead – Detect lookahead bias before trusting backtest results
Data & Backtesting
record_data – Capture live or historical market data into a .floxlog tape
run_backtest – Run a Python strategy against a CSV in a sandboxed subprocess
compute_indicator – Run a single indicator over a price array
Live Engine Inspection (Read-Only)
get_positions, get_open_orders, get_pnl – Read runtime state snapshots
get_kill_switch – Check if trading is halted and why
list_strategies / get_strategy_state – List strategies and inspect their state
get_indicator_values – Live indicator readings inside a running strategy
get_event_log / explain_decision – Query events and trace causal chains (e.g., why a fill happened)
Live Engine Control (Write, dry-run by default)
place_order, cancel_order, cancel_all – Order management
flatten_positions – Close all open positions with market orders
set_kill_switch – Halt or resume all trading
Replay & Counterfactuals
replay_window – Sandbox replay over a time window with optional param overrides
whatif – Counterfactual replay to test "what if" parameter scenarios
DeFi / AMM Analytics
price_amm_swap – Price a DEX swap (Uniswap v2/v3, Raydium CP) at wei-level precision
route_amm_swap – Find best execution across multiple AMM venues
amm_price_impact – Generate a slippage/depth table across trade sizes
replay_pool_tape – Backtest a DEX LP position by replaying recorded swap history
Implement and run trading strategies via the embedded JavaScript (QuickJS) binding of the FLOX framework. Includes scaffolding support.
Develop and execute trading strategies using Node.js bindings of the FLOX framework. Supports scaffolding and strategy execution.
Run and backtest trading strategies using Python bindings of the FLOX framework. Provides tools for scaffolding strategies, running sandboxed backtests on CSV data, and executing live strategies.
lrvx is a framework for building trading systems.
Strategies, backtests, paper trading, and live execution sit behind one toolkit. AI agents discover the surface and drive it end-to-end through an MCP control plane. One strategy class runs backtest, paper, and live. Bindings for Python, Node.js, Codon, embedded JavaScript, and a stable C API.
Documentation is available at docs.lrvx.dev
Related MCP server: TradingMCP
Language | Install | Docs |
Python |
| |
Node.js |
| |
Codon | build from source | |
JavaScript (embedded) | bundled with C++ build | |
C API |
|
All bindings expose the same strategy API, indicators, order books, backtesting, and data I/O. The C API is the integration point for adding support for any other language.
lrvx-mcp is a Model Context Protocol server that gives AI coding agents (Cursor, Claude Code, Cline) grounded access to the lrvx surface — symbol lookups across bindings, scaffolders, indicator and backtest tools, full-text doc search.
pip install lrvx-mcpSee the package README for setup and the full tool list.
Native exchange connectors (Bybit, Bitget, Hyperliquid, Polymarket) live under connectors/ and build with -DLRVX_BUILD_CONNECTORS=ON. The flag defaults to OFF so a backtest-only or research build doesn't pay the dependency cost. See the connectors README for adapter notes and the optional Polymarket Rust toolchain step.
Beyond trading on a market, lrvx can be one: the optional venue/ module adds a matching engine and the machinery around it, so many participants can trade against a single order book. See the venue docs.
The CMake options that gate every optional artefact (bindings, demo, tools, tests, benchmarks, connectors) are catalogued in docs/build/feature-flags.md. Defaults are OFF so a bare cmake -B build produces only the core C++ static library.
For commercial support, enterprise connectors, and custom development, visit lrvx.dev/services.
Contributions are welcome via pull requests.
Please follow the existing structure and naming conventions.
Tests, benchmarks, and documentation should be included where appropriate.
Code style is enforced via clang-format. See contributing guide.
lrvx is licensed under the MIT License. See LICENSE for details.
lrvx is provided "as is" without warranty of any kind, express or implied. The authors are not liable for any damages or financial harm arising from its use, including trading losses or system failures. This software is intended for educational and research purposes. Production use is at your own risk. See DISCLAIMER.md for full legal notice.
The depth / slippage table for one AMM pool: the realized average price and price impact for each of a list of trade sizes, exact to the wei. Use this to reason about how large a trade a pool can absorb before quoting. Sizes are human 'NUMBER SYMBOL' strings. Requires the optional lrvx dependency.
| Name | Required | Description | Default |
|---|---|---|---|
| pool | Yes | A pool spec: {venue, token0:{symbol,decimals}, token1:{symbol,decimals}, ...venue params}. | |
| sizes | Yes | Trade sizes as 'NUMBER SYMBOL' strings. |
Cancel every open order, optionally filtered by symbol. Default dry_run=true. The most common 'panic stop' primitive after set_kill_switch. account is required and gated the same way as place_order: paper scope may only target paper-prefixed accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | 0 (default) cancels across all symbols. | |
| account | Yes | Account whose orders to cancel. paper-prefixed names are allowed in paper scope; live scope is required for any other. | |
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the dry_run default (important for safety), and mentions account gating rules. However, it does not state what happens in live mode, whether the operation is reversible, or what the response format is. For a mutation tool, this is a moderate gap, but the dry_run default is a significant behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are dense with purposeful information: the core action, the filter, the critical default, and the context/usage. Every phrase earns its place, and the most important detail (dry_run default) is mentioned early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description covers the essential context: purpose, filter, default behavior, and account gating. It does not mention return values or error semantics, but given the tool's simplicity and the presence of situational context (panic stop), it is reasonably complete. A more detailed description could note expected outcome, but this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (dry_run is not described in the schema). The description adds value by specifying the dry_run default and explaining the account scope rules more clearly than the schema. It also clarifies that symbol=0 means 'all symbols'. These details go beyond the schema's basic descriptions, partially compensating for the undocumented dry_run parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel every open order') and the optional filter ('optionally filtered by symbol'), with a specific verb and resource. It also differentiates from the sibling cancel_order by implying batch scope and positions itself relative to set_kill_switch, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool ('panic stop' after set_kill_switch) and explains the account gating variation from place_order. It does not explicitly contrast with cancel_order, but the phrase 'cancel every open order' makes the broad-vs-single distinction clear. The guidance is solid but could be more explicit about not using it for single-order cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel one open order by id. Talks HTTP to the local ControlServer. Default dry_run=true. Useful for operator-driven cleanup or panic stop. account is required and gated the same way as place_order: paper scope may only target paper-prefixed accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | Account the order belongs to. paper-prefixed names are allowed in paper scope; live scope is required for any other. | |
| dry_run | No | ||
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It discloses 'Default dry_run=true' and 'Talks HTTP to the local ControlServer', which adds useful behavioral context. But it never explicitly states that when dry_run=false the order is actually cancelled, nor does it mention side effects or return behavior – a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, each adding value. The purpose is front-loaded, followed by implementation, default, use case, and a constraint. While not as tight as a two-sentence example, there is no fluff and it reads efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation tool with no annotations and no output schema, it covers the essential purpose, default behavior, and account constraints. However, it does not clarify what happens when dry_run=false (presumably real cancellation) or the result/error behavior, leaving an agent uncertain about the tool's actual effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only account is described). The description compensates by clarifying order_id as the target ('by id'), dry_run default behavior, and account gating rules. This adds meaningful semantics beyond the bare schema, though it does not fully describe each parameter's acceptable values or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Cancel one open order by id' – a specific verb, resource, and scope. It clearly differentiates from siblings like cancel_all by emphasizing a single order and the 'open' status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: 'Useful for operator-driven cleanup or panic stop' and explains account gating similar to place_order. However, it does not explicitly mention alternatives like cancel_all for bulk cancellation, so it lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a single lrvx 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 lrvx dependency.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Input series (e.g. close prices). Up to 125k samples. | |
| name | Yes | Indicator name in lrvx — case either matches the class (`EMA`, `RSI`, `Bollinger`) or the function (`ema`, `rsi`, `vwap`). |
Top-k full-text search over the lrvx documentation (how-to guides, reference pages, tutorials, error codes, bindings overviews, explanations). Use this to ground answers about lrvx 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 lrvx 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 .lrvxrun → docs_search('lrvxrun').
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of results to return (1..25). Default 5. | |
| query | Yes | Free-text query. Plain word lists are AND-matched. Wrap a phrase in double quotes for exact match. |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | ||
| max_depth | No | Stop walking after this many parents. Default 32. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly states that it walks the causal-parent chain to the root and returns the chain in order. It omits edge cases (e.g., missing root, cycles) and performance characteristics, but for a read-only traversal tool the core behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and result, followed by practical usage examples. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return value ('chain in order from requested event to its root') and gives a concrete walk-through example. It does not detail the shape of each chain element, which would improve completeness, but it is sufficient for a straightforward traversal tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 'max_depth' with a description and default, but 'event_id' has no schema-level description. The description adds conceptual meaning ('the requested event', causal-parent chain) but does not specify the format or expected identifier style for event_id. Schema coverage is 50%, and the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific verb ('Walk an event's causal-parent chain back toward the root') and resource ('event's causal-parent chain'), and explains the output ordering. It does not explicitly contrast with the sibling tool 'explain_event', leaving some ambiguity about when to choose one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use cases ('why did this fill happen', 'trace the cause of order 42') and explains what the chain reveals. However, it offers no explicit when-not-to-use guidance or alternatives, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the fields of a lrvx event struct. Accepts a type name ('LrvxTradeData', 'LrvxBookData', 'LrvxBarData', 'LrvxSymbolContext', 'LrvxSignal') 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'.
| Name | Required | Description | Default |
|---|---|---|---|
| event | No | Optional event dict to introspect. If type_name is omitted, the dict's shape is matched against known struct shapes. | |
| type_name | No | Event struct name. One of: LrvxTradeData, LrvxBookData, LrvxBarData, LrvxSymbolContext, LrvxSignal. |
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. account is required and gated the same way as place_order: paper scope may only target paper-prefixed accounts, and rows the positions accessor tags with a different account are skipped.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Restrict to one symbol; omit to flatten all. | |
| account | Yes | Account whose positions to flatten. paper-prefixed names are allowed in paper scope; live scope is required for any other. | |
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and largely delivers: it discloses the dry_run default, the paper/live account gating rule inherited from place_order, and that mismatched-account rows are skipped. It stops short of explaining what dry_run=true versus false returns or the side effects of a live flatten, so it is not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, then default behavior, then when-to-use and constraints. Every sentence carries information, with no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple flatten action it covers the core invocation concerns: what it does, when to use it, required-account constraints, filtering, and dry-run default. It lacks output/error behavior, but there is no output schema and the tool is simple enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents symbol and account, and the description adds meaning beyond it: dry_run defaults to true, account is required with the same gating as place_order, and mismatched rows are skipped. The uncovered dry_run parameter therefore gets useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence is specific: 'Close every open position with opposite-side market orders, optionally filtered by symbol' names the verb, the resource (positions), and the mechanism. It is clear enough that an agent will not confuse it with pure order-cancellation tools, though it does not explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use for ‘close everything’ operator actions or end-of-day flatten.' It does not list alternatives or when-not-to-use cases, but the ‘close everything’ framing provides a clear selection signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Event type filter (e.g. 'signal', 'order', 'fill', 'risk_check'). | |
| limit | No | Max records to return. Default 100. | |
| strategy | No | ||
| to_ts_ns | No | ||
| from_ts_ns | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States read-only nature and mentions filters AND-compose and default limit 100. No annotations provided, so description carries the burden; it covers key behavioral traits but lacks details on pagination or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with examples, front-loaded with purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main use cases and parameter behavior, but without output schema, it does not explain return values. Time range parameter format is not clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%; description adds context like 'Filters AND-compose' and 'Default limit 100', but does not elaborate on strategy, from_ts_ns, or to_ts_ns beyond being filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'query' and the resource 'engine event log', listing event types (signals, orders, fills, risk checks). It clearly distinguishes from sibling tools like get_open_orders or get_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('what happened in the last 5 minutes', 'show me all the signals from ema-trend') but does not explicitly state when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return canonical lrvx 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.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic. One of: strategy, connector, indicator, event-handler, risk, backtest. | |
| language | No | Optional language filter. One of: python, node, codon, cpp. |
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional: filter to one indicator. | |
| strategy | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states the tool is read-only, a key behavioral trait. No annotations provided, so the description carries the burden; it does so well by clarifying the live nature of the data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states the core function, second gives usage examples. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers purpose, filtering, read-only nature, and use cases. Does not mention error handling for invalid strategies, but that's acceptable for this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 50% description coverage; only 'name' has a description. The description adds context for 'name' ('filter to one indicator'), which matches the schema. The 'strategy' parameter is not elaborated, but the description doesn't need to repeat the schema; it adds some value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live values of indicators in a strategy, with an optional name filter. It distinguishes from siblings like 'compute_indicator' and 'list_indicators'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete examples like 'what's the EMA reading' and 'is the RSI overbought now', guiding the agent on when to use it. Doesn't explicitly mention alternatives, but the examples are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| state_path | No | Override snapshot path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the return shape {active, reason, since_ns}, the idle fallback when no snapshot exists, and the read-only nature. This goes beyond the minimum and clearly explains runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding distinct value: action and output, usage scenarios, and edge case plus sibling alternative. No redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter, the description covers purpose, return values, fallback behavior, and relationship to the sibling tool. The return shape is stated inline, so no output schema is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the state_path parameter is already fully documented. The description adds minor context by implying state_path is an override to the runtime snapshot, but this is not substantial enough to exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads kill-switch state from the runtime state snapshot with a specific verb and resource. It distinguishes from the sibling set_kill_switch by explicitly noting 'to flip the switch use set_kill_switch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage scenarios are given: 'is trading halted' and 'why was the kill switch tripped'. It also provides guidance on when not to use it (use set_kill_switch instead) and explains the no-snapshot edge case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Case-insensitive substring matched against symbol_name or strategy. | |
| state_path | No | Override snapshot path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is read-only and describes the special response when the engine is not running. This is good behavioral context, though it could be more thorough about normal return behavior or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each adding value: purpose, usage guidance, and a behavioral note. It is front-loaded and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, usage, and a specific edge case (engine not running), but fails to describe the normal return structure. Since no output schema is present, the description should explain what the successful response contains (e.g., list of orders, fields). This gap lowers completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for both parameters. The description merely rephrases the filter parameter without adding new meaning, so it meets the baseline but does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read in-flight orders from the runtime state snapshot,' providing a specific verb and resource. It also gives usage examples like 'what orders are pending,' which solidifies the purpose and distinguishes it from mutation tools like cancel_order or place_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this for what orders are pending / do I have anything sitting on Bybit.' It does not explicitly list when not to use or alternatives, but the context is clear given the sibling tool names and the read-only nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy | No | Filter the per-strategy breakdown to one row; total still reflects the full snapshot. | |
| state_path | No | Override snapshot path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses read-only nature, the output structure (realized + unrealized + fees per strategy), and an error behavior (engine_not_running idle response when no snapshot). This fully compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences covering purpose, usage, and behavior. No fluff, every sentence serves a purpose. Front-loaded with the core action in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return values and error case. No output schema, but description compensates by listing realized/unrealized/fees. Doesn't mention output format or limits, but for a simple snapshot read, it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that filtering by strategy only affects the breakdown, not the total ('total still reflects the full snapshot'). This nuance is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read PnL totals plus per-strategy breakdown' and gives concrete query examples ('what's my PnL', 'how is strategy X doing today'). It distinctly identifies the resource (runtime snapshot) and the action (read). Among 30+ sibling tools, none overlap in purpose, making it easily distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use: 'for what's my PnL / how is strategy X doing today'. It doesn't list alternatives or when NOT to use, but the context is strong enough for correct selection. Lacks explicit sibling differentiation, but the use case is narrow enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read positions from a running lrvx 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 LRVX_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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Filter to one account. | |
| strategy | No | Filter to one strategy. | |
| state_path | No | Override snapshot path (defaults to LRVX_RUNTIME_STATE or /tmp/lrvx-runtime-state.json). |
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states 'Read-only' (implying no side effects) and describes the output format. This is adequate transparency for a simple state retrieval tool. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the action and output. Every part adds value: the verb, the output type, contents, read-only nature, and example prompts. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description sufficiently covers purpose, parameter (via example), and return structure (JSON dict with listed fields). No further context is needed given the simplicity and sibling tool landscape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no parameter descriptions in schema), so the description must compensate. It implies the single 'name' parameter is the strategy identifier via the example 'ema-trend'. While not explicitly stating the parameter's meaning, the example and context make it sufficiently clear. Baseline for zero-param schema coverage is 4, and this meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a strategy's current state as a JSON dict, specifying included fields (params, position view, last decisions). It also provides concrete usage examples ('what does strategy X think right now'), which distinguish it from sibling tools that handle orders, indicators, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates read-only usage and provides user query examples, implying when to call the tool. However, it does not explicitly exclude cases where other tools (e.g., get_positions) might be preferred, nor does it mention prerequisites like the strategy must exist. The guidance is good but lacks explicit boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new lrvx project from a bundled template. Thin wrapper around the canonical lrvx 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 lrvx project' / 'I want to scaffold a research notebook' / 'start a live trading bot'. Three templates ship with lrvx: 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.
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | Template to scaffold from. Required. | |
| target_dir | No | Parent directory the project is created under. Default: current working dir. | |
| project_name | Yes | Directory name for the new project. Created under `target_dir`. Special characters in the name become snake_case in the bundled `__PROJECT_SLUG__`. |
Enumerate the public exports of one lrvx 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entries to return. Default 50. | |
| filter | No | Optional substring filter on symbol name. | |
| language | Yes | Binding surface. One of: capi, python, cpp, capi, python, node, codon, quickjs. |
Search the lrvx C-API surface from the committed ABI snapshot. Returns name + return type + parameter types for every exported lrvx_* function. Use when the user is writing FFI code (Codon, QuickJS, Rust cgo, ctypes) or asks 'what C symbols can I call'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entries to return. Default 50. | |
| filter | No | Optional substring filter on function name. |
List every indicator exposed by the lrvx 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 lrvx support' or before suggesting an indicator name.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional substring filter; case-insensitive. |
List the strategies the running lrvx 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'.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Resolve a lrvx error code (e.g. 'E_SYM_001') to its full Markdown documentation page — fix recipe, common causes, diagnostics. Use whenever a LrvxError is raised in user code; never guess at a fix from the message alone.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Error code, e.g. 'E_SYM_001'. Case-sensitive. |
Resolve a lrvx symbol across every surface (C++, C-API, Python, Node, Codon, QuickJS). Methods resolve too, reported as Owner.method. 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 ('LrvxBarData', 'BarData', 'lrvx_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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Symbol name in any binding's spelling. Case-sensitive; common transformations (Lrvx prefix, lrvx_indicator_ prefix) are tried automatically. | |
| language | No | Optional binding filter. One of: capi, cpp, capi, python, node, codon, quickjs. |
Call this FIRST when you don't know which lrvx 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Use when the user wants to BUILD A MARKET rather than trade on one: simulate several agents/strategies against one shared order book, model market impact with reacting counterparties, or run a matching engine, clearing ledger, margin/liquidation, market-data feed or venue gateway. Returns a Markdown guide to the optional lrvx venue module (lrvx::venue): headers, order vocabulary, derivatives waterfall, the multi-agent demo, build flag, and verification posture. No arguments. Cheap; pure bundled text. NOT for an ordinary single-strategy backtest over historical data -- use run_backtest.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Place an order through the user's running lrvx engine. Talks HTTP to the local ControlServer the user app embeds; reads URL + bearer token from LRVX_CONTROL_URL and LRVX_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.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | Yes | ||
| side | Yes | ||
| type | No | Default market. | |
| price | No | Required for limit orders; ignored for market. | |
| reason | No | Free-text annotation recorded in the audit log. | |
| symbol | Yes | ||
| account | Yes | Account to place against. paper-prefixed names are allowed in paper scope; live scope is required for any other. | |
| dry_run | No | Default true. Set false to actually dispatch. | |
| approve_token | No | Required for live scope. One-shot token issued by ControlServer.issue_approval(). |
Price a DEX swap against an AMM pool, exact to the wei, through lrvx's integer curves. Use this to quote a fill or measure price impact on a constant-product (Uniswap v2), Raydium CP (Solana), or Uniswap v3 concentrated-liquidity pool from its on-chain state. Amounts are decimal strings (native wei / lamports), so 256-bit values are lossless. Requires the optional lrvx dependency.
| Name | Required | Description | Default |
|---|---|---|---|
| i | No | In-token index (default 0). | |
| j | No | Out-token index (default 1). | |
| pool | Yes | Pool parameters as decimal strings. constant_product: reserve0, reserve1, fee_num, fee_den. raydium_cp: reserve0, reserve1, trade_fee_rate. uniswap_v3: sqrt_price_x96, liquidity, fee_pips, ticks (optional [sqrtRatio, net] pairs). | |
| venue | Yes | The pool's AMM type. | |
| amount_in | Yes | Input amount, native wei (decimal string). |
Capture market data into a .lrvx tape. Wraps the canonical recording paths — for mode=live shells out to the lrvx 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 .lrvx directory drivable by BacktestRunner.run_tape.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | `historical` = ccxt backfill of past data. `live` = capture from now onwards via `lrvx tape record`. | |
| to_dt | No | Historical mode. End datetime — ISO or unix-ms. | |
| symbol | Yes | Symbol in the exchange's spelling (BTC/USDT, BTCUSDT — both accepted). | |
| from_dt | No | Historical mode. Start datetime — ISO (2026-04-01) or unix-ms. | |
| duration | No | Live mode. Recording duration (`1h`, `30m`, `2d`). Omit for an open-ended recording (Ctrl+C to stop). | |
| exchange | Yes | ccxt exchange id (bitget, binance, bybit, ...). | |
| out_path | Yes | Output `.lrvx` directory (will be created if missing). | |
| data_type | No | Historical mode only. `klines` (1m bars by default) or `trades` (per-print). Trades have higher fidelity but are limited by what each exchange exposes. | |
| max_records | No | Historical mode. Refuse to start if estimated row count exceeds this. Default 1_000_000. |
Backtest a DEX position from a recorded pool history. Replays a list of swaps (or decoded Uniswap v2 Swap logs) through the exact curve and returns the price / reserves / LP-value / impermanent-loss / drift series over time. Use this to evaluate an LP position or a trading sequence against a real transcript. Requires the optional lrvx dependency.
| Name | Required | Description | Default |
|---|---|---|---|
| pool | Yes | A pool spec: {venue, token0:{symbol,decimals}, token1:{symbol,decimals}, ...venue params} -- the replay's starting state. | |
| swaps | No | Swaps as [ts, 'NUMBER SYMBOL', into?] entries. Supply this or `evm_logs`. | |
| evm_logs | No | Decoded Uniswap v2 Swap log dicts (data word order amount0In, amount1In, amount0Out, amount1Out). Supply this or `swaps`. |
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy | No | ||
| to_ts_ns | No | ||
| from_ts_ns | No | ||
| param_overrides | No | Optional dict of strategy params to swap before the replay. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is read-only with sandbox-only mutations, which is a key behavioral trait. However, it does not explain auth needs, rate limits, or implications of parameter values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, to the point, front-loaded with the main action, and provides necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (including nested objects) and no output schema, the description lacks enough detail about parameters, return values, and inner workings. The usage examples help but do not cover the full complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (one parameter described). The description does not explicitly describe parameters; it only hints at time window and strategy via context. This insufficiently compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a sandbox replay over a time window, with a specific verb ('run') and resource ('sandbox replay'). It distinguishes from sibling tools like run_backtest by emphasizing sandbox-only and read-only nature, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage examples like 'replay the last hour' and 'rerun this period in sandbox', giving clear context. However, it does not mention when not to use this tool or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Best execution for a DEX swap across a set of AMM pools, exact to the wei. Give it the same notional and several venues (constant-product, Raydium CP, Uniswap v3) and it returns the venue that fills the most, the fill, and a per-venue comparison. Amounts are human 'NUMBER SYMBOL' strings (e.g. '50000 USDC'); each pool carries its token symbols and decimals, so directions are by symbol and a mis-routed swap raises instead of returning a quiet zero. Requires the optional lrvx dependency.
| Name | Required | Description | Default |
|---|---|---|---|
| into | No | Out-token symbol (optional; inferred otherwise). | |
| amount | Yes | Input amount as 'NUMBER SYMBOL', e.g. '50000 USDC'. | |
| venues | Yes | Pool specs. Each: {venue, token0:{symbol,decimals}, token1:{symbol,decimals}, ... venue params}. constant_product/uniswap_v2: reserves (['1000 WETH','2000000 USDC']), fee, fee_den. raydium_cp: reserves, trade_fee. uniswap_v3: sqrt_price_x96, liquidity, fee, ticks. |
Run a Python lrvx 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.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Symbol name to register before the run. Default: BTCUSDT. | |
| dataset_path | Yes | Absolute path to a CSV dataset on disk. Capped at 64 MiB. | |
| strategy_code | Yes | Python source defining a `lrvx.Strategy` subclass at module level. The worker also accepts a top-level `STRATEGY = MyStrategy` assignment as the entry point. | |
| wall_timeout_s | No | Wall-clock timeout in seconds. Default 60, capped at 600. |
Return a starter lrvx 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 lrvx bookkeeping (constructor, hook names, signal builder) from memory. language is required — lrvx 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.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Strategy shape. One of: bar-driven, trade-driven, hybrid. Default: bar-driven. | |
| name | No | Class name for the generated strategy. Must be a valid identifier. Default: MyStrategy. | |
| language | Yes | Target language. Required. lrvx is polyglot — ask the user which binding they want before calling this tool. |
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. The kill switch is engine-level, not per-account, so only live scope may call this -- paper tokens are refused even with dry_run=false.
| Name | Required | Description | Default |
|---|---|---|---|
| active | Yes | ||
| reason | No | Free-text annotation recorded in the audit log. | |
| dry_run | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must carry behavioral disclosure. It reveals the dry-run default and its effect (dry_run=true default, explicit false applies the change), the engine-level scope (not per-account), and the refusal of paper tokens. This is substantial, but it does not mention side effects like audit logging (though the schema hints at reason recording), persistence across restarts, or failure conditions, which would make it complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states the core action and behavior; the second covers the dry-run default, the use case, and the scope restriction. Information density is high and the most critical operational detail (scope refusal) is front-loaded at the end, keeping it memorable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a setter with three parameters, no output schema, and no annotations, the description covers all essential aspects: the state change semantics, the dry-run safety mechanism, the intended use cases, and the access scope restriction. Nothing an agent needs to correctly call the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only reason has a description). The description directly explains the meaning and effect of the two undocumented parameters: active (true halts, false resumes) and dry_run (default true, explicit false applies). This fully compensates for the schema gap and adds decision-relevant semantics beyond the raw boolean types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Set') and a precise resource ('engine's kill-switch state'), then immediately clarifies the effect of each boolean value. It distinguishes this from the sibling get_kill_switch by the write nature of the operation, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for emergency halt and for resuming after manual review,' which is a direct when-to-use instruction. It also states a hard constraint: 'only live scope may call this -- paper tokens are refused even with dry_run=false,' which is critical operational guidance that the agent must know before invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend lrvx 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 lrvx indicators. Pure keyword heuristic; no LLM call. Always confirm shape with list_indicators after picking one.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | How many candidates to return. Default 3. | |
| description | Yes | Free-text description of what kind of indicator the user wants. |
Static-analysis check on a Python lrvx 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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Python source for the strategy module/class. |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Python source of the strategy module / class. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses heuristic nature, false negatives, and specific patterns checked (AST walk, negative shift, forward-index, attribute names). However, it lacks mention of the return format or side effects (presumably read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no fluff, front-loaded with purpose. Every sentence adds value: purpose, method, patterns, limitations. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter and no output schema, the description lacks a hint about what the tool returns (e.g., warnings list, success indicator). Also does not clarify whether it is state-modifying (should not be). Otherwise, it covers when to use and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a basic description of 'code' parameter. The description adds significant context by explaining what kind of code (strategy module/class) and what patterns are analyzed, enriching the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a static-analysis check for lookahead bias, a specific bug. It uses a specific verb ('checks') and resource ('strategy code's AST'), and its name distinguishes it from the broader validate_strategy sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Run before trusting any backtest result.' It does not explicitly exclude scenarios or mention alternatives, but the context is strong enough for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy | Yes | ||
| to_ts_ns | No | ||
| from_ts_ns | No | ||
| param_overrides | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing side effects. 'Counterfactual replay' and 'same as replay_window' imply a simulation, but it never explicitly states whether this is read-only, whether it can affect trading state, or what safety constraints apply. The examples hint at output (PnL), but not enough for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core concept, then practical examples. No filler or redundant phrasing, and the structure makes the tool's purpose immediately accessible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested object param_overrides, no annotations, no output schema), the description provides meaningful context via examples and the replay_window reference. It doesn't explain the exact format of param_overrides or return values, but the examples partially cover that, making it reasonably complete for an experienced agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clearly explains 'strategy' as a filter and 'param_overrides' as the counterfactual changes, with illustrative examples. The time parameters (from_ts_ns, to_ts_ns) are implicitly covered by 'same as replay_window,' which adds semantic context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Counterfactual replay' and positions it as a specialized variant of replay_window with a strategy-name filter and required param_overrides. The concrete examples ('what if EMA period was 50 instead of 21') make the tool's purpose unmistakable and distinguish it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'same as replay_window plus a strategy-name filter and required param_overrides,' which tells the agent exactly how this tool differs from the base replay tool. It also provides 'Use for' scenarios that specify when to invoke it, making the selection criteria clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.11.0compute_indicator1 field changedInput schema / properties / name / descriptionPrevious value: -"Indicator name in flox_py — case either matches the class (`EMA`, `RSI`, `Bollinger`) or the function (`ema`, `rsi`, `vwap`)."New value: +"Indicator name in lrvx — case either matches the class (`EMA`, `RSI`, `Bollinger`) or the function (`ema`, `rsi`, `vwap`)."explain_event1 field changedInput schema / properties / type_name / descriptionPrevious value: -"Event struct name. One of: FloxTradeData, FloxBookData, FloxBarData, FloxSymbolContext, FloxSignal."New value: +"Event struct name. One of: LrvxTradeData, LrvxBookData, LrvxBarData, LrvxSymbolContext, LrvxSignal."flox_overviewflox_venue_guideget_positions1 field changedInput schema / properties / state_path / descriptionPrevious value: -"Override snapshot path (defaults to FLOX_RUNTIME_STATE or /tmp/flox-runtime-state.json)."New value: +"Override snapshot path (defaults to LRVX_RUNTIME_STATE or /tmp/lrvx-runtime-state.json)."lookup_symbol1 field changedInput schema / properties / name / descriptionPrevious value: -"Symbol name in any binding's spelling. Case-sensitive; common transformations (Flox prefix, flox_indicator_ prefix) are tried automatically."New value: +"Symbol name in any binding's spelling. Case-sensitive; common transformations (Lrvx prefix, lrvx_indicator_ prefix) are tried automatically."lrvx_overviewlrvx_venue_guiderecord_data2 fields changedInput schema / properties / mode / descriptionPrevious value: -"`historical` = ccxt backfill of past data. `live` = capture from now onwards via `flox tape record`."New value: +"`historical` = ccxt backfill of past data. `live` = capture from now onwards via `lrvx tape record`."Input schema / properties / out_path / descriptionPrevious value: -"Output `.floxlog` directory (will be created if missing)."New value: +"Output `.lrvx` directory (will be created if missing)."run_backtest1 field changedInput schema / properties / strategy_code / descriptionPrevious value: -"Python source defining a `flox.Strategy` subclass at module level. The worker also accepts a top-level `STRATEGY = MyStrategy` assignment as the entry point."New value: +"Python source defining a `lrvx.Strategy` subclass at module level. The worker also accepts a top-level `STRATEGY = MyStrategy` assignment as the entry point."scaffold_strategy1 field changedInput schema / properties / language / descriptionPrevious value: -"Target language. Required. FLOX is polyglot — ask the user which binding they want before calling this tool."New value: +"Target language. Required. lrvx is polyglot — ask the user which binding they want before calling this tool."v0.10.0cancel_all2 fields changedInput schema / properties / accountAdded value: +{
+ "description": "Account whose orders to cancel. paper-prefixed names are allowed in paper scope; live scope is required for any other.",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "account"
+]cancel_order2 fields changedInput schema / properties / accountAdded value: +{
+ "description": "Account the order belongs to. paper-prefixed names are allowed in paper scope; live scope is required for any other.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "order_id"
-]New value: +[
+ "account",
+ "order_id"
+]flatten_positions2 fields changedInput schema / properties / accountAdded value: +{
+ "description": "Account whose positions to flatten. paper-prefixed names are allowed in paper scope; live scope is required for any other.",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "account"
+]run_backtest3 fields changedInput schema / properties / wall_timeout_s / descriptionPrevious value: -"Wall-clock timeout in seconds. Default 60."New value: +"Wall-clock timeout in seconds. Default 60, capped at 600."Input schema / properties / wall_timeout_s / maximumAdded value: +600Input schema / properties / wall_timeout_s / minimumAdded value: +1v0.6.9explain_decisionflox_venue_guideget_exampleget_kill_switchinit_projectlist_bindingslist_capi_functionslist_indicatorslookup_error_codelookup_symbolset_kill_switchvalidate_strategywhatifv0.6.8explain_decisionget_exampleget_kill_switchinit_projectlist_bindingslist_capi_functionslist_indicatorslookup_error_codelookup_symbolset_kill_switchvalidate_strategywhatifv0.6.6amm_price_impactprice_amm_swapreplay_pool_taperoute_amm_swapv0.6.3cancel_allcancel_ordercompute_indicatordocs_searchexplain_decisionexplain_eventflatten_positionsflox_overviewget_event_logget_exampleget_indicator_valuesget_kill_switchget_open_ordersget_pnlget_positionsget_strategy_stateinit_projectlist_bindingslist_capi_functionslist_indicatorslist_strategieslookup_error_codelookup_symbolplace_orderrecord_datareplay_windowrun_backtestscaffold_strategyset_kill_switchsuggest_indicatorvalidate_strategyvalidate_strategy_no_lookaheadwhatifScored across 38 tools
Most tools have clearly distinct purposes, but a few pairs (validate_strategy vs validate_strategy_no_lookahead, replay_window vs whatif, price_amm_swap vs amm_price_impact) could be confused by name alone. The detailed descriptions disambiguate them well, so agents are unlikely to misselect if they read them.
The vast majority of tools follow a verb_noun pattern (list_*, get_*, cancel_*, set_*, run_backtest, etc.), which provides a predictable structure. However, there are a few oddballs like flox_overview, flox_venue_guide, whatif, and amm_price_impact that break the pattern, creating minor inconsistency.
With 38 tools, this server far exceeds the 15-tool sweet spot and even the 25-tool threshold. While the tools cover a wide range of features (discovery, backtesting, live inspection, orders, DEX), the sheer number makes the surface heavy to navigate, though each tool individually has a clear role.
The tool surface covers the major workflows: documentation, strategy scaffolding/validation, backtesting/replay, live engine inspection, order management, and DEX pricing/routing. Minor gaps exist (e.g., no explicit strategy deletion or risk-limit configuration), but agents can work around them with the provided tools like scaffold_strategy and docs_search.
Trading MCP server for AI agents, with live market data, account reads and controlled execution.
Research-only MCP server: your AI as a quant research desk. 90 tools, no trades, no brokers.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
MCP server exposing the Backtest360 engine API as tools for AI agents.
