QuanterLab

start_paper_trade

Start a strategy live: it runs on live market data, on paper, with a note on it every morning (the lab's paper trade). It is what "start it live, follow it, paper trade it, run it live, watch it" ask for, and what a tap on a run's offer to start it live does. save_trading_config never does this: it keeps a run's settings, and nothing goes live from it.

    A first call starts nothing: its answer carries `ask`, the question for the person, with two offers. The same
    call with confirm=true, made after the person's yes, starts it.

    What it tracks: a finished run of this account (task_id: a ready test, a paper's circuit, a saved lab
    project's run, a backtest or a walk-forward), a published paper (study, from search or fetch) or one of the
    person's saved lab projects (project_id, from list_my_primitives_projects).

    It registers the strategy in the person's saved work, sets it up on paper with 100,000 for 90 days, checks it
    on the last six months and puts it live. Its first update comes after the next US market close. When the
    check takes longer, it goes on on QuanterLab and the strategy goes live by itself when it is done. Nothing
    here places an order or moves money: it is simulated on paper, on the data served each day.

    An account runs one strategy at a time. With one already tracked, a call starts nothing and its `ask`
    offers the swap, with two offers. The same call with replace=true and the replace_id its message names,
    made after the person's yes, stops that one (its record is kept) and tracks this one instead.

    Its card shows what started; `message` and `open_url` say the same for a host without cards. A strategy that
    cannot go live as it is answers with why in `message`, and, for a paper whose data stops at its publication,
    an offer with the exact call of its live version. my_paper_trades says later how it is doing.

    Args:
        task_id: The task_id of one of this account's finished runs.
        study: Instead of task_id, a published paper's id.
        project_id: Instead of task_id, the id of one of the account's saved lab projects.
        live_version: With study, true tracks the paper's live version: the same rule on the data served
            today.
        replace: True once the person has said yes to tracking this one instead of the one the account
            tracks.
        replace_id: With replace, the id of the strategy the account tracks, as the answer that asked names it.
            Another one tracked by then is asked about again.
        confirm: True once the person has said yes to the question the first call asked.

Input Schema

Name	Required	Description	Default
`study`	No
`confirm`	No
`replace`	No
`task_id`	No
`project_id`	No
`replace_id`	No
`live_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes far beyond the annotations: states the first call is a no-op that only returns a question, that an account tracks one strategy at a time and the replace flow stops the old one while keeping its record, that setup is 100k/90 days with a six-month check, that the first update arrives after the next US market close, that a long check falls back to async, and that no order or money movement occurs. This resolves the non-idempotent, non-destructive hints into concrete outcomes.

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

Conciseness3/5

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

Purpose and routing are front-loaded, but the body is long and narrative, with awkward constructions ("It is what 'start it live, follow it...' ask for") and a typo ("goes on on QuanterLab"). Most content earns its place, but the same lifecycle could be stated in noticeably fewer words.

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 7-param, no-output-schema, stateful mutation tool, the description covers the full lifecycle: input sources, confirmation gating, concurrent-strategy conflict, async fallback, error surfacing via `message`, and where to check status afterwards. Nothing needed to invoke it correctly is 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 coverage is 0%, so the description carries the full burden and does: each of the 7 args is explained, including the mutually exclusive task_id/study/project_id sources with where each id comes from, and non-obvious semantics for live_version, replace, replace_id ("as the answer that asked names it"), and confirm.

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 opening sentence states a specific verb and resource ("Start a strategy live... on live market data, on paper") and explicitly contrasts with the sibling save_trading_config and forward-references my_paper_trades. An agent can immediately tell this apart from the backtest/scan starters and from save_trading_config.

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 enumerates the user phrasings that should trigger this tool, spells out the two-phase confirm flow (first call returns `ask`, second call with confirm=true), and names the alternative (save_trading_config) that does NOT go live. It also gives the exclusion condition for the replace path and requires a human yes before proceeding.

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

All QuanterLab tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?