Skip to main content
Glama

start_pairs_scan

Scan an index for pairs of stocks that move together.

    For one chosen pair (KO and PEP, say), `start_regime_analysis` with
    `ticker` and `ticker_b` checks that pair directly.

    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 1 to 5 minutes (every pair in the universe after
    a correlation screen). The call returns `{task_id, status, kind,
    dashboard_url}`; `get_pairs_scan_progress(task_id)` reports progress
    and, when the scan has finished, carries `result` with up to ten
    pairs, those that passed every filter and then the closest misses,
    each with its own statistics rounded (`candidates`).

    `steps` has the same shape as in `start_mr_scan`. The filters and
    their settings, defaults in brackets:
        correlation      min_corr, the lowest return correlation [0.7]
        cointegration    max_pvalue, the highest Engle-Granger p-value [0.05]
        spread_halflife  min_hl and max_hl, the spread's half-life band in
                         days [5, 60]
        beta_stability   max_cov, how much the hedge ratio may vary, in
                         percent [50]; window, bars [60]
        spread_hurst     max_h, the highest Hurst exponent of the spread [0.45]
        johansen         min_rank, the fewest cointegrating relations [1]

    Args:
        index: '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.
        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 pair 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?

Adds substantial context beyond the annotations: expected 1-5 minute runtime, the daily rate allowance with 'refused calls don't count', the response envelope {task_id, status, kind, dashboard_url}, that progress is polled via get_pairs_scan_progress, and that the row is auto-filled so no show_report_card is needed. The annotations only say it's a non-destructive, non-idempotent mutation; the description supplies the operational behavior an agent actually needs.

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 critical content (purpose, alternative, cost, return shape) is front-loaded and the filter block is scannable. It is somewhat long and the report-card discussion plus the awkward leading indentation and line breaks add mild noise, but little of it is truly redundant.

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?

With no output schema, the description correctly explains the return envelope, the `candidates` result (up to ten pairs, rounded stats), and `report_url`. What's missing is any mention of `duration`/`timeframe`, which materially affect a backtest-style scan, so an agent must guess those defaults.

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 coverage is 0%, so the description carries the load and mostly does: it enumerates the index values and the fallback semantics, defines `question` as a one-sentence restatement used as the report title, and documents the nested `steps` filter shape (min_corr, max_pvalue, min_hl/max_hl, max_cov, window, max_h, min_rank) with defaults even though `steps` is an untyped array. However, `duration` and `timeframe` are never mentioned, leaving two of five parameters undocumented.

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+resource+scope: 'Scan an index for pairs of stocks that move together.' It immediately contrasts with the sibling start_regime_analysis ('For one chosen pair ... start_regime_analysis ... checks that pair directly'), so an agent can distinguish a universe-wide scan from a single-pair check without opening either schema.

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?

Explicitly names the alternative tool and the condition selecting it (single pair -> start_regime_analysis), states the daily-allowance constraint and that refused calls are free, and warns that an unsupported index (DAX, FTSE 100) triggers a note and a substitution rather than a run. When-to-use, when-not, and cost are all covered.

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