Skip to main content
Glama

Backtesting Arena

Get BTC Key Levels (S/R clusters + indicator levels)

arena_get_key_levels
Read-only

Which price levels matter above and below spot? Reproducible Bitcoin structural levels on BOTH sides of spot, in TWO distinct provenance classes. (1) resistance/support: swing-pivot clusters — where past pivot highs+lows cluster into price zones (touch-count, band, last-touch date, signed distance), resistance above spot, support below, nearest-first. (2) indicator_levels.above / .below: named indicator STANDS as marks — 200-day & 200-week simple moving averages, Bull Market Support Band (20-week SMA, 21-week EMA) and 50-week SMA of the last completed week, short-term-holder cost basis, Pi-Cycle legs — each carrying its source, formula and as_of date. The two classes are kept separate on purpose: pivots are where price REACTED before, indicator levels are where an indicator STANDS now. Both are measured price clusters: they say where trading has concentrated, not where anyone defends a level. [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_key_levels"
  }
}

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. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, and the description adds meaningful beyond-schema context: the deliberate separation of pivot clusters from indicator stands, the inclusion of source/formula/as_of provenance per level, and the caveat that these are measured concentration zones rather than defended levels. The '[Free tier]' tag also discloses an access constraint. It does not describe result size, ordering guarantees beyond 'nearest-first', or rate limits.

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 two numbered provenance classes and the front-loaded question make it easy to scan, and almost every clause carries information. It is somewhat dense and slightly repetitive, restating the pivot-vs-indicator distinction twice (once in the 'kept separate on purpose' sentence, again in the 'measured price clusters' caveat), which could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 0 params, read-only annotations and no output schema, the description carries the full burden of describing the return surface and does so in detail, down to sub-fields per level class. What remains unstated is minor: relative ordering across the two classes, approximate level counts, and response size.

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 there is no parameter meaning to convey; the baseline for a 0-param schema applies. The description instead spends its space explaining output shape fields (touch-count, band, last-touch date, signed distance), which is useful but belongs to a different dimension.

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?

The description names a specific resource (Bitcoin structural price levels on both sides of spot) and enumerates its two output classes (swing-pivot S/R clusters vs. named indicator stands), so an agent knows exactly what it returns. It stops short of explicitly contrasting itself with near-neighbors like arena_get_indicator_snapshot or arena_get_btc_market_structure, which the indicator-levels content could be confused with.

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?

The opening question ('Which price levels matter above and below spot?') implies the use case and the 'on BOTH sides of spot' framing implies it is a structural-levels lookup rather than a single-value quote. However, there is no explicit when-to-use/when-not statement and no named alternative for the overlapping indicator-snapshot territory.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.