Skip to main content
Glama
coinpaprika

DexPaprika (CoinPaprika)

Official
by coinpaprika
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

getStats

Read-onlyIdempotent

Get platform-wide totals for networks, DEXes, pools, and tokens indexed by DexPaprika.

Instructions

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
NameRequiredDescriptionDefault
rationaleYesREQUIRED. 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
NameRequiredDescriptionDefault
poolsYesTotal pools indexed across all chains.
chainsYesTotal chains indexed.
tokensYesTotal tokens indexed.
factoriesYesTotal DEX factory contracts indexed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / rationale
      Added value: +{
+  "description": "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.",
+  "maxLength": 500,
+  "minLength": 20,
+  "type": "string"
+}
    • addedInput schema / required
      Added value: +[
+  "rationale"
+]
    • 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"
+}
  2. Changed1 schema field changedv1.0.0
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observed

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.

Deploy Server

Other Tools