quantifyme

Deploy Strategy (generate + backtest + go live)

one_shot

Destructive

End-to-end deploy: generate strategy → train → deploy live.

One of `prompt` (free-form NL), `preset` (curated winning strategy), or
`community_id` (copy a published community strategy) is required. If more
than one is passed, precedence is community_id > preset > prompt.

Args:
  prompt: Natural-language strategy description (e.g. "Buy when RSI < 30, sell > 70").
  symbol: Currency pair to backtest on. One of: EURUSD, USDJPY, GBPUSD,
    USDCHF, USDCAD, AUDUSD, NZDUSD. Default EURUSD.
  timeframe: Candle granularity. One of: 1min, 5min, 15min, 1h. Default 15min.
  claude_model: Which Claude variant to use for code generation.
    "sonnet" (default — best quality, 1/day free) or "haiku" (faster, 3/day free).
    Ignored when `preset` is set (no generation needed).
  preset: Curated winning-strategy slug. Skips Claude generation entirely
    — deploys a pre-saved strategy known to backtest well on the chosen
    symbol. Available slugs: ema_cross_fast, momentum, scalper_stack,
    sma_only, trend_ema, volatility, bb_squeeze, all_mix, pivot_kid_ema.
    Not every slug exists for every symbol — call list_models afterwards
    to confirm what deployed.
  community_id: Copy-trade a published community strategy. Pass the `id`
    of an entry from `browse_community`. Loads that exact strategy code,
    skips Claude generation, then trains + deploys it. `symbol`/`timeframe`
    still apply to the backtest+deploy.
  webhook_url: Optional webhook to receive live signals.
  telegram_chat_id: Optional Telegram chat ID for signal delivery.

Returns IMMEDIATELY (the deploy runs in the background so the live card can
stream progress) with:
    - job_token (str): pass to get_deploy_result to fetch the final result.
    - poll_url (str): the card polls this for live progress; you can ignore it.
    - pending (bool): always true here — the deploy is still running.
    - symbol, timeframe (str).

Call this EXACTLY ONCE per request. Pass the user's words as `prompt`; do not
pre-pick presets/community strategies — the server routes (vague → a proven
community strategy, specific rules → a fresh generation).

NEXT STEP (always): call get_deploy_result(job_token) ONCE — it blocks until the
deploy finishes and returns the out-of-sample stats + `stem` + `source`/`author`
as TEXT so you can summarize. The live card already shows the chart, so you do
NOT need get_model_chart. If source='community', tell the user it used a
pre-existing strategy by @author and offer to generate a custom one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`preset`	No
`prompt`	No
`symbol`	No
`timeframe`	No
`webhook_url`	No
`claude_model`	No
`community_id`	No
`telegram_chat_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.9/5.0

Behavior5/5

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

Discloses that the deploy runs in background, returns immediately with a job_token, and that the live card streams progress. Mentions daily limits for Claude models. The description adds significant behavioral context beyond annotations (destructiveHint=true, readOnlyHint=false). No contradiction.

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 thorough but somewhat lengthy; however, it is well-structured with a summary, parameter list, return value explanation, and usage instructions. Every sentence adds value, though a more concise format could be achieved while retaining key information.

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?

Given the tool's complexity (8 parameters, multiple modes, asynchronous behavior, output schema), the description is complete. It covers all modes, precedence, defaults, return fields, next steps, daily limits, and cross-references to other tools (list_models, browse_community, get_deploy_result), adequately equipping an AI agent to use the tool correctly.

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?

Despite 0% schema description coverage, the description thoroughly documents all 8 parameters: explains allowed values, defaults (e.g., symbol defaults to EURUSD, timeframe to 15min), precedence, and special behaviors (e.g., claude_model ignored when preset is set). Compensates fully for missing schema descriptions.

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 clearly states the tool's purpose as 'End-to-end deploy: generate strategy → train → deploy live' and distinguishes three input modes (prompt, preset, community_id) with precedence rules, differentiating it from siblings like generate_strategy and browse_community.

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 states when to use each mode, precedence (community_id > preset > prompt), that it should be called exactly once per request, and provides the next step to call get_deploy_result. Also advises against pre-picking presets/community strategies and instructs how to handle community-sourced results.

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

All quantifyme tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, though browse_community, find_strategy, and one_shot (community_id) are related and could cause confusion if descriptions are not read carefully. Overall well-differentiated.

Naming Consistency4/5

Overwhelmingly follows a verb_noun pattern (browse_community, find_strategy, generate_strategy, get_deploy_result, etc.). A few exceptions like 'one_shot' and 'top_up' break the pattern but are still clear and memorable.

Tool Count4/5

13 tools cover the major functions of a trading strategy platform (discover, generate, deploy, monitor, account management). The count feels appropriate, though 'stream_test' is diagnotic and may not be needed in all contexts.

Completeness3/5

Covers core workflows well—browse, find, generate, deploy, and get results. However, lacks tools to update or stop a deployed model, and there's no way to edit an existing strategy, leaving some lifecycle gaps.

Resources

Need Help?