DexPaprika

getStats

Read-onlyIdempotent

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.

Input Schema

TableJSON 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

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

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

First observedJul 28, 2026

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.

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?