Skip to main content
Glama

Backtesting Arena

by io.github.Schoasch
OverviewDiscussionsAdmin

Get Arena Pulse Historical Series

arena_get_pulse_history

How did market heat get to where it is? Returns the Arena-Pulse TIME SERIES: one row per day with date, 0–100 score and band, in ascending date order. Use it for trend, turning points and "how did we get here"; for today's value alone call arena_get_pulse (cheaper, one row). include_components=true adds the 8 stored component readings per day (key, rawValue, earnedPoints, maxPoints) — this answers WHICH component moved the score, and caps the window at 365 days (the payload is ~8× a score row); check component_epochs before comparing component values across dates. Range capped by tier. [Free 30d / Pro 365d / Power unlimited]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoNumber of days back from today (auto-clamped by tier — Free=30, Pro=365, Power=3650).
include_componentsNoDefault false (rows carry date, score, band only). When true, each row also carries the 8 stored component readings of that day; window capped at 365 days.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_components
      Added value: +{
+  "description": "Default false (rows carry date, score, band only). When true, each row also carries the 8 stored component readings of that day; window capped at 365 days.",
+  "type": "boolean"
+}
  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.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It states the return format (one row per day, date/score/band, ascending), the optional component expansion (8 component readings with key, rawValue, earnedPoints, maxPoints), the window cap of 365 days when include_components=true, the ~8× payload multiplier, and the tier-dependent range cap. It also discloses a caveat about comparing component values across dates.

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 appropriately sized for a tool with two parameters, component-expansion complexity, and usage distinctions. Each sentence earns its place: the opening question frames the use case, the return format is stated immediately, the sibling alternative is mentioned early, and the component mode/tier caps are explained without fluff.

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 no output schema and no annotations, the description supplies everything an agent needs to invoke the tool correctly: exact row structure, optional component fields, window/range caps, the component_epochs prerequisite, and guidance on when to use the simpler sibling. Nothing essential 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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the purpose of include_components ('answers WHICH component moved the score') and the component_epochs caveat. However, it partially repeats schema information about the 365-day cap and tier clamping, which limits the additional semantic lift.

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 clear framing question and then states a specific verb+resource: 'Returns the Arena-Pulse TIME SERIES: one row per day with date, 0–100 score and band, in ascending date order.' It explicitly distinguishes itself from its sibling arena_get_pulse (today's value alone), so an agent can tell exactly what this tool does and how it differs.

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 gives explicit when-to-use context: 'Use it for trend, turning points and "how did we get here"; for today's value alone call arena_get_pulse (cheaper, one row).' It also provides a prerequisite warning ('check component_epochs before comparing component values across dates') and documents tier-based range caps. No ambiguity remains about selecting this tool over alternatives.

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