A
licenseNot graded
qualityB
maintenancePerplexity for social: ask what competitors are running across social and get answers grounded in real ad and creative data, not guesses.
2
Apache 2.0
DexPaprika
Server Details
Real-time DEX and on-chain data across 36 blockchains: liquidity pools, token prices, OHLCV, transactions, and cross-chain search. 17 keyless tools.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 62 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.6/5.0
Scored across 20 tools
Disambiguation5/5
Each tool targets a distinct resource+action (network, DEX, pool, token) crossed with a clear operation (discovery, details, OHLCV, indicators, transactions). The few potentially overlapping pairs (getNetworkPools vs getNetworkPoolsFilter, getTopTokens vs filterNetworkTokens, getTokenDetails vs getTokenMultiPrices) are explicitly delineated in descriptions with 'choose this over X' guidance. An agent can reliably select the right tool.
Naming Consistency5/5
Nearly all tools follow a clean camelCase verb_noun pattern (getNetworkPools, getPoolDetails, getTokenOHLCV, filterNetworkTokens). The only outliers (search, submitFeedback) are single standard verbs that remain unambiguous. Fully predictable naming.
Tool Count4/5
20 tools is slightly heavy but justified by a broad domain spanning networks, DEXes, pools, tokens, and per-resource analytics (details, OHLCV, indicators, transactions). Each tool earns its place, though the filter/ranking pairs add some redundancy.
Completeness5/5
The surface covers the full lifecycle: onboarding (getCapabilities), discovery (search, getNetworks, getStats), drill-down (DEXes, pools, tokens, transactions), historical/analytics (OHLCV, indicators), and a feedback path. No obvious dead ends for the stated market-data purpose.
Available Tools
20 toolsfilterNetworkTokensARead-onlyIdempotentInspect
Get tokens on one network matching numeric thresholds, returned under 'results' with has_next_page and next_cursor. Read-only and keyless. Choose this over getTopTokens when the user gives numeric constraints or a time window. Use for 'tokens with FDV over $10M on Base', 'newly created tokens today', or 'low-liquidity high-volume tokens'. Optional filters (AND-combined): volume_24h_min/max, liquidity_usd_min/max, fdv_min/max, txns_24h_min, price_change_percentage_24h_min/max, created_after/created_before (a relative offset such as '-24h', Unix seconds, RFC3339 or YYYY-MM-DD). Also network (required); limit (default 50, max 100); cursor to page; sort_by (default 'volume_usd_24h', alias order_by); sort_dir asc/desc (default 'desc', alias sort).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly. | |
| limit | No | OPTIONAL: Items per page (default: 50, max: 100) | |
| cursor | No | OPTIONAL: Pagination cursor. Pass `next_cursor` from a previous response to fetch the next page. Replaces the old page number. | |
| fdv_max | No | OPTIONAL: Maximum FDV in USD | |
| fdv_min | No | OPTIONAL: Minimum FDV in USD | |
| network | Yes | REQUIRED: Network ID from getNetworks | |
| sort_by | No | OPTIONAL: Sort field. Defaults to 'volume_usd_24h'. Prefer the canonical names; short legacy names are still accepted. The REST API calls this parameter order_by. | |
| order_by | No | OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly. | |
| sort_dir | No | OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort. | |
| 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. | |
| txns_24h_min | No | OPTIONAL: Minimum transactions in 24h | |
| created_after | No | OPTIONAL: Only tokens created at or after this time: a relative offset such as '-24h' or '-7d', Unix seconds, RFC3339 or YYYY-MM-DD | |
| created_before | No | OPTIONAL: Only tokens created at or before this time, same formats as created_after (e.g. '-1h') | |
| volume_24h_max | No | OPTIONAL: Maximum 24h volume in USD | |
| volume_24h_min | No | OPTIONAL: Minimum 24h volume in USD | |
| liquidity_usd_max | No | OPTIONAL: Maximum token liquidity in USD | |
| liquidity_usd_min | No | OPTIONAL: Minimum token liquidity in USD | |
| price_change_percentage_24h_max | No | OPTIONAL: Maximum 24h price change, in percent | |
| price_change_percentage_24h_min | No | OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds tokens down at least 20%. This is the only price-change window tokens carry; for 6h, 1h or 5m use getNetworkPoolsFilter. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered; the description still adds 'keyless' and the response envelope (results/has_next_page/next_cursor) which annotations do not express. It stops short of noting rate limits or result-size caveats, so it is strong but not exhaustive.
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 the return shape, the sibling routing rule and usage examples before the parameter recap. It is long, and enumerating every filter partly duplicates the schema, but each block is dense and earns its place.
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?
An output schema exists, yet the description still names the envelope so the agent knows how to paginate; it covers the required param, defaults, limits and alias mapping. Nothing needed to call this 19-parameter tool 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 coverage is 100%, so the baseline is 3, but the description adds genuine value beyond the schema: that optional filters are AND-combined, the accepted time formats for created_after/before ('-24h', Unix, RFC3339, YYYY-MM-DD), and the alias relationships (order_by/sort_by, sort/sort_dir). These clarifications go past the per-field schema text.
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 verb+resource ('Get tokens on one network matching numeric thresholds') and immediately names the alternative it is not ('Choose this over getTopTokens'). An agent can distinguish it from getTopTokens 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 routing rule with the selecting condition (numeric constraints or a time window) plus three concrete user-phrasing examples. No inference required to pick this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getCapabilitiesARead-onlyIdempotentInspect
Get the static agent onboarding guide for this server: supported workflows, network name synonyms (mapping words like 'eth' to the canonical slug 'ethereum'), recommended call sequences, and common pitfalls. Read-only and keyless. Read it once at the start of a session before your first query, or when asked 'how do I use this API?', 'what order should I call things in?', or 'which slug maps to eth?'. This returns onboarding docs, not live market data; for the actual list of network slugs use getNetworks, and for coverage totals use getStats. Takes no parameters beyond a short rationale.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| stats | Yes | |
| server | Yes | |
| workflows | Yes | Named tool sequences for common agent tasks. |
| rate_limits | No | How limits work for hosted tool calls. Not the REST allowances: your own plan does not apply, except to own_key_tools. |
| agent_skills | Yes | |
| documentation | Yes | |
| common_pitfalls | Yes | Known edge cases agents should be aware of. |
| network_synonyms | Yes | Canonical network id -> common alternates an agent might try. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, open-world. The description adds genuinely new context: it is static docs, keyless, and returns onboarding material rather than live market data — an important distinction that prevents misuse as a data endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what the tool is, then what it contains, then when to call it, then what it is not. Every sentence carries distinct information and there is no padding.
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?
An output schema exists, so return value details are out of scope. The description supplies purpose, triggers, exclusions and sibling routing — everything needed to invoke correctly.
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?
The single parameter has 100% schema description coverage, so the schema already fully documents the required rationale. The description only notes 'takes no parameters beyond a short rationale', adding slight framing but no syntax or format detail beyond the schema's baseline.
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 verb and resource ('Get the static agent onboarding guide for this server') and enumerates its contents: workflows, slug synonyms, recommended call sequences, pitfalls. It also explicitly separates itself from siblings getNetworks and getStats, so an agent can place it immediately.
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?
Gives concrete triggers ('read it once at the start of a session before your first query', 'how do I use this API?', 'which slug maps to eth?') and names the alternative tools to use for adjacent needs (getNetworks for slugs, getStats for coverage). When/when-not and alternatives are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getDexPoolsARead-onlyIdempotentInspect
Get the pools belonging to one specific DEX on one network, e.g. all Uniswap v3 pools on ethereum, returned under 'results' with has_next_page and next_cursor. Read-only and keyless. Proxies /networks/{network}/pools/search with a dex_name filter; the old /networks/{network}/dexes/{dex}/pools endpoint was removed, so the 24h volume field is now volume_usd_24h and there is no page_info. Narrower than getNetworkPools (a single exchange, not the whole chain). Use for 'show me Raydium pools', 'top pairs on PancakeSwap', or 'liquidity on Orca'. Get the dex id from getNetworkDexes or search first, and pass that response's dex_id field ('uniswap_v3'), matched case-insensitively. Do not pass its dex_name field ('Uniswap V3'): a human display name returns HTTP 200 with an empty results[] rather than an error, so an empty answer here usually means the wrong form of the name was sent. Params: network (required slug); dex (required id, e.g. 'uniswap_v3'; the REST API calls this query parameter dex_name); limit (default 10, max 100); cursor (pass the previous next_cursor to page); sort_by (default 'volume_usd_24h', canonical *_24h fields, short legacy names still accepted, alias order_by); sort_dir 'asc'/'desc' (default 'desc', alias sort). The old page number is superseded: page 2 and above return an error pointing at cursor.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dex | Yes | REQUIRED: the dex_id field from getNetworkDexes (e.g., 'uniswap_v3'), matched case-insensitively. Do not pass that response's dex_name field, the human display name (e.g., 'Uniswap V3'): it returns an empty results[] instead of an error, so a wrong value looks like a real but empty answer. The REST API calls this parameter dex_name. | |
| page | No | SUPERSEDED: the replacement endpoint is cursor-paginated and ignores page. page=1 (or 0) still returns the first page as before; page=2 or above returns an error telling you to use cursor. | |
| sort | No | OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly. | |
| limit | No | OPTIONAL: Number of items per page (default: 10, max: 100) | |
| cursor | No | OPTIONAL: Pagination cursor. Pass `next_cursor` from a previous response to fetch the next page (read `has_next_page` to know if more remain). Replaces the old page number. | |
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| sort_by | No | OPTIONAL: Sort field. Canonical parameter name. Defaults to 'volume_usd_24h'. Prefer the canonical *_24h names; short legacy names (volume_usd, transactions, last_price_change_usd_24h) are still accepted and normalized. The REST API calls this parameter order_by. | |
| order_by | No | OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly. | |
| sort_dir | No | OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort. | |
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the safety profile is covered; the description still adds real context: keyless access, the return envelope ('results' with has_next_page/next_cursor), the upstream REST path being proxied, the removed endpoint and renamed volume field, and the dangerous silent-empty behavior when a display name is passed. It does not cover rate limits, though that is a minor omission relative to what is disclosed.
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-loads the core purpose and the sibling contrast before the parameter detail, and every sentence carries operational information (routing, prerequisites, pagination migration, name-form trap). It is dense to the point of being a wall of text in one unbroken paragraph, which costs a little readability.
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 tool with 10 params, required rationale, and an output schema, the description covers enough to call it correctly: scope, network/dex prerequisites, the aliasing between MCP and REST names, cursor-vs-page migration, sort defaults, and the silent-empty failure mode. Return values are largely left to the output schema, as appropriate.
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 the baseline is 3, and much of the description's parameter prose (limit default/max, cursor paging, page superseded, sort_by/sort and order_by aliases) is a near-verbatim restatement of the schema descriptions. The one genuinely additive parameter insight — that an empty results[] usually signals the wrong name form — is already in the schema too, so little is added beyond structured data.
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 precise verb+resource+scope: 'Get the pools belonging to one specific DEX on one network,' with a concrete example ('all Uniswap v3 pools on ethereum'). It explicitly distinguishes itself from the sibling getNetworkPools ('a single exchange, not the whole chain'), so an agent can route 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?
Gives trigger phrases ('show me Raydium pools', 'top pairs on PancakeSwap'), a prerequisite chain (call getNetworkDexes or search first and pass dex_id), and an explicit negative rule (do not pass dex_name) with the failure mode explained. It also names the alternative tool to use for whole-chain listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getNetworkDexesARead-onlyIdempotentInspect
List the DEXes (exchanges) operating on one network, such as Uniswap on ethereum or Raydium on solana, returned under 'dexes' with page_info (page, total_pages). Read-only and keyless. Use for 'which DEXes are on Base?', 'does Solana have Orca?', or to get a dex id to feed into getDexPools. Scope is a single network; call getNetworks first for the slug. Params: network (required slug); limit (default 10, max 100); page (default 1, 1-indexed); sort_by (only 'pool'; legacy alias order_by); sort_dir 'asc' or 'desc' (default 'desc'; legacy alias sort).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | OPTIONAL: Page number, 1-indexed. Server accepts page=0 (treated as page=1) for backward compatibility. | |
| sort | No | OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly. | |
| limit | No | OPTIONAL: Number of items per page (default: 10, max: 100) | |
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| sort_by | No | OPTIONAL: Sort field. Canonical parameter name; older tools used order_by. The REST API calls this parameter order_by. | |
| order_by | No | OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly. | |
| sort_dir | No | OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort. | |
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| dexes | Yes | |
| page_info | Yes |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint, idempotentHint, non-destructive), and the description adds substantial context beyond them: 'keyless' states auth requirements, and it reveals the return shape ('returned under dexes with page_info (page, total_pages)') plus default values and legacy alias behavior. No contradiction with annotations — 'Read-only' aligns with 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?
Purpose is front-loaded in the first clause, followed by compact behavioral, usage, prerequisite, and routing notes. The trailing param enumeration is dense and readable as a quick-reference, though it partially duplicates a schema that already fully documents every parameter.
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?
With an output schema, rich annotations, and 100% schema parameter coverage, the description covers the remaining ground: when to call, concrete example queries, prerequisite and downstream tools, auth posture, return envelope, and defaults. No material gap remains for an agent to invoke this tool correctly.
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 the baseline is 3. The description's param summary (defaults, alias pairs sort_by/order_by and sort_dir/sort) is convenient, but that same information already lives in each schema property description, so it adds convenience rather than new meaning.
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 verb and resource ('List the DEXes (exchanges) operating on one network') with concrete examples (Uniswap on ethereum, Raydium on solana). The single-network scope and the pointer to getDexPools as the downstream consumer distinguish it from getNetworkPools and getDexPools without requiring an agent to open any 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?
Explicitly enumerates the query intents it serves ('which DEXes are on Base?', 'does Solana have Orca?') and the downstream use ('to get a dex id to feed into getDexPools'). It also names the prerequisite step ('call getNetworks first for the slug'), giving an agent a complete routing path across siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getNetworkPoolsARead-onlyIdempotentInspect
Get the top liquidity pools across a whole network, ranked by 24h volume by default, returned under 'results' with has_next_page and next_cursor. Read-only and keyless. This is the primary chain-wide pool discovery tool. Use for 'biggest pools on ethereum', 'top trading pairs on Base', or 'most active pools on Solana'. Narrow to one exchange with getDexPools, or apply numeric/time filters with getNetworkPoolsFilter. Params: network (required slug); limit (default 10, max 100); cursor (pass previous next_cursor to page); sort_by (default 'volume_usd_24h', canonical *_24h fields, alias order_by); sort_dir 'asc' or 'desc' (default 'desc', alias sort).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly. | |
| limit | No | OPTIONAL: Number of items per page (default: 10, max: 100) | |
| cursor | No | OPTIONAL: Pagination cursor. Pass `next_cursor` from a previous response to fetch the next page (read `has_next_page` to know if more remain). Replaces the old page number. | |
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| sort_by | No | OPTIONAL: Sort field. Canonical parameter name. Defaults to 'volume_usd_24h'. Prefer the canonical *_24h names; short legacy names (volume_usd, transactions, last_price_change_usd_24h) are still accepted. The REST API calls this parameter order_by. | |
| order_by | No | OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly. | |
| sort_dir | No | OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort. | |
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description still adds real behavioral context beyond them: 'keyless' (no auth), the response envelope ('results' with has_next_page and next_cursor), and the cursor-based paging contract. It stops short of rate limits or result-size caveats, so it is strong but not exhaustive.
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 the core purpose, then examples, then routing, then a compact parameter digest. The trailing param sentence is somewhat redundant against a 100%-covered schema, but it is scannable and nothing is wasted or buried.
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?
An output schema exists, so return values need not be explained, yet the description still names the envelope and paging fields. With a required network slug, aliased sort params and required rationale all accounted for, an agent has everything needed to call this correctly.
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% and the enum lists are fully documented in the schema, so the baseline is 3. The description restates defaults (limit 10/max 100, sort_dir desc), the alias pairs (sort/order_by) and cursor paging, but adds little syntax or format meaning that the schema does not already carry.
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 verb+resource ('Get the top liquidity pools across a whole network') plus the default ranking ('24h volume'), and explicitly positions itself as 'the primary chain-wide pool discovery tool'. It names the siblings it is not (getDexPools for single-exchange, getNetworkPoolsFilter for numeric/time filters), so an agent can route without opening any 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?
Gives concrete trigger phrases ('biggest pools on ethereum', 'top trading pairs on Base', 'most active pools on Solana') and names two alternatives with the exact condition that selects each. Both when-to-use and when-to-use-something-else are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getNetworkPoolsFilterARead-onlyIdempotentInspect
Get pools on one network filtered by numeric thresholds, returned under 'results' with has_next_page and next_cursor. Read-only and keyless. Choose this over getNetworkPools when the user gives numeric constraints or a time window. Use for 'pools over $1M liquidity on Base', 'pools created in the last 24h', or 'high-volume low-liquidity pairs'. Optional filters (AND-combined): volume_24h_min/max, volume_7d_min/max, liquidity_usd_min/max, txns_24h_min, price_change_percentage_{24h,48h,6h,1h,5m}_min/max (percent, negatives allowed), created_after/created_before (a relative offset such as '-24h', Unix seconds, RFC3339 or YYYY-MM-DD). Also network (required); limit (default 50, max 100); cursor to page; sort_by (default 'volume_usd_24h', alias order_by); sort_dir asc/desc (default 'desc', alias sort).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly. | |
| limit | No | OPTIONAL: Items per page (default: 50, max: 100) | |
| cursor | No | OPTIONAL: Pagination cursor. Pass `next_cursor` from a previous response to fetch the next page. Replaces the old page number. | |
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| sort_by | No | OPTIONAL: Sort field. Canonical parameter name. Defaults to 'volume_usd_24h'. Prefer the canonical *_24h names; short legacy names (volume_24h, volume_7d, liquidity) are still accepted. The REST API calls this parameter order_by. | |
| order_by | No | OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly. | |
| sort_dir | No | OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort. | |
| 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. | |
| txns_24h_min | No | OPTIONAL: Minimum transactions in 24h | |
| created_after | No | OPTIONAL: Only pools created at or after this time: a relative offset such as '-24h' or '-7d', Unix seconds, RFC3339 or YYYY-MM-DD | |
| volume_7d_max | No | OPTIONAL: Maximum 7d volume in USD | |
| volume_7d_min | No | OPTIONAL: Minimum 7d volume in USD | |
| created_before | No | OPTIONAL: Only pools created at or before this time, same formats as created_after (e.g. '-1h') | |
| volume_24h_max | No | OPTIONAL: Maximum 24h volume in USD | |
| volume_24h_min | No | OPTIONAL: Minimum 24h volume in USD | |
| liquidity_usd_max | No | OPTIONAL: Maximum pool liquidity in USD | |
| liquidity_usd_min | No | OPTIONAL: Minimum pool liquidity in USD | |
| price_change_percentage_1h_max | No | OPTIONAL: Maximum 1h price change, in percent | |
| price_change_percentage_1h_min | No | OPTIONAL: Minimum 1h price change, in percent | |
| price_change_percentage_5m_max | No | OPTIONAL: Maximum 5m price change, in percent | |
| price_change_percentage_5m_min | No | OPTIONAL: Minimum 5m price change, in percent. The shortest window we carry, so it is the one to reach for on 'what is moving right now'. | |
| price_change_percentage_6h_max | No | OPTIONAL: Maximum 6h price change, in percent | |
| price_change_percentage_6h_min | No | OPTIONAL: Minimum 6h price change, in percent | |
| price_change_percentage_24h_max | No | OPTIONAL: Maximum 24h price change, in percent | |
| price_change_percentage_24h_min | No | OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds pools down at least 20%. | |
| price_change_percentage_48h_max | No | OPTIONAL: Maximum 48h price change, in percent | |
| price_change_percentage_48h_min | No | OPTIONAL: Minimum 48h price change, in percent |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: 'keyless' (no auth required), the response envelope with has_next_page/next_cursor, and the fact that filters are AND-combined. It does not add rate-limit or error behavior, but against annotations that already carry safety, this is strong.
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?
It is front-loaded with purpose and return shape, then routing, then examples, then the filter list—a sensible order for a 27-param tool. It is dense and includes some restatement of schema content, but nothing is padded with marketing language.
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 27-param, two-required-filter tool with an output schema, the description covers pagination defaults (limit 50/max 100, cursor), sort defaults and aliases, time-window formats, and negative handling. An agent has everything needed to call it correctly without further reading.
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 the baseline is 3; the schema already documents every filter's units and the created_after/before formats. The description's enumeration of filters largely restates the schema, with the notable additions being 'AND-combined' semantics and the percent/negatives note. Net value above the schema is marginal.
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 gives a specific verb+resource+scope ('Get pools on one network filtered by numeric thresholds') and even names the sibling it is not (getNetworkPools), so the agent can distinguish it 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?
It explicitly routes: 'Choose this over getNetworkPools when the user gives numeric constraints or a time window,' and then supplies concrete usage examples ('pools over $1M liquidity on Base', 'pools created in the last 24h'). When-to-use and the alternative are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getNetworksARead-onlyIdempotentInspect
List every blockchain network DexPaprika indexes, each row carrying its network id (slug), 24h volume, transaction count, and pool count. Read-only and keyless. Start here (or getCapabilities) to get the exact network slug that nearly every other tool requires as its 'network' argument. Use for 'which chains do you support?', 'is Base/Solana/Arbitrum covered?', or 'what is the slug for Polygon?'. Returns the full array with no pagination or sorting; takes no parameters beyond a short rationale. For platform-wide totals rather than a per-network list use getStats.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| networks | Yes | All supported blockchain networks with current 24h volume + indexing stats. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints, and the description adds useful behavioral details beyond those: it states 'keyless' access, 'returns the full array with no pagination or sorting,' and that no parameters besides rationale are accepted. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is packed with high-value information—purpose, return fields, keyless access, usage examples, and a cross-reference to getStats—while remaining compact. Every sentence contributes to either selection, invocation, or interpretation of the tool; there is no filler.
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 simple list tool with a single required parameter and an output schema, the description fully covers what the agent needs: what the result contains, how to obtain the network slug for downstream calls, pagination/sorting behavior, and the alternative for platform-wide statistics. Nothing critical 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?
The schema already documents the single rationale parameter with a clear description (coverage 100%), and the description reiterates 'takes no parameters beyond a short rationale.' This adds marginal clarity but does not materially extend what the schema provides, so baseline 3 is appropriate.
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 begins with a specific verb and resource: 'List every blockchain network DexPaprika indexes,' and enumerates the exact data fields (slug, volume, transaction count, pool count). It distinguishes itself from getStats and getCapabilities, so an agent can clearly tell what this tool does and what it does not.
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?
Gives explicit when-to-use guidance: 'Start here (or getCapabilities) to get the exact network slug that nearly every other tool requires' and provides concrete example queries like 'is Base/Solana/Arbitrum covered?'. It also names the alternative getStats for platform-wide totals, offering both inclusion and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getPoolDetailsARead-onlyIdempotentInspect
Get the full current snapshot for one pool by address: its two tokens, current price, liquidity/TVL, 24h volume, and transaction counts, returned as a single pool object (not a list). Read-only and keyless. Use after search or getNetworkPools surfaces a pool, or for 'price/TVL of this pool?' or 'details for pool 0x...'. Returns live values only; for historical candles use getPoolOHLCV, and for the raw swap feed use getPoolTransactions. Params: network (required slug); pool_address (required, e.g. '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640'); inversed (optional bool, default false, flips the token price ratio to token1/token0).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| inversed | No | OPTIONAL: Whether to invert the price ratio (default: false) | |
| 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. | |
| pool_address | Yes | REQUIRED: Pool address or identifier (e.g., '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640') |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| fee | No | |
| chain | No | |
| dex_id | No | |
| tokens | No | |
| dex_name | No | |
| created_at | No | |
| factory_id | No | |
| last_price | No | |
| price_time | No | |
| price_stats | No | |
| last_price_usd | No | |
| token_reserves | No | |
| created_at_block_number | No |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that the tool is 'Read-only and keyless,' that it 'Returns live values only,' and that the result is a single object rather than a list. This adds meaningful behavioral context that the annotations alone do not provide, and it does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded: purpose comes first, followed by usage context, alternatives, then parameters. Despite length, every sentence earns its place by adding either scoping, routing, or parameter clarification that the schema and annotations do not already cover.
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?
The description fully covers what an agent needs: what the tool returns, when to use it, which siblings to use instead, the read-only/keyless behavior, and the key parameter semantics including the inversed flag. Since an output schema exists, the description does not need to explain return fields in more detail.
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% for all parameters, so the baseline is 3. The description adds value by clarifying the pool_address format with a concrete example and explaining that inversed 'flips the token price ratio to token1/token0,' which is more semantically informative than the schema's 'whether to invert the price ratio'.
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 the full current snapshot for one pool by address,' and enumerates exactly what the snapshot contains (tokens, price, liquidity/TVL, 24h volume, transaction counts). It also explicitly says the result is a 'single pool object (not a list),' which clearly distinguishes it from any list-returning sibling.
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?
The description gives explicit when-to-use guidance: after search or getNetworkPools surfaces a pool, or for questions like 'price/TVL of this pool?' or 'details for pool 0x...'. It also names concrete alternatives and exclusions: use getPoolOHLCV for historical candles and getPoolTransactions for the raw swap feed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getPoolIndicatorARead-onlyIdempotentInspect
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 and keyless. 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. 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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
ParametersJSON 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. |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/non-destructive, but the description adds genuinely non-structured behavior: server-side computation, 'keyless', values ordered oldest-first one per completed candle, cross-indicator parameters being refused, and the smoothing caveat that you must start ~10 periods before the first value you rely on. It stops short of describing pagination limits or error modes beyond the refusal rule.
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 correctly — what it does, why to use it over the alternative, then return shape, then parameters. It is a single dense block that is longer than strictly necessary, and the interpretive guidance (RSI > 70 overbought, MACD histogram sign flip) could be trimmed or split, but nearly every sentence carries actionable content.
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, multi-indicator tool with an output schema and full annotation coverage, the description supplies the selection logic, return-field shape, interval/cursor caveats, and per-indicator parameter routing. An agent has everything needed to choose the tool and construct a correct call.
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; the description still earns credit by consolidating the per-indicator parameter mapping (period for rsi/ema/bbands/vwap, fast/slow/signal for macd, std_dev for bbands) and by adding the two behavioral rules the schema only hints at: pass interval every time, and cursor must not be combined with start. It omits the required rationale parameter, but that is fully documented in the schema.
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?
Opens with a specific verb+resource ('Get a technical indicator ... for one pool') and immediately scopes it to five named indicators computed server-side from the pool's OHLCV candles. It also differentiates itself from the nearest sibling by naming getPoolOHLCV and the pool-vs-token distinction implied by getTokenIndicator.
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?
Gives concrete trigger questions ('is this pool overbought?', 'RSI of this pair', 'MACD cross on the last candle') and an explicit alternative-plus-rationale: use this 'instead of fetching getPoolOHLCV and computing the indicator yourself.' The when-to-use case and the substitute it replaces are both stated outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getPoolOHLCVARead-onlyIdempotentInspect
Get historical OHLCV candles (open, high, low, close, volume) for one pool over a time range, returned as a time-series array. Read-only and keyless. Use for 'price history of this pair', 'hourly chart for the last week', 'candles since Jan 1', or backtesting; for the single current price use getPoolDetails instead. Params: network (required); pool_address (required); start (required; easiest as a relative offset from now such as '-24h' or '-7d', so you need not know today's date; also Unix seconds, RFC3339 or yyyy-mm-dd); end (optional); interval one of '1m','5m','10m','15m','30m','1h','6h','12h','24h' (default '24h'); limit (default 100, max 1000 candles); inversed (optional bool, default false).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | OPTIONAL: End time for historical data, same formats as start (e.g. '-1h') | |
| limit | No | OPTIONAL: Number of OHLCV data points to retrieve (default: 100, max: 1000). One row per `interval`. | |
| start | Yes | REQUIRED: Start time. A relative offset from now is simplest and needs no knowledge of today's date: '-24h' (last 24 hours), '-7d', '-90m' (units s, m, h, d). Also accepts RFC3339 (e.g. '2024-01-01T00:00:00Z'), Unix epoch seconds and YYYY-MM-DD (treated as 00:00:00 UTC). | |
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| interval | No | OPTIONAL: Interval granularity (default: '24h') | 24h |
| inversed | No | OPTIONAL: Whether to invert the price ratio for alternative pair perspective (default: false) | |
| 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. | |
| pool_address | Yes | REQUIRED: Pool address or identifier |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ohlcv | Yes | Open-High-Low-Close-Volume rows ordered by time_open ascending. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so 'Read-only' is largely redundant. However, 'keyless' conveys an authorization fact the annotations do not (no API key required), and the stated default/max behavior (limit max 1000 candles, interval default '24h') adds operational context before invocation.
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, example phrasings, and the sibling alternative, then parameters. It is a single dense paragraph; the trailing parameter recap is somewhat redundant with a 100%-covered schema, but no sentence is filler.
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?
An output schema exists, so return-value detail is unnecessary, and the description covers scope, formats, defaults, required vs optional params, and the sibling boundary. Nothing an agent needs to call it correctly 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 the schema already documents every parameter, including the relative-offset format, the enum, and the limit default. The description's parameter recap largely restates schema content, adding little syntax or edge-case detail beyond it, which lands at the baseline 3.
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 verb and resource ('Get historical OHLCV candles ... for one pool over a time range') plus the return shape ('time-series array'). It explicitly distinguishes itself from the sibling getPoolDetails ('for the single current price use getPoolDetails instead'), so an agent can route between them 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?
Gives concrete usage scenarios ('price history of this pair', 'hourly chart for the last week', 'candles since Jan 1', backtesting) and names the alternative tool for the contrasting case. The when-to-use condition is explicit, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getPoolTransactionsARead-onlyIdempotentInspect
Get one pool's recent individual swap transactions, newest first, returned under 'transactions' (paginate with page, or a cursor). 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 getPoolDetails still gives the pool's 24h transaction counts and volume. These are per-trade records, not aggregated candles (use getPoolOHLCV) or a summary snapshot (use getPoolDetails). Use for 'recent trades on this pool', 'who swapped in the last hour', or 'raw transaction feed'. Params: network (required); pool_address (required); limit (default 10, max 100); page (default 1, up to 100 pages) or cursor (a transaction id); from (optional, inclusive: a relative offset such as '-1h', Unix seconds, RFC3339 or YYYY-MM-DD; capped to the last 7 days); to (optional, exclusive, same formats, must be after from).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | OPTIONAL: Filter transactions up to this time (exclusive), same formats as from. Must be after 'from'. | |
| from | No | OPTIONAL: Filter transactions starting from this time (inclusive): a relative offset such as '-1h' or '-24h', Unix seconds, RFC3339 or YYYY-MM-DD. Results always capped to last 7 days. | |
| page | No | OPTIONAL: Page number, 1-indexed. Up to 100 pages. Server accepts page=0 (treated as page=1) for backward compatibility. | |
| limit | No | OPTIONAL: Number of items per page (default: 10, max: 100) | |
| cursor | No | OPTIONAL: Transaction ID used for cursor-based pagination | |
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| 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. | |
| pool_address | Yes | REQUIRED: Pool address or identifier |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| page_info | Yes | |
| transactions | Yes |
TDQS
A4.8/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, and the description still adds substantial context: API-key requirements on the connection, the specific DP401_API_KEY_REQUIRED failure mode with no upstream call, the 403 for free keys, and the fallback to getPoolDetails. That is uncommon, high-value 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-loads the core purpose and safety profile, then params, then alternatives. Dense but largely earns its length; the auth/fallback sentence is slightly repetitive against the param block, keeping it out of 5 territory.
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 an 8-param read tool with an output schema, this covers purpose, auth preconditions, failure modes, pagination, time filtering, and sibling alternatives. Return shape is delegated correctly to the output schema, and nothing needed to invoke 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 coverage is 100%, so baseline is 3; the description nonetheless consolidates pagination semantics (page up to 100 or cursor by transaction id), the default/max for limit, and the ordering ('newest first') plus the time-filter formats and 7-day cap. It adds ordering and the page-vs-cursor distinction beyond schema text.
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 verb and resource ('one pool's recent individual swap transactions, newest first') and explicitly distinguishes itself from getPoolOHLCV (aggregated candles) and getPoolDetails (summary snapshot). An agent can route without opening a 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?
Names both alternatives and the condition selecting them, and gives concrete use-case phrases ('recent trades on this pool', 'who swapped in the last hour', 'raw transaction feed'). When-to-use is fully covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getStatsARead-onlyIdempotentInspect
Get platform-wide totals for DexPaprika: the number of networks, DEXes, pools, and tokens indexed, returned as a single summary object. Read-only and keyless. Use for 'how much data do you cover?', 'how many chains or pools total?', or a one-line coverage summary. These are ecosystem-wide counts, not per-network figures; use getNetworks for the per-chain breakdown, or getCapabilities for onboarding docs. Takes no parameters beyond a short rationale.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| pools | Yes | Total pools indexed across all chains. |
| chains | Yes | Total chains indexed. |
| tokens | Yes | Total tokens indexed. |
| factories | Yes | Total DEX factory contracts indexed. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful context beyond those annotations: it is keyless, returns a single summary object, and represents ecosystem-wide counts only. This complements the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by concrete use cases, exclusions, sibling alternates, and a note on parameters. Every sentence earns its place; there is no filler or repetition.
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 simple read-only summary tool, the description is complete: it states what is returned, how it behaves, when to use it, and how it differs from sibling tools. The output schema covers return values, and annotations cover safety traits, so nothing essential 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?
The input schema fully documents the sole 'rationale' parameter with clear guidance and constraints, so schema coverage is 100%. The description only adds that there are no functional parameters beyond the rationale, which is helpful but does not materially extend the schema's already thorough parameter semantics.
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 names a specific verb and resource ('Get platform-wide totals for DexPaprika') and enumerates exactly what is counted: networks, DEXes, pools, and tokens. It also clearly distinguishes this from the per-network breakdown provided by getNetworks, so an agent can tell them apart without opening 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?
The description provides explicit example queries ('how much data do you cover?', 'how many chains or pools total?') and explicitly says when not to use it: these are not per-network figures, so use getNetworks for per-chain data and getCapabilities for onboarding docs. This is excellent routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTokenDetailsARead-onlyIdempotentInspect
Get one token's data and metadata by contract address on one network: multi-timeframe price and volume metrics, plus name, website, Twitter, and Telegram links, returned as a single token object. Read-only and keyless. Use for 'price and volume for 0x... on Base' or 'tell me about this token'. If you only have a symbol like WETH, call search first to resolve the address and network. For many tokens' prices at once use getTokenMultiPrices; for the pools holding this token use getTokenPools. Params: network (required slug); token_address (required contract address, e.g. 'JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN' on solana).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| 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. | |
| token_address | Yes | REQUIRED: Token contract address (e.g., 'JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN' for Jupiter on Solana) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| name | No | |
| chain | No | |
| symbol | No | |
| summary | No | |
| website | No | |
| added_at | No | |
| decimals | No | |
| has_image | No | |
| description | No | |
| price_stats | No | |
| total_supply | No | Raw on-chain total supply. Big numbers may overflow JS Number; handle as string for tokens with 18+ decimals. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds beyond these flags by stating the call is keyless, returns a single token object, and includes multi-timeframe metrics plus metadata. This gives the agent practical behavioral context such as no authentication and expected return shape without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence serves a distinct purpose: state the operation, confirm read-only/keyless, provide example queries, route to alternatives, and summarize parameters. It is front-loaded with the core purpose and contains no filler, tautology, or redundant exposition.
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?
Given a full output schema, high schema coverage, and rich annotations, the description provides everything needed to select and invoke the tool correctly. It handles the ambiguous symbol-only case, names related sibling tools, and confirms behavioral expectations. No critical information 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?
The input schema covers all three required parameters with descriptions, so the baseline is 3. The description adds marginal extra meaning like 'slug' for network and an example token address, but mostly restates what is already in the schema. It does not significantly deepen parameter understanding.
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 and resource: 'Get one token's data and metadata by contract address on one network.' It lists concrete contents (price/volume metrics, name, website, Twitter, Telegram links) and explicitly distinguishes itself from siblings like getTokenMultiPrices and getTokenPools. An agent can clearly tell what this tool does and does not do.
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?
The description gives explicit example user intents ('price and volume for 0x... on Base', 'tell me about this token'), instructs to call search first when only a symbol is known, and names alternatives for bulk prices (getTokenMultiPrices) and pools (getTokenPools). This is comprehensive when/when-not guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTokenIndicatorARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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
ParametersJSON 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. |
TDQS
A4.8/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 adds substantial context beyond them: auth requires a Dev/Pro/Enterprise key in the Authorization header, no key yields DP401_API_KEY_REQUIRED with nothing sent upstream, and a free key yields 403. It also documents parameter refusal across indicators and smoothing warm-up behavior.
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 is front-loaded and nearly every clause carries information (auth, fallback, output fields, param rules). It is a single dense block that could be broken into segments, and the interpretation guidance is somewhat peripheral, but the length is largely justified for a 14-parameter, 5-indicator tool.
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?
Given the tool's complexity (14 params, 5 indicator modes, auth gating), the description covers everything an agent needs: required inputs, per-indicator output fields, data ordering, error fallbacks, and smoothing caveats. An output schema exists, so return-value explanation is a bonus rather than a requirement.
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, but the description adds real meaning: it maps each parameter to the indicator it applies to, warns that a parameter belonging to another indicator is refused, and repeats critical defaults. Enum values and formats live in the schema, but the cross-parameter rules and interpretation notes go beyond 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?
States a specific verb and resource ('Get a technical indicator (RSI, EMA, MACD, Bollinger Bands or VWAP) for one token'), plus the computation source ('server-side from the token's USD candles across every pool'). It also distinguishes itself from the sibling getPoolIndicator and links to getTokenOHLCV as the same series, so an agent can route correctly without opening 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?
Gives explicit when-to-use and when-not guidance: when the caller lacks a valid paid key, 'fall back to getPoolIndicator on the token's most liquid pool, found with getTokenPools sorted by volume.' Names the alternatives and the exact condition that selects them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTokenMultiPricesARead-onlyIdempotentInspect
Get current USD prices for up to 10 tokens on the same network in one batched call, returned as a prices array plus a missing_tokens list. Read-only and keyless. Tokens that cannot be priced come back in missing_tokens rather than being dropped, so check that list for partial failures. Use for 'prices for these tokens', 'compare the price of X, Y and Z', or building a portfolio/dashboard snapshot. For one token with full metadata and multi-timeframe stats use getTokenDetails. Params: network (required slug, all tokens must share it); tokens (required array of 1 to 10 contract addresses).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tokens | Yes | REQUIRED: Up to 10 token contract addresses on the same network. | |
| network | Yes | REQUIRED: Network ID from getNetworks | |
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| prices | Yes | USD prices for the requested tokens, in input order. |
| missing_tokens | No | Input tokens that upstream could not price (invalid address, no liquidity, unknown contract). Empty array when all input tokens were resolved. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive, so the description focuses on extra behavior: it is keyless, and tokens that fail to price are returned in missing_tokens instead of being silently dropped, with a warning to check that list. These details materially affect how an agent should interpret results and are not available from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, result shape, safety, partial-failure caveat, use cases, sibling alternative, and parameter constraints. It front-loads the core operation before context, so an agent gets the essential decision information first.
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 batched read tool with a full output schema and safety annotations, this description covers the non-obvious failure mode, the intended use cases, the alternative tool, and cross-parameter constraints. There is no critical gap left to guesswork.
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 schema carries the baseline meaning. The description adds value by emphasizing that network is the slug, all tokens must share it, and tokens are contract addresses, and it restates the 1-to-10 array bound in prose. The required rationale parameter is left to the schema, which is acceptable given its complete description there.
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 clause names a specific operation ('Get current USD prices'), the exact resource scope ('up to 10 tokens on the same network'), and the call style (one batched call). It also differentiates itself from the close sibling getTokenDetails by stating that getTokenDetails is for one token with metadata and multi-timframe stats.
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 matching use cases ('prices for these tokens', 'compare the price of X, Y and Z', portfolio/dashboard snapshot) and names the alternative for single-token enrichment (getTokenDetails). This lets an agent route between siblings without inferring intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTokenOHLCVARead-onlyIdempotentInspect
Get historical USD OHLCV candles for one token over a time range, returned as a time-series array. The price and volume are computed across every pool the token trades in on the network (a volume-weighted price, and volume summed across those pools), not a single pair. 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 getPoolOHLCV on the token's main pool, found with getTokenPools sorted by volume. Use for 'price history of this token' or 'USD chart for this token'; for a single pair's candles use getPoolOHLCV, and for the current price use getTokenDetails. Params: network (required); token_address (required); start (required; easiest as a relative offset from now such as '-24h', so you need not know today's date; also Unix seconds, RFC3339 or yyyy-mm-dd); end (optional, same formats); interval one of '1m','5m','10m','15m','30m','1h','6h','12h','24h' (default '24h'); limit (default 10, max 1000 candles). Dev plan history is limited to the last 30 days. There is no inversed parameter on this endpoint.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | OPTIONAL: End time, same formats as start (e.g. '-1h') | |
| limit | No | OPTIONAL: Number of data points to retrieve (default: 10, max: 1000) | |
| start | Yes | REQUIRED: Start time. A relative offset from now is simplest and needs no knowledge of today's date: '-24h' (last 24 hours), '-7d', '-90m' (units s, m, h, d). Also accepts RFC3339 (e.g. '2024-01-01T00:00:00Z'), Unix epoch seconds and YYYY-MM-DD (treated as 00:00:00 UTC). | |
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| interval | No | OPTIONAL: Interval granularity (default: '24h') | 24h |
| 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. | |
| token_address | Yes | REQUIRED: Token contract address |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ohlcv | Yes | USD candles for the token across all its pools, ordered by time_open ascending. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the read-only/idempotent safety profile; the description adds substantial context beyond that: keys must run on the caller's Dev/Pro/Enterprise key via Authorization header, no key yields DP401_API_KEY_REQUIRED without sending anything upstream, a free key yields 403, and Dev-plan history caps at 30 days. It also discloses the aggregation semantics (volume-weighted price, summed volume).
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 the core purpose and aggregation caveat before alternatives, then auth behavior, then params. It is dense and long, but nearly every sentence carries operational weight; only the param enumeration slightly duplicates the schema rather than adding new 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?
An output schema exists, so return-value explanation is unnecessary, and the description still conveys the shape (a time-series array). It covers auth requirements, error paths, plan limits, aggregation semantics, and sibling routing, leaving no gap an agent needs to call it 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 coverage is 100%, so most parameter detail is already documented. The description still adds value by foregrounding the relative-offset convention as the 'easiest' form and by noting 'there is no inversed parameter on this endpoint', a disambiguation not in the schema, though it largely restates the interval/limit/default facts.
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 verb+resource (get historical USD OHLCV candles for one token) and immediately qualifies the scope: aggregated across every pool the token trades in, volume-weighted, not a single pair. It explicitly distinguishes itself from getPoolOHLCV and getTokenDetails, so an agent can route 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?
Gives explicit use cases ('price history of this token', 'USD chart for this token'), names two alternatives with the condition that selects each (getPoolOHLCV for a single pair, getTokenDetails for current price), and even describes the fallback path when auth fails. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTokenPoolsARead-onlyIdempotentInspect
Get the liquidity pools that contain a specific token on one network, returned under 'results' with has_next_page and next_cursor. Read-only and keyless. Use for 'which pools hold WETH on ethereum?' or 'liquidity venues for 0x...'. Network-scoped, so run search first if unsure of the network; unknown addresses return empty results, not an error. For the token's own price use getTokenDetails. Params: network (required); token_address (required); limit (default 10, max 100); cursor to page; sort_by (default 'volume_usd_24h', alias order_by); sort_dir asc/desc (default 'desc', alias sort). Extra params such as inversed or paired_token_address are unsupported and error.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly. | |
| limit | No | OPTIONAL: Number of items per page (default: 10, max: 100) | |
| cursor | No | OPTIONAL: Pagination cursor. Pass `next_cursor` from a previous response to fetch the next page (read `has_next_page` to know if more remain). Replaces the old page number. | |
| address | No | REMOVED alias for paired_token_address. No longer supported by the API; supplying it returns an error. | |
| network | Yes | REQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana') | |
| reorder | No | REMOVED alias for inversed. No longer supported by the API; supplying true returns an error. | |
| sort_by | No | OPTIONAL: Sort field. Canonical parameter name. Defaults to 'volume_usd_24h'. Prefer the canonical *_24h names; short legacy names (volume_usd, transactions, last_price_change_usd_24h) are still accepted. The REST API calls this parameter order_by. | |
| inversed | No | REMOVED: the pair-perspective flip is no longer supported by the API; the pools/search replacement returns pool-perspective metrics only. Supplying true returns an error. For a single pool, getPoolDetails with inversed=true still flips the perspective. | |
| order_by | No | OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly. | |
| sort_dir | No | OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort. | |
| 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. | |
| token_address | Yes | REQUIRED: Token contract address | |
| paired_token_address | No | REMOVED: the second-token pair filter is no longer supported by the API. Supplying it returns an error. Filter client-side on each result's tokens[] instead. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description still adds non-obvious behavior: keyless auth, the response envelope ('results' with has_next_page/next_cursor), empty-result-rather-than-error semantics, and that extra params like inversed or paired_token_address error out. That is meaningful disclosure beyond the structured fields.
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 and routing guidance, and every sentence carries information. The trailing 'Params:' inventory is somewhat redundant with the fully-documented schema and slightly inflates length, but it is dense rather than padded.
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?
Despite 13 parameters, 3 required, and a mandatory rationale field, the description covers pagination, sorting, network scoping, unsupported params, and error behavior. An output schema exists, so return-value detail is not required and the brief envelope mention is sufficient.
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; the description goes further by restating defaults, max limit, and the alias pairs (sort_dir/sort, sort_by/order_by) and by warning which legacy params are unsupported. It largely mirrors the schema text rather than adding new semantics, so it stops short of a 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?
States a specific verb and resource ('Get the liquidity pools that contain a specific token on one network'), including the scope constraint (network-scoped) that separates it from getNetworkPools and getDexPools. The worked examples ('which pools hold WETH on ethereum?') make the resource unambiguous.
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?
Names an alternative and the condition that selects it: 'For the token's own price use getTokenDetails', plus 'run search first if unsure of the network'. It also sets expectations for edge cases ('unknown addresses return empty results, not an error'), so the agent knows when a valid-looking call is still the right one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTopTokensARead-onlyIdempotentInspect
Get the top tokens on one network ranked by volume, liquidity, transactions, FDV, or 24h price change, returned under 'results' with has_next_page and next_cursor. Read-only and keyless. Use for 'top gainers on Solana', 'highest-volume tokens on Base', or 'biggest tokens by FDV on ethereum'. For arbitrary numeric filters or a time window use filterNetworkTokens instead. Params: network (required slug); limit (default 50, max 100); cursor (pass previous next_cursor to page); sort_by (default 'volume_usd_24h', alias order_by), noting that ranking by raw price is unsupported and silently falls back to volume; sort_dir asc/desc (default 'desc', alias sort).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | OPTIONAL: alias of sort_dir; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes sort, so use this name when calling the REST API directly. | |
| limit | No | OPTIONAL: Items per page (default: 50, max: 100) | |
| cursor | No | OPTIONAL: Pagination cursor. Pass `next_cursor` from a previous response to fetch the next page. Replaces the old page number. | |
| network | Yes | REQUIRED: Network ID from getNetworks | |
| sort_by | No | OPTIONAL: Ranking field. Defaults to 'volume_usd_24h'. Prefer the canonical names (volume_usd_24h, liquidity_usd, txns_24h, fdv_usd, price_change_percentage_24h); short legacy names are still accepted. Note: ordering by price is not supported and falls back to volume. The REST API calls this parameter order_by. | |
| order_by | No | OPTIONAL: alias of sort_by; both are accepted. Not deprecated at the REST layer: api.dexpaprika.com itself takes order_by, so use this name when calling the REST API directly. | |
| sort_dir | No | OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided. The REST API calls this parameter sort. | |
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| query | No | Echo of the resolved query and filters the API applied. |
| results | Yes | |
| next_cursor | No | Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page. |
| has_next_page | No | True if more results are available; fetch them by passing next_cursor as `cursor`. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds useful context: the tool is keyless, pagination uses next_cursor, and ranking by raw price silently falls back to volume. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that covers purpose, use cases, an alternative, return shape, pagination, defaults, aliases, and a behavioral fallback quirk. It is front-loaded and every sentence adds operational value.
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?
The output schema exists, so detailed return-value documentation is not needed. The description covers usage scenarios, routing to the alternative, pagination, sorting behavior, defaults, and authentication state. Paramater-level rules like rationale are reasonably left to the schema.
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 coverage is 100%, so the input schema already documents all parameters and their defaults. The description mostly restates schema information, adding only minor extra value such as noting that network is a slug. With high schema coverage, the baseline score of 3 is appropriate.
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 and object: 'Get the top tokens on one network ranked by volume, liquidity, transactions, FDV, or 24h price change.' It also names the closest alternative, filterNetworkTokens, so an agent can distinguish this tool from its siblings without opening 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 example queries ('top gainers on Solana', 'highest-volume tokens on Base') and explicitly says when to use filterNetworkTokens instead: 'For arbitrary numeric filters or a time window.' This is strong positive and negative routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchARead-onlyIdempotentInspect
Search across ALL networks at once for tokens, pools, and DEXes by name, symbol, or address, returning three arrays: 'tokens', 'pools', and 'dexes'. Read-only and keyless. This is the cross-chain entry point when you do not yet know which network something lives on; once you have a network slug from the results, switch to the network-scoped tools. Use for 'find PEPE', 'what is the address for USDC', or 'which chain is this token on?'. Several words work: 'WETH USDC' returns the pools pairing both, and a network name ('brett base') narrows results to that chain. No matches returns empty arrays, not an error. Params: query (required; a name, symbol, or contract address, e.g. 'uniswap', 'bitcoin', or '0x...'); limit (optional, caps results per category, applied client-side).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | OPTIONAL: Cap items returned per category (tokens, pools, dexes). Upstream returns all matches by default; this client-side slice keeps payloads small for agents. Applies independently to each category. | |
| query | Yes | REQUIRED: Search term (e.g., 'uniswap', 'bitcoin', 'ethereum', 'WETH USDC', or a token address). | |
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| dexes | Yes | |
| pools | Yes | |
| tokens | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, but the description adds real value: keyless operation, empty-array-on-no-match instead of an error, and multi-word query behavior ('WETH USDC'). It doesn't discuss result ordering or pagination, keeping it short of a 5.
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, scope, return shape, then usage, then params. Slightly long due to multiple examples, but each sentence (empty arrays, multi-word behavior) carries information an agent needs.
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?
Output schema exists, so return values needn't be explained, yet the description still notes the three arrays and no-match behavior. Scope, usage, and the sibling handoff are all present — nothing an agent needs to call this 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 coverage is 100% so the baseline is 3, but the description adds semantics beyond the schema — multi-word queries, network-name narrowing ('brett base'), and that limit is a client-side slice per category. Params are well covered.
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 verb (search) plus the three resources searched (tokens, pools, dexes) and the scope (ALL networks). It explicitly distinguishes itself from the network-scoped siblings, so an agent can pick it without opening 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?
Gives explicit when-to-use ('cross-chain entry point when you do not yet know which network') and a handoff rule ('once you have a network slug, switch to the network-scoped tools'), plus concrete example queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submitFeedbackAInspect
Report a problem back to the DexPaprika team when a tool got you stuck, returned something unexpected, lacked data you needed, or behaved differently than documented. Use whenever you hit a dead end, a response shape surprised you, or coverage was missing; even partial feedback helps and every submission is read. Low friction: provide goal, expected, and observed instead of a rationale field.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | REQUIRED: What you (or the user behind you) were trying to accomplish. 10-500 characters; longer goals are validation-rejected at the MCP layer. | |
| expected | No | OPTIONAL: What you expected to happen. Capped at 500 characters; trim or summarize longer narratives. | |
| observed | No | OPTIONAL: What actually happened. Capped at 500 characters; trim or summarize longer narratives. Longer text triggers an MCP -32602 input validation error. | |
| severity | No | OPTIONAL: How badly this affected your task. Default 'minor'. | minor |
| blocked_at | No | OPTIONAL: Tool name or step where you got stuck. | |
| attempted_tools | No | OPTIONAL: List of tool names you called, in order, before submitting this feedback. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True if the feedback row was persisted. |
| message | Yes | |
| severity | No | |
| tracking_id | No | Stable id agents can reference in follow-up submissions; null if persistence failed. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide broad hints (readOnlyHint false, destructiveHint false, etc.), so the description carries the behavioral burden. It discloses that submissions are read, that partial feedback is valued, that there is no rationale field, and that long inputs are validation-rejected at the MCP layer—all useful behavioral context. Nothing in the description contradicts the annotations.
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 and follows with concrete usage triggers and a low-friction tip; every sentence serves a role. Minor redundancy exists between 'stuck, returned something unexpected, lacked data' and 'dead end, response shape surprised, coverage was missing,' but overall it is appropriately sized and scannable.
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 feedback submission tool, the description covers purpose, when to use it, what behavior to expect, and guidance on structuring feedback. The output schema exists, and the input schema fully documents parameters, so no critical information for correctly invoking the tool 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 the schema fully documents all six parameters and their constraints. The description reinforces the goal/expected/observed trio and mentions length caps, but this adds only marginal framing rather than genuinely new parameter meaning. Baseline 3 is appropriate given the complete schema coverage.
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 uses a specific verb and resource ('Report a problem back to the DexPaprika team') and clearly enumerates the situations that warrant submission. It is unmistakably distinct from the data-retrieval sibling tools, none of which handle user feedback.
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?
The description explicitly says 'Use whenever you hit a dead end, a response shape surprised you, or coverage was missing,' giving concrete trigger conditions. It also clarifies that partial feedback is acceptable and directs agents to provide goal, expected, and observed, which functions as usage guidance. No alternative feedback tool exists among siblings, so exclusion statements are unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Added
getPoolIndicator - Added
getTokenIndicator
4 tool updates
- Changed
getDexPools2 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_48h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_48h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
- Changed
getNetworkPools2 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_48h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_48h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
- Changed
getNetworkPoolsFilter4 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_48h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - added
Input schema / properties / price_change_percentage_48h_maxAdded value: +{ + "description": "OPTIONAL: Maximum 48h price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_48h_minAdded value: +{ + "description": "OPTIONAL: Minimum 48h price change, in percent", + "type": "number" +} - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_48h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
- Changed
getTokenPools2 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_48h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_48h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
1 tool update
- Changed
search1 field changed- changed
Input schema / properties / query / descriptionPrevious value: -"REQUIRED: Search term (e.g., 'uniswap', 'bitcoin', 'ethereum', or a token address)."New value: +"REQUIRED: Search term (e.g., 'uniswap', 'bitcoin', 'ethereum', 'WETH USDC', or a token address)."
1 tool update
- Changed
getCapabilities1 field changed- added
Output schema / properties / rate_limitsAdded value: +{ + "additionalProperties": true, + "description": "How limits work for hosted tool calls. Not the REST allowances: your own plan does not apply, except to own_key_tools.", + "properties": { + "basis": { + "type": "string" + }, + "on_limit": { + "type": "string" + }, + "own_key_note": { + "type": "string" + }, + "own_key_tools": { + "items": { + "type": "string" + }, + "type": "array" + }, + "rest_api_limits_url": { + "type": "string" + } + }, + "required": [ + "basis", + "on_limit", + "own_key_tools", + "own_key_note", + "rest_api_limits_url" + ], + "type": "object" +}
1 tool update
- Added
getTokenOHLCV
3 tool updates
- Changed
filterNetworkTokens4 fields changed- changed
Input schema / properties / created_after / descriptionPrevious value: -"OPTIONAL: Only tokens created after this UNIX timestamp"New value: +"OPTIONAL: Only tokens created at or after this time: a relative offset such as '-24h' or '-7d', Unix seconds, RFC3339 or YYYY-MM-DD" - changed
Input schema / properties / created_after / typePrevious value: -"number"New value: +"string" - changed
Input schema / properties / created_before / descriptionPrevious value: -"OPTIONAL: Only tokens created before this UNIX timestamp"New value: +"OPTIONAL: Only tokens created at or before this time, same formats as created_after (e.g. '-1h')" - changed
Input schema / properties / created_before / typePrevious value: -"number"New value: +"string"
- Changed
getNetworkPoolsFilter4 fields changed- changed
Input schema / properties / created_after / descriptionPrevious value: -"OPTIONAL: Only pools created after this UNIX timestamp"New value: +"OPTIONAL: Only pools created at or after this time: a relative offset such as '-24h' or '-7d', Unix seconds, RFC3339 or YYYY-MM-DD" - changed
Input schema / properties / created_after / typePrevious value: -"number"New value: +"string" - changed
Input schema / properties / created_before / descriptionPrevious value: -"OPTIONAL: Only pools created before this UNIX timestamp"New value: +"OPTIONAL: Only pools created at or before this time, same formats as created_after (e.g. '-1h')" - changed
Input schema / properties / created_before / typePrevious value: -"number"New value: +"string"
- Changed
getPoolTransactions4 fields changed- changed
Input schema / properties / from / descriptionPrevious value: -"OPTIONAL: Start of time-range filter, Unix epoch SECONDS (inclusive). Window is capped to last 7 days. Note: getPoolOHLCV uses `start` (string) for the same concept; getPoolTransactions uses numeric epoch for tighter filtering."New value: +"OPTIONAL: Filter transactions starting from this time (inclusive): a relative offset such as '-1h' or '-24h', Unix seconds, RFC3339 or YYYY-MM-DD. Results always capped to last 7 days." - changed
Input schema / properties / from / typePrevious value: -"number"New value: +"string" - changed
Input schema / properties / to / descriptionPrevious value: -"OPTIONAL: Filter transactions up to this UNIX timestamp (exclusive). Must be after 'from'."New value: +"OPTIONAL: Filter transactions up to this time (exclusive), same formats as from. Must be after 'from'." - changed
Input schema / properties / to / typePrevious value: -"number"New value: +"string"
1 tool update
- Changed
getPoolOHLCV3 fields changed- changed
Input schema / properties / end / descriptionPrevious value: -"OPTIONAL: End time for historical data (max 1 year from start)"New value: +"OPTIONAL: End time for historical data, same formats as start (e.g. '-1h')" - changed
Input schema / properties / limit / descriptionPrevious value: -"OPTIONAL: Number of OHLCV data points to retrieve (default: 100, max: 366). One row per `interval`."New value: +"OPTIONAL: Number of OHLCV data points to retrieve (default: 100, max: 1000). One row per `interval`." - changed
Input schema / properties / start / descriptionPrevious value: -"REQUIRED: Start time. RFC3339 recommended (e.g. '2024-01-01T00:00:00Z'). Also accepts Unix epoch seconds and YYYY-MM-DD (treated as 00:00:00 UTC)."New value: +"REQUIRED: Start time. A relative offset from now is simplest and needs no knowledge of today's date: '-24h' (last 24 hours), '-7d', '-90m' (units s, m, h, d). Also accepts RFC3339 (e.g. '2024-01-01T00:00:00Z'), Unix epoch seconds and YYYY-MM-DD (treated as 00:00:00 UTC)."
17 tool updates
- Changed
filterNetworkTokens3 fields changed- added
Input schema / properties / price_change_percentage_24h_maxAdded value: +{ + "description": "OPTIONAL: Maximum 24h price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_24h_minAdded value: +{ + "description": "OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds tokens down at least 20%. This is the only price-change window tokens carry; for 6h, 1h or 5m use getNetworkPoolsFilter.", + "type": "number" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "has_next_page": { + "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.", + "type": "boolean" + }, + "next_cursor": { + "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.", + "type": [ + "string", + "null" + ] + }, + "query": { + "additionalProperties": {}, + "description": "Echo of the resolved query and filters the API applied.", + "type": "object" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "added_at": { + "description": "ISO 8601 timestamp when DexPaprika first indexed this token.", + "type": "string" + }, + "chain": { + "type": "string" + }, + "decimals": { + "type": "number" + }, + "fdv": { + "description": "Fully-diluted valuation in USD.", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Token contract address (chain-canonical form).", + "type": "string" + }, + "name": { + "type": "string" + }, + "symbol": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "results" + ], + "type": "object" +}
- Changed
getCapabilities1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "agent_skills": { + "type": "string" + }, + "common_pitfalls": { + "description": "Known edge cases agents should be aware of.", + "items": { + "type": "string" + }, + "type": "array" + }, + "documentation": { + "type": "string" + }, + "network_synonyms": { + "additionalProperties": { + "items": { + "type": "string" + }, + "type": "array" + }, + "description": "Canonical network id -> common alternates an agent might try.", + "type": "object" + }, + "server": { + "additionalProperties": true, + "properties": { + "name": { + "type": "string" + }, + "version": { + "type": "string" + } + }, + "required": [ + "name", + "version" + ], + "type": "object" + }, + "stats": { + "additionalProperties": true, + "properties": { + "console_url": { + "type": "string" + }, + "docs_url": { + "type": "string" + }, + "free_key_credits_per_month": { + "type": "number" + }, + "free_key_requests_per_minute": { + "type": "number" + }, + "free_tier": { + "type": "boolean" + }, + "free_tier_credits_per_month": { + "type": "number" + }, + "free_tier_max_data_delay_seconds": { + "type": "number" + }, + "free_tier_requests_per_minute": { + "type": "number" + }, + "key_required_to_start": { + "type": "boolean" + }, + "networks": { + "type": "number" + }, + "pools_approx": { + "type": "number" + }, + "pricing_url": { + "type": "string" + }, + "tokens_approx": { + "type": "number" + } + }, + "required": [ + "networks", + "tokens_approx", + "pools_approx", + "free_tier", + "key_required_to_start" + ], + "type": "object" + }, + "workflows": { + "additionalProperties": { + "items": { + "type": "string" + }, + "type": "array" + }, + "description": "Named tool sequences for common agent tasks.", + "type": "object" + } + }, + "required": [ + "server", + "stats", + "network_synonyms", + "workflows", + "common_pitfalls", + "documentation", + "agent_skills" + ], + "type": "object" +}
- Changed
getDexPools3 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "has_next_page": { + "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.", + "type": "boolean" + }, + "next_cursor": { + "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.", + "type": [ + "string", + "null" + ] + }, + "query": { + "additionalProperties": {}, + "description": "Echo of the resolved query and filters the API applied.", + "type": "object" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "chain": { + "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.", + "type": "string" + }, + "created_at": { + "description": "ISO 8601 pool-creation timestamp.", + "type": "string" + }, + "created_at_block_number": { + "type": "number" + }, + "dex_id": { + "type": "string" + }, + "dex_name": { + "type": "string" + }, + "fee": { + "description": "Pool fee (units depend on DEX; null for some DEXes).", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Pool contract address.", + "type": "string" + }, + "last_price": { + "type": [ + "number", + "null" + ] + }, + "last_price_usd": { + "type": [ + "number", + "null" + ] + }, + "tokens": { + "items": { + "additionalProperties": true, + "properties": { + "added_at": { + "description": "ISO 8601 timestamp when DexPaprika first indexed this token.", + "type": "string" + }, + "chain": { + "type": "string" + }, + "decimals": { + "type": "number" + }, + "fdv": { + "description": "Fully-diluted valuation in USD.", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Token contract address (chain-canonical form).", + "type": "string" + }, + "name": { + "type": "string" + }, + "symbol": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "results" + ], + "type": "object" +}
- Changed
getNetworkDexes1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "dexes": { + "items": { + "additionalProperties": true, + "properties": { + "chain": { + "type": "string" + }, + "dex_id": { + "type": "string" + }, + "dex_name": { + "type": "string" + }, + "display_name": { + "type": "string" + }, + "id": { + "type": "string" + }, + "network_id": { + "type": "string" + }, + "pools_count": { + "type": "number" + }, + "protocol": { + "type": "string" + }, + "txns_24h": { + "type": "number" + }, + "volume_usd_24h": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "page_info": { + "additionalProperties": true, + "properties": { + "limit": { + "description": "Items per page in the request.", + "type": "number" + }, + "page": { + "description": "Current page number (1-indexed).", + "type": "number" + }, + "total_items": { + "description": "Total number of items across all pages.", + "type": "number" + }, + "total_pages": { + "description": "Total number of pages available.", + "type": "number" + } + }, + "type": "object" + } + }, + "required": [ + "dexes", + "page_info" + ], + "type": "object" +}
- Changed
getNetworkPools3 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "has_next_page": { + "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.", + "type": "boolean" + }, + "next_cursor": { + "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.", + "type": [ + "string", + "null" + ] + }, + "query": { + "additionalProperties": {}, + "description": "Echo of the resolved query and filters the API applied.", + "type": "object" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "chain": { + "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.", + "type": "string" + }, + "created_at": { + "description": "ISO 8601 pool-creation timestamp.", + "type": "string" + }, + "created_at_block_number": { + "type": "number" + }, + "dex_id": { + "type": "string" + }, + "dex_name": { + "type": "string" + }, + "fee": { + "description": "Pool fee (units depend on DEX; null for some DEXes).", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Pool contract address.", + "type": "string" + }, + "last_price": { + "type": [ + "number", + "null" + ] + }, + "last_price_usd": { + "type": [ + "number", + "null" + ] + }, + "tokens": { + "items": { + "additionalProperties": true, + "properties": { + "added_at": { + "description": "ISO 8601 timestamp when DexPaprika first indexed this token.", + "type": "string" + }, + "chain": { + "type": "string" + }, + "decimals": { + "type": "number" + }, + "fdv": { + "description": "Fully-diluted valuation in USD.", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Token contract address (chain-canonical form).", + "type": "string" + }, + "name": { + "type": "string" + }, + "symbol": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "results" + ], + "type": "object" +}
- Changed
getNetworkPoolsFilter11 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - added
Input schema / properties / price_change_percentage_1h_maxAdded value: +{ + "description": "OPTIONAL: Maximum 1h price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_1h_minAdded value: +{ + "description": "OPTIONAL: Minimum 1h price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_24h_maxAdded value: +{ + "description": "OPTIONAL: Maximum 24h price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_24h_minAdded value: +{ + "description": "OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds pools down at least 20%.", + "type": "number" +} - added
Input schema / properties / price_change_percentage_5m_maxAdded value: +{ + "description": "OPTIONAL: Maximum 5m price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_5m_minAdded value: +{ + "description": "OPTIONAL: Minimum 5m price change, in percent. The shortest window we carry, so it is the one to reach for on 'what is moving right now'.", + "type": "number" +} - added
Input schema / properties / price_change_percentage_6h_maxAdded value: +{ + "description": "OPTIONAL: Maximum 6h price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_6h_minAdded value: +{ + "description": "OPTIONAL: Minimum 6h price change, in percent", + "type": "number" +} - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "has_next_page": { + "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.", + "type": "boolean" + }, + "next_cursor": { + "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.", + "type": [ + "string", + "null" + ] + }, + "query": { + "additionalProperties": {}, + "description": "Echo of the resolved query and filters the API applied.", + "type": "object" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "chain": { + "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.", + "type": "string" + }, + "created_at": { + "description": "ISO 8601 pool-creation timestamp.", + "type": "string" + }, + "created_at_block_number": { + "type": "number" + }, + "dex_id": { + "type": "string" + }, + "dex_name": { + "type": "string" + }, + "fee": { + "description": "Pool fee (units depend on DEX; null for some DEXes).", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Pool contract address.", + "type": "string" + }, + "last_price": { + "type": [ + "number", + "null" + ] + }, + "last_price_usd": { + "type": [ + "number", + "null" + ] + }, + "tokens": { + "items": { + "additionalProperties": true, + "properties": { + "added_at": { + "description": "ISO 8601 timestamp when DexPaprika first indexed this token.", + "type": "string" + }, + "chain": { + "type": "string" + }, + "decimals": { + "type": "number" + }, + "fdv": { + "description": "Fully-diluted valuation in USD.", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Token contract address (chain-canonical form).", + "type": "string" + }, + "name": { + "type": "string" + }, + "symbol": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "results" + ], + "type": "object" +}
- Changed
getNetworks1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "networks": { + "description": "All supported blockchain networks with current 24h volume + indexing stats.", + "items": { + "additionalProperties": true, + "properties": { + "display_name": { + "description": "Human-readable network name (e.g. 'Ethereum').", + "type": "string" + }, + "id": { + "description": "Network slug for use in other endpoints (e.g. 'ethereum').", + "type": "string" + }, + "pools_count": { + "description": "Number of indexed pools on this network.", + "type": "number" + }, + "txns_24h": { + "description": "Total transactions in the last 24h on this network.", + "type": "number" + }, + "volume_usd_24h": { + "description": "Total 24h trading volume across all pools on this network, USD.", + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "networks" + ], + "type": "object" +}
- Changed
getPoolDetails1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "chain": { + "type": "string" + }, + "created_at": { + "type": "string" + }, + "created_at_block_number": { + "type": "number" + }, + "dex_id": { + "type": "string" + }, + "dex_name": { + "type": "string" + }, + "factory_id": { + "type": "string" + }, + "fee": { + "type": [ + "number", + "null" + ] + }, + "id": { + "type": "string" + }, + "last_price": { + "type": [ + "number", + "null" + ] + }, + "last_price_usd": { + "type": [ + "number", + "null" + ] + }, + "price_stats": {}, + "price_time": { + "type": "string" + }, + "token_reserves": { + "items": {}, + "type": "array" + }, + "tokens": { + "items": { + "additionalProperties": true, + "properties": { + "added_at": { + "description": "ISO 8601 timestamp when DexPaprika first indexed this token.", + "type": "string" + }, + "chain": { + "type": "string" + }, + "decimals": { + "type": "number" + }, + "fdv": { + "description": "Fully-diluted valuation in USD.", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Token contract address (chain-canonical form).", + "type": "string" + }, + "name": { + "type": "string" + }, + "symbol": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
getPoolOHLCV1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "ohlcv": { + "description": "Open-High-Low-Close-Volume rows ordered by time_open ascending.", + "items": { + "additionalProperties": true, + "properties": { + "close": { + "type": "number" + }, + "high": { + "type": "number" + }, + "low": { + "type": "number" + }, + "open": { + "type": "number" + }, + "time_close": { + "description": "ISO 8601 timestamp of bucket close (inclusive at 23:59:59 for 24h).", + "type": "string" + }, + "time_open": { + "description": "ISO 8601 timestamp of bucket open.", + "type": "string" + }, + "volume": { + "description": "Trade volume in the bucket, in pair-quote units (or USD where applicable).", + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "ohlcv" + ], + "type": "object" +}
- Changed
getPoolTransactions2 fields changed- changed
Input schema / properties / from / descriptionPrevious value: -"OPTIONAL: Start of time-range filter, Unix epoch SECONDS (inclusive). Window is capped to last 7 days. Note: getPoolOHLCV uses `start` (string) for the same concept — getPoolTransactions uses numeric epoch for tighter filtering."New value: +"OPTIONAL: Start of time-range filter, Unix epoch SECONDS (inclusive). Window is capped to last 7 days. Note: getPoolOHLCV uses `start` (string) for the same concept; getPoolTransactions uses numeric epoch for tighter filtering." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "page_info": { + "additionalProperties": true, + "properties": { + "limit": { + "description": "Items per page in the request.", + "type": "number" + }, + "page": { + "description": "Current page number (1-indexed).", + "type": "number" + }, + "total_items": { + "description": "Total number of items across all pages.", + "type": "number" + }, + "total_pages": { + "description": "Total number of pages available.", + "type": "number" + } + }, + "type": "object" + }, + "transactions": { + "items": { + "additionalProperties": true, + "properties": { + "amount_usd": { + "type": "number" + }, + "block_number": { + "type": "number" + }, + "block_timestamp": { + "type": "string" + }, + "id": { + "type": "string" + }, + "pool_id": { + "type": "string" + }, + "token0": {}, + "token1": {} + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "transactions", + "page_info" + ], + "type": "object" +}
- Changed
getStats1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "chains": { + "description": "Total chains indexed.", + "type": "number" + }, + "factories": { + "description": "Total DEX factory contracts indexed.", + "type": "number" + }, + "pools": { + "description": "Total pools indexed across all chains.", + "type": "number" + }, + "tokens": { + "description": "Total tokens indexed.", + "type": "number" + } + }, + "required": [ + "chains", + "factories", + "pools", + "tokens" + ], + "type": "object" +}
- Changed
getTokenDetails1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "added_at": { + "type": "string" + }, + "chain": { + "type": "string" + }, + "decimals": { + "type": "number" + }, + "description": { + "type": "string" + }, + "has_image": { + "type": "boolean" + }, + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "price_stats": {}, + "summary": {}, + "symbol": { + "type": "string" + }, + "total_supply": { + "description": "Raw on-chain total supply. Big numbers may overflow JS Number; handle as string for tokens with 18+ decimals.", + "type": [ + "number", + "string" + ] + }, + "website": { + "type": "string" + } + }, + "type": "object" +}
- Changed
getTokenMultiPrices1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "missing_tokens": { + "description": "Input tokens that upstream could not price (invalid address, no liquidity, unknown contract). Empty array when all input tokens were resolved.", + "items": { + "type": "string" + }, + "type": "array" + }, + "prices": { + "description": "USD prices for the requested tokens, in input order.", + "items": { + "additionalProperties": true, + "properties": { + "chain": { + "type": "string" + }, + "id": { + "description": "Token contract address.", + "type": "string" + }, + "price_usd": { + "description": "Current USD price; null if not available.", + "type": [ + "number", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "prices" + ], + "type": "object" +}
- Changed
getTokenPools3 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "has_next_page": { + "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.", + "type": "boolean" + }, + "next_cursor": { + "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.", + "type": [ + "string", + "null" + ] + }, + "query": { + "additionalProperties": {}, + "description": "Echo of the resolved query and filters the API applied.", + "type": "object" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "chain": { + "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.", + "type": "string" + }, + "created_at": { + "description": "ISO 8601 pool-creation timestamp.", + "type": "string" + }, + "created_at_block_number": { + "type": "number" + }, + "dex_id": { + "type": "string" + }, + "dex_name": { + "type": "string" + }, + "fee": { + "description": "Pool fee (units depend on DEX; null for some DEXes).", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Pool contract address.", + "type": "string" + }, + "last_price": { + "type": [ + "number", + "null" + ] + }, + "last_price_usd": { + "type": [ + "number", + "null" + ] + }, + "tokens": { + "items": { + "additionalProperties": true, + "properties": { + "added_at": { + "description": "ISO 8601 timestamp when DexPaprika first indexed this token.", + "type": "string" + }, + "chain": { + "type": "string" + }, + "decimals": { + "type": "number" + }, + "fdv": { + "description": "Fully-diluted valuation in USD.", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Token contract address (chain-canonical form).", + "type": "string" + }, + "name": { + "type": "string" + }, + "symbol": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "results" + ], + "type": "object" +}
- Changed
getTopTokens1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "has_next_page": { + "description": "True if more results are available; fetch them by passing next_cursor as `cursor`.", + "type": "boolean" + }, + "next_cursor": { + "description": "Opaque pagination cursor. Pass back as the `cursor` argument to fetch the next page; null/absent on the last page.", + "type": [ + "string", + "null" + ] + }, + "query": { + "additionalProperties": {}, + "description": "Echo of the resolved query and filters the API applied.", + "type": "object" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "added_at": { + "description": "ISO 8601 timestamp when DexPaprika first indexed this token.", + "type": "string" + }, + "chain": { + "type": "string" + }, + "decimals": { + "type": "number" + }, + "fdv": { + "description": "Fully-diluted valuation in USD.", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Token contract address (chain-canonical form).", + "type": "string" + }, + "name": { + "type": "string" + }, + "symbol": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "results" + ], + "type": "object" +}
- Changed
search1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "dexes": { + "items": { + "additionalProperties": true, + "properties": { + "chain": { + "type": "string" + }, + "dex_id": { + "type": "string" + }, + "dex_name": { + "type": "string" + }, + "display_name": { + "type": "string" + }, + "id": { + "type": "string" + }, + "network_id": { + "type": "string" + }, + "pools_count": { + "type": "number" + }, + "protocol": { + "type": "string" + }, + "txns_24h": { + "type": "number" + }, + "volume_usd_24h": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "pools": { + "items": { + "additionalProperties": true, + "properties": { + "chain": { + "description": "Network slug (e.g. 'ethereum'). Note: also exposed as 'network' on some endpoints.", + "type": "string" + }, + "created_at": { + "description": "ISO 8601 pool-creation timestamp.", + "type": "string" + }, + "created_at_block_number": { + "type": "number" + }, + "dex_id": { + "type": "string" + }, + "dex_name": { + "type": "string" + }, + "fee": { + "description": "Pool fee (units depend on DEX; null for some DEXes).", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Pool contract address.", + "type": "string" + }, + "last_price": { + "type": [ + "number", + "null" + ] + }, + "last_price_usd": { + "type": [ + "number", + "null" + ] + }, + "tokens": { + "items": { + "$ref": "#/properties/tokens/items" + }, + "type": "array" + } + }, + "type": "object" + }, + "type": "array" + }, + "tokens": { + "items": { + "additionalProperties": true, + "properties": { + "added_at": { + "description": "ISO 8601 timestamp when DexPaprika first indexed this token.", + "type": "string" + }, + "chain": { + "type": "string" + }, + "decimals": { + "type": "number" + }, + "fdv": { + "description": "Fully-diluted valuation in USD.", + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Token contract address (chain-canonical form).", + "type": "string" + }, + "name": { + "type": "string" + }, + "symbol": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "tokens", + "pools", + "dexes" + ], + "type": "object" +}
- Changed
submitFeedback1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "message": { + "type": "string" + }, + "ok": { + "description": "True if the feedback row was persisted.", + "type": "boolean" + }, + "severity": { + "enum": [ + "blocker", + "major", + "minor", + "nit" + ], + "type": "string" + }, + "tracking_id": { + "description": "Stable id agents can reference in follow-up submissions; null if persistence failed.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "ok", + "message" + ], + "type": "object" +}
5 tool updates
- Changed
filterNetworkTokens2 fields changed- removed
Input schema / properties / price_change_percentage_24h_maxRemoved value: -{ - "description": "OPTIONAL: Maximum 24h price change, in percent", - "type": "number" -} - removed
Input schema / properties / price_change_percentage_24h_minRemoved value: -{ - "description": "OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds tokens down at least 20%. This is the only price-change window tokens carry; for 6h, 1h or 5m use getNetworkPoolsFilter.", - "type": "number" -}
- Changed
getDexPools2 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
- Changed
getNetworkPools2 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
- Changed
getNetworkPoolsFilter10 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - removed
Input schema / properties / price_change_percentage_1h_maxRemoved value: -{ - "description": "OPTIONAL: Maximum 1h price change, in percent", - "type": "number" -} - removed
Input schema / properties / price_change_percentage_1h_minRemoved value: -{ - "description": "OPTIONAL: Minimum 1h price change, in percent", - "type": "number" -} - removed
Input schema / properties / price_change_percentage_24h_maxRemoved value: -{ - "description": "OPTIONAL: Maximum 24h price change, in percent", - "type": "number" -} - removed
Input schema / properties / price_change_percentage_24h_minRemoved value: -{ - "description": "OPTIONAL: Minimum 24h price change, in percent. Negative values are allowed, so -20 finds pools down at least 20%.", - "type": "number" -} - removed
Input schema / properties / price_change_percentage_5m_maxRemoved value: -{ - "description": "OPTIONAL: Maximum 5m price change, in percent", - "type": "number" -} - removed
Input schema / properties / price_change_percentage_5m_minRemoved value: -{ - "description": "OPTIONAL: Minimum 5m price change, in percent. The shortest window we carry, so it is the one to reach for on 'what is moving right now'.", - "type": "number" -} - removed
Input schema / properties / price_change_percentage_6h_maxRemoved value: -{ - "description": "OPTIONAL: Maximum 6h price change, in percent", - "type": "number" -} - removed
Input schema / properties / price_change_percentage_6h_minRemoved value: -{ - "description": "OPTIONAL: Minimum 6h price change, in percent", - "type": "number" -} - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
- Changed
getTokenPools2 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "price_change_percentage_6h", - "price_change_percentage_1h", - "price_change_percentage_5m", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
1 tool update
- Changed
filterNetworkTokens2 fields changed- added
Input schema / properties / price_change_percentage_24h_maxAdded value: +{ + "description": "OPTIONAL: Maximum 24h price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_24h_minAdded value: +{ + "description": "OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds tokens down at least 20%. This is the only price-change window tokens carry; for 6h, 1h or 5m use getNetworkPoolsFilter.", + "type": "number" +}
4 tool updates
- Changed
getDexPools2 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
- Changed
getNetworkPools2 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
- Changed
getNetworkPoolsFilter10 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - added
Input schema / properties / price_change_percentage_1h_maxAdded value: +{ + "description": "OPTIONAL: Maximum 1h price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_1h_minAdded value: +{ + "description": "OPTIONAL: Minimum 1h price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_24h_maxAdded value: +{ + "description": "OPTIONAL: Maximum 24h price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_24h_minAdded value: +{ + "description": "OPTIONAL: Minimum 24h price change, in percent. Negative values are allowed, so -20 finds pools down at least 20%.", + "type": "number" +} - added
Input schema / properties / price_change_percentage_5m_maxAdded value: +{ + "description": "OPTIONAL: Maximum 5m price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_5m_minAdded value: +{ + "description": "OPTIONAL: Minimum 5m price change, in percent. The shortest window we carry, so it is the one to reach for on 'what is moving right now'.", + "type": "number" +} - added
Input schema / properties / price_change_percentage_6h_maxAdded value: +{ + "description": "OPTIONAL: Maximum 6h price change, in percent", + "type": "number" +} - added
Input schema / properties / price_change_percentage_6h_minAdded value: +{ + "description": "OPTIONAL: Minimum 6h price change, in percent", + "type": "number" +} - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
- Changed
getTokenPools2 fields changed- changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd_24h", - "volume_usd_7d", - "volume_usd_30d", - "liquidity_usd", - "txns_24h", - "created_at", - "price_usd", - "price_change_percentage_24h", - "volume_usd", - "transactions", - "last_price_change_usd_24h", - "volume_24h", - "volume_7d", - "volume_30d", - "liquidity" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "price_change_percentage_6h", + "price_change_percentage_1h", + "price_change_percentage_5m", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
1 tool update
- Changed
getDexPools7 fields changed- added
Input schema / properties / cursorAdded value: +{ + "description": "OPTIONAL: Pagination cursor. Pass `next_cursor` from a previous response to fetch the next page (read `has_next_page` to know if more remain). Replaces the old page number.", + "type": "string" +} - changed
Input schema / properties / dex / descriptionPrevious value: -"REQUIRED: DEX identifier from getNetworkDexes (e.g., 'uniswap_v3')"New value: +"REQUIRED: the dex_id field from getNetworkDexes (e.g., 'uniswap_v3'), matched case-insensitively. Do not pass that response's dex_name field, the human display name (e.g., 'Uniswap V3'): it returns an empty results[] instead of an error, so a wrong value looks like a real but empty answer. The REST API calls this parameter dex_name." - changed
Input schema / properties / order_by / enumPrevious value: -[ - "volume_usd", - "price_usd", - "transactions", - "last_price_change_usd_24h", - "created_at" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +] - removed
Input schema / properties / page / defaultRemoved value: -1 - changed
Input schema / properties / page / descriptionPrevious value: -"OPTIONAL: Page number, 1-indexed. Server accepts page=0 (treated as page=1) for backward compatibility."New value: +"SUPERSEDED: the replacement endpoint is cursor-paginated and ignores page. page=1 (or 0) still returns the first page as before; page=2 or above returns an error telling you to use cursor." - changed
Input schema / properties / sort_by / descriptionPrevious value: -"OPTIONAL: Sort field. Canonical parameter name. Defaults to 'volume_usd' if neither sort_by nor order_by is provided. The REST API calls this parameter order_by."New value: +"OPTIONAL: Sort field. Canonical parameter name. Defaults to 'volume_usd_24h'. Prefer the canonical *_24h names; short legacy names (volume_usd, transactions, last_price_change_usd_24h) are still accepted and normalized. The REST API calls this parameter order_by." - changed
Input schema / properties / sort_by / enumPrevious value: -[ - "volume_usd", - "price_usd", - "transactions", - "last_price_change_usd_24h", - "created_at" -]New value: +[ + "volume_usd_24h", + "volume_usd_7d", + "volume_usd_30d", + "liquidity_usd", + "txns_24h", + "created_at", + "price_usd", + "price_change_percentage_24h", + "volume_usd", + "transactions", + "last_price_change_usd_24h", + "volume_24h", + "volume_7d", + "volume_30d", + "liquidity" +]
Related MCP Servers
- AlicenseCqualityBmaintenanceCompetitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs119 npmMIT
- AlicenseAqualityCmaintenanceEnables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.1611 npm1MIT
industrylens-mcpofficial
AlicenseNot gradedqualityBmaintenanceBrowse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.MIT
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.