Skip to main content
Glama

start_regime_optimization

Run QuanterLab's regime-aware threshold optimization.

    Adaptive threshold optimization via HMM regime detection plus
    per-regime grid search. Long-running (typically 2-10 min). Returns
    `{task_id, status, kind, dashboard_url}`; `get_regime_optimization_progress`
    reports progress and, when the run has finished, carries `result`.

    Every account runs it within a daily allowance; a refused call does not count, and get_started and
    every run's answer give today's count.

    Args:
        ticker: Asset to analyze.
        base_config: Strategy template, the same shape as
            `start_backtest`'s arguments (entry/exit indicators and
            conditions).
        param_x / param_y: The two settings to grid over, each
            `{"name": ..., "min": ..., "max": ...}` with an optional
            "steps" (2-30; default `grid_steps`). "name" is one of:
              "entry.length"         a setting of the entry, exit or
                                     confirmation indicator ("exit.fast")
              "rsi.length"           the same, found by the indicator's id
                                     when exactly one lane uses it
              "entry.conditions[0]"  the number an entry, exit or
                                     confirmation condition compares against
            Indicator settings move in whole numbers: a decimal setting
            (Bollinger's std) runs at each whole number inside its range
            (a range holding fewer than two answers with QuanterLab's note
            and the nearest version, one tap), and a rule of the same lane
            written against the swept indicator's column runs written the
            other way round, the same rule; the answer's `changed` says so
            in one line. A rule of
            another lane that reads the swept column is refused with what
            to change.
        duration: Historical window (default '5y').
        n_regimes: 0 to pick the number of regimes automatically (default),
            or 2-4.
        mode: 'all' (default) | 'static' | 'per_regime' | 'dynamic_mean' |
            'regression', the optimizers QuanterLab's regime page offers.
        objective: Metric to maximize per regime: 'sharpe' (default) |
            'total_return_pct' | 'profit_factor'.
        question: Optional. One sentence restating what the run should answer, not the person's
            message: the title of the report the finished run becomes, and kept only as that.

    A run of more than 500 backtests (in every outer window, the grid on all its days, the grid again for
    each market state, and one test) runs nothing and answers with QuanterLab's note and the nearest versions
    that run whole, one tap each. The default grid of 4 by 4 runs whole on the default five years.

    When the run has finished, its progress answer also carries `report_url`: the run written up as a
    QuanterLab report (the setting each market state picked, the rules side by side against holding the
    stock). The call waits for the run while it is likely to finish inside it; the run's card in the chat
    shows the result or, for a longer run, how far it is, and fills in by itself, with the next steps as
    choices and the report link. A run started here needs no `show_report_card`.
    

Input Schema

NameRequiredDescriptionDefault
modeNoall
tickerYes
param_xYes
param_yYes
durationNo5y
questionNo
n_regimesNo
objectiveNosharpe
timeframeNo1d
grid_stepsNo
base_configYes
outer_opt_barsNo
outer_step_barsNo
outer_test_barsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: expected 2-10 minute runtime, the immediate return shape, progress polling via a sibling, daily allowance behavior, refusal handling, the 500-backtest guard, waiting behavior, and report generation. These details are consistent with readOnlyHint=false, idempotentHint=false, and destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the length is largely justified by 14 parameters and nested configuration semantics. Some passages about indicator settings and swept columns are convoluted, but the overall structure follows a useful purpose, return, constraint, and Args progression.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description properly explains the immediate return keys, the progress result, report_url, and runtime expectations. It is nearly complete for calling the tool, though the advanced outer-window parameters are not explained.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry parameter meaning; it documents the required ticker, base_config shape, param_x/param_y structure and accepted names, duration, n_regimes, mode, objective, and question in useful detail. It leaves timeframe, outer_opt_bars, outer_step_bars, and outer_test_bars undocumented, and grid_steps is only referenced indirectly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: it runs regime-aware threshold optimization via HMM regime detection and per-regime grid search. It clearly identifies the progress sibling used to retrieve completion/result, but it does not explicitly distinguish this tool from start_regime_analysis.

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

Usage Guidelines4/5

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

It explains that the run is long-running, that get_regime_optimization_progress should be used for progress/result, that a completed run carries report_url, and that no show_report_card is needed. It also notes the daily allowance and refusal behavior, but it does not state when to prefer start_regime_analysis versus this optimization tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources