Skip to main content
Glama

Nansen

by io.github.nansen-ai
OverviewDiscussionsAdmin

Loading technical indicators

token_technical_indicators
Read-only

Get a technical-analysis snapshot for a token: SMA(20/50/200), EMA(12/26), RSI(14), MACD(12,26,9), Bollinger Bands(20, 2σ), ATR(14), and rolling VWAP(20), computed from the last 260 closed candles at an explicit timeframe.

Supports EVM chains and Solana for on-chain tokens, AND Hyperliquid perpetual futures. For Hyperliquid perps, pass chain="hyperliquid" and use the perp symbol as tokenAddress (e.g. "BTC", "HYPE" for native perps; "XYZ:ORDI" for XYZ-namespaced perps — prefix is normalized automatically).

YOU MUST USE THIS for technical analysis instead of computing indicators from raw token_ohlcv candles — it uses far more history (260 closed candles) and charting-platform conventions (SMA-seeded EMA, Wilder RSI/ATR, population-σ Bollinger).

Timeframes (explicit, no auto-resolution):

  • 5m / 15m / 30m / 1h / 4h: intraday and short-horizon analysis

  • 1d (default): swing/position horizon

  • 1w: long-term trend

Output: a snapshot header (candles used, date range, last close, 5-candle price change) plus one row per indicator, each with a 5-candle trend delta so you can read direction, not just level:

  • SMA 20/50/200: values, price vs each, MA slopes

  • EMA 12/26: values, spread %, widening/narrowing

  • RSI(14): level, prior candle, 5-candle change

  • MACD(12,26,9): line/signal/histogram, rising/falling, candles since signal cross

  • Bollinger(20,2σ): bands, %B, bandwidth and its change

  • ATR(14): value and % of price (volatility), rising/falling

  • VWAP(20): value, price vs VWAP

Indicators without enough closed-candle history render as n/a (e.g. SMA200 on young tokens); the candle count used is always reported. VWAP is n/a on Hyperliquid 5m-1h timeframes (volume is NULL in those views) — use 4h or 1d for Hyperliquid VWAP.

Example Usage: Daily technical snapshot for WETH: { "chain": "ethereum", "tokenAddress": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2", "timeframe": "1d" } 

4-hour snapshot for the BTC Hyperliquid perp:
```
{
    "chain": "hyperliquid",
    "tokenAddress": "BTC",
    "timeframe": "4h"
}
```

Input Schema

NameRequiredDescriptionDefault
requestYesRequest for the token_technical_indicators tool (explicit timeframe, always computed up to now — no date range).

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / request / additionalProperties
      Added value: +false
    • removedInput schema / properties / request / anyOf
      Removed value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Request for the token_technical_indicators tool (explicit timeframe,\nalways computed up to now — no date range).",
-    "properties": {
-      "chain": {
-        "type": "string"
-      },
-      "timeframe": {
-        "default": "1d",
-        "description": "Candle timeframe for the indicator computation: 5m, 15m, 30m, 1h, 4h, 1d, or 1w. Default: 1d.",
-        "enum": [
-          "5m",
-          "15m",
-          "30m",
-          "1h",
-          "4h",
-          "1d",
-          "1w"
-        ],
-        "type": "string"
-      },
-      "tokenAddress": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "chain",
-      "tokenAddress"
-    ],
-    "type": "object"
-  }
-]
    • addedInput schema / properties / request / description
      Added value: +"Request for the token_technical_indicators tool (explicit timeframe,\nalways computed up to now — no date range)."
    • addedInput schema / properties / request / properties
      Added value: +{
+  "chain": {
+    "type": "string"
+  },
+  "timeframe": {
+    "default": "1d",
+    "description": "Candle timeframe for the indicator computation: 5m, 15m, 30m, 1h, 4h, 1d, or 1w. Default: 1d.",
+    "enum": [
+      "5m",
+      "15m",
+      "30m",
+      "1h",
+      "4h",
+      "1d",
+      "1w"
+    ],
+    "type": "string"
+  },
+  "tokenAddress": {
+    "type": "string"
+  }
+}
    • addedInput schema / properties / request / required
      Added value: +[
+  "chain",
+  "tokenAddress"
+]
    • addedInput schema / properties / request / type
      Added value: +"object"
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld; the description covers the substance: computation is over the last 260 closed candles with no date range, indicators lacking history render as n/a with the candle count always reported, and Hyperliquid perp symbols are accepted with automatic prefix normalization. These are non-obvious behaviors an agent cannot infer from schema or annotations, and none of it contradicts readOnlyHint=true.

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 critical routing instruction and the Hyperliquid rule are front-loaded and the timeframe block is scannable, so structure is strong. The per-indicator 'Output' enumeration is somewhat long and partly duplicates the output schema that already exists, which costs some tightness.

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 single nested-request parameter tool with an output schema, everything an agent needs is present: which chains/assets are supported, what happens on insufficient history, the Hyperliquid VWAP caveat, and a worked example. Even though the output schema exists, the return-value summary is accurate rather than contradictory.

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

Parameters5/5

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

Schema coverage is nominally 100%, but only the timeframe enum is documented in the schema; the description supplies the missing semantics for tokenAddress, explaining that on Hyperliquid it takes a perp symbol ('BTC', 'HYPE', 'XYZ:ORDI' with auto-normalized prefix), plus two concrete usage examples. This adds real meaning beyond the schema rather than restating it.

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?

The description opens with a specific verb+resource pair ('Get a technical-analysis snapshot for a token') and enumerates the exact indicators and their periods, so the agent knows precisely what will be computed. It also explicitly distinguishes itself from the closest sibling, token_ohlcv, by naming it as the thing not to use for indicator computation.

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?

It states the positive case ('YOU MUST USE THIS ... instead of computing indicators from raw token_ohlcv candles'), gives the reason (more history, charting-platform conventions), and maps timeframes to analysis horizons (5m–4h intraday, 1d swing, 1w long-term). It also flags the edge case where a different timeframe must be chosen (VWAP on Hyperliquid 5m–1h is n/a, use 4h or 1d).

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

All Nansen 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