Skip to main content
Glama

start_regime_analysis

Analyze one stock, or check one chosen pair of stocks.

    One stock: HMM regime detection, Hurst exponent, Bollinger/Keltner
    squeeze, Monte Carlo forward simulation.

    A pair (`ticker` and `ticker_b`, e.g. KO and PEP): whether the two
    hold together for spread trading. The QuanterLab pairs check rates
    the evidence that the two prices hold together as strong, mixed or
    weak, with a score out of a hundred, from the Engle-Granger and
    Johansen cointegration tests, the spread's half-life, how much the
    hedge ratio moves, and how often the two stocks share a market
    regime. It is the check to run when someone asks "is X / Y a
    tradable pair?" about any two stocks; `start_pairs_scan` searches a
    whole index for pairs instead.

    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.

    An analysis takes about 30 seconds to 2 minutes. The call returns
    `{task_id, status, kind, dashboard_url}`; `get_regime_analysis_progress`
    reports progress and, when it has finished, carries `result`: for one
    stock, the regime now and how long it has run, volatility against the
    stock's own history, how the stock behaves (trending, mean reverting
    or a random walk), its trend and its drops, rounded; for a pair, how
    strong the evidence is that the two hold together and the check's
    score, the cointegration tests as p-value bands, the spread's
    half-life, the hedge ratio's variation, the correlation, and how often
    the two shared a regime, rounded.

    Unlike `start_regime_optimization`, which uses HMM regimes to
    grid-search trading thresholds, this analysis is descriptive.

    Args:
        ticker: Stock symbol (uppercased). Required.
        ticker_b: Optional second ticker; with it the analysis checks the
            pair (`ticker` / `ticker_b`) for spread trading.
        mode: Optional. `'volatility'` runs only the squeeze module.
        years: Lookback window in years (default 2).
        params: Optional dict overriding module-specific knobs. Most
            useful: `hmm_enabled` / `hurst_enabled` / `squeeze_enabled` /
            `mc_enabled` (disable modules); `hmm_states`; `mc_simulations`.
        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.

    When the run has finished, its progress answer also carries `report_url`: the analysis written up as
    a QuanterLab report (the market states and their spells, or for a pair the checks of whether the two
    hold together). 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
modeNo
yearsNo
paramsNo
tickerYes
questionNo
ticker_bNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Adds substantial context beyond annotations: async task behavior, 30 seconds to 2 minutes runtime, daily allowance, refused calls not counting, the `{task_id, status, kind, dashboard_url}` return shape, and how `get_regime_analysis_progress` later supplies `result` and `report_url`. It also explains the chat card behavior and that `show_report_card` is unnecessary, with no contradiction of `readOnlyHint=false` or `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 description is front-loaded with the one-stock versus pair distinction and is organized clearly into result, Args, and async/report behavior. It is still lengthy and repeats some result/report details across paragraphs, so it is comprehensive but not maximally tight.

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

Completeness5/5

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

For a complex async analysis tool with no output schema, it covers inputs, runtime, quota behavior, return shape, progress retrieval, report artifact, and UI behavior. Nothing material needed to invoke it correctly appears to be missing.

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

Parameters5/5

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

Schema description coverage is 0%, but the description compensates with an Args section covering all six parameters: required `ticker`, optional `ticker_b` pair behavior, `mode='volatility'`, default `years=2`, `params` override examples such as `hmm_enabled` and `mc_simulations`, and `question` as the report title. This gives meaning well beyond the bare schema.

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

Purpose5/5

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

States a specific action: analyze one stock or check one chosen pair, and enumerates what each path does. It explicitly distinguishes itself from `start_pairs_scan` and `start_regime_optimization`, so an agent can select it without opening sibling schemas.

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

Usage Guidelines5/5

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

Gives explicit routing: use it for a single stock or a specific pair, use `start_pairs_scan` for an index-wide search, and use `start_regime_optimization` for threshold grid-search rather than descriptive analysis. It also names the natural-language prompt it answers: "is X / Y a tradable pair?"

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