Skip to main content
Glama
Sign In

Backtesting Arena

by io.github.Schoasch
OverviewDiscussionsAdmin

Batch — several snapshots in one call

arena_batch
Read-only

Several market snapshots in ONE call instead of one roundtrip per read. Batchable reads (14): spot_price, pulse, cycle, fear_greed, funding_rate, macro_regime, iv_snapshot, etf_flows, stablecoin_supply, mayer_multiple, onchain_latest, max_pain, altcoin_season, bullmarket_ampel. Pass 1-6 queries; each returns its result OR a structured error (partial success — one failing query does not abort the rest). Each query consumes one rate-limit unit: the batch saves roundtrips, not quota. Payloads, tier gates and source attribution are identical to the single tools; per-query args match the single tool's parameters (e.g. {tool: "iv_snapshot", args: {currency: "BTC"}}). For history tools, backtests or anything not in the list, call the single tool. [Free tier]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "queries": "<queries>"
    },
    "name": "arena_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
queriesYes1-6 queries, executed in order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / queries / items / additionalProperties
      Removed value: -false
    • addedInput schema / properties / queries / items / properties / args / propertyNames
      Added value: +{
+  "type": "string"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnlyHint=true, it discloses the key behaviors an agent would otherwise learn the hard way: partial success (one failing query does not abort the batch), per-query rate-limit consumption, and that payloads/tier gates/source attribution match the single tools. This is exactly the context annotations cannot carry.

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?

The value proposition and partial-success semantics are front-loaded, and every sentence carries information. The 14-item enumeration is bulky but is the actual whitelist the agent needs, so it earns its space rather than being padding.

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 carries the return burden — and it does, describing per-query result-or-structured-error semantics and identical payload shape to the single tools. Combined with the 1-6 bound and ordering in the schema, an agent has everything needed to invoke 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, and the description adds real value on top by explaining that per-query args mirror the underlying single tool's parameters, with a concrete example ({tool: "iv_snapshot", args: {currency: "BTC"}}). It stops short of documenting anything about the free-form args object's valid keys, which is inherent to the passthrough design.

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 a specific verb and resource — executing several market snapshots in one call — and enumerates the 14 batchable reads, so an agent can tell exactly what is and is not covered. It is explicitly distinguished from the per-tool siblings by saying history/backtests must use the single tools.

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?

Gives a clear when-to-use (replace N roundtrips with one batch), a when-not-to-use (history tools, backtests, anything outside the list → call the single tool), and an operational caveat that quota is not saved. Nothing about selection is left to inference.

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