DexPaprika

getNetworkDexes

Read-onlyIdempotent

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).

Input Schema

TableJSON Schema

Name	Required	Description
`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

TableJSON Schema

Name	Required	Description	Default
`dexes`	Yes
`page_info`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 2, 2026

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

Changed4 schema fields changedJul 30, 2026

changedInput schema / properties / order_by / description

Previous value: -"DEPRECATED alias for sort_by. Both accepted; prefer sort_by going forward."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: -"DEPRECATED alias for sort_dir. Both accepted; prefer sort_dir going forward."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: Sort field. Canonical parameter name; older tools used order_by."New value: +"OPTIONAL: Sort field. Canonical parameter name; older tools used order_by. The REST API calls this parameter order_by."

changedInput schema / properties / sort_dir / description

Previous value: -"OPTIONAL: Sort direction (asc/desc). Canonical parameter name. Defaults to 'desc' if neither sort_dir nor sort is provided."New value: +"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."

First observedJul 28, 2026

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.

All DexPaprika tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?