Skip to main content
Glama

Backtesting Arena

by io.github.Schoasch
OverviewDiscussionsAdmin

Get Spot-ETF Net-Flow Trend (BTC / ETH / SOL)

arena_get_etf_flows

Spot-ETF net flows (USD millions) — is the flow impulse turning or accelerating? The summary only gives point-in-time deltas; this exposes the trend: 30d/90d net flow, a direction label (inflows/outflows/flat) and a daily series (every US trading day: cumulative inflow + that day's net flow; resolution states points and spacing) so direction and speed are visible, not just a single delta. Read impulse for what the flow is doing — it has four states (accelerating / decelerating / reversal / flat) and is the field to quote. Two neighbouring fields measure different things and are easy to confuse: acceleration_usd_m is the signed difference last-30d minus prior-30d and gets LARGE precisely when the flow reverses, while the older boolean accelerating requires the same direction AND a bigger magnitude — so a swing from outflows to inflows shows a big positive acceleration_usd_m together with accelerating: false, which is correct and reads like a contradiction. impulse reports that case as 'reversal'. When impulse is 'reversal', reversal_recovered_pct says how much of the preceding counter-move has actually come back, with its denominator in reversal_basis_usd_m — quote it alongside, because a reversal in direction is not yet a reversal in the stock. Both are null otherwise. source_inconsistencies lists the days on which the source's own daily net flow and the change of its cumulative disagree (BTC: 2 of ~700 days, 2026-04-23/24 — the two-day sum matches, the day split does not); cumulative deltas and the 30d/90d windows are unaffected, per-day sums over those dates are. NYSE closing days that the source still lists come back with net_flow_usd_m null and market_closed: true (a closed market is not a zero flow). availability states when a day's flow was first known (measured from our own ingest; the source has no publication time) — use it for point-in-time work. For long windows pass format: 'columns' (parallel arrays, far smaller). Default BTC; pass asset=ETH or asset=SOL. Source SoSoValue. [Free tier]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoLength of the returned daily series in days (every US trading day in the window). Default 365, clamped 7–1095.
assetNoWhich spot-ETF flows. Default BTC.
formatNoDefault 'rows' (series[] of objects). 'columns' returns series_columns instead — parallel arrays (date, cum_net_inflow_usd_m, net_flow_usd_m, market_closed) with each field name once; use it for long windows, it is much smaller.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
+  "description": "Default 'rows' (series[] of objects). 'columns' returns series_columns instead — parallel arrays (date, cum_net_inflow_usd_m, net_flow_usd_m, market_closed) with each field name once; use it for long windows, it is much smaller.",
+  "enum": [
+    "rows",
+    "columns"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / days / description
      Previous value: -"Length of the returned cumulative series in days. Default 365, clamped 90–1095."New value: +"Length of the returned daily series in days (every US trading day in the window). Default 365, clamped 7–1095."
  3. 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"
-]
  4. Added

TDQS

A4.6/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 thoroughly: it clarifies the apparent contradiction between acceleration_usd_m and the boolean accelerating, defines impulse states, explains that reversal_recovered_pct/reversal_basis_usd_m are null otherwise, documents source_inconsistencies dates, market_closed:true on NYSE holidays (closed market != zero flow), and availability timing. This is unusually rich behavioral disclosure.

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?

Front-loaded with the core purpose and result shape, and nearly every sentence carries unique field semantics. It is dense and formatted as one long block, which slightly hurts scannability, but little is wasted.

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?

There is no output schema, so the description must explain returns — and it does comprehensively: series contents, resolution, direction labels, null semantics, and provenance caveats. An agent has everything needed to call and interpret it correctly.

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 the baseline is 3, but the description adds meaning: it ties format:'columns' to long-window efficiency, implies the 30d/90d windows that days spans, and notes the default asset. It goes beyond restating the schema even if the schema already covers most fields.

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?

Specific verb and resource: it exposes the spot-ETF net-flow TREND (30d/90d net flow, direction label, daily series) rather than point-in-time deltas, and explicitly contrasts itself with 'the summary' that only gives deltas. An agent can distinguish it from the many arena siblings without opening a 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?

Gives concrete selection guidance: pass format:'columns' for long windows, default asset is BTC with ETH/SOL alternatives, and use availability for point-in-time work. It stops short of naming a competing sibling or stating when NOT to use it, so it is clear context without explicit exclusions.

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