Real-time DEX and on-chain data across 36 blockchains: liquidity pools, token prices, OHLCV, transactions, and cross-chain search. 17 keyless tools.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 17 of 17 tools scored.
Every tool has a clearly distinct purpose: network listings, DEX listings, pool discovery, pool snapshots, OHLCV, transactions, token details, multi-price, token pools, search, stats, and feedback. Potential overlaps like getTopTokens vs filterNetworkTokens are explicitly disambiguated in descriptions.
Mostly follows camelCase verb-first pattern (getNetworks, getPoolDetails, getTokenMultiPrices). However, the pair filterNetworkTokens and getNetworkPoolsFilter are inconsistently structured; the latter should logically be filterNetworkPools for full consistency.
At 17 tools, it slightly exceeds the ideal 3-15 range, but each tool covers a distinct data operation for a comprehensive DEX-market API. The count feels justified given the breadth of features, though it is on the heavier side.
The domain of read-only DEX analytics is well covered: networks, DEXes, pools, tokens, search, stats, and per-pool history. Minor gaps exist, such as no direct token price history endpoint, but pool OHLCV and token details cover most needs.
filterNetworkTokensAGet 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, 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).
| 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 after this UNIX timestamp | |
| created_before | No | OPTIONAL: Only tokens 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 token liquidity in USD | |
| liquidity_usd_min | No | OPTIONAL: Minimum token liquidity in USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description states 'Read-only and keyless', disclosing authentication requirements. It also reveals response shape (results, has_next_page, next_cursor) and clarifies that filters are AND-combined. This adds significant behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, starting with purpose then moving to usage, filters, and parameters. It is slightly long due to listing many filters, but every sentence contributes operational detail—no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 17 parameters and no output schema, the description carries a heavy burden. It fully covers the response envelope, pagination mechanics, filter semantics, aliases, and concrete example use cases, making the tool self-explanatory for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds value by explaining AND-combination semantics, alias relationships (sort_by/order_by, sort_dir/sort), and defaults (limit 50, sort default volume_usd_24h). This goes beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 tokens on one network matching numeric thresholds', and explicitly names response fields ('results', has_next_page, next_cursor). It distinguishes itself from the sibling tool getTopTokens, making its purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Choose this over getTopTokens when the user gives numeric constraints or a time window' and gives concrete example queries ('tokens with FDV over $10M on Base'). This goes beyond implied usage and clearly delineates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getCapabilitiesAGet 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.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent, non-destructive. Description reinforces these traits and adds specific behavioral context: 'static', 'keyless', 'returns onboarding docs not live market data'. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: front-loaded purpose, followed by usage context, then distinctions. At 5 sentences, it is concise but some details could be tightened; still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains what the returned guide contains. It covers the tool's static nature, keyless access, and clear boundaries. Missing exact format details but sufficient for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description for the required 'rationale' parameter. The tool description only adds 'Takes no parameters beyond a short rationale.' which adds no new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns a static agent onboarding guide, listing contents (workflows, synonyms, sequences, pitfalls). It distinguishes from siblings by specifying what getNetworks and getStats do instead, making it clear this is not for live data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-call scenarios: 'at the start of a session', or when asked specific questions. Also states what it does NOT return ('not live market data') and directs to alternatives for other needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getDexPoolsAGet 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.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive, but the description adds valuable behavioral context: the tool is keyless, proxies a search endpoint, the old endpoint was removed, field naming changed (volume_usd_24h), the page parameter is superseded by cursor, and wrong dex_name returns empty results rather than an error. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense and well-structured, front-loaded with purpose and then covering use cases, pitfalls, and parameter notes. Each sentence contributes either differentiation, usage guidance, or parameter semantics, though some parameter details duplicate schema info. It's appropriately sized for a 10-param tool with no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return shape ('results' with has_next_page and next_cursor), pagination mechanism, and notable field changes. It covers required and optional params and aliases, making it sufficient for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical semantics beyond the schema: the dex parameter must be the dex_id (not human dex_name), aliases for sort_by/sort_dir, legacy sort field names, and cursor pagination replacement for page. These clarifications prevent common misuse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets pools for one DEX on one network, provides a concrete example (Uniswap v3 on ethereum), and differentiates it from getNetworkPools by noting it's narrower. This satisfies both verb+resource and sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use it ('show me Raydium pools', 'top pairs on PancakeSwap') and distinguishes from getNetworkPools as narrower. It also instructs to get the dex id from getNetworkDexes first, giving clear context and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getNetworkDexesAList 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).
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it is 'Read-only and keyless', describes the response structure (under 'dexes' with page_info), and mentions pagination. This provides useful context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 4-5 sentences, front-loads the main purpose, gives usage examples, then lists parameters compactly. No superfluous information, every sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the output shape (dexes, page_info with page and total_pages). It covers pagination, prerequisites, and connections to sibling tools. Missing no critical context for a listing endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by summarizing parameters with defaults and legacy aliases (sort_by/order_by, sort_dir/sort). This helps the agent understand the parameter relationships and defaults concisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists DEXes on a network, gives specific examples (Uniswap on ethereum, Raydium on solana), and mentions the response structure. It also distinguishes from sibling tool getDexPools by noting that the dex id can be used as input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('which DEXes are on Base?', 'does Solana have Orca?') and prerequisite ('call getNetworks first for the slug'). It also clarifies the scope is a single network and how to use the output with getDexPools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getNetworkPoolsAGet 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).
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, but the description adds 'Read-only and keyless' and describes the response structure (results, has_next_page, next_cursor) and cursor-based pagination, providing useful behavioral context beyond annotations. It does not mention rate limits or error behavior, but this is not a major gap given the safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it states the primary purpose, gives usage examples, differentiates alternatives, and summarizes all parameters in a compact way. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 8 parameters and no output schema, the description covers the main purpose, use cases, parameter semantics, pagination behavior, and response format. It is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds value by summarizing parameters and clarifying canonical names vs aliases (sort_by vs order_by, sort_dir vs sort), which helps the agent choose the correct parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets 'the top liquidity pools across a whole network' and default ranking by 24h volume. It explicitly distinguishes from sibling tools by saying 'Narrow to one exchange with getDexPools, or apply numeric/time filters with getNetworkPoolsFilter.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete example queries ('biggest pools on ethereum', 'top trading pairs on Base') and explicitly names alternatives for different scopes, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getNetworkPoolsFilterAGet 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).
| 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 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds 'Read-only and keyless', clarifies the response shape ('returned under results with has_next_page and next_cursor'), and explains filter semantics ('AND-combined'). These details go beyond the structured annotations and meaningfully inform the agent about behavior and response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense. It front-loads the purpose, then provides usage alternatives, then systematically lists filter and pagination parameters. Every sentence carries actionable information without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by disclosing the response envelope ('results', 'has_next_page', 'next_cursor'). Despite 17 parameters, all are covered in grouped form, and the description mentions required network and default behaviors. It even notes the REST-layer alias nuance, making it complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by grouping filters (volume_24h_min/max, etc.), explaining aliases (sort_by/order_by, sort_dir/sort), setting defaults (limit 50, max 100, sort_dir desc), and describing pagination via cursor. This goes well beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Get pools on one network filtered by numeric thresholds', clearly distinguishing it from sibling getNetworkPools. It further reinforces distinction by naming getNetworkPools explicitly and stating when to choose this tool over it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Choose this over getNetworkPools when the user gives numeric constraints or a time window.' It also gives concrete example queries ('pools over $1M liquidity on Base', 'pools created in the last 24h'), making the use case crystal clear and leaving no ambiguity about when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getNetworksAList 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.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral details beyond annotations: 'Read-only and keyless', 'Returns the full array with no pagination or sorting', and 'takes no parameters beyond a short rationale'. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, front-loaded with the primary action, and every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return structure (network id, volume, txns, pool count) and behavior (full array, no pagination). It also notes authentication status (keyless) and integration guidance. Complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the rationale parameter fully described in the schema. The description only restates that it 'takes no parameters beyond a short rationale', adding no new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List every blockchain network DexPaprika indexes', providing a clear verb and resource. It distinguishes itself from sibling tools by noting it returns network slugs needed by other tools and contrasts with getStats for platform-wide totals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit scenarios are given: 'Start here... to get the exact network slug', 'Use for which chains...', and alternatives are mentioned (getStats). While it doesn't explicitly state when not to use it, the guidance is clear and distinguishes usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getPoolDetailsAGet 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).
| 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') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description confirms read-only and keyless behavior, consistent with annotations (readOnlyHint, destructiveHint false). It adds value by stating 'Returns live values only' and clarifying no authentication needed, beyond what annotations specify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Paragraph is well-structured with clear sections: purpose, usage, alternatives, params. Every sentence adds value; no redundancy. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 params, sibling tools, and no output schema, the description provides sufficient context: explains output shape (single pool object), live values, and when to use each sibling. Complements schema well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description omits the 'rationale' parameter (required). It explains inversed semantics with 'flips the token price ratio to token1/token0' and gives examples for network and pool_address. The missing param reduces completeness slightly, but schema covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets a full snapshot for one pool, lists specific data fields (tokens, price, liquidity, volume, tx counts), and clarifies it returns a single object not a list. It distinguishes from sibling tools like getPoolOHLCV and getPoolTransactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after search/getNetworkPools, for price/TVL/details queries) and when not to use (for historical candles or raw swap feed), naming alternatives. This provides clear context for the AI agent to select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getPoolOHLCVAGet 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; Unix timestamp, RFC3339, or yyyy-mm-dd); end (optional, capped to 1 year after start); interval one of '1m','5m','10m','15m','30m','1h','6h','12h','24h' (default '24h'); limit (default 100, max 366 candles); inversed (optional bool, default false).
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | OPTIONAL: End time for historical data (max 1 year from start) | |
| limit | No | OPTIONAL: Number of OHLCV data points to retrieve (default: 100, max: 366). One row per `interval`. | |
| start | Yes | 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). | |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'Read-only and keyless', plus specific constraints like 'end capped to 1 year after start' and 'max 366 candles', which are not in annotations. This adds useful behavioral context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and behavioral traits, then parameter details. It's efficient and well-organized, though the parameter list makes it somewhat lengthy. Minor room for trimming but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description mentions 'returned as a time-series array' but lacks specifics about the array structure (e.g., keys for OHLCV). For 8 parameters and no output schema, some output details would improve completeness. Still adequate for operational use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds format details (start accepts Unix, RFC3339, yyyy-mm-dd), lists interval enum values, explains inversed, and states limit max (366). These details go beyond schema descriptions to help the agent form correct parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Get historical OHLCV candles...' using a specific verb and resource. It clearly distinguishes itself from the sibling tool getPoolDetails for current price, and specifies use cases like 'price history', 'hourly chart', 'backtesting'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use for price history... for the single current price use getPoolDetails instead.' Provides concrete examples and a clear exclusion, guiding the agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getPoolTransactionsAGet one pool's recent individual swap transactions, newest first, returned under 'transactions' (paginate with page, or a cursor). Read-only and keyless. 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 Unix seconds, inclusive, capped to the last 7 days); to (optional Unix seconds, exclusive, must be after from).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | OPTIONAL: Filter transactions up to this UNIX timestamp (exclusive). Must be after 'from'. | |
| from | No | 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. | |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds that the tool is 'keyless' and mentions the 7-day cap on time-range filtering. It also notes the difference in parameter types between this tool and getPoolOHLCV. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: first sentence states purpose and response format, second distinguishes siblings, third gives use cases, fourth lists parameters. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and differentiates from siblings, but misses the required 'rationale' parameter in its summary. Without an output schema, it would benefit from describing the transaction fields. The description is adequate but has a gap that could lead to missed required input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. However, the description's param summary omits the required 'rationale' parameter, which could mislead agents into thinking it's optional or nonexistent. The description adds minimal new details beyond the schema (defaults, caps) but the omission of a required param is a significant fault.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves one pool's recent individual swap transactions, ordered newest first. It explicitly distinguishes from sibling tools getPoolOHLCV (aggregated candles) and getPoolDetails (summary snapshot), and provides specific use cases like 'recent trades on this pool'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use scenarios ('recent trades on this pool', 'who swapped in the last hour', 'raw transaction feed') and when-not-to-use by naming alternative tools (getPoolOHLCV, getPoolDetails). This clearly guides the agent on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getStatsAGet 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.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description does not need to add much. It confirms 'Read-only and keyless', which adds a slight behavioral detail beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a short usage note. No unnecessary words. Information is front-loaded with purpose, then usage guidelines. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one parameter, no output schema), the description covers purpose, usage, and distinctions. It mentions return type 'single summary object' but lacks details on exact structure. Still sufficient for a simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter (rationale). Description says 'Takes no parameters beyond a short rationale' but does not add additional meaning or context beyond what the schema already provides. Baseline 3 due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it returns platform-wide totals (networks, DEXes, pools, tokens) as a single summary object. It distinguishes from siblings like getNetworks (per-chain) and getCapabilities (onboarding docs). Verb 'Get' plus specific resource makes purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use examples ('how much data do you cover?', total counts) and explicitly tells when not to use it (use getNetworks for per-chain, getCapabilities for docs). Includes alternatives, making guidelines complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTokenDetailsAGet 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).
| 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds 'Read-only and keyless' and describes return format (single token object with price/volume and metadata), providing additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences: front-loads purpose, then usage guidelines, then examples, then params. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only data retrieval tool with 3 required params and no output schema, the description explains return value (single token object with price/volume and metadata), usage examples, and alternatives, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description lists param names with examples for network and token_address, adding a bit of value, but rationale is not covered in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get', resource 'one token's data and metadata', and scope 'by contract address on one network'. Distinguishes from siblings like getTokenMultiPrices and getTokenPools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (price/volume queries, token info) and when not (if only symbol, use search first; for many tokens use getTokenMultiPrices; for pools use getTokenPools). Provides specific query examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTokenMultiPricesAGet 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).
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, idempotent, and non-destructive traits. The description adds 'Read-only and keyless' (no API key needed) and explains that unpriceable tokens appear in 'missing_tokens' list, signaling partial failures. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, output behavior, usage guidance. Front-loaded with the key action and constraints. No fluff, each sentence adds unique value. Could be slightly more structured with explicit sections, but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description details the return structure (prices array, missing_tokens list). Covers partial failures and usage guidance. Parameter list is complete. For a simple fetch tool with good sibling context, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—all parameters have descriptions. The description adds meaning by restating constraints: network is a 'required slug, all tokens must share it', tokens are 'required array of 1 to 10 contract addresses'. This reinforces schema info and clarifies cross-parameter dependency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', resource 'current USD prices', scope 'up to 10 tokens on the same network', and key output details ('prices array plus a missing_tokens list'). It distinguishes from sibling getTokenDetails by specifying the single-token, multi-timeframe alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases: 'prices for these tokens', 'compare the price of X, Y and Z', 'portfolio/dashboard snapshot'. Provides a clear alternative: 'For one token with full metadata and multi-timeframe stats use getTokenDetails'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTokenPoolsAGet 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.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, idempotentHint=true), the description adds key behavioral context: 'Read-only and keyless', unknown addresses return empty results 'not an error', and unsupported parameters (inversed, paired_token_address) 'error'. These details are not in the annotations and give the agent important expectations for edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: it opens with the core purpose, then usage guidance, then a concise parameter summary. Each sentence adds value without redundancy, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters and no output schema, the description covers the essential context: network scoping, pagination fields, sorting options, aliases, and error behavior. The only minor gap is the exact structure of each pool item in 'results', but that is likely inferable and not critical for selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds practical semantics by summarizing required params, defaults, aliases (sort_by/order_by, sort_dir/sort), and explicitly warning about unsupported params that return errors. This goes beyond the schema's descriptions, making invocation more reliable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the liquidity pools that contain a specific token on one network.' It specifies the resource (liquidity pools), the scope (a specific token on one network), and the expected response shape ('returned under results with has_next_page and next_cursor'). It also distinguishes from sibling tools by focusing on token-based lookup rather than network-wide pools or pool details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance with example queries ('which pools hold WETH on ethereum?') and alternatives ('For the token's own price use getTokenDetails'). It advises running search first if the network is uncertain and explains that unknown addresses return empty results rather than errors, helping the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTopTokensAGet 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).
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds the important caveat that sorting by price is unsupported and silently falls back to volume, which goes beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then usage guidelines, then parameter details. Although slightly long, each section earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers response structure (has_next_page, next_cursor), pagination, parameter defaults, and keyless access. For a tool with 8 params and no output schema, this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds value by explaining aliases (sort/order_by) and the silent fallback behavior, exceeding mere schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the top tokens on one network ranked by...' with specific examples, differentiating from sibling tool filterNetworkTokens. The verb, resource, and scope are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use examples ('top gainers on Solana') and precisely identifies the alternative for arbitrary filters ('use filterNetworkTokens instead'). This is ideal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchASearch 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?'. 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).
| 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', 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, non-destructive. The description adds 'Read-only and keyless', explains empty-array behavior instead of errors, and clarifies client-side limiting. This adds useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by supplementary details. A minor improvement could be reducing redundancy about return arrays, but overall it is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and absence of output schema, the description fully covers the return format (three arrays), parameter behavior, usage context, and edge cases (empty arrays). No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing full parameter documentation. The description adds value by elaborating on the query parameter's purpose and clarifying that limit is applied client-side per category, which aids agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool searches across ALL networks for tokens, pools, and DEXes, returning three arrays. It distinguishes itself from network-scoped siblings by positioning as the cross-chain entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use guidance ('when you do not yet know which network something lives on' and specific examples like 'find PEPE'), and explicitly advises switching to network-scoped tools once a network slug is known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submitFeedbackAInspectReport 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.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only false values, placing burden on the description. The description explains that feedback is read by the team and mentions validation constraints, but does not explicitly state side effects (e.g., data storage) or idempotency. It adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the purpose and includes necessary guidance without excessive verbosity. It's concise enough for efficient reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple feedback submission tool without an output schema, the description provides sufficient context: when to use, what to provide, and constraints. It lacks return value description but that's acceptable given the tool's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 each parameter. The description adds semantic value by advising low-friction format: 'provide goal, expected, and observed instead of a rationale field.' This helps agents construct effective feedback.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: reporting problems back to the DexPaprika team when stuck or encountering unexpected behavior. It uses a specific verb ('report') and resource, and distinguishes it from sibling tools that are all data retrieval functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: when a tool gets stuck, returns unexpected results, lacks data, or behaves differently than documented. It also encourages submitting partial feedback and provides format guidance. While it doesn't state when not to use it, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
