Skip to main content
Glama

Backtesting Arena

Get Crypto Cycle Snapshot (BTC / ETH / SOL)

arena_get_cycle

Crypto cycle position — where are we in the cycle? Default BTC: point-in-time 9-indicator aggregation (Pi-Cycle Top & Bottom, Mayer Multiple, weekly RSI, 200-week-MA distance, halving position, Fear & Greed, BTC-dominance trend, mining-difficulty trend — each indicator’s 0-100 sub-score is in the score_* fields; the weights are in drivers[] under fields="full"; components without input are excluded and weights renormalized, see indicator_coverage). Includes an ath block (E32): ATH on UTC daily-close basis with ath_date, days_since_ath and drawdown_from_ath_pct vs BOTH the scoring price and the live spot. Pass asset=ETH or asset=SOL for a per-coin cycle read built from the transferable price-derived indicators (Mayer, weekly-RSI, 200-week-MA distance) with renormalized weights; BTC-native indicators (halving, dominance, mining, F&G, Pi-Cycle) are returned as not_applicable rather than faked. All return raw + Z-Score, signal enum, and a percentiles block ranking each indicator against that asset’s own history. The signal enum is a FIXED SCORE-BAND LABEL (<25 accumulation · 25–45 recovery · 45–60 expansion · 60–75 distribution · ≥75 overheated), not an independent market-phase detection: the 45–60 band is the neutral middle, so a mid-band score reads "expansion" even in a drawdown market — the label describes the score band, not the market. BTC additionally returns highlights[] (rule-based markers for currently unusual indicator values — descriptive, versioned ruleset; empty array = nothing unusual) and price_context (price at scoring time vs live spot with drift % — the scores rest on the scoring-time price). Point-in-time scored — not reconstructable from a generic price API. The volatility series itself is arena_get_volatility_history; this tool carries the regime context around it. score_fields_note explains the four score fields: z_score/z_adj_score are the composite standardized against its own history and mapped back onto the 0-100 scale, NOT statistical z-values; halving_context.ath_days_after_halving puts the observed cycle high next to days_since_halving. Pass fields="full" (BTC) for drivers[]: each indicator sub-score with its renormalized weight, contribution (they add up to raw_score — the input of the z_adj_score that signal follows) and percentile_rank against its own history. Related: arena_get_historical_analog (what followed states like this one), arena_get_bullmarket_ampel, arena_get_pulse. [Free tier]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
assetNoWhich asset’s cycle. Default BTC. ETH/SOL return a price-derived cycle read with not_applicable fields for BTC-native indicators.
fieldsNoBTC only. 'full' adds `drivers[]` (indicator sub-scores with renormalized weight, contribution summing to raw_score, percentile_rank with basis and n) plus drivers_note.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / fields
      Added value: +{
      +  "description": "BTC only. 'full' adds `drivers[]` (indicator sub-scores with renormalized weight, contribution summing to raw_score, percentile_rank with basis and n) plus drivers_note.",
      +  "enum": [
      +    "full"
      +  ],
      +  "type": "string"
      +}
  2. 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"
      -]
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: point-in-time scored and not reconstructable from a price API, missing components excluded and weights renormalized, ETH/SOL BTC-native indicators returned as not_applicable rather than faked, and — critically — an explicit warning that the signal enum is a fixed score-band label, not independent market-phase detection. This preempts the most likely misinterpretation of the output.

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?

It is front-loaded (purpose and BTC default first) and much of the density is justified by the absence of an output schema, but the single wall-of-text paragraph packs many clauses via em-dashes and parentheticals, hurting scannability. Several embedded asides (e.g., the long signal-band restatement) could be tightened without losing meaning.

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 high-complexity tool with no output schema, the description is thorough: it documents the ath block, percentiles, highlights[], price_context, score_fields_note, halving_context, and the drivers[] contents, plus the per-asset deviations. An agent has enough to interpret the returns correctly without a schema.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning beyond the schema: it explains what ETH/SOL actually return (not_applicable BTC-native fields with renormalized weights) and enumerates what drivers[] plus drivers_note contain under fields="full". This goes past the enum values the schema already lists.

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?

States a specific verb+resource (“crypto cycle position”) with an explicit default (BTC) and per-asset variants, and it actively disambiguates from siblings by naming arena_get_volatility_history as the series-level tool while this one “carries the regime context around it.” An agent can tell this apart from arena_get_pulse, arena_get_bullmarket_ampel, and arena_get_historical_analog without opening any schema.

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?

Provides clear selection context: default BTC, pass asset=ETH/SOL for a price-derived read, pass fields="full" for drivers[], and it names related follow-up tools (historical_analog, bullmarket_ampel, pulse). It stops short of explicit when-to-use/when-not routing (e.g., no statement of when to prefer this over arena_get_bullmarket_ampel), so it is clear context without full exclusion guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.