DexPaprika

getTokenIndicator

Read-onlyIdempotent

Get a technical indicator (RSI, EMA, MACD, Bollinger Bands or VWAP) for one token, computed server-side from the token's USD candles across every pool it trades in on the network (the same series as getTokenOHLCV), returned as a time series. Read-only. Runs on the caller's own Dev, Pro or Enterprise API key, set as the Authorization header on the connection to this server; without one it returns DP401_API_KEY_REQUIRED and sends nothing upstream, and a free key gets 403. In either case fall back to getPoolIndicator on the token's most liquid pool, found with getTokenPools sorted by volume. Values come oldest first, one per completed candle: rsi, ema and vwap return value; macd returns macd, signal and histogram; bbands returns upper, middle and lower. RSI over 70 is commonly read as overbought and under 30 as oversold; a MACD histogram that changes sign means MACD crossed its signal line. RSI, EMA and MACD are smoothed, so start at least ten periods before the first value you rely on. Params: network (required); token_address (required); indicator (required): 'rsi', 'ema', 'macd', 'bbands' or 'vwap'; interval (pass it every time: '1m','5m','10m','15m','30m','1h','6h','12h','24h' or '1d'); start (optional; a relative offset such as '-24h' or '-7d', Unix seconds, RFC3339 or yyyy-mm-dd; without it you get the last limit values); end (optional, exclusive); limit (default 100, max 1000); cursor (next_cursor of the previous page, not with start); period for rsi (default 14), ema (20), bbands (20) and vwap (14); fast_period (12), slow_period (26) and signal_period (9) for macd only; std_dev (2) for bbands only. A parameter that belongs to another indicator is refused.

Input Schema

Name	Required	Description
`end`	No	OPTIONAL: End of the range, exclusive, same formats as start. Defaults to now
`limit`	No	OPTIONAL: Values per response (default 100, max 1000)
`start`	No	OPTIONAL: First candle. A relative offset from now is simplest: '-24h', '-7d' (units s, m, h, d). Also Unix seconds, RFC3339 or YYYY-MM-DD. Without it you get the last `limit` values
`cursor`	No	OPTIONAL: next_cursor from the previous page. Do not combine with start
`period`	No	OPTIONAL: rsi (default 14), ema (default 20), bbands (default 20), vwap (default 14). Not for macd
`network`	Yes	REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana')
`std_dev`	No	OPTIONAL, bbands only: band width in standard deviations (default 2)
`interval`	No	Candle interval the indicator is computed on. Pass it every time; '1d' equals '24h'
`indicator`	Yes	REQUIRED: 'rsi', 'ema', 'macd', 'bbands' (Bollinger Bands) or 'vwap'
`rationale`	Yes	REQUIRED. 1-2 sentence rationale for this call (e.g. "User asked for X; calling Y to fetch Z"). Logged for MCP improvement, never shown to end users. No PII or secrets. See the server `instructions` field for the full convention and worked examples.
`fast_period`	No	OPTIONAL, macd only: fast EMA period (default 12)
`slow_period`	No	OPTIONAL, macd only: slow EMA period (default 26), must be above fast_period
`signal_period`	No	OPTIONAL, macd only: signal line period (default 9)
`token_address`	Yes	REQUIRED: Token contract address

Output Schema

Name	Required	Description
`data`	Yes	One value per completed candle, oldest first.
`network`	No
`interval`	No
`indicator`	No
`parameters`	No	Parameters used, defaults included.
`next_cursor`	No	Pass as cursor for the next page; empty on the last page.
`pool_address`	No	Set on pool indicators.
`has_next_page`	No
`token_address`	No	Set on token indicators.

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedOct 23, 2026

removedOutput schema / properties / data / items / additionalProperties
```
Removed value: -true
```

addedOutput schema / properties / data / items / anyOf

Added value: +[
+  {
+    "additionalProperties": true,
+    "properties": {
+      "histogram": {
+        "description": "macd minus signal; a sign change is a crossover.",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "lower": {
+        "description": "bbands lower band.",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "macd": {
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "middle": {
+        "description": "bbands middle band (the moving average).",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "signal": {
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "timestamp": {
+        "description": "Open time of the candle, RFC3339.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "upper": {
+        "description": "bbands upper band.",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "value": {
+        "description": "rsi, ema and vwap.",
+        "type": [
+          "number",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "timestamp"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / data / items / properties

Removed value: -{
-  "histogram": {
-    "description": "macd minus signal; a sign change is a crossover.",
-    "type": "number"
-  },
-  "lower": {
-    "description": "bbands lower band.",
-    "type": "number"
-  },
-  "macd": {
-    "type": "number"
-  },
-  "middle": {
-    "description": "bbands middle band (the moving average).",
-    "type": "number"
-  },
-  "signal": {
-    "type": "number"
-  },
-  "timestamp": {
-    "description": "Open time of the candle, RFC3339.",
-    "type": "string"
-  },
-  "upper": {
-    "description": "bbands upper band.",
-    "type": "number"
-  },
-  "value": {
-    "description": "rsi, ema and vwap.",
-    "type": "number"
-  }
-}

removedOutput schema / properties / data / items / required
```
Removed value: -[
-  "timestamp"
-]
```
removedOutput schema / properties / data / items / type
```
Removed value: -"object"
```

changedOutput schema / properties / has_next_page / type

Previous value: -"boolean"New value: +[
+  "boolean",
+  "null"
+]

changedOutput schema / properties / indicator / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / interval / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / network / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / next_cursor / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

removedOutput schema / properties / parameters / additionalProperties
```
Removed value: -{}
```

addedOutput schema / properties / parameters / anyOf

Added value: +[
+  {
+    "additionalProperties": {},
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / parameters / type
```
Removed value: -"object"
```

changedOutput schema / properties / pool_address / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / token_address / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

AddedOct 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, the description discloses authentication behavior, specific error codes, that no upstream request is sent without a valid key, and the fallback path. It also explains return-value semantics for each indicator and warns that RSI, EMA, and MACD are smoothed, so at least ten periods of warm-up are needed before relying on values.

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 description is front-loaded with purpose, then auth/fallback, return semantics, and parameter notes, so an agent can extract the key constraints quickly. It is still long and repeats several schema details, which keeps it from being maximally concise.

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 14-parameter tool with an output schema, the description covers the critical context an agent needs: auth requirements, error behavior, fallback strategy, indicator output fields, smoothing caveats, and indicator-specific parameter rules. Nothing important for correct invocation appears 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?

Schema coverage is 100%, so the baseline is 3. The description restates many schema details but adds useful cross-parameter meaning, especially that interval should be passed every time and that a parameter belonging to another indicator is refused, plus an integrated summary of which parameters apply to which indicator.

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 states a specific verb and resource: get a technical indicator (RSI, EMA, MACD, Bollinger Bands, or VWAP) for one token, computed server-side across all pools and returned as a time series. It also distinguishes the token-wide series from getTokenOHLCV and explicitly routes to the sibling getPoolIndicator in fallback cases.

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 gives explicit when-not guidance tied to API key availability: without a paid key it returns DP401_API_KEY_REQUIRED and sends nothing upstream, while a free key gets 403. It then names the alternative and how to use it: fall back to getPoolIndicator on the token's most liquid pool, found with getTokenPools sorted by volume.

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

All DexPaprika tools Inspect

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

Need Help?