Skip to main content
Glama

start_mr_scan

Run QuanterLab's mean-reversion scanner across an index.

    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.

    A scan takes about 30 seconds to 3 minutes. The call returns
    `{task_id, status, kind, dashboard_url}`; `get_mr_scan_progress(task_id)`
    reports progress and, when the scan has finished, carries `result`:
    each filter's rule as applied with how many names passed it, and up
    to ten names, those that passed every filter and then the closest
    misses, ranked, each with its own statistics rounded (`candidates`).

    `steps` is an ordered list of filters, each
    `{"type": ..., "params": {...}}`; a name has to pass a filter to reach
    the next. The filters and their settings, defaults in brackets:
        hurst           max_h, the highest Hurst exponent that passes [0.45];
                        window, bars [100]
        halflife        min_hl and max_hl, the half-life band in days [5, 100]
        adf             max_pvalue, the highest ADF p-value that passes [0.05]
        kpss            min_pvalue, the lowest KPSS p-value that passes [0.05]
        variance_ratio  max_vr, the highest variance ratio [0.95]; lag, bars [5]
        autocorr        max_acf, the highest lag-one autocorrelation [0.0]
        volatility      min_vol and max_vol, annual volatility as a fraction
                        [0.15, 0.60]
        liquidity       min_dv, average daily dollar volume in millions [10]

    Args:
        steps: The filters, in order (required).
        index: The universe: 'sp500', 'nasdaq100' or 'dowjones'. Asked for another index (the DAX, the
            FTSE 100), pass it all the same: QuanterLab answers with its note and the same scan on the S&P
            500, and nothing runs.
        timeframe: '1d' (daily bars, the only timeframe this connector runs).
        duration: The history: '6m', '1y' or '3y'.
        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 answer also carries `report_url`: the scan written up as a QuanterLab
    report (the funnel and every name that passed). 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
indexNosp500
stepsYes
durationNo3y
questionNo
timeframeNo1d

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the basic mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description goes far beyond by disclosing the quota model and that refused calls are free, the expected latency, the exact response shape {task_id, status, kind, dashboard_url}, the waiting semantics, and the report_url delivered on completion. It even warns that an unsupported index still consumes a turn but runs nothing, which is a genuine behavioral trap an agent must know to avoid.

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?

Front-loaded with the action, then quota, then return shape, then parameters — a sensible ordering for a tool with no schema documentation. It is long, but the bulk is the filter reference, which is unavoidable at 0% schema coverage; the only fat is a few convoluted clauses such as "The call waits for the run while it is likely to finish inside it" and the run-card sentence, which read awkwardly and could be tightened.

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?

No output schema exists, so the description explains the immediate return value, the deferred result payload delivered via get_mr_scan_progress (per-filter pass counts, up to ten ranked candidates with statistics), and the post-completion report_url. Combined with quota, latency, and the full filter spec, an agent has everything needed to call this correctly and set user expectations.

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 coverage is 0% and the schema has no titles beyond bare names and no enums, so the description carries the full burden — and it does: index values ('sp500', 'nasdaq100', 'dowjones') with out-of-set handling, timeframe ('1d' only), duration ('6m'/'1y'/'3y'), question semantics (one sentence, becomes report title, not the user's message), and steps as an ordered filter chain. The filter catalogue enumerates all eight types with their parameter names, meanings, units, and bracketed defaults, plus the pass-to-next-filter chaining rule.

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?

Opens with a specific verb and resource: "Run QuanterLab's mean-reversion scanner across an index," which is immediately distinguishable from siblings like start_pairs_scan, start_backtest, and start_regime_analysis. The follow-on text clarifies it launches an asynchronous task whose result surfaces through get_mr_scan_progress, so the agent knows exactly what class of operation this is.

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?

Gives concrete usage context: the daily allowance (a refused call does not count and the count is available via get_started and each run's answer), the 30s–3min runtime, and the fact that a run started here needs no show_report_card. It also explains the non-obvious fallback behavior when a user asks for an unsupported index (DAX/FTSE → S&P 500 scan and nothing runs). It does not explicitly contrast against start_pairs_scan or other scan starters, so it falls short of full when/when-not/alternatives coverage.

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