Skip to main content
Glama

quantifyme

by ai.quantifyme
OverviewDiscussionsAdmin

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 → the best
curated preset for the market, or a fresh build when there is none; specific
rules → a fresh generation). A community strategy deploys only after the user
has seen its author and code (get_strategy_code) and picked it: then pass its
`community_id`.

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. If the
result carries a `suggestion`, you may offer that community strategy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
presetNo
promptNo
symbolNo
timeframeNo
webhook_urlNo
claude_modelNo
community_idNo
telegram_chat_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds substantial context the annotations cannot: the deploy is asynchronous and returns immediately with job_token/poll_url/pending, it must be called EXACTLY ONCE, generation is skipped for preset/community paths, and claude_model carries free-tier limits (1/day sonnet, 3/day haiku). These are real operational constraints an agent 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?

Front-loaded with the one-line purpose, then structured Args and NEXT STEP sections; almost every sentence carries routing or behavioral information. It is on the long side and repeats the call-once emphasis, but the density is justified for an 8-parameter orchestration tool.

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?

Despite the output schema existing, the description still clarifies the immediate return shape (job_token, poll_url, pending, symbol, timeframe) and explicitly routes the agent to get_deploy_result for final stats, noting the chart is already on the card. Nothing needed to call it correctly or handle its result 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 description coverage is 0% and there are 8 parameters, so the description carries the full burden — and it does: it enumerates allowed symbols, timeframes, preset slugs, defines claude_model variants and their side effects, explains community_id's provenance requirement, and clarifies symbol/timeframe still apply to backtest on the community path. Every parameter gains meaning beyond the bare schema types.

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 first line states a specific verb chain (generate → train → deploy live) on a named resource, and the tool is clearly distinguishable from siblings like generate_strategy (which only generates) and get_deploy_result (which only polls). An agent can tell exactly what this composite tool does without opening the 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?

Explicit routing rules: exactly one of prompt/preset/community_id is required, with precedence community_id > preset > prompt spelled out. It also states when to pass a prompt vs pre-pick a preset ('pass the user's words as prompt; do not pre-pick'), the prerequisite for community_id (user must have seen author/code via get_strategy_code), and the mandatory follow-up call to get_deploy_result. This is near-complete when/when-not guidance.

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

All quantifyme toolsInspect
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