Skip to main content
Glama

Backtesting Arena

by io.github.Schoasch
OverviewDiscussionsAdmin

Get MA-Distance Time Series (measured, not estimated)

arena_get_ma_distance_history

How far above or below its moving averages did price stand back then? A measured time series, not an estimate. Covers six MAs (50/100/200-day and 50/100/200-week; weekly MAs are simple averages over ISO-week closes, the same definition arena_get_cycle uses, so today's value agrees with that tool). Per date and MA: distance_pct plus TWO percentile ranks — expanding against the pair's own full prior history (with rank_n, null below 500 observations) and rolling over the trailing 504 days. Warm-up discipline: before an MA's full window exists the field is null, never an average over fewer days — a "200-week MA" computed from 400 days looks plausible and is a different metric; the coverage block names each MA's first valid date. BTCUSDT reaches back to 2011-07 via the platform's own pre-Binance closes (source named in price_source); the first valid 200-week value is ~2015-05. Range capped by tier from today backwards; granularity daily/weekly/monthly, coarsened with an explicit note when a request would exceed the row cap. What the numbers are: ratios and ranks, not absolute price or MA levels. For today's absolute MA levels as named marks use arena_get_key_levels (indicator_levels block); for the cycle-scored 200-week distance use arena_get_cycle. [Free 30d / Pro 365d / Power 3650d]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoISO date, default today.
masNoSubset of MAs; default all six.
fromNoISO date. Clamped to the tier window measured back from today.
pairNoPair, e.g. "BTCUSDT" (default), "ETHUSDT", "SOLUSDT". Non-BTC pairs start at their Binance listing.
granularityNoDefault 'daily'. Rows above the cap are coarsened with an explicit note.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / context
      Removed value: -{
-  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
-  "type": "string"
-}
    • removedInput schema / required
      Removed value: -[
-  "context"
-]
  2. Added

TDQS

A5/5.0
Behavior5/5

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It thoroughly documents return semantics (distance_pct, two percentile ranks with rank_n and null below 500 obs), warm-up rules (null before full window, never averaging over fewer days), data source (pre-Binance closes for BTCUSDT), tier-based range capping, granularity coarsening with explicit note, and explicitly states what the numbers are NOT (absolute price/MA levels). This level of transparency is exceptional.

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

Conciseness5/5

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

The description is long but every sentence earns its place. It front-loads the core purpose in the first sentence, then layers details in logical order (MA list, rank types, warm-up, data source, range, granularity, what-not-included, alternatives). No redundancy: each clause adds new information. The length is justified by the tool's complexity.

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?

With no output schema, the description must explain what the caller receives, and it does so comprehensively: it mentions the returned fields (distance_pct, two percentile ranks, rank_n, coverage block with first valid dates), edge cases (null before warm-up, tier caps, coarsening), and the specific meaning of each value. It also covers the pair-specific start dates. For a tool with this many parameters and behavioral nuances, the description leaves nothing essential unclear.

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?

Even though schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains the ISO-week close definition for weekly MAs, the distinction between expanding and rolling ranks, the meaning of 'rank_n' null condition, the clamping behavior of 'from' to tier window, and the coarsening behavior for granularity. Each parameter's semantics is enriched, not just restated.

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 opens with a precise verb-resource statement ('How far above or below its moving averages did price stand back then?') and clearly distinguishes itself from siblings by naming arena_get_key_levels and arena_get_cycle with specific use cases. The title adds 'measured, not estimated' which further clarifies its unique role. This is exactly what an agent needs to quickly identify when to call this tool.

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?

The description explicitly states when to use this tool vs alternatives: 'For today's absolute MA levels as named marks use arena_get_key_levels; for the cycle-scored 200-week distance use arena_get_cycle.' It also clarifies the context (measured time series vs estimates) and warns about the warm-up discipline. This gives the agent clear decision criteria without having to open other tools' definitions.

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

All Backtesting Arena 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