MangroveAI

run_backtest

Start a backtest of one saved strategy over a window of history. Takes a strategy_id -- it reads the stored strategy's own rules, asset, timeframe and risk parameters. The recorded market is the default; pass quote_token and/or market_data_venue when the person chooses another quote or execution venue. An omitted choice keeps its recorded value. Check and report the selected market; never silently substitute a feed. IT RETURNS A SUBMISSION, NOT A RESULT: a real backtest takes minutes, so this hands back the run's id and the config it will use, and the metrics arrive on their own once the engine finishes. Tell the person it is running; do not call this again for the same question, and do not wait. It consumes a unit of the user's monthly backtest allowance at submission -- so it CHECKS THE STRATEGY FIRST, and a refusal costs nothing: a problem (verify_strategy's problems) always refuses, and a signal parameter still at its library default refuses until you either save chosen values or pass acknowledge_defaults=true to stand by the defaults deliberately. One (strategy, window) is ONE measurement: submitting the same strategy over the same dates again is refused and the existing run named -- read that with get_backtest instead. Both start_date and end_date are required: name the days, so the same question asked next week gives the same answer. Every message carries the current time, so work them out from that. A YYYY-MM-DD end date covers that whole UTC day; an end date of today stops at the end of yesterday, the last complete day; a later date is refused. get_benchmark reads the same dates the same way. When the person names no window, its length is set by the candle size: 5m 1 month, 15m 2 months, 30m 3 months, 1h 4 months, 4h 12 months, 1d 12 months (a month is 30 days). Pass end_date = today and start_date = today minus 30 days per month (1h: today minus 120 days); today is not complete, so the window covers exactly that many days, through the end of yesterday.

[Access: pay 0.10 USDC via x402 (PAYMENT-SIGNATURE header) OR authenticate with an API key. An x402-capable client will auto-pay; API-key clients pay nothing per call.]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "end_date": "<end_date>",
      "start_date": "<start_date>",
      "strategy_id": "<strategy_id>"
    },
    "name": "run_backtest"
  }
}

Input Schema

Name	Required	Description
`end_date`	Yes	ISO end of the window.
`start_date`	Yes	ISO start of the window, e.g. 2026-01-01.
`quote_token`	No	Quote currency of the requested market.
`strategy_id`	Yes	The strategy's UUID.
`engine_generation`	No	Only set when the person specifies an engine generation; omitted uses latest.
`market_data_venue`	No	Exact venue of the requested market.
`acknowledge_defaults`	No	Pass True to submit even though signal parameters are at their library defaults -- an explicit statement that the defaults were considered and stood by, never a way to skip considering them.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say the call is a non-readonly, non-idempotent, open-world mutation. The description adds far more: it returns a submission id and resolved config rather than metrics, metrics arrive asynchronously, it consumes a unit of the monthly allowance at submission time, refusals cost nothing, duplicates are refused and the existing run named, and payment can be x402 or API key. These are exactly the operational facts an agent cannot get from 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.

Conciseness3/5

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

Purpose and the critical "returns a submission, not a result" warning are front-loaded well, but the description runs long and repeats itself: the omitted-choice rule is stated twice, and the end-date/today rule is explained and then restated in the final default-window paragraph. Heavy ALL-CAPS emphasis and a trailing bracketed payment paragraph add bulk that could be tightened without losing 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?

For a 7-parameter, async, paid, non-idempotent mutation with no output schema, the description covers the return shape, timing, refusal semantics, duplicate handling, date derivation, and payment modes. Nothing an agent needs in order to invoke it correctly and report back to the user 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 already 100%, yet the description still adds real meaning: strategy_id implies the stored strategy's rules/asset/timeframe/risk are read from it, quote_token and market_data_venue default to the recorded market and an omitted choice keeps its recorded value (with a warning never to silently substitute a feed), acknowledge_defaults is framed as deliberate acceptance of library defaults, and the date parameters get concrete day-boundary and window-length semantics. That is substantial value on top of 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?

"Start a backtest of one saved strategy over a window of history" names a specific verb and resource, and the description immediately scopes it as submission-oriented rather than result-oriented, explicitly separating it from get_backtest ("read that with get_backtest instead") and verify_strategy (whose problems it reuses). An agent can tell exactly what this does and what it does not do.

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?

It states when to call (a saved strategy plus a window), when NOT to call again ("do not call this again for the same question, and do not wait"), what refusal conditions exist (unresolved verify problems, defaults, duplicate strategy+window), and names the alternative tools for the follow-up paths (get_backtest, get_benchmark). This is explicit routing guidance, not inference.

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

All MangroveAI 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.