DexPaprika (CoinPaprika)

Official

by coinpaprika

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

getTokenIndicator

Read-onlyIdempotent

Instructions

Get a technical indicator (RSI, EMA, MACD, Bollinger Bands or VWAP) for one token, computed server-side from its USD candles across every pool it trades in on the network (the series getTokenOHLCV returns), as a time series. Requires a Dev, Pro or Enterprise plan: set DEXPAPRIKA_API_KEY to that key and DEXPAPRIKA_API_BASE_URL to https://api-pro.dexpaprika.com. On a keyless or free key this returns 403 (DP403_PLAN_REQUIRED); then use getPoolIndicator on the token's main pool, found with getTokenPools sorted by volume. Use for 'RSI of this token' or a token-level signal for an agent; for one pair use getPoolIndicator. 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.

Addedv2.8.0Oct 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The annotations already cover the safety profile (read-only, idempotent, non-destructive, open-world), but the description adds substantial behavioral context: plan/auth requirements, exact error code behavior, server-side computation basis, oldest-first ordering, one value per completed candle, indicator-specific return fields, RSI/MACD interpretation rules, and smoothing warm-up. This is far more than the annotations alone provide and contains no contradictions.

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 long but appropriately front-loaded: purpose, plan constraints, fallback, output shape, interpretation, then parameters. Almost every sentence provides useful context for a complex 14-parameter tool. It loses a point for repeating several schema-level parameter details, making it denser than strictly necessary.

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 complex, plan-gated, multi-parameter indicator tool, the description is complete: it covers purpose, routing alternatives, authentication/plan behavior, output fields, indicator interpretation, warm-up needs, and parameter constraints. Although an output schema exists, the description still helpfully explains return fields and is not missing anything an agent needs to call the tool 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 description coverage is 100%, so the schema already documents each parameter, including defaults and ranges. The description mostly repeats that information but adds a useful cross-parameter constraint: a parameter belonging to another indicator is refused. That extra validation guidance goes slightly beyond the schema, but most parameter semantics are already covered by structured fields.

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 for one token, computed server-side from its USD candles across every pool it trades in as a time series. It explicitly distinguishes this from getTokenOHLCV (which returns the candle series) and from getPoolIndicator (which gives a pair/pool-level indicator), so an agent can tell the tools apart without inspecting schemas.

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 concrete when-to-use guidance ('RSI of this token' or a token-level signal for an agent) and an explicit alternative for one pair (getPoolIndicator). It also states the plan requirements and the keyless/free-key fallback path, including the exact 403 code and the workaround via 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.