Skip to main content
Glama

atr

Read-onlyIdempotent

[Trading Data API] Average True Range (Wilder's) + volatility-regime classification (low/normal/high/extreme by historical percentile). Crypto or stocks.

Example: /v1/atr?symbol=BTC&timeframe=1h&period=14

Use when you need volatility for position sizing or stops: Wilder ATR plus a low/normal/high/extreme regime. Not for implied volatility for BTC/ETH (use volatility).

Behavior: read-only. Priced via x402 (USDC on Base) or free with WICKEDAPI_API_KEY; with neither, you get HTTP 402 with the decoded price in payment_required (a price quote, not a failure).

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": {
      "symbol": "<symbol>"
    },
    "name": "atr"
  }
}

Input Schema

NameRequiredDescriptionDefault
classNoOptional. stock|crypto for non-curated symbols.
periodNoOptional. ATR period (default 14).
symbolYesRequired. e.g. BTC, NVDA, SPY (or any with &class=).
timeframeNoOptional. 1m,5m,15m,30m,1h,2h,4h,6h,12h,1D,1W (default 1h).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, but the description goes well beyond them: it discloses the x402/USDC-on-Base payment model, the free path via WICKEDAPI_API_KEY, and that an unauthenticated call yields HTTP 402 with a decoded price quote rather than a failure. That payment-semantics detail is exactly the kind of context annotations cannot express.

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?

Purpose and regime classification are front-loaded, followed by a concrete example, usage routing, and a compact behavior note. Slightly long due to the payment paragraph, but each block (example, exclusion, pricing) carries distinct information.

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?

For a read-only computed-metric tool with full parameter documentation and no output schema, the definition covers what it computes, when to use it, the sibling alternative, and the payment/auth edge case an agent must handle. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so symbol, timeframe, period, and class are already documented with defaults and enum-like value lists in the schema. The example URL reinforces the symbol/timeframe/period usage but the description adds no semantics beyond the schema, making baseline 3 correct.

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 computation — "Average True Range (Wilder's) + volatility-regime classification (low/normal/high/extreme by historical percentile)" — for a named resource domain (crypto or stocks). It also distinguishes itself explicitly from the sibling `volatility` tool (implied volatility for BTC/ETH).

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?

"Use when you need volatility for position sizing or stops" names the motivating use cases, and "Not for implied volatility for BTC/ETH (use volatility)" gives an explicit exclusion with the correct alternative sibling.

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.