DexPaprika (CoinPaprika)

Official

Overview Schema Source Related Servers Discussions Admin

getNetworkPoolsFilter

Read-onlyIdempotent

Filter DEX pools on a network by numeric thresholds like liquidity, volume, or creation time. Returns paginated results with next-cursor, enabling queries such as 'pools over $1M liquidity'.

Instructions

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, created_after/created_before (Unix timestamps). 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).

Input Schema

TableJSON Schema

Name	Required	Description
`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: 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 (preferred): Field to sort by (default: 'volume_usd_24h'). Prefer the canonical *_24h 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 (preferred): Sort direction (default: 'desc'). 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 number of transactions in 24h
`created_after`	No	OPTIONAL: Only pools created after this UNIX timestamp
`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 before this UNIX timestamp
`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%.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`query`	No
`results`	No
`next_cursor`	No
`has_next_page`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv2.5.0Aug 19, 2026

changedInput schema / properties / order_by / enum

Previous 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"
+]

addedInput schema / properties / price_change_percentage_1h_max

Added value: +{
+  "description": "OPTIONAL: Maximum 1h price change, in percent",
+  "type": "number"
+}

addedInput schema / properties / price_change_percentage_1h_min

Added value: +{
+  "description": "OPTIONAL: Minimum 1h price change, in percent",
+  "type": "number"
+}

addedInput schema / properties / price_change_percentage_24h_max

Added value: +{
+  "description": "OPTIONAL: Maximum 24h price change, in percent",
+  "type": "number"
+}

addedInput schema / properties / price_change_percentage_24h_min

Added value: +{
+  "description": "OPTIONAL: Minimum 24h price change, in percent. Negatives are allowed, so -20 finds pools down at least 20%.",
+  "type": "number"
+}

addedInput schema / properties / price_change_percentage_5m_max

Added value: +{
+  "description": "OPTIONAL: Maximum 5m price change, in percent",
+  "type": "number"
+}

addedInput schema / properties / price_change_percentage_5m_min

Added 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"
+}

addedInput schema / properties / price_change_percentage_6h_max

Added value: +{
+  "description": "OPTIONAL: Maximum 6h price change, in percent",
+  "type": "number"
+}

addedInput schema / properties / price_change_percentage_6h_min

Added value: +{
+  "description": "OPTIONAL: Minimum 6h price change, in percent",
+  "type": "number"
+}

changedInput schema / properties / sort_by / enum

Previous 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"
+]

Changed4 schema fields changedv2.3.2Jul 30, 2026

changedInput schema / properties / order_by / description

Previous value: -"OPTIONAL (deprecated alias of sort_by): Field to sort by"New value: +"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."

changedInput schema / properties / sort / description

Previous value: -"OPTIONAL (deprecated alias of sort_dir): Sort direction"New value: +"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."

changedInput schema / properties / sort_by / description

Previous value: -"OPTIONAL (preferred): Field to sort by (default: 'volume_usd_24h'). Prefer the canonical *_24h names; short legacy names are still accepted."New value: +"OPTIONAL (preferred): Field to sort by (default: 'volume_usd_24h'). Prefer the canonical *_24h names; short legacy names are still accepted. The REST API calls this parameter order_by."

changedInput schema / properties / sort_dir / description

Previous value: -"OPTIONAL (preferred): Sort direction (default: 'desc')"New value: +"OPTIONAL (preferred): Sort direction (default: 'desc'). The REST API calls this parameter sort."

Changed9 schema fields changedv1.0.2Jul 29, 2026

addedInput schema / properties / cursor

Added value: +{
+  "description": "OPTIONAL: Pagination cursor. Pass `next_cursor` from a previous response to fetch the next page. Replaces the old page number.",
+  "type": "string"
+}

changedInput schema / properties / order_by / enum

Previous value: -[
-  "volume_24h",
-  "volume_7d",
-  "volume_30d",
-  "liquidity",
-  "txns_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"
+]

removedInput schema / properties / page

Removed value: -{
-  "default": 1,
-  "description": "OPTIONAL: Page number for pagination (default: 1, 1-indexed)",
-  "type": "number"
-}

changedInput schema / properties / sort_by / description

Previous value: -"OPTIONAL (preferred): Field to sort by (default: 'volume_24h')"New value: +"OPTIONAL (preferred): Field to sort by (default: 'volume_usd_24h'). Prefer the canonical *_24h names; short legacy names are still accepted."

changedInput schema / properties / sort_by / enum

Previous value: -[
-  "volume_24h",
-  "volume_7d",
-  "volume_30d",
-  "liquidity",
-  "txns_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"
+]

addedOutput schema / properties / has_next_page
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / next_cursor

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

removedOutput schema / properties / page_info

Removed value: -{
-  "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"
-}

addedOutput schema / properties / query

Added value: +{
+  "additionalProperties": {},
+  "type": "object"
+}

Addedv1.0.1Jun 24, 2026

TDQS

A4.6/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, so the safety profile is covered. The description adds value beyond annotations by stating 'keyless' (no auth requirement), that filters are AND-combined, documenting defaults (limit 50/max 100, sort_by/sort_dir defaults), and noting aliases. No contradiction with 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?

Two compact sentences plus a filter enumeration. Front-loaded with purpose and the key sibling differentiator. While somewhat dense given 25 parameters, every clause earns its place: purpose, read-only/keyless, when-to-use with examples, filter list, required/default/alias info. No filler, but a bit heavy to parse.

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 25-parameter tool with an output schema and rich annotations, the description is thoroughly complete. It covers purpose, sibling differentiation, examples, read-only/keyless status, ALL available filters, required network param, pagination (cursor/limit), and sort defaults. The output schema handles return values, so the brief mention of 'results' with has_next_page/next_cursor 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 coverage is 100% with rich per-parameter descriptions, so baseline is 3. The description adds genuine cross-parameter semantics not in the schema: the AND-combination of filters, which params are required, default values for limit/sort_by/sort_dir, and the alias relationships (sort_by/order_by, sort_dir/sort). This provides real value beyond the structured 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?

Uses a specific verb+resource: 'Get pools on one network filtered by numeric thresholds'. Explicitly distinguishes itself from sibling getNetworkPools by naming it and describing the differentiator (numeric constraints/time windows). The three concrete example queries reinforce the exact scope.

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 an explicit when-to-use directive: 'Choose this over getNetworkPools when the user gives numeric constraints or a time window.' Provides three concrete user-query examples ('pools over $1M liquidity on Base', 'pools created in the last 24h', 'high-volume low-liquidity pairs') that map to filters. Clearly implies the alternative for non-numeric queries.

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

Deploy Server