YourAITools MCP Hub

TASignal: Rule backtest

ta_backtest

Read-onlyIdempotent

Same as GET, POST {"symbol":"SOL","timeframe":"4h","strategy":"ema_cross","fast":20,"slow":50}

[TASignal via YourAITools MCP Hub] No free tier (paid route only). Paid: backtest $0.05 per call, with a credits key (Authorization: Bearer yatc_...) or x402 (USDC; the hub returns the payment terms). Failed tool calls aren't charged: credits are refunded automatically and x402 payments only settle on success.

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": {
      "symbol": "<symbol>",
      "strategy": "<strategy>"
    },
    "name": "ta_backtest"
  }
}

Input Schema

Name	Required	Description
`bars`	No	Candles to test, 100-2000 (default 500)
`fast`	No	Fast period (sma_cross/ema_cross default 20, macd_cross 12)
`slow`	No	Slow period (sma_cross/ema_cross default 50, macd_cross 26)
`tier`	No	Paid tier: backtest $0.05. Default backtest.
`lower`	No	RSI entry level for longs (default 30)
`upper`	No	RSI entry level for shorts / exit (default 70)
`period`	No	RSI period (default 14) or breakout lookback (default 20)
`signal`	No	MACD signal period (default 9)
`symbol`	Yes	Base asset ticker, e.g. BTC, ETH, SOL, HYPE (BTC-PERP, ETH-USD and SOLUSDT are accepted too)
`fee_bps`	No	Fee per side in basis points (default 5)
`strategy`	Yes	Strategy rule
`direction`	No	default long_only
`timeframe`	No	Candle timeframe: 15m, 1h, 4h or 1d (default 1h; risk default 4h)

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 30, 2026
- addedInput schema / properties / strategy / examples
```
Added value: +[
+  "ema_cross"
+]
```
- addedInput schema / properties / symbol / examples
```
Added value: +[
+  "BTC"
+]
```
- addedInput schema / properties / timeframe / examples
```
Added value: +[
+  "1d"
+]
```
First observedOct 24, 2026

TDQS

C2.7/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds genuinely new context: paid-only route, $0.05 per call, how to authenticate (Bearer yatc_... or x402 USDC), and that failures are refunded or unsettled. That billing/failure semantics is exactly what an agent cannot infer from 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?

The payment paragraph is dense but every clause earns its place. The leading sentence, however, is a fragment that wastes the most valuable position in the description on a reference the reader cannot resolve.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 13 parameters, no output schema, and no statement of what a backtest returns (equity curve, win rate, drawdown, trade list), an agent cannot tell what it will get back or how to interpret it. Payment and auth are covered, but the tool's core output contract is entirely absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including per-strategy defaults for fast/slow, so the schema does the heavy lifting. The example payload (symbol SOL, timeframe 4h, strategy ema_cross, fast 20, slow 50) adds a mildly useful canonical invocation and implies the POST body shape, but no parameter is explained further than the schema already does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The only purpose-bearing text is the opaque phrase 'Same as GET, POST {...}', which gestures at a GET counterpart that is never named or described. Nothing states that this runs a rule-based strategy backtest over historical candles, computes performance, or what a 'result' even is; the name and title carry almost all the meaning.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to choose this over siblings such as ta_bias or ta_risk, nor when a backtest is inappropriate. The only routing guidance is pricing ('paid route only'), not task guidance.

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

All YourAITools MCP Hub tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?