Skip to main content
Glama

start_test

Runs one of QuanterLab's ready tests on a stock or fund as a circuit of the lab's cards: the rule is tuned on past years only, then tested on the last three years, which the tuning never saw, against simply holding the same stock. It takes no settings to start: each test has its own default stock, below, and a test picked from get_started's card or named in words runs as it is.

    Tests: mean_reversion (a fitted model that buys when the price has fallen unusually far below its recent
    level; default KO), trend_following (a model that rides a trend while it lasts; SPY), momentum (holds
    while the last few months were up; QQQ), buy_the_dip (buys after two days of sharp falls, the 2-day RSI
    under 10; SPY), famous_rule (the 200-day line: hold above the 200-day average, cash below; SPY), and mvo
    (a book of up to 20 stocks of an index picked each quarter by mean-variance optimisation, from the companies
    in the index on that date; it takes `index`, not a ticker, and is set against holding the index's fund).

    Its card draws the circuit as the lab does and lights each card as it runs, with the result under it.
    get_primitives_run_progress follows it by its task_id; when it has finished it answers with the result,
    report_url and offers, each with its exact call, the first one tracking the test live
    (start_paper_trade). The circuit card shows the result, so a ready test needs no show_report_card.

    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:
        test: mean_reversion, trend_following, momentum, buy_the_dip, famous_rule or mvo.
        ticker: Optional. The stock or fund to test it on, as its symbol ('AAPL', 'SPY'); else the test's own.
        index: Optional, for mvo: nasdaq100 (its own) or dow30. The book on the S&P 500 does not run here
            yet (more than a run here does in full in under a minute), and another index (the DAX, the
            FTSE 100) has no dated members: pass what the person asked all the same, and QuanterLab answers
            with its note and the same book on the Nasdaq 100, one tap away, and nothing runs.
        settings: Optional. The one setting a test lets a person change, by name: mean_reversion
            {"z_entry": 1 to 3.5}, trend_following {"trend_threshold": 0.25 to 3}, momentum {"months": 1 to
            4}, buy_the_dip {"rsi_below": 2 to 30}, famous_rule {"days": 20 to 300}, mvo {"holdings": 5 to
            30}, e.g. {"days": 100} for
            the 100-day line; and on every test {"stop_loss": 0.5 to 30}, the lab's Stop Loss card added
            under the forward test, which sells everything once the run has lost that many percent since the
            start of the month. A test changed by talking ("use the 100-day line instead", "add a stop
            loss") is the same call: the same test and stock and the last run's settings with that one change;
            the card draws the changed circuit and runs it. Without settings the test runs as it stands.
        question: Optional. One sentence restating what the run should answer, not the person's message: the
            title of the report, and kept only as that.
        study: Optional, instead of test. A published paper's id (from search or fetch). Unchanged, it answers
            at once with the paper's registered result: the run its last registered window recorded, from that
            window's date to the day it was recorded, and it uses none of today's runs. Changed (its settings)
            or with to_today, it runs the paper's circuit from that window's date to today. It takes no ticker;
            its `settings` are the settings the paper names (fetch lists them, e.g. {"symbol": "QQQ"} for which
            fund, {"spread_bps": 20} for the trading cost), and a refusal names them.
        to_today: Optional, with study. True runs the paper's circuit unchanged from its last registered window
            to today, a run like any other: what the person asks for with "run it up to today", or a tap on
            that offer after a paper's registered result.
    

Input Schema

NameRequiredDescriptionDefault
testNo
indexNo
studyNo
tickerNo
questionNo
settingsNo
to_todayNo

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?

Beyond annotations, it discloses the daily allowance, that a refused call does not count, and where to check today's count. It explains asynchronous behavior: get_primitives_run_progress follows by task_id, and the final answer includes result, report_url, and offers (e.g., start_paper_trade). It also describes the circuit card drawing and lighting each card as it runs, providing rich behavioral context without contradicting the annotations.

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 core purpose and organized into paragraphs plus a clear Args section. It is lengthy, with some repetitive or parenthetical details (e.g., repeated settings and stop-loss explanations), but the complexity of seven optional parameters and multiple modes justifies most of the length. Minor tightening would improve it.

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?

With no output schema, the description explains the return shape: result, report_url, and offers each with its exact call. It covers async follow-up via get_primitives_run_progress, daily allowances, special index handling for mvo, and the study path with to_today. This is enough for an agent to call the tool correctly across its modes.

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 Args section fully compensates: it lists the allowed test values, explains ticker as an optional symbol, details index options and their caveats for mvo, and gives per-test settings ranges plus the universal stop_loss setting. It also explains question, study, and to_today semantics, including how settings change behavior. This is comprehensive parameter documentation well beyond the 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?

The description states a specific verb and resource: 'Runs one of QuanterLab's ready tests on a stock or fund as a circuit of the lab's cards.' It explicitly lists the ready tests (mean_reversion, trend_following, etc.) and distinguishes them from custom backtests by scoping the tool to 'ready tests' and referencing get_started's card. This gives an agent enough to separate it from sibling start_* tools.

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 gives clear usage context: a test picked from get_started's card or named in words runs as it is, and it explains the study vs. test paths and to_today behavior. It also notes that a ready test needs no show_report_card. However, it never explicitly says when to choose this over sibling tools like start_backtest for custom strategies, leaving that comparison implicit.

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