Backtesting Arena

Asset Snapshot — one coin, one call

arena_get_asset_snapshot

Read-only

Where does this coin stand? ONE call per Binance USDT pair instead of six: last daily close, 7/30/90/365-day returns, relative strength vs BTC and vs ETH on the same horizons (with the MEASURED base rate next to it — the median altcoin loses against Bitcoin, so a positive number is a description, not an edge), the F6 trend state vs BTC, ATH/drawdown/days-since-ATH on the available exchange history (ath_scope says which), SMA200 distance, a parabolic state (in a parabolic run now? last run? plus what followed such runs per exit rule, from knowledge object parabolic_base_rate), realized 30d volatility and ATR%, liquidity from our own daily Binance universe measurement (24h-volume rank today vs 30 days ago, 30d mean/median volume, band), tokenomics ratios from the gem screener (Pro+, CoinGecko ratios only), derivatives (BTC only so far), price_time_displacement (how far back in time today’s close sits: days since first reached, share of days below today, in USD and vs BTC, plus the place in the daily ranking — full ranking in knowledge type ptd_ranking) and a data_quality block: history span, candle count, missing days, coverage %, source/stitch, listing status (delisted pairs are flagged) and a mechanical A/B/C grade whose rule travels in the payload. Every source can fail independently — sources_used / sources_unavailable make the basis auditable. Works for any Binance USDT pair, not just BTC/ETH/SOL. detail: 'full' adds the raw BTC/ETH benchmark returns behind the relative numbers. Descriptive, no signal. For the strategy-side question ("should I take this entry?") use arena_get_signal_context. [Free tier]

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": {
      "pair": "<pair>"
    },
    "name": "arena_get_asset_snapshot"
  }
}

Input Schema

Name	Required	Description	Default
`pair`	Yes	Binance USDT pair, e.g. 'SOLUSDT'. Case-insensitive.
`detail`	No	'standard' (default). 'full' adds the raw BTC/ETH benchmark returns used for the relative numbers.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
AddedSep 24, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With readOnlyHint=true already covering the safety profile, the description adds substantial behavioral context: independent source failures, auditable sources_used/sources_unavailable fields, data_quality grading, delisted-pair flagging, free-tier status, and the fact that the output is descriptive rather than a signal. This goes well beyond what the annotation provides.

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 opening question and 'ONE call instead of six' framing are front-loaded and effective, but the body is a single dense run-on sentence with heavy parentheticals. The length is partly justified by the many metrics returned, yet the structure would be easier to parse if broken into shorter logical groups.

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 lack of an output schema and only a readOnly annotation, the description provides an unusually complete picture of what the tool returns, how sources can fail, what data_quality covers, and how detail='full' changes the response. An agent has enough context to call the tool correctly and interpret its output limits.

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%, so the schema already fully documents both 'pair' and 'detail'. The description reinforces that it works for any Binance USDT pair and that detail='full' adds raw BTC/ETH benchmarks, but this largely repeats the schema rather than adding new parameter-level syntax or constraints.

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 identifies the resource as a per-coin snapshot for any Binance USDT pair, not just BTC/ETH/SOL, and enumerates the main contents such as returns, relative strength, trend state, volatility, liquidity, tokenomics, derivatives, and data quality. It also explicitly distinguishes itself from the strategy-oriented sibling by saying 'For the strategy-side question ... use arena_get_signal_context'.

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

Usage Guidelines4/5

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

It gives a clear usage context ('Where does this coin stand?') and explicitly routes strategy/entry questions to arena_get_signal_context. However, it does not systematically compare against other descriptive siblings like arena_get_spot_price or arena_get_indicator_snapshot, so the alternative guidance is useful but not exhaustive.

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

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