Skip to main content
Glama

Backtesting Arena

by io.github.Schoasch

Get Platform Activity Dashboard

arena_get_platform_activity

What are people backtesting right now? What is being backtested on Backtesting Arena right now — platform activity, NOT market sentiment. hotAssets, hotStrategies, trendingUp/trendingDown, assetDistribution, strategyAssetMatrix and totalRuns aggregate over the window selected by period (7d default, 30d or 90d). Three fields have FIXED windows independent of period: dailyActivity (daily counts, up to 365 days — year heatmap), weeklyTrend (weekly counts, up to 365 days), profitTrend (share of profitable runs per pair, last 30 days vs. previous 30 days). The counts include our own systematic coverage runs, so this measures where testing attention concentrates (coverage-weighted), not crowd positioning; for market sentiment use arena_get_fear_greed, arena_get_funding_rate, arena_get_altcoin_season or arena_get_pulse. Replaces arena_get_sentiment (deprecated alias, removed after 2026-11-15). Pass detail:'summary' for a ~2 KB digest (totals + top-3 of each list, no matrix or daily series) — prefer it unless you need the full blocks; the full response is ~53 KB. [Free tier]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNo'summary' = totals + top-3 lists (~2 KB, names what it truncates); 'full' (default) = all 11 blocks (~53 KB incl. strategyAssetMatrix and daily series).
periodNoAggregation window. Default '7d'.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "'summary' = totals + top-3 lists (~2 KB, names what it truncates); 'full' (default) = all 11 blocks (~53 KB incl. strategyAssetMatrix and daily series).",
+  "enum": [
+    "summary",
+    "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. Added

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries full disclosure burden and discharges it thoroughly: counts include systematic coverage runs so the metric is coverage-weighted rather than crowd positioning, three fields have FIXED windows independent of `period`, response sizes are quantified (~2 KB vs ~53 KB), and free-tier status is stated. These are behavioral quirks an agent could not infer from the schema.

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

Conciseness4/5

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

Exceptionally information-dense and front-loaded: purpose and the market-sentiment distinction come first, followed by block contents, window behavior, caveats, alternatives, deprecation, and size guidance — every sentence earns its place. Minor deductions for the doubled opening question ('What are people backtesting right now? What is being backtested...') and the single dense unbroken paragraph.

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 tool with no annotations and no output schema, the description covers the full decision surface: the 11 blocks and what they contain, window semantics including the fixed-window exception, response-size implications, the coverage-weighting caveat, alternatives, and deprecation status. Nothing required to invoke it correctly is missing.

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% and both params have enums with descriptions, so the baseline is 3. The description adds real value beyond the schema: it explains that `period` only affects some blocks while three fields ignore it, and it ties `detail` to concrete size and truncation tradeoffs — meaning beyond the enum labels.

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 names a specific resource (platform activity dashboard on Backtesting Arena) with concrete blocks (hotAssets, hotStrategies, trendingUp/trendingDown, assetDistribution, strategyAssetMatrix, totalRuns), and actively disambiguates itself with 'platform activity, NOT market sentiment'. This distinguishes it from numerous arena_get_* sentiment siblings without needing to open their schemas.

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?

Explicitly routes sentiment-seeking callers to arena_get_fear_greed, arena_get_funding_rate, arena_get_altcoin_season or arena_get_pulse, and advises preferring detail:'summary' unless the full blocks are needed. It also warns that arena_get_sentiment is a deprecated alias removed after 2026-11-15 — concrete when-to-use and when-not-to-use guidance.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation2/5

Many tools cover overlapping market indicators (e.g., cycle state, pulse, bullmarket ampel, volatility phases) and several share similar get_*_history patterns, which could cause an agent to select the wrong one. However, each tool has detailed descriptions with explicit references to related tools to reduce ambiguity.

Naming Consistency3/5

Tool names generally follow a verb_noun pattern (arena_get_*, arena_list_*, arena_run_*, arena_subscribe_*), but there are inconsistencies such as 'validate_strategy' (no arena_ prefix), 'arena_status' (not a clear verb_noun), and variations like 'arena_run_grid_backtest' vs 'arena_run_backtest'.

Tool Count2/5

With 84 tools, the server is heavily over-scoped for a typical MCP server, likely causing navigation and selection overhead. While the domain (crypto backtesting and analytics) is broad, 84 tools exceed reasonable coherence and impose a high cognitive load.

Completeness4/5

The tool surface covers a wide range of analytics (market indicators, backtesting, validation, alerts, subscriptions, reports) with few obvious dead ends. Minor gaps exist like lack of direct portfolio management or strategy editing, but core workflows are well covered.

Resources