Skip to main content
Glama
Sign In

Backtesting Arena

by io.github.Schoasch
OverviewDiscussionsAdmin

Get BTC Short-Term-Holder Cost Basis (latest)

arena_get_sth_cost_basis
Read-only

What did recent buyers pay on average — and how far is spot from that? Latest BTC short-term-holder cost basis (realized price of coins younger than ~155 days, BRK brk_sth_realized_price), derived STH-MVRV (spot ÷ STH cost basis), an in_loss flag, plus ±1σ/±2σ bands: basis × exp(±k·σ), σ of ln(price ÷ basis) over a 730-day ROLLING window (sigma_method/sigma_window_days travel in the payload; similar construction to public STH band charts, own convention — not a rebuild). band_zone names the state (above/below basis, beyond ±2σ); sth_mvrv_percentile is the rolling 730d rank. Measured band coverage (2026-08-25, full history): 32.1% of days outside ±1σ (near the Gaussian 31.7%), 7.4% outside ±2σ (wider than the Gaussian 4.6% — fat tails); the bands are descriptive geometry (the measured coverage above tells you how literally to take them). On-chain context you weigh with the percentile field. [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_sth_cost_basis"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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"
-]
  2. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations only say readOnlyHint=true, and the description goes far beyond that: it discloses the rolling 730-day sigma window, that sigma_method/sigma_window_days travel in the payload, measured band coverage (32.1% outside ±1σ, 7.4% outside ±2σ with fat tails), and that the bands are 'descriptive geometry'. That is exactly the calibration context an agent needs to interpret output without over-trusting it.

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?

The lead question and metric definition are front-loaded, which is good, but the single dense paragraph packs nested parentheticals, formula notation, provenance caveats and statistics into one block. Much of it earns its place, but the ±1σ/±2σ construction sentence is hard to parse on first read and could be split or trimmed.

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?

With no output schema, the description carries the burden of explaining returns, and it does: sth_mvrv_percentile, in_loss flag, band_zone states, and the band construction are all defined. Nothing material for correct invocation and interpretation 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?

The tool takes zero parameters, so semantics are trivially satisfied; the baseline for 0 params applies. The description correctly adds no parameter noise and instead spends its budget on payload meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete framing question and then names the exact metric: 'Latest BTC short-term-holder cost basis (realized price of coins younger than ~155 days, BRK brk_sth_realized_price)', plus the derived fields it returns. Highly specific, though it never names which sibling (e.g. arena_get_onchain_latest, arena_get_btc_market_structure) an agent should pick instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: 'On-chain context you weigh with the percentile field' suggests it feeds a judgement call, and '[Free tier]' flags cost. There is no explicit when-to-use / when-not-to-use versus the many sibling on-chain and market-structure tools.

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