DexPaprika (CoinPaprika)

Official

Overview Schema Source Related Servers Discussions Admin

getPoolIndicator

Read-onlyIdempotent

Get a technical indicator (RSI, EMA, MACD, Bollinger Bands or VWAP) for one pool, computed server-side from the pool's completed OHLCV candles and returned as a time series. Read-only.

Instructions

Get a technical indicator (RSI, EMA, MACD, Bollinger Bands or VWAP) for one pool, computed server-side from the pool's completed OHLCV candles and returned as a time series. Read-only. Use for 'is this pool overbought?', 'RSI of this pair', 'MACD cross on the last candle', or as a ready-made signal input for a trading or screening agent, instead of fetching getPoolOHLCV and computing the indicator yourself. The indicator follows the pool's price as getPoolOHLCV reports it, with no inversed parameter. History depth and interval follow the same plan limits as getPoolOHLCV; asking for more returns 403 with a message naming the plan that allows it. 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); pool_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
`pool_address`	Yes	REQUIRED: Pool address or identifier
`signal_period`	No	OPTIONAL, macd only: signal line period (default 9)

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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real operational context beyond them: 403 with a plan-naming message when history exceeds plan limits, cursor must not be combined with start, cross-indicator parameter rejection, and a smoothing caveat (start ten periods before the first value you rely on). This is unusually rich behavioral disclosure.

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?

Front-loaded with purpose, then use cases, then behavior, then a trailing parameter recap. The structure is logical and each section earns its place, but the final parameter enumeration largely duplicates the fully-covered schema and adds length for an agent that already has the schema.

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, 4-required analytical tool with an output schema, the description still documents the per-indicator return field shapes (value / macd, signal, histogram / upper, middle, lower) and interpretation guidance (RSI 70/30, MACD histogram sign change). Nothing needed to call or interpret it correctly is 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 description coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it pairs each parameter with its owning indicator (period for rsi/ema/bbands/vwap, fast/slow/signal_period only for macd, std_dev only for bbands) and states the refusal behavior when a foreign parameter is supplied. Mostly it restates schema content, which caps it below 5.

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 first sentence gives a specific verb and resource (compute a named technical indicator for one pool, server-side, from completed OHLCV candles) and enumerates the supported indicators. It distinguishes itself from getPoolOHLCV (raw candles) and getTokenIndicator (token scope) so an agent can route correctly without opening either schema.

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?

Explicit when-to-use phrasing ('is this pool overbought?', 'RSI of this pair', 'MACD cross on the last candle') plus a named alternative ('instead of fetching getPoolOHLCV and computing the indicator yourself'). It also states the precondition that interval must be passed every time and that indicator-specific params are refused, which prevents misuse.

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