Backtesting Arena

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

arena_get_etf_flows

Read-only

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, SOL, XRP, LTC, HBAR, DOGE, LINK, AVAX or DOT (US spot ETFs; the last seven have stored history only from 2026-09-21, so their 30d/90d windows are null until covered — note says so). No ZEC or NEAR ETF data. Source SoSoValue. [Free tier]

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "arena_get_etf_flows"
  }
}

Input Schema

Name	Required	Description
`days`	No	Length of the returned daily series in days (every US trading day in the window). Default 365, clamped 7–1095.
`asset`	No	Which US spot-ETF flows. Default BTC. XRP/LTC/HBAR/DOGE/LINK/AVAX/DOT: stored history starts 2026-09-21 (grows daily).
`format`	No	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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 29, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / days / maximum
```
Added value: +9007199254740991
```
- addedInput schema / properties / days / minimum
```
Added value: +-9007199254740991
```

Changed2 schema fields changedOct 20, 2026

changedInput schema / properties / asset / description

Previous value: -"Which spot-ETF flows. Default BTC."New value: +"Which US spot-ETF flows. Default BTC. XRP/LTC/HBAR/DOGE/LINK/AVAX/DOT: stored history starts 2026-09-21 (grows daily)."

changedInput schema / properties / asset / enum

Previous value: -[
-  "BTC",
-  "ETH",
-  "SOL"
-]New value: +[
+  "BTC",
+  "ETH",
+  "SOL",
+  "XRP",
+  "LTC",
+  "HBAR",
+  "DOGE",
+  "LINK",
+  "AVAX",
+  "DOT"
+]

Changed1 schema field changedOct 2, 2026

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"
+}

Changed1 schema field changedSep 28, 2026

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."

Changed3 schema fields changedAug 25, 2026

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"
-]
```

AddedJul 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With only readOnlyHint in annotations, the description carries real weight and delivers: closed trading days return net_flow_usd_m null with market_closed true, null windows for recently listed assets, `availability` semantics for point-in-time work, and an honest disclosure of source-inconsistency days. It also pre-empts the apparent contradiction between acceleration_usd_m and the boolean accelerating, which is exactly the kind of field-level behavior an agent cannot infer.

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?

Dense but front-loaded and organized by concern – impulse semantics, the acceleration/accelerating confusion, data-quality caveats, then parameters. Some sentences are long and the impulse four-state explanation is partly restated, which costs a point against strict conciseness.

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?

No output schema exists, so the description must explain returned fields, and it does for impulse, acceleration_usd_m, accelerating, reversal_recovered_pct, reversal_basis_usd_m, source_inconsistencies, market_closed, availability and resolution. An agent could interpret the response correctly without further documentation.

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 schema already carries the basics; the description adds the rationale for format='columns' (far smaller output), the BTC default, and the 2026-09-21 history start that makes 30d/90d windows null. These restate and slightly enrich the schema rather than introduce new semantics.

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 the resource (spot-ETF net flows in USD millions) and the specific value-add over a point-in-time snapshot: 30d/90d windows, a direction label and a daily series. The opening framing question ('is the flow impulse turning or accelerating?') plus the explicit contrast with 'the summary' lets an agent pick this tool without opening the 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?

Clear contextual guidance: use it when direction and speed matter rather than a single delta, pass format='columns' for long windows, and default/alternate assets are listed. It does not name the sibling tool that provides the point-in-time summary, so the routing is implied rather than explicit.

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.